I spent almost a decade on software delivery within banks, and I saw the same pattern repeatedly. When something goes wrong in a release, the instinct is to slow down: extend QA cycles, add approval layers, deploy less frequently. But that response often concentrates risk rather than reducing it. Fewer releases mean larger releases, which results in:
- More changes bundled together
- More potential failure points
- A harder recovery when something does go wrong
An unplanned outage in a core banking function generates support tickets, invites regulatory scrutiny, and signals to the market that the bank can't manage change safely. Recovery can't be simple when each deployment brings six weeks' worth of accumulated changes.
Feature flags are how most banks try to escape that trap. By decoupling deployment from release—shipping code to production without exposing it to customers until it's ready—teams can move faster and release more frequently. And when something goes wrong after a feature goes live, a flag gives you an instant kill switch, allowing you to remove the feature from the UI without requiring a redeploy or a full rollback.
But a kill switch is only as useful as the system around it. When nobody knows which flag controls what, who owns it, or whether turning it off will break something else, the tool built to contain incidents becomes a potential source of them.
That's the difference between a feature flag and a feature management (FM) system. A feature flag is the toggle. A feature management system is the infrastructure built around it that makes flags safe to operate at scale in a regulated environment.
There is also a new pressure that makes this urgent. Banks are shipping more code than they used to, and more of it is written with AI assistance, into the same regulated environment. When a regulator asks who authorized a change, “an AI tool suggested it” is not an answer. The faster the team ships, the more the governance gap matters.
In this article, I'll explain where homegrown flag systems often break down, what a feature management system offers that a homegrown tool can't, and what it looks like when banks get feature flag governance right.
Why homegrown flag systems break down
In the early days of feature flag adoption, building a homegrown flag system is an easy decision to justify, even for financial institutions. The initial scope is often small, and a lightweight internal solution is faster to stand up than a procurement process. For a while, it works. Problems arise when a system built as a simple toggle mechanism is asked to do considerably more.
When the safety tool becomes the risk
Many banks running homegrown flag systems don't realize they need more robust governance until compliance issues crop up. Regulators whether OCC, FFIEC, or under DORA in Europe, demand audit trails... and granular approvals that most homegrown systems were never designed to produce.
In a homegrown system, flags accumulate over the years with no clear ownership or history. Nobody knows which flags are still active, which are stale, or what would break if one were turned off.
That's a precarious position for any software team, but for highly regulated institutions like banks, a flag system with no clear audit trail is untenable.
The hidden costs of maintaining a homegrown system
While the costs to build a homegrown flag system are usually minimal, banks can underestimate the ongoing work required to keep it reliable, compliant, and useful as it scales. That maintenance cost has three components that are often overlooked:
Technical debt
Flags accumulate faster than they are retired. Every unresolved flag is a conditional branch that has to be tested around and carried forward into every future release. Over time, the codebase becomes harder to work in.
Engineering burden
As the number of developers, teams, and flags grows, so does the work required to keep the homegrown system functional. What started as a lightweight internal tool now needs to support dozens of developers across multiple teams and environments. Keeping it reliable at that scale is a significant, ongoing engineering investment.
Opportunity cost
Every engineering hour spent extending flag infrastructure, manually pulling together audit records when regulators come calling, or debugging inconsistencies across environments is an hour not spent on the banking features that generate revenue.
How a feature management system addresses these shortcomings
A purpose-built feature management system is designed to handle exactly the problems that homegrown tools accumulate over time. Where homegrown systems lack audit trails, FM systems generate them automatically. Where flag ownership gets lost, FM systems track it clearly. And where maintenance eats into product work, FM systems significantly reduce that burden.
Examples of feature management in practice
Based on my experience working inside banks for almost a decade, here is what the shift from a homegrown flag system to a feature management system looks like in practice, and why the difference matters.
Automatic audit trails
Say a new instant international transfer feature goes live. Shortly after, a rounding error in currency conversion starts causing duplicate debits. The immediate response is to flip the flag off.
But in a regulated environment, that's only half the job. The regulator will want to know who made that change, when, and under whose authorization. A feature management system generates that record automatically as part of the same action that flipped the flag.
Flag ownership and lifecycle
One of the most common things I saw inside banks was a codebase carrying hundreds of flags that nobody fully understood anymore. Flags created years earlier by developers who had since moved on, with no record of what they controlled or whether they were still active. Turning one off felt risky. Leaving it on felt risky, too.
A feature management system addresses this by making ownership explicit from the moment a flag is created. Every flag has an assigned owner, a creation date, and a record of every change made to it. That visibility makes it possible to safely retire stale flags rather than carry them forward indefinitely.
Approval workflows and shared accountability
Homegrown flag systems are rarely built with shared accountability in mind. There's no structured way for the business side to authorize a release decision before it goes live.
An approval workflow changes that dynamic. When a flag change is ready to go live, a business manager signs off before it's released. Engineering makes the change, but the business side authorizes the release. The decision becomes a joint one, and the sign-off is automatically logged.
When I talk to banks now, this is what they want: governance that is part of how releases happen, not a report assembled after the fact. That is also why I work on CloudBees Feature Management. We built it so ownership, approvals, kill switches, and audit trails come standard with the flag system and connect to the pipeline you already run, instead of being one more thing your team has to build and maintain.
