Stop Reporting on the Core. Start Decoupling From It.
The reporting-tool builder is still hostage to its core in every respect; the decoupling-strategy builder has quietly bought its way out.
The Question That Reveals How a Bank Really Thinks About Its Data Layer
Ask a technology leader what their data platform is for, and the answer tells you almost everything about the risk their institution is carrying. If the answer is “reporting” — a place to assemble the numbers the business and the regulator need — then the platform is being run as a convenience, and the aging core banking system underneath it is still absorbing every genuinely new demand the business generates. If the answer is “decoupling” — a deliberate layer that stands between the business and a fragile core — then the institution has understood something its peers usually learn the hard way. The pattern I have observed is that most banks give the first answer while believing they are giving the second, and the gap between the two is where a great deal of avoidable risk lives.
This is a Perspective with a single argument, and it is this: in an institution running an aging, poorly supported core, the data layer’s most valuable role is not reporting but decoupling — deliberately absorbing analytical and informational demand that would otherwise land on the core, so that the business can move forward while the system beneath it is not disturbed. Treated as a reporting tool, the data platform is a cost centre that produces documents. Treated as a decoupling strategy, it is the single most effective way to reduce the operational risk of a core the institution cannot easily replace. Same technology; entirely different intent; entirely different value.
Why Every Demand That Reaches the Core Is a Demand That Carries Risk
To see why decoupling matters, look closely at what happens when a new requirement lands directly on an aging core. The business wants a new view of customer behaviour, a new analytical cut for a regulator, a new feed for a downstream capability. If the only place that data lives is the core, satisfying the requirement means building something new against the core — a query, an extract, an integration, a change. And an aging, poorly supported core is precisely the system where building something new is most dangerous.
The danger compounds for reasons specific to legacy systems. The people who understood the core deeply have often moved on, so change is made with incomplete knowledge of the consequences. The vendor support that would once have de-risked a modification may be reduced or gone. The system’s headroom is finite, and analytical load competes with the transactional processing the bank actually runs on. Every new thing built against such a core adds a small increment of instability to the one system the institution can least afford to destabilise. Individually each increment looks acceptable. Collectively they are how a fragile core becomes a fragile bank.
The cruel arithmetic of a legacy core is that the business’s success generates the demand that threatens it. The more value the institution wants from its data, the more load it places on the system least able to bear it — unless something stands in between to absorb that demand instead.
The Data Layer as a Demand Absorber
That something is the data layer, used deliberately as a demand absorber. The strategy is simple to state and demanding to hold to: get the data out of the core once, into a governed layer built to be worked hard, and then route every new analytical and informational demand to that layer rather than back to the core. The core does one thing — it hands over its data on a controlled, well-understood basis. Everything else the business wants to do with that data happens somewhere the business is free to experiment, to build, and to change without asking whether the core can survive it.
The shift this produces is qualitative, not just architectural. Once the data layer is absorbing demand, the core stops being the place where new capability is built and becomes merely the place where transactions are processed and data originates. New requirements no longer translate into new risk to the core, because they are satisfied against the layer built to take them. The business experiences this as speed — it can have what it needs without waiting for a nervous change to a fragile system — and the technology function experiences it as a dramatic reduction in the frequency with which anyone has to touch the core at all. Reducing the number of times you must modify a system you do not fully understand and cannot easily support is, on its own, one of the highest-value risk reductions available to a bank in this position.
“The goal is not a core that never changes. It is a core that changes only when the business truly requires the core itself to change — and never merely because someone needed a report.”
Decoupling Is a Strategy, Which Means It Must Be Chosen and Defended
The reason most banks give the reporting answer while believing they give the decoupling one is that decoupling does not happen by default. Build a data platform without the decoupling intent and demand will keep leaking back to the core, because in any individual case reaching straight into the core is faster than doing the disciplined thing. A team under deadline extracts directly from the core because the data is not yet in the layer. A new feed is pointed at the core because that is where the data “really” is. Each shortcut re-establishes exactly the dependency the platform was meant to break, and each is nearly invisible at the moment it is taken.
Decoupling as a strategy therefore requires an explicit, defended rule: new demand is served from the data layer, and the core is touched only when the requirement is genuinely a change to core function. Holding that line has a cost — sometimes the disciplined path is slower than the shortcut — and the institutions that succeed are the ones whose leadership understands that the slower path is buying down a risk that the faster path silently accumulates. This is a leadership decision as much as a technical one, because only leadership can insist on the more disciplined route when the expedient one is sitting right there.
The Prize: Optionality on the Core Itself
There is a second, larger benefit to decoupling that is easy to miss when the focus is on day-to-day risk reduction, and it may be the most valuable of all. Once the business’s analytical and informational capability has been genuinely decoupled from the core, the core becomes far easier to replace. A core that has a hundred bespoke analytical dependencies wired directly into it is nearly impossible to migrate, because every one of those dependencies must be found, understood and re-pointed before the core can move. A core whose only real job is to originate data into a governed layer presents a far smaller, far cleaner migration surface.
In other words, the decoupling layer does not just protect the aging core in the present — it earns the institution the optionality to deal with the core on its own timetable. The bank can run the fragile core longer with lower risk because demand no longer lands on it, and it can replace the core more cleanly when the time comes because the business no longer depends on it directly. Both of those are strategic freedoms, and both are unavailable to the institution that built its data platform to write reports. The reporting-tool builder is still hostage to its core in every respect; the decoupling-strategy builder has quietly bought its way out.
The Reframe Worth Insisting On
None of this requires different technology from what a bank building a reporting layer would buy. It requires a different answer to the question of what the thing is for. Held as a reporting tool, the data platform produces documents and leaves the core carrying every new demand the business invents. Held as a decoupling strategy, the same platform becomes the mechanism by which an institution reduces the operational risk of a system it cannot afford to lose and buys itself the freedom to replace that system on its own terms.
The leaders who get the most from their data investment are the ones who stop asking it to report on the core and start using it to become independent of the core. That is the reframe worth insisting on, and it is worth insisting on early — because every requirement satisfied against a fragile core before the decoupling layer is in place is a risk taken that never needed to be taken, and a dependency created that will one day have to be unwound.