Using my book “Rip Out the Core” as a foundation for this discussion, we land on a potentially tighter definition than the industry is used to. Instead of the core being
“the oldest system nobody dares switch off” or
“whatever the vendor brochure says”,
we drew a clear boundary around a small real time engine that services accounts, runs product agreements, and records postings in a contract level subledger. Everything else, customer data, product catalogues, payments, channels, analytics, and the general ledger, lives outside that nucleus, integrated through well defined APIs and events.
This strict definition sparked a great conversation over on LinkedIn. Now it’s time to take the next step in that dialogue and explore what comes after agreeing on a thin core. How do we actually shift towards a thin core, “coreless” banking architecture in practice, and what does that mean for the many ledgers a bank runs.
From One Big Kitchen to a House of Modular Rooms
A core banking system used to be like a giant kitchen that claimed to be the whole house. In decades past, banks poured every functionality into the core, ledger, accounts, payments, customer info, reporting, you name it, all tightly coupled in one monolithic package. That made a certain sense in an era when technology was costly and integration was painful. But today that model is a liability. A single, do everything core becomes a bottleneck for change. It’s as if you designed your entire house around one oversized kitchen. Any renovation anywhere means ripping up the same central floor.
The remedy is to stop building the house around the stove. In other words, we must make the core smaller, sharper and better connected, more like a modular appliance than an entire house system.
Defining a thin core is the foundation. By thin core, I mean the core system only holds what absolutely must be centralised and what absolutely must be right in real time. In practice, that’s the contract execution and its subledger, the running journal of transactions for each account, plus the minimal logic to carry out product rules defined in the specific contracts with the customer and post entries.
We keep that contract runtime small, deterministic and boring.
Money shouldn’t be exciting at the ledger level. A bank’s source of truth for transactions should be dull in the best way, focused on accuracy and stability.
Crucially, this small core is also highly connected via events. It talks to the rest of the enterprise by publishing every significant state change as an event. It listens for commands coming in through clear APIs. Instead of one big tangle of internal calls, we get a chatty little engine in the middle of a big open room. Each service around it, customer management, product catalogue, payments processing, channels, and the rest, does its own job and plugs into the core’s event stream rather than into its database. The result is an architecture where the core is just one part of a larger platform ecosystem, not the whole show.
Think of the bank as a house again.
In a modern smart home, you don’t have one giant appliance that washes clothes, keeps food cold, and plays Netflix for the family. You have a washing machine, a fridge, a TV. Each is excellent at its task. Each is replaceable without gutting the house. All are connected on the home network. The thin core is like the home’s central heating and plumbing. It is essential infrastructure, maintained carefully, but it doesn’t dictate how you decorate the living room or what you cook for dinner. By keeping the core minimal, you gain freedom of movement everywhere else.
The less you cram into the centre, the more freedom you have at the edges.
Ledgers Inside and Outside
Keeping the Books Straight
Focusing the core on the contract subledger has major implications for how we handle ledgers across the bank. In a thin core model, the core platform’s built in ledger, the subledger, records every posting on an account in real time. Deposits, withdrawals, interest accruals, fees. It records them with full detail of timestamp, amount, and the logic applied. This is the authoritative record at the contract level. It’s the thing auditors and regulators love. A complete, sequenced journal of how each customer agreement, an account, a loan, and so on, has evolved, kept safe and consistent by the core.
What the core does not try to be is the enterprise’s general ledger or finance system. Those belong outside the core. In a modern architecture, finance and reporting systems subscribe to the core’s events, for example an “entry booked” event, to update their own ledgers and balances. The general ledger, which aggregates across accounts and products for accounting and compliance, remains a separate system that the core feeds. This separation of concerns is deliberate. The core’s job is to capture each atomic transaction faithfully. Finance’s job is to aggregate, reconcile, and report on the big picture. Mixing those roles in one system caused plenty of pain in legacy environments. Think endless reconciliation exercises every weekend. By aligning ledger types properly, we avoid that pain. The core subledgers stay lean and real time, while the general ledger can do what it does best without slowing down customer transactions.
Keeping ledgers aligned in this way also supports clarity when you inevitably change things. If a bank decides to introduce a new module or an external service, say a separate credit card platform, it’s crucial to designate a system of record for each contract type. You might feed a consolidated finance ledger from multiple sources, but each customer contract should have one and only one place where the authoritative transaction history lives. By nailing down which ledger does what, you gain the freedom to spread capabilities around. Multiple cores and their subledgers can coexist as long as everyone knows which system is the master for a given product or account. Meanwhile, the corporate general ledger simply consumes the outputs.
In short, ledger alignment in a coreless architecture means each level of ledger has a clear role. The core subledger holds granular truth. The enterprise ledger supports financial control. Other specialised ledgers, for risk, treasury, and more, can subscribe to events as needed. This clarity is non negotiable. If you scatter posting logic and balances across a dozen microservices, a vendor black box and a couple of undocumented scripts, you’ll have a nightmare when the auditors come knocking. A coreless approach doesn’t throw ledgers to the wind. It recentres them. You still have a single source of posting truth, but it’s much smaller and it’s defined by business contract, not by an all encompassing software package.
Coexistence Layers
Many Cores, One Customer Experience
Breaking the core into a thin, ledger centric engine raises a practical question. What if you end up with multiple such engines. In fact, embracing a coreless mindset often means you run multiple specialised cores in parallel, by design. A retail bank might use one modern core platform for deposits, another for loans, maybe even a dedicated ledger for credit cards. This is no longer the accidental patchwork of the past, where banks bolted on separate systems because the old core couldn’t handle a new product. Instead, this can be a strategic multi core architecture. Each core is optimised for its domain, all orchestrated under a unifying scheme. Done right, it delivers the benefits of specialisation without losing coherence. But to achieve that, you need a couple of architectural guardrails.
The first is to ensure that having multiple ledgers doesn’t result in a disjointed experience for customers or staff. Practical design patterns for routing and orchestration are critical. Typically, banks introduce an integration hub or a coexistence layer that acts as a traffic cop, directing each request or transaction to the correct core based on rules.
For example, send mortgage account updates to the loan core, deposit transactions to the retail core. This layer also aggregates data from all cores to present a unified view. So, your customer service rep sees one combined picture of the customer, even if behind the scenes five different engines are involved. The customer, similarly, experiences one bank through their app or branch, not a collage of systems.
The second guardrail is clear data ownership. We touched on this with ledger alignment. Each core owns the truth for a given slice of data. When you have multiple cores, you must partition data domains carefully, for example one core is the master for current accounts, another for mortgages, and avoid double booking the same data in two places. If something absolutely must be shared, say customer profile information, designate one system as primary and have others subscribe or reference it. By doing this, a multi core setup can achieve near real time consistency without endless reconciliation, because each piece of information has a home.
Many banks still keep an enterprise data warehouse or lake as a safety net to consolidate everything for reporting, but the ideal is that day to day operations don’t rely on after the fact reconciliation. Instead, events from each core flow into a real time data fabric, and the coexistence layer plus integration middleware ensure that no matter how many ledgers are humming underneath, the bank behaves as one for the customer.
It’s worth noting that core vendors themselves have adapted to this reality.
Modern core banking platforms are being built to either support a coreless, API first model or enable multi core deployments out of the box. For example, some new cloud native cores, like Thought Machine’s Vault, are essentially collections of microservices with an extensible ledger and product engine that integrate via APIs. They provide a strong ledger centric core, but expect you to compose surrounding services, very much in line with the thin core philosophy.
Others, like 10x Banking, pitch themselves as a meta core platform, which can sit above multiple product systems and coordinate them under one umbrella. That effectively acknowledges that coexistence is the norm during transformation.
Even the long standing incumbent vendors are breaking their monoliths into modular components and microservices, allowing phased migrations and parallel runs.
The message across the industry is consistent.
“The era of one mega core doing everything is over”
Banks are increasingly picking best of breed components or multiple ledgers for different needs, and making them work together via well defined interfaces. The thin core and the coexistence layer go hand in hand. Together they turn what could be chaos, lots of systems, into agility. Systems that each do one job well, under orchestration.
Flexibility and Resilience by Design through Platform Banking
Why go through all this architectural effort? You ask.
Because the payoff is flexibility, agility, and resilience.
Qualities that traditional architectures have sorely lacked.
A thin core, event driven, multi component architecture essentially turns a bank into a platform business, giving me the chance to repeat my personal mantra
“The future of banking will be dominated by platforms”
Instead of a single factory line that produces and delivers banking products end to end and grinds to a halt whenever something changes, you get a modular ecosystem of capabilities.
New product idea? You don’t have to rewrite the core. You can develop a new service or plug into a fintech partner’s API.
Spike in volume or a new regulatory requirement? You can scale or swap out the affected module without a year long freeze on every other change.
In a world where unexpected shocks seem to come every year, from pandemic disruptions to fintech upheavals, this model is simply more resilient. If one part fails or struggles, you can address it without bringing the whole bank down for maintenance. If a new opportunity arises, you can plug in a new module or partner in weeks or months, not years, because your core is no longer a tangled ball of every function.
Crucially, this is a business first evolution. We’re not separating ledgers and services just for the fun of it, or because microservices are cool again. We’re doing it so that banks can execute strategy at the speed of software. A platform model bank can reposition itself faster.
Want to enter a new market? If your core and surrounding services are built as a platform, you might launch a new product line by composing existing capabilities and third party services, rather than building entirely from scratch.
Want to offer banking as a service or embed your products in someone else’s ecosystem? An API driven coreless architecture makes that feasible. You expose specific services securely, without giving away the keys to your whole legacy kingdom.
The thin core is what makes this nimbleness possible, because it ensures that the parts of the bank that differentiate, customer experience, partnerships, analytics, specialised products, aren’t cemented into a rigid core. They live out in the ecosystem where they can evolve rapidly. Meanwhile, the parts that must not fail, the ledger and contract execution, remain rock solid and governed, but they’re kept intentionally narrow to avoid becoming a change bottleneck.
Think of it this way.
A coreless banking architecture is really about discipline. It’s about each component knowing its job. The core’s job is trust. Balances right to the penny, transactions executed correctly, on time, every time.
The surrounding platform’s job is innovation. Try new features, connect with partners, learn from data, delight the customer. By decoupling these, you actually get a more innovative bank and a safer bank at the same time.
You gain agility without trading off stability. In an uncertain future, that combination is gold. Banks face fast moving competitors, evolving regulations, and customers whose expectations are shaped by the latest app they download.
It’s an environment where, often, inaction is the riskiest strategy and clinging to a monolith is a recipe for getting left behind.
A platform approach with a thin core gives you optionality. It’s a bit like having a blueprint that can accommodate change. You build with an assumption that new rooms will be added to the house or old ones renovated over time. When something big changes, be it a new technology, a new regulation, or a new competitor, your bank can adapt by adjusting modules rather than tearing out foundations again.
What Happens When Customers Bring Their Own Bots with Agentic AI
There’s another reason to pursue this modular, platform first model, and it’s coming at banks fast.
The growth of Agentic AI and the rise of intelligent agents are knocking on the door, and do not just take my word for it. According to McKinsey “AI agents are poised to make sophisticated money decisions for customers, reshaping banking and affecting billions of dollars in revenue.”
We’re on the cusp of an era when customers might not interact with their bank through traditional channels at all. Instead, they’ll use AI driven assistants, bots, to manage their finances. In such a scenario, a customer’s AI might handle everything from shopping around for the best loan rates, to moving money between accounts for optimal interest, to negotiating fees or executing savings rules, all on the customer’s behalf. It sounds futuristic, but we’re already seeing the early signals. Voice assistants and chatbots are evolving from simple Q and A machines to action taking agents. Apps are exposing more APIs for integration. Fintechs are building “self driving money” features that automate financial decisions.
What does this have to do with coreless banking?
Everything!
If your architecture is modular and open, built on APIs and events, then an AI agent can interact with your bank much like a human could, querying balances, initiating transactions, assembling services, only faster and more intelligently.
In a platform model bank, this is a huge opportunity.
Your bank can become the orchestrator or participant in an AI driven ecosystem. For example, a customer might have an AI financial adviser that connects to your lending API, a third party investment platform, and a couple of bank accounts.
That AI could seamlessly move money or refinance something with you if your systems play well with others.
If you’ve embraced coreless principles, that’s a win. You can plug into these agent driven value chains, exposing just the services and data that make sense, securely and in real time.
If, however, your bank is a closed monolith, you’re going to be sidelined. A bot isn’t going to patiently fill out forms on a 1970s green screen terminal or wait for an overnight batch update. It will route around friction.
We can easily imagine that future customers might not “open a banking app” at all. They’ll tell their AI assistant what they need, and it will dynamically find and use the services of whatever institutions fit the task. Banks that provide easy digital hooks into their capabilities will have a shot at that business. Those that don’t, won’t even know they missed it.
Even on the operations side, agentic AI pairs naturally with a coreless architecture.
With clear domains and data streams, a bank can deploy AI agents internally to automate routine decisions and workflows. Think AI ops bots watching the event stream for anomalies, or compliance bots auto checking transactions. The event based design of a coreless system means there’s a rich flow of information that AI can latch onto to make real time judgements. The modular design means the AI can even take action by invoking APIs. Say, triggering a micro service to handle a customer request it just parsed from a voice interaction.
In a tightly coupled core, such AI integration is much harder.
Everything is locked away in one big box, and the AI ends up like an outsider trying to break in.
In a platform setup, the AI is more like an integral part of the ecosystem and not an external observer trying to follow along.
An agent that can mix and match services.
This is why moving to a platform model is often described as moving from a manufacturing mindset to a distribution mindset in banking.
You stop thinking of your bank as the sole factory for products behind high walls, and start thinking of it as a set of capabilities that can be distributed, combined, and consumed in many ways. Human customers will consume some of those capabilities directly via great user experiences. Increasingly, AI agents will consume them invisibly on behalf of customers. Being ready for that future is a strategic consideration today, not tomorrow.
Building for a Coreless Future
None of this is easy. Let’s not sugar coat it.
Transforming decades of legacy core banking into a thin core, API and event rich platform is as much a cultural and organisational journey as a technical one. It requires banks to rethink siloed teams, to invest in new skills, and to possibly embrace new business models.
But as I often remind colleagues, inaction is riskier than action at this juncture.
The cracks in the old model are showing, and the speed of change is only accelerating.
The good news is that we now have a blueprint, and increasingly, real world examples, for how to do it pragmatically.
Start with a clear definition of core. Enforce strict boundaries around it. Peel off surrounding capabilities into manageable domains. Introduce coexistence layers to keep things coherent. Gradually modernise piece by piece.
It’s a journey, one my upcoming book Rip Out the Core is all about, not a one off project. But every step, each capability you decouple or each ledger you align correctly, is a step towards a more adaptable bank.
In a way, the journey to coreless banking is like renovating that old house to be future proof.
You might start by upgrading the plumbing, getting the core ledger in order, then knocking down a wall to create an open floor plan, integrating through events, then adding new rooms as your needs grow, plugging in new services or even new cores.
Throughout, you keep the water running and the lights on for the family, because banks, like homes, can’t just shut down for a year. Eventually, you end up with something that hardly resembles the cramped house you started with. It’s more like a platform with a roof, extensible, reconfigurable, resilient. Most importantly, it’s a house that can welcome new inhabitants like AI agents or ecosystem partners without collapsing.
So, is coreless banking worth it?
Absolutely!
But as a means to an end.
That end is a bank that can actually keep up with, or even get ahead of, whatever the future throws at it, be it a new fintech trend, a new regulation, or a generation of customers who think about finance in a completely new way.
The thin core is a means to give your institution a strong spine and a flexible body. The various ledgers, properly aligned, form the circulatory system that keeps information flowing wherever it needs to go. The platform architecture provides the organs and muscles that let you run, adapt, and create. And the brain. The “brain” of tomorrow’s bank might not be a piece of software at all. It might be an AI, or millions of them, working in concert with your platform. If you’ve built your bank right, that prospect isn’t scary. It’s exciting.
Clarity of definition was our first conversation, knowing what the core is and isn’t.
Now we see how that clarity enables a broader transformation.
By keeping the core tight and letting the ecosystem expand around it, we position ourselves for a future where change is the only constant. Whether that change comes from tech innovation, market disruption, or customers bringing their own intelligent agents, a coreless bank, a bank built as a platform, can embrace it. In the end, the core was never meant to be the whole house.
By remembering that, we can finally stop mopping the floor and start redesigning the house for the next century of banking.
Stay tuned for more insights on this journey. In my book Rip Out the Core, A Practical Path to Coreless Banking, I dive deeper into the methods and real world examples of making this transition. Until then, keep questioning the old assumptions and imagine what your bank could do when it’s freed from the chains of a monolithic core.
