Architecture-First Thinking Makes Modernization Less Risky
Finding a safe path to growth through architectural clarity
Most banking modernization conversations don’t start with that stated goal.
They start with a need to meet a customer demand, an expired contract, or a broken system.
Senior leaders know something has to change. Customers expect more: seamless, personalized experiences; instant transactions; interactions that make them feel understood and valued. Rail innovation and AI evolution are accelerating the entire ecosystem. Regulators are asking sharper questions as they navigate the implications. Boards want confidence, not experimentation.
At the same time, every path forward for financial institutions feels risky.
And the age-old choice of “wait and see”, while uncomfortable, at least feels safe.
So leaders do what prudent leaders do.
They make decisions that seem reasonable.
A Reasonable Decision That Increased Exposure
In 2018, TSB Bank approved a core banking migration as part of its separation from Lloyds. The decision followed years of planning, multiple board-level reviews, and third-party project audits. On paper, it looked disciplined and well governed.
The outcome was very different. The platform experienced immediate technical failures, outages, and fraud activity, that locked millions of customers out of their accounts and resulted in ~£50 million in fines. The CEO resigned.
The point of this story is not that the decision was unreasonable.
It wasn’t.
It was pragmatic. And that is what made the risk harder to see.
This Pattern Is Familiar
Most institutions have their own version of this story.
Not dramatic failures, but smaller ones.
A capability added to solve a real business problem or customer need
A workaround introduced to buy time until a long-term solution can be implemented
A one-off control embedded inside a product or channel
A decision that made sense locally, at the time
Over time, these choices accumulate.
A bank wants to introduce a real-time capability: faster fraud checks, a more personalized experience, or instant payments.
Because the core operates in batch, the solution is to add a third-party service that maintains its own real-time view of customer and account data. It works. So it scales.
Over time, more use cases require the same pattern. Fraud, payments, experience, onboarding. Each capability pulls a localized, near-real-time extract of core data. Some live inside the institution. Others live with third parties.
No single decision creates the problem. But collectively, the institution now has multiple versions of “real time,” scattered across its ecosystem.
The result is not just operational complexity. It becomes harder to change vendors, harder to modernize the core, and harder to understand which systems hold authoritative data.
What began as a practical way to move faster becomes an architectural constraint that limits how safely the institution can evolve.
No one chooses to build a patchwork ecosystem.
It’s the result of years of compounding choices.
Choosing the status quo increases your risk and limits your choices.
But so does taking action without architectural clarity.
Why Adopting Instant Payments Seems Risky
When institutions adopt instant payments, many start with “receive only” as a way to limit exposure.
But without architectural clarity around fraud, liquidity, and control, that starting point often becomes a ceiling rather than a phase.
Boards ask whether systems like RTP or FedNow expose financial institutions to more risk. Real-time settlement removes the ability to delay or “leisurely” review a transaction. Liquidity buffers shift from generous cushions to dynamic, intraday management. With 24/7 continuous settlement, low-probability, high-impact tail events feel inevitable.
The concern that a sudden, massive outflow could occur is understandable.
But that’s not the point.
Instant payments do not introduce new risk.
They eliminate the time delay.
And that delay was actually where much of the risk was hiding.
It masked fragmented systems.
It absorbed coordination gaps.
It acted as an informal control.
Speed did not introduce new risks into the system.
It removed a control mechanism institutions had been relying on without realizing it.
When that time lapse disappears, architecture and explicit risk controls must take its place.
What Remains Unspoken
Many issues raised in board conversations trace back to historical architectural decisions. Taken together, they can feel overwhelming
Funding volatility under 24/7 real-time settlement
Reluctance to move away from 30-40 year old core technology, reinforced by stories that 60-80% of core migrations fail
Concern that Shadow AI and “vibe coding” used to bypass slow internal processes may create security vulnerabilities or expose confidential information
Technology bloat consuming nearly 40% of IT budgets, increasing cyber and data vulnerabilities, complicating compliance, deepening 3rd party dependency, and slowing innovation
Temporary shortcuts that have become permanent liabilities
These are not standalone issues.
They are signs that decisions, data, and control are fractured across the organization, embedded in products, channels, and one-off projects.
Risk has been managed locally.
Growth is happening globally.
That disconnect is where exposure compounds.
Where Transformation Actually Becomes the Safer Path
Transformation does not become safer by slowing everything down.
It becomes safer when institutions are clear about where control lives as speed increases.
Growth becomes safer when:
Decisions are not trapped inside individual products or channels
Data is not fragmented across systems that cannot act in real time
Controls are not depending on delay and manual intervention
Learning and insights are managed centrally instead of being lost locally
This is not an argument for replacing all systems.
This is not a call to accelerate transformation.
It is a recognition that thoughtful architectural choices can mitigate these risks.
Growth becomes safer when architecture, not urgency, determines where control is managed.
The Leadership Question That Matters
This article is not about how to modernize.
It is about how to see what is already happening.
A strong leader should be able to answer one question clearly:
Do we know where real-time decisions are managed today,
and can that discipline scale as growth accelerates?
If you can’t answer that question, the risk you are worried about is not transformation.
It is control being embedded by default rather than by design.
About the Author
Marcia Klingensmith is the Instant Payments Maven™ and a global strategist helping financial institutions navigate payments modernization with clarity, confidence, and disciplined risk management. She works with senior leaders to surface second- and third-order impacts across architecture, liquidity, fraud, and governance as instant payments and emerging technologies compress time and increase complexity.
#thefutureisnow #instantpaymentsmaven
Exceptional framing on how batch delay functioned as an implicit control layer. The shift from time as a safety buffer to explicit architectural controls is the exact inflection point where most institutions hesitate. In my experience, boards see real-time settlement risk but miss that their current systmes already carry that exposure, just hidden behind processing windows and overnight reconciliation.