Why feature flags in a bank are production changes
A feature flag in a bank can change which customers see a payment route, what a transfer limit is, or whether a new applicant can finish onboarding, and it can do this in seconds without a deployment. That makes the flag a production change in its own right. It needs the same approval, evidence and data location controls as any other system that moves money or decides on customers. The short answer on platforms is that GrowthBook, Unleash and Flagsmith each fit different parts of that requirement, and the choice turns on which controls the bank must be able to prove to its auditors and supervisors.
Banks differ from SaaS and ecommerce teams in what a flag change leaves behind. The change record is evidence. Under DORA, Regulation (EU) 2022/2554, which has applied since 17 January 2025 to 20 types of financial entity, the ICT services behind flag evaluation belong in the register of information required by Article 28(3), and each ICT contract must state where data is processed under Article 30(2). Targeting attributes such as account tier, segment, region or risk band are customer data, so the evaluation service and its telemetry must sit where the bank's data rules allow. On the audit side, SEC Release 33-8810 names program changes and access to programs and data as IT general control areas, so a toggle that changes a financially relevant system will be tested much like a code release.
Start by listing which flags touch a financially relevant system, a cardholder data path or a customer decision, and treat that list as the scope for change control. For each platform, confirm three things in writing before you select one: whether approval workflows, SSO with SCIM and advanced permissioning are included in the edition you will run, whether evaluation and attribute data can stay in your own EU or national region, and how audit logs are exported and retained. GrowthBook's pricing page lists approval workflows, SSO with SCIM and advanced permissioning under self-hosted Enterprise, and the free self-hosted Open Source plan does not include them, so those controls carry a licence cost to plan for. Ask Unleash and Flagsmith for the same answers. PCI DSS v4.0.1 applies where flags can affect the cardholder data environment, so include those flags in the assessment scope.
Which rules shape a flag platform in financial services
This table maps the rules most likely to reach a flag or experimentation platform at a bank or fintech to what each one asks for and what it means for the build. Read it as a list of questions to take to your compliance and audit teams, because none of these sources certifies a flag tool. The main takeaway is that the obligations attach to the organization and its contracts, so the flag platform must be able to produce evidence for them.
| Requirement | Source | What it means for the build |
|---|---|---|
| Register of ICT contractual arrangements | DORA Article 28(3) | If the flag platform supports an important function, record the contract, provider, hosting location and sub-processors in the register. Confirm whether self-hosting removes the vendor from scope for your entity. |
| Documented, tested exit strategy | DORA Article 28(8) | Keep flag definitions, targeting rules and experiment history exportable in open formats, and test a restore into a second environment before go-live. |
| Contract terms on location and data return | DORA Article 30(2) | Where a vendor hosts the platform, the contract must state processing locations, advance notice of changes and data return on termination. Self-hosting keeps location under your control, but document it anyway. |
| Scope of entities covered | DORA Article 2(1), points (a) to (t) | Covers 20 types of financial entity, from credit and payment institutions to insurers and crypto-asset service providers. Confirm your entity type with counsel before scoping the change controls. |
| Program changes and access to programs and data | SEC Release 33-8810, IT general control areas | Flag toggles that change financial systems may be assessed as program changes. Keep approvals, segregation of duties and access reviews for the flag console and its roles. |
| MFA for any user of an information system | FTC Safeguards Rule, 16 CFR 314.4(c)(5) | Require MFA or SSO for every console user and admin account, or record a written approval of an equivalent control from the Qualified Individual. |
| Cardholder data environment scope | PCI DSS v4.0.1 | If flags or experiment payloads touch cardholder data or could affect that environment, the platform falls in scope. Keep card fields out of targeting attributes and confirm scope with your QSA. |
| Swift Customer Security Controls Framework | Swift CSP v2026, 32 controls (26 mandatory, 6 advisory) | Applies only if you are a Swift user. Confirm which controls cover the flag host and its administrators, then plan independent assessment and the annual KYC-SA attestation. |
When a flag toggle counts as a production change
A flag toggle is a production change when it alters what a financial system does for a customer or for the books. A flag that changes a credit decision threshold, a displayed fee, a fraud rule or a payment route modifies a system that supports financial reporting or a critical function, even though nobody redeployed code. The bank therefore needs a written list of which flags are in scope, usually defined by the business process and the system they touch rather than by the tool that stores them. Confirm this list with internal audit and the owners of credit, payments and fraud before the first production flag is created, and tag each in-scope flag so it can be filtered in reviews and evidence requests.
Once a flag is in scope, the change needs the same controls as a code release. The person who requests a change to a payment route or fraud rule should not be the person who approves it, and the approver should not hold rights to flip the flag in production without that approval being recorded. The SEC guidance on internal control over financial reporting, Release 33-8810, names program changes and access to programs and data as example IT general control areas, so both the approval workflow and the role model in the flag platform are evidence an assessor will sample. Ask the vendor or implementation partner which roles can request, approve and publish, and whether approval workflows are included in the edition you plan to run.
The audit log must show who changed what, when, and from which value to which value, for every environment. Confirm that the platform records changes to targeting rules, rollout percentages and environment settings, not only flag creation, and that logs are exported to storage the bank controls and retained for the period its policies require. Test this before go-live by making a sample change in a non-production environment and tracing it through the approval record, the log entry and the exported copy. Where the bank's programs are subject to other frameworks, the same trail also supports change management evidence in the wider control environment.
Which open-source platform fits a regulated flag program
GrowthBook publishes a clear edition split that makes it a useful reference point for a regulated flag program. Its LICENSE file states that code outside its enterprise directories is MIT Expat licensed, while the enterprise directories fall under the GrowthBook Enterprise License. The self-hosted Open Source plan is free with unlimited users, but it is limited to one project and does not include the controls a bank usually needs for change governance.
- Open Source edition scope: Unlimited users and one project, with no approval workflows, SSO, SCIM or advanced permissioning.
- Enterprise edition scope: Self-hosted Enterprise adds SSO and SCIM, advanced permissioning, approval workflows, safe rollouts and holdouts, under the GrowthBook Enterprise License.
- Licensing split: The enterprise directories are separately licensed, so a bank that modifies those paths needs counsel to review the obligations.
- Pricing model: The published Enterprise tier is quoted on request, so the cost depends on the written scope and seat count.
Confirm with GrowthBook which Enterprise features are included in the self-hosted agreement, and request the license terms in writing before shortlisting.
Unleash is a candidate for a flag program that needs a self-hosted control plane with strong separation between environments. The bank should not assume that its change request, approval and audit log features are available in every edition. Those features need to be checked against current Unleash documentation for the exact edition and version being evaluated, because edition boundaries can change between releases.
- Change requests: Confirm whether change requests and scheduled approvals are part of the edition under consideration, and whether they can be enforced per environment.
- Approvals: Verify whether approvers can be required by role, and whether a requester can be prevented from approving their own change.
- Audit logs: Confirm what events are recorded, how long they are retained in the product, and whether they can be exported to the bank's log store.
- SSO and provisioning: Check which identity protocols and user provisioning options are included in the self-hosted edition.
- Licensing: Review the license terms of the edition in use with counsel before deployment.
Request a written feature matrix for the edition and version under review, and test each control in a non-production environment before relying on it as evidence.
Flagsmith is another self-hosted option that banks may shortlist. As with other candidates, the decision depends on which edition supplies the governance features the bank needs, not on the open-source core alone. Treat the feature list as something to verify with the vendor for the specific version and deployment model, rather than as a settled comparison.
- Governance features: Confirm whether approval flows, change requests and environment-level permissions are available in the self-hosted edition under review.
- Access control: Check role-based access, SSO support and whether user management can be driven from the bank's identity provider.
- Audit trail: Verify which configuration changes and user actions are logged, the log format, and whether logs can be forwarded to a central system.
- Edition boundaries: Map each required control to a specific edition, and record that mapping in the procurement file.
- Licensing: Have counsel review the open-source license and any commercial terms before the bank adopts the self-hosted build.
Ask the vendor to demonstrate approvals, SSO and audit log export in a test tenant, and keep the demonstration output as part of the evaluation record.
Keeping customer attributes used for targeting inside the bank
Targeting rules are where customer data leaves the bank without anyone deciding it should. A rule that sends premium offers to customers in a given region, with a given product holding or risk tier, carries personal data in every evaluation request. Under GDPR, those attributes are personal data whether or not they are labeled as such in the flag console. The first decision is to list every attribute a flag or experiment rule reads, classify it, and decide which ones may be evaluated inside the bank's environment. Risk tier and product holdings usually belong in the second group, so treat them as restricted fields from the start.
Local evaluation in the SDK is the main pattern for keeping attributes inside the environment. With the flag service hosted in the bank's own cloud account or data center, the application's SDK can evaluate rules against attributes held in the application process, so the attribute values need not be sent to a remote evaluation endpoint. Confirm with each vendor whether its SDK supports local evaluation for every rule type you need, including segments and percentage rollouts, and whether any rule type falls back to a server call. Also check what the SDK sends in telemetry, such as event payloads, exposure logs, or SDK version and error reports, and whether those payloads include the attribute values or user identifiers. Ask for the telemetry behavior in writing and test it against a network capture in a non-production environment.
For experiments, GrowthBook's documented pattern keeps the analysis where the bank's data already sits. It queries the bank's own warehouse or database, runs only SELECT queries, and transmits only aggregated statistics back to the GrowthBook service, according to its data source documentation. Confirm with the vendor and your data team that no row-level records, identifiers or attribute values are written to the GrowthBook metadata store, and that the self-hosted deployment does not call out to external services for statistics. Record the answers as part of the data flow diagram that your privacy and third-party risk teams review before go-live.
How a bank rolls out flag governance in phases
A bank should not switch on approvals, audit logs and targeting data for every flag at once. The phases below build the flag inventory first, then the controls, then the evidence, so each step produces something an auditor or change manager can test before the platform carries customer-facing decisions.
Inventory flags and business owners
List every flag, experiment and targeting rule in the current estate, including those set by hand in code or config files. For each one, record the business owner who can answer for its effect, the systems it touches and the environments where it is live. Flags with no named owner are the first finding to resolve, because change approval depends on knowing who decides. Ask the platform team to confirm whether the flag inventory can be exported with owner metadata before this phase starts.
Classify flags by impact
Group flags by what they can change: payment routing, pricing, eligibility, fraud or limit checks, customer-facing content and internal tooling. High-impact flags that alter financially relevant systems need approval, segregation of duties and logged changes. Low-impact flags can follow a lighter path. Document the classification rules in writing so that a flag's tier is set by its effect, not by the team that created it, and review the tiers when a flag's scope changes.
Design editions, approvals and roles
Decide which platform edition provides the approval workflows, advanced permissioning and SSO that the classification needs. For GrowthBook, the self-hosted Open Source plan does not include approval workflows, while the self-hosted Enterprise plan does, so confirm the feature list against the current pricing page and the licence terms before design. Define roles that separate those who request a change, those who approve it and those who deploy it.
Integrate identity and the role model
Connect the flag platform to the bank's identity provider so that people sign in with corporate accounts, and map platform roles to the same joiner, mover and leaver process used for financially relevant systems. Confirm whether SCIM provisioning is available in the chosen edition so that access removal follows HR changes. Test that a user who leaves the bank loses approval rights and that role changes are themselves logged.
Pilot on non-customer-facing flags
Run the first approvals, logs and deployment steps on internal tooling flags and non-customer-facing experiments, where a wrong change has limited customer impact. Use the pilot to confirm that a toggle creates a change record, that the approver is recorded, and that the audit log shows the before and after state. Keep a written list of what the pilot did not cover, such as customer attributes used for targeting, so it is not mistaken for proof of the full process.
Build the evidence pack and test controls
Before wider use, assemble the evidence an assessor will sample: the flag register, classification rules, approval records, role assignments, access reviews and sample audit log extracts. Have internal audit or the control owner test a sample of changes end to end, and record exceptions and remediation. Auditors and supervisors decide whether the controls are effective. DeployOpen prepares the controls and evidence for that assessment but does not issue the conclusion.
Evidence auditors and supervisors ask for from flag tooling
This table maps the evidence a bank or fintech should expect an auditor or supervisor to request for production flag changes and experiments, who typically asks for it, and which part of the flag stack produces it. DORA sets no certification scheme, so the evidence is assessed by independent auditors and supervisors against the controls the organization documents, not against a DORA badge a vendor can provide.
| Evidence | Who asks | Which component produces it |
|---|---|---|
| Approval records for production flag changes | Internal audit, SOX auditors for financially relevant systems | Change request workflow with approver identity and timestamp, which the Enterprise editions of the flag platform may provide (confirm with vendor) |
| Access reviews for flag admins | Internal audit, information security, SOX IT general controls assessors | Identity provider group exports and the platform's role and permission listing, reviewed on a set schedule |
| Change logs with actor and timestamp | External auditors sampling flag toggles, incident responders | Platform audit log for each flag, with exports shipped to the bank's central log store |
| DORA register entry for the flag vendor or hosting provider | Competent authority supervisors under DORA Article 28(3) | The bank's ICT third-party register, recording the self-hosted platform and any hosting or support provider with service locations |
| Exit plan for the flag vendor or hosting provider | Supervisors reviewing DORA Article 28(8) exit strategies | Documented export of flag definitions and tested restore into an alternate environment, with transition steps written in advance |
| Experiment result records | Model risk and product governance reviewers, auditors checking decisions tied to customer outcomes | Experiment analysis output with metric definitions, dates and frozen configuration, kept in the bank's data environment |
What banks ask before they self-host flags
What does a self-hosted feature flag project cost a bank?
The cost is set mostly by scope, not by the software itself, because the open-source editions are free to run. Cost components are the infrastructure your team runs in its own cloud or data center, the implementation work (planning, configuration, identity and approval integration, data source connections), internal staff time for control owners and engineers, and ongoing support and upgrades. The main drivers are the edition you need, the number of flags and environments in scope, how many systems the flags connect to, and whether production hosting must meet your resilience standards. The free self-hosted GrowthBook Open Source plan includes unlimited users but one project, while the self-hosted Enterprise tier adds SSO and SCIM, approval workflows and sticky bucketing. Ask any implementation partner for a quote that lists one-time and recurring items separately, and state which edition each line assumes.
How long does a bank flag platform rollout take?
Duration depends on how many systems are in scope, how many existing flags or experiments must be migrated, and how many approval and control reviews the bank runs before go-live. A rollout limited to a few non-customer-facing services is much shorter than one that covers payments, onboarding and pricing flags with audit evidence required from day one. Migration from a commercial tool adds time because importers rarely carry over every advanced setup: GrowthBook's LaunchDarkly importer documentation warns that some advanced configurations are not handled, and the application still has to switch SDKs after import. Timelines should be written into a fixed-scope agreement, with the phases, owners and acceptance criteria stated before work begins.
What must the bank's team provide before implementation starts?
Several inputs must be ready early, and most delays come from missing ones. You need named control owners who approve flag changes and can answer audit questions, a decision on how engineers and approvers authenticate (usually your existing identity provider with role-based access), and read access to the data source used for experiment analysis. You also need an inventory of the customer attributes that targeting rules will use, so the team can confirm they stay inside your infrastructure. Finally, you need a change management owner who can map flag changes to your existing production change process. Agree on who signs off each input in the written scope.
Can our internal engineers run a self-hosted flag platform alone?
Some banks run it entirely in-house, and that works when the team already operates Kubernetes, managed databases and an identity provider, and has capacity for upgrades and security patching. The harder parts for a regulated bank are not the installation: they are the approval workflows, segregation of duties, audit log retention, backup and restore testing, and the evidence that a control operated as designed. Internal teams often underestimate the ongoing work of keeping the platform patched and documented. An implementation partner can plan, configure, harden, document and support the platform inside your environment, while your staff keep ownership of the change decisions. Decide the split of responsibilities explicitly before choosing the model.
Is a free self-hosted edition enough for a bank?
The free edition is enough for some uses, such as internal experiments with no approval requirements, but most bank deployments need features outside it. The GrowthBook pricing page lists approval workflows, SSO and SCIM, advanced permissioning and sticky bucketing as Enterprise features for self-hosted installs, and the free Open Source plan includes one project. Before deciding, check whether the free tier provides the change requests, approvals and audit trail your change process requires, whether role separation meets your access policy, and whether the license terms allow your intended internal use. Confirm the current edition feature list directly with the vendor, since editions change.
How does DORA apply to a self-hosted flag tool?
DORA applies to the financial entity's ICT third-party arrangements, and self-hosting does not remove those obligations. Even when you run open-source software yourself, any implementation partner or hosting provider is an ICT service provider, so the contract should state where services are provided and data processed, with advance notice of changes, and cover data return on termination. Article 28(3) requires the arrangement to appear in your register of information, and Article 28(8) requires documented, tested exit strategies for services that support critical or important functions. Ask your legal and third-party risk teams to review the contract terms and the register entry before go-live.
Questions to ask an implementation partner before signing
Start with change management, because it decides whether a flag toggle can be audited at all. Ask the partner to show, for a sample flag change in a non-production environment, how the change is raised, who approves it, where the approval is recorded and how the change reaches production. Ask whether the chosen edition provides change requests and approval workflows natively, which the GrowthBook pricing page places in its self-hosted Enterprise tier, or whether the partner will build that control around the open-source edition. Confirm the edition name, license terms and feature list in writing, because edition features change between releases.
Next, ask how approvals and segregation of duties are configured in practice. Request the role model: who can create a flag, who can edit targeting rules, who can approve a production change and whether any single account can do more than one of these. Ask how SSO and SCIM provisioning connect to the platform's identity provider so that leavers lose access automatically. For logs, ask where audit records are stored, whether they are written to a separate store the flag administrators cannot edit, how long they are retained and how the bank retrieves them for an auditor's sample. Retention periods should come from the bank's own policy, not the vendor's default.
Then ask where targeting attributes live. Customer attributes used for targeting should be evaluated inside the bank's infrastructure, and the partner should show the data flow for each SDK, including whether evaluation is local or remote and what telemetry leaves the network. Finally, ask how the partner supports DORA documentation. Under Article 28(3) the bank needs the ICT contract in its register of information, and under Article 30(2) the contract must state where data is processed. Ask for the exit strategy and data return procedure required by Article 28(8) and Article 30(2), and ask how the fixed scope, deliverables and handover are written into the statement of work before work starts.
How DeployOpen scopes and supports flag governance for banks
Flag governance for a bank is set up once, then maintained for years. DeployOpen plans, implements, hardens, documents and supports self-hosted flag platforms inside the client's own cloud accounts, data centers or air-gapped networks, under a scope agreed in writing before work starts. The cards below cover what that scope includes and where responsibilities stay with the bank.
Fixed scope agreed in writing
Most engagements are fixed-scope, so the platform edition, environments, integrations, identity model, approval rules and acceptance tests are written down before work begins. For a bank, the scope should name which flags count as production changes and which teams can approve them. Ask the partner to list every deliverable and what is excluded, since exclusions are where change requests and audit log exports often get lost.
Hardening and self-hosted deployment
DeployOpen deploys the flag platform in the bank's own infrastructure, then hardens it for production use. This covers network placement, access to the database that holds flag definitions, secrets handling for SDK keys, and backup and restore for the metadata store. Confirm with the partner which hardening steps follow the bank's own baseline and which are new controls that need owner sign-off.
Control design and evidence preparation
DeployOpen prepares the controls and evidence that a bank's internal audit or external assessor will sample: approval records, role assignments, change history and configuration exports. DeployOpen does not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies, so the bank should agree in advance which evidence packs will be produced and who signs off on them.
Documentation and handover
Runbooks, architecture records, role matrices and the flag lifecycle procedure are written as part of the engagement and handed to the bank's operations and security teams. Ask whether the documents are kept in the bank's own repository and whether they cover the steps for disabling a flag during an incident, rotating SDK keys and restoring the platform from backup.
Retainers for ongoing support
After go-live, upgrades, security patches, backup verification and access reviews continue. DeployOpen offers these as retainers, which are separate from the fixed-scope build. Ask what the retainer covers for releases, how upgrades are tested in a non-production environment first, and how response to a production incident is handled, including who the bank contacts out of hours.
How quotes are built
DeployOpen does not publish a price list. A quote follows from the written scope, so the bank should give the partner its environment count, integration list, data residency requirements and evidence expectations before asking for one. Compare quotes on the same scope definition, and confirm which items are one-time work and which recur under a retainer.
