The COBOL apocalypse conversation this week has been useful, because it has forced the industry to confront something it has been avoiding for decades. But most of the coverage is stopping at the wrong point. Everyone is talking about COBOL. Nobody is talking about the architectural philosophy that COBOL gave birth to, the one that outlived the mainframe, survived the client server era, made it through the cloud revolution, and is still being sold to banks today with a straight face.

Core banking. The idea that you can package every conceivable banking function into a single platform, run it as a monolithic system, and call that an architecture. It was a reasonable compromise when banking was about cutting a cheque once a month and buying a house every twenty years. It is a completely useless approach to solving modern banking needs, and the fact that it has persisted this long is one of the most remarkable examples of institutional inertia in the history of enterprise technology.

This is a companion to my earlier article on the COBOL announcement that shook IBM’s stock price. That piece was about the death of COBOL as a moat. This one is about the death of the architectural philosophy that COBOL created, and why that second death is the one that actually matters.

1. Where Core Banking Came From

1.1 The Original Problem Was Real

To understand why core banking became so entrenched, you need to go back to where it started. The first computerised core banking systems emerged in the late 1960s and early 1970s, built in COBOL and running on IBM mainframes. The business problem they were solving was genuine and significant: banks had enormous volumes of transactions to process, they were doing it manually or with primitive automation, and they needed centralisation, speed, and reliability.

1.2 A Pragmatic Solution for a Narrow World

The solution was a single centralised computer that handled everything. Account management, transaction processing, interest calculation, fee charging, regulatory reporting, all of it in one place, in one codebase, with batch processing that ran overnight. Transactions were processed in groups at end of day because that was the technical reality of the hardware. Intraday balances required workarounds. The system was only accessible during banking hours. These were not design choices made out of laziness. They were pragmatic responses to the constraints of 1970s computing.

And it worked. For the banking reality of the 1970s, it worked extremely well. A customer visited one branch. They had a current account and perhaps a savings account. They wrote cheques. They took out a mortgage once in their adult life. The entire relationship was narrow, predictable, low volume, and slow moving. A batch processing system that updated balances overnight was entirely adequate for that world. The monolithic architecture made sense because the problem it was solving was genuinely monolithic.

1.3 When the Compromise Became the Convention

The architectural sin came later. It came when that original pragmatic compromise got packaged up, sold as a product, extended by vendors across decades, and eventually canonised as the correct way to build a bank’s technology. The compromise became the convention. The workaround became the standard. And by the time the banking world had changed beyond recognition, the core banking system had become too embedded, too expensive, and too complex to dislodge.

2. The Stuck Thought That Refuses to Die

2.1 How the Monolith Started to Fracture

By the 1980s and 1990s, banking had already changed enough that the monolithic core was showing its limitations. Banks were adding credit cards, mortgages, foreign exchange, investment products. Each of these added specialist systems, often with their own ledgers, their own data models, their own business logic. The monolith started to fracture, not by design but by accretion, as new modules were bolted onto an architecture that was never designed to accommodate them.

2.2 Vendors Responded by Building Bigger Monoliths

Vendors responded by building larger monoliths. Temenos, Oracle FLEXCUBE, Finacle, SAP Banking; these systems attempted to consolidate the sprawl by packaging more and more functionality into a single platform. The pitch was compelling: one vendor, one contract, one system of record, one throat to choke. For a generation of technology leaders who had lived through the nightmare of integrating dozens of incompatible specialist systems, the appeal was understandable.

2.3 The Cost of Change Became Prohibitive

But the packaging created a new problem. These systems were so comprehensive, so interconnected, and so deeply embedded in a bank’s operations that they became impossible to change without enormous risk and cost. Upgrading a core banking system became a multi year programme. Configuring a new product required navigating hundreds of interdependent parameters. Adding a feature that the vendor had not anticipated required either a costly customisation that would be deprecated in the next release, or a multi year wait for the vendor roadmap to catch up with the business need.

The result was that the rigid coupling of product features and core systems became inadequate, while the complexity protecting those systems kept growing. Banks found themselves in a situation where the cost of change was so high that they simply stopped changing. Instead they wrapped the core in middleware, built APIs around the edges, and told themselves that digital transformation was happening while the fundamental architecture underneath stayed frozen.

2.4 The Gap Between the Front Door and the Engine Room

Look at the screenshot below. This is an Oracle FLEXCUBE drawdown screen, the kind of interface that bank operations staff use every day in institutions that run major corporate and syndicated lending books. It is not a screenshot from 1998. This is the actual class of interface that was active in Citibank’s operations in August 2020.

The screen is a form with unlabelled fields, cryptic component codes (COLLAT, COMPINTSF, DEFAUL, DFLFTC), checkbox columns with ambiguous headers, and no affordance whatsoever to indicate what selecting a given combination of options will actually do to real money. In the Citibank case, a contractor attempting to process a routine interest payment on the Revlon term loan instead initiated a full principal repayment of roughly $900 million dollars, to the wrong counterparties, with no confirmation step capable of catching the error before it cleared. Citibank recovered most of it after a long legal battle. They did not recover all of it.

This is not a UI design failure. It is an architectural one. The reason the FLEXCUBE interface looks the way it does is that it is trying to expose the full configurability of a system designed to handle thousands of product permutations across every banking function imaginable, through a single generalised screen. The monolith underneath has no concept of what a specific transaction is supposed to do in plain language terms. It has parameters. The operator maps parameters to intent. When that mapping is wrong, the transaction executes exactly as configured, not as intended.

A domain driven architecture inverts this. A payments domain knows what a principal repayment is. It has a specific workflow for authorising it. It has explicit confirmation gates appropriate to the size and type of transaction. It cannot be accidentally triggered by checking the wrong box on a generalised parameter screen because the operation exists as a named, typed, validated function rather than as a configuration state. The modern app on the customer’s phone and the modern interface on the operator’s screen share the same design philosophy because they are both built on top of systems that understand what they are doing. The engine room matches the front door.

The FLEXCUBE screenshot is not an embarrassing historical artefact. Banks running Oracle FLEXCUBE, Temenos T24, and Finastra Fusion are operating interfaces like this today, in production, across their most sensitive wholesale and retail operations. The Citibank incident was the moment the industry glimpsed what operational risk looks like when the complexity of a monolith is projected directly onto the people responsible for operating it.

3. Why the Monolith Cannot Serve Modern Banking

3.1 Modern Banking Has Different Problems

The problems modern banking needs to solve are completely different from the problems of 1970. A customer today might interact with their bank hundreds of times a month, not once. They expect real time balances, instant payments, instant lending decisions, personalised product recommendations, seamless integration with third party services, and the ability to open a new product in under two minutes. They expect the bank to know them across every product and every channel simultaneously. They expect changes to the product to happen in days, not years.

None of these requirements can be met by a batch processing system designed to update balances overnight. None of them are well served by a monolith where changing one component requires testing the entire system. None of them benefit from packaging every banking function into a single platform that can only scale vertically and can only be deployed as a whole.

3.2 The Monolith Cannot Serve Different Masters

The reason this distinction matters is not academic. When you force domains with fundamentally different characteristics into a single architectural model, you end up optimising for none of them and constraining all of them.

Payments needs to scale horizontally and instantly. On a major public holiday, payment volumes can spike to ten times normal load with almost no warning. In a monolithic core, scaling payments means scaling everything; the lending engine, the regulatory reporting module, the customer identity system, all of it, because they share infrastructure, share databases, and share deployment pipelines. You are paying to scale components that do not need to scale because the architecture cannot distinguish between them. And when the scaling event ends, you cannot scale down selectively either.

Lending has the opposite problem. A lending decision engine benefits from rich customer data, complex scoring models, and the ability to iterate rapidly on decision logic as credit conditions change. In a monolithic core, changing the lending decision model requires a change to the core system. That means a change freeze, a full regression test cycle across every function the monolith owns, a release management process designed for a system where everything is coupled to everything else. A lender who wants to tighten credit criteria in response to a deteriorating macroeconomic signal cannot do it in a day. They wait for the next release window.

Regulatory reporting needs something different again: a complete, immutable, auditable record of every state change in the system, queryable across arbitrary time ranges, accurate to the transaction. A monolith that was designed for operational speed is not designed for this. The data model optimised for processing transactions is rarely the data model optimised for reconstructing the history of those transactions for a regulator. Banks running monolithic cores typically solve this by building a separate reporting warehouse that ingests data from the core and tries to reconstruct an audit trail after the fact. That warehouse is always slightly wrong and everyone knows it.

Three domains, three completely different technical requirements, one architecture serving all of them badly. That is not a coincidence. It is what happens when the architecture is selected for comprehensiveness rather than fit.

3.3 What Domain Driven Architecture Actually Enables

What serves these requirements is a domain driven architecture where payments is a domain, lending is a domain, identity is a domain, notifications is a domain, and each of these domains owns its own data, exposes its own APIs, publishes its own events, and can be scaled, deployed, and changed independently of every other domain. When the payments domain needs to handle ten times the usual volume on a public holiday, it scales without touching the lending domain. When the product team wants to iterate on the lending decision engine, they do it without a change freeze on the rest of the bank. When regulatory requirements change the way identity must be handled, that change is contained to the identity domain rather than rippling through a monolith in unpredictable ways.

A domain driven architecture treats each of these as an independently deployable unit with clear ownership and explicit interfaces. Domains talk to each other by publishing events that other domains can consume, or by exposing APIs that other domains can call. They do not share databases. They do not share code. They own their own data and are responsible for keeping it consistent. When a domain changes, it publishes a new event schema or a new API version, and the downstream consumers can upgrade on their own schedule.

3.4 The Clean Sheet Answer

Here is the most telling evidence that core banking as an architectural philosophy is obsolete: virtually every new bank built in the last decade has explicitly rejected it.

Monzo and Starling built around domain driven design and event driven architecture from the ground up. They did not choose this approach because it was fashionable. They chose it because when you are starting from a clean sheet, building a monolithic core banking system is obviously the wrong answer to the problems you are actually trying to solve. The pattern works. It has been proven at scale. The only remaining argument for the monolithic core is switching cost and organisational inertia, and those are not architectural arguments.

4. The Vendor Trap

4.1 The Proposition and Its Hidden Costs

The core banking vendor market deserves its own examination, because it has been one of the primary mechanisms through which the stuck thought has perpetuated itself.

The major core banking vendors have built extraordinarily successful businesses on a straightforward proposition: banking is too complex for you to build yourself, so buy our platform and we will handle the complexity for you. For smaller and mid tier banks without large technology organisations, this proposition was often correct. The cost of building and maintaining a custom core was prohibitive, and the vendor platform, for all its limitations, was more reliable than what the bank could build in house.

But the proposition came with hidden costs that only became apparent over time. Implementation took years. Customisation was expensive and fragile. Upgrades required the kind of programme management that consumed entire technology departments. The vendor roadmap moved at the vendor’s pace, not the bank’s.

4.2 The Dependency Deepens Over Time

Most critically, the more deeply a bank embedded itself in a vendor’s platform, the more expensive it became to ever leave. This is the architectural equivalent of the MIPS pricing problem. Just as MIPS pricing gave IBM leverage over every new workload a bank wanted to run, core banking vendor contracts give those vendors leverage over every new product a bank wants to launch. The bank becomes dependent not just on the platform but on the vendor’s interpretation of what banking should look like, what products should be possible, what data models should exist. The vendor’s architecture becomes the bank’s architecture by default, and the bank’s ability to differentiate on technology becomes increasingly constrained.

4.3 The Complexity Moat Is by Design

The vendors know this. Their licensing models, their implementation dependencies, their proprietary data formats are all optimised to make the cost of leaving feel higher than the cost of staying. The limitations of the packaged approach have become undeniable but the switching costs have made change feel impossible. It is a very sophisticated form of the same complexity moat that COBOL built around the mainframe.

5. The Question Nobody in the Room Ever Asked

5.1 The Wrong Question, Asked Expensively

Here is what continues to baffle me about the generation of banking technology leaders who ran these programmes. Somewhere in every one of those core banking replacement journeys, there was a room full of smart people, expensive people, people with decades of enterprise software experience, and collectively they convinced themselves that the central question they needed to answer was: which vendor can replace my current mess with a different vendor’s mess?

5.2 The Requirements Document as a Form of Self Harm

Think about what that process actually looked like. A bank assembles a requirements document. That requirements document runs to hundreds of pages. It covers every feature, every workflow, every edge case, every regulatory obligation, every reporting requirement, every integration point the current system handles, and then, for good measure, it adds everything the business has ever wanted but never got. The team spends months on it. Consultants bill handsomely for it. It becomes a definitive statement of what the bank wants from its technology for the next twenty years.

And at no point in that process does the penny drop that writing a twenty year feature wishlist for a monolithic vendor platform is itself a form of institutional self harm. The very act of producing that document is an admission that you have outsourced your architectural thinking to a sales catalogue. You are not designing a technology strategy. You are shopping.

5.3 The Quote Arrives and Nobody Asks the Hard Question

Then the quotes come in. The implementation is going to take three years, minimum. The risk profile is enormous. The cost is tens of millions of dollars before a single client sees any benefit. The programme will consume your best people, freeze your change pipeline, and create the kind of organisational stress that makes good engineers leave. And somewhere in that moment, in every single one of those programmes, someone should have stood up and asked the question that apparently nobody ever did: what is in this for our clients?

Not for the vendor. Not for the compliance team. Not for the CIO who wants a modern system on their CV. For the clients.

5.4 Better MIS Is Not Client Value

The honest answer to what the programme delivers for clients is, in almost every case: nothing they will ever see.

Better MIS reports. Slicker ETL. A compliance model that does not require a spreadsheet army to maintain. Internal dashboards that no longer require a PhD to operate. These are real improvements. They are not nothing. But they are improvements the client will never encounter, never feel, and never benefit from in any direct way.

The standard defence is that operational resilience is client value. That a bank which cannot see its own positions clearly will eventually harm its clients through failure, mis-selling, or collapse. That argument is not wrong. But it proves too little. Operational resilience justifies modernising your reporting layer. It does not justify a three year programme, tens of millions of dollars, and a change freeze across your entire product organisation; and then delivering the same products, at the same price, through the same channels, to clients who were unaware anything had changed.

The clients were going to get the same products, at the same price, with the same service model, through the same channels. The account was still going to be the account. The loan was still going to be the loan. The three year programme, the tens of millions of dollars, the organisational disruption; all of it was being spent on internal plumbing dressed up as transformation.

5.5 The Uncomfortable Question That Was Never Asked

This is what makes the entire core banking replacement era so difficult to defend in retrospect. The industry hired armies of technologists, built enormous internal capability, and then concluded that the highest and best use of that capability was to manage the procurement of vendor platforms. The talent was real. The investment was real. The output was a new set of vendor dependencies that looked marginally more modern than the old ones and came with an implementation trauma that took years to recover from.

If that talent had been directed at building domain capability instead of managing vendor relationships, the outcome would have been categorically different. But that would have required someone in the room to ask the uncomfortable question: why are we paying all these people if the answer is always to pay a vendor to do the actual work?

6. The Exquisite Pain of the Core Banking Upgrade

There is a particular kind of suffering in enterprise technology that has no equivalent elsewhere in the industry. It is the core banking upgrade. And if you have never lived through one, you cannot fully appreciate the combination of expense, duration, risk, and ultimate anticlimax that defines the experience.

A typical core banking upgrade programme runs three to five years. It consumes hundreds of millions of dollars when you account for implementation partners, internal resource, parallel running, testing infrastructure, and the inevitable scope creep that accompanies any programme of this complexity. It occupies the attention of the most senior technology leadership in the organisation for its entire duration. It generates a programme governance structure so elaborate that the governance itself becomes a full time job. It dominates board reporting, risk committee agendas, and regulator conversations for years at a stretch.

And then it goes live. And the very best outcome, the outcome the programme director dreams about, the outcome that gets celebrated with a quiet internal announcement and a cautious all staff email, is that nobody noticed. Not the customers. Not the operations teams. Not the regulators. The system behaves exactly as it did before, processes the same transactions, produces the same outputs, and the only visible change is that the version number in the admin console has incremented.

That is the success case. Three years. Tens of millions of dollars. New leadership, because the old CTO either burned out or was quietly moved on sometime around year two. And the headline achievement is: we did not break anything.

The business case that justified the programme spoke of future capability. Once on the new platform, the bank would be able to launch products faster, integrate with partners more easily, respond to regulatory changes with less pain, and unlock features from the vendor roadmap that the old system could not support. Some of those things materialise. Many of them do not, or materialise so slowly that the business opportunity they were meant to serve has already been captured by someone else.

Because here is the uncomfortable truth about the features you were going to unlock after the upgrade: if a customer wanted them badly enough, they left before you finished the programme. The customers who stayed either do not care about those features, have adapted their behaviour around their absence, or are locked in by switching costs of their own. You spent three years and a hundred million dollars catching up to a market position you should have held five years ago, in a world that has moved on since then.

The cruelest part is the competitive dynamics. When a major bank announces a core banking replacement programme, the correct response from every competitor is quiet celebration. Not because you wish them ill, but because you know what is coming. That bank is about to disappear into an internal programme for three to five years. Their best technology people will be consumed by the upgrade. Their ability to ship new products will be constrained by change freezes. Their senior leadership will be distracted. Their risk appetite will contract because nobody wants a major incident during a core migration. They will emerge on the other side with a swollen balance sheet, exhausted teams, and technology leadership that has largely turned over, and they will need another year just to rediscover what they were doing before the programme started. During their upgrade cycle the bank will have essentially gifted all of their competitors an uncontested market space.

This is the final indictment of the monolithic core banking model. It does not just constrain your architecture. It periodically forces you to consume enormous organisational energy in programmes whose best case outcome is standing still, while your competitors who made different architectural choices are shipping features every sprint. The upgrade treadmill is not an accident. It is a structural consequence of the architecture, and it will not end until the architecture changes.

7. The Replacement Trap

The question, then, is what to do about it. And this is where the industry has consistently chosen the wrong answer.

When a bank decides to replace its core banking system, it produces a requirements document. That document captures everything the current system does, everything the business has wanted but never received, and everything compliance has been asking for since the last major programme. It is a comprehensive statement of what the bank needs from its technology for the next twenty years. The selection process that follows evaluates vendors against that document. The winning vendor is the one whose platform covers the most requirements at an acceptable cost with a credible implementation track record.

Notice what has just happened. The bank has selected a new system based on its ability to replicate the functional footprint of the old one. The selection criterion is comprehensiveness. The winner is the most capable monolith available. The bank has spent eighteen months and several million dollars in consulting fees to procure a more modern version of the architectural problem it was trying to escape.

Ripping out one monolithic core and replacing it with another, even a genuinely more capable one, does not change the fundamental constraint. The constraint is not the age of the technology. The constraint is the architectural model: a single system that owns all the data, embeds all the business logic, and must be deployed, upgraded, and changed as a whole. A newer monolith has a cleaner codebase and a more modern API layer. It has exactly the same properties that will make it unmovable in fifteen years. You will be having this conversation again. The vendors know this. It is not a flaw in their business model. It is the business model.

The problem is not the technology. The problem is the decision to package every banking function into a single platform and call that an architecture. No amount of re-platforming resolves that decision. It only defers the reckoning.

7.1 The Strangler Fig Is the Only Approach That Consistently Works

The right approach is to strangle the core incrementally, building new capabilities on modern domain architecture alongside the existing system, migrating workloads progressively, and shrinking the footprint of the legacy core until it either becomes so small that replacement is trivial or its remaining functions are so well isolated that they can be maintained indefinitely without constraining everything else. This is the strangler fig pattern applied to banking, and it is the only migration approach that consistently produces good outcomes at acceptable risk.

7.2 Why the Argument Keeps Getting Ignored

The reason this argument has been ignored for so long is partly organisational and partly commercial, and partly something more primitive than either.

The organisational problem is that incremental transformation is harder to fund and harder to explain to a board than a single big programme. A “core banking replacement” is a project. An “incremental domain migration” is a journey with no obvious end date, and boards are more comfortable writing cheques for projects than journeys. But that framing only explains the governance mechanics. It does not explain the appetite for it, the genuine enthusiasm that intelligent people bring to these programmes. That comes from somewhere else.

Everyone wants to be at the big reveal. The go live. The moment the new system takes over and the old one is switched off forever. There is a ribbon cutting energy to a major core banking replacement that a decade of quiet domain migration can never replicate. Careers are built around it. It has a name and a programme board and a war room and a launch date. It is the kind of thing you put at the top of your CV and describe in keynotes. The people running these programmes are not stupid and they are not cynical. They genuinely believe in the transformational moment. They want to be the ones who finally fixed it.

The problem is that technology is not a rehabilitation programme. You do not get ill, go to rehab, come out cured, and return to normal life. Banks that treat core banking replacement as rehab are back in the same room five years after go live, wondering why the new system is already calcifying, already accumulating the technical debt that made the old one unbearable, already generating the requirements document for the next replacement. The cycle is not a coincidence. It is what happens when you try to solve a continuous problem with a discrete event.

Technology change is an infinite game. There is no big reveal. There is no moment at which the architecture is finished and the organisation can declare victory and go home. The neobanks that built domain driven architectures did not do it in one programme. They did it continuously, deploying changes daily, evolving domain boundaries as the business changed, treating the architecture as a living thing that requires constant attention rather than a project that can be completed and closed. That is not a less exciting way to run technology. It is the only way that actually works.

The commercial dimension reinforces this dynamic, and it does not require conspiracy to explain. The vendors who benefit most from large replacement programmes are the same vendors with the most presence at industry events, the most investment in thought leadership, and the most seats at the tables where technology strategy gets discussed. They do not need to coordinate. They just need to keep showing up, sponsoring the conferences, funding the research, and making the case for the kind of programmes that happen to be good for their revenue model. A vendor whose business depends on large implementation programmes has no commercial incentive to sell you a philosophy of incremental continuous change. The big reveal is very good for their business. The infinite game is not. The result is an industry conversation that is shaped, without anyone necessarily intending it, by the organisations with the most to gain from the status quo.

8. The Objections That Miss the Point

8.1 The Wheelchair Argument

There is a class of objection to the domain migration argument that surfaces reliably in every serious conversation about replacing COBOL and core banking systems. It goes something like this: AI will never replicate the performance of those undocumented hand optimised assembly routines that the COBOL engineers wrote to extract maximum throughput from the mainframe. Therefore AI cannot replace COBOL.

This objection is technically accurate and entirely irrelevant. It is the equivalent of arguing that electric vehicles cannot replace combustion engines because an electric motor cannot replicate the precise combustion dynamics of a finely tuned V8. You are not trying to replicate the V8. You are trying to move people from one place to another, and electric motors do that better by most measures that actually matter.

The assembly optimisation objection assumes that the goal is to take the existing system and make AI run it faster. It is not. The argument in this article; and the argument the neobanks proved in practice; is that you do not start with a wheelchair and strap a rocket to it. You build something that was designed from the beginning to go fast. A domain built specifically to process payments at scale, running on modern hardware, with a data model designed for throughput rather than retrofitted from 1972, does not have the same performance constraints as a COBOL batch processor. It does not need to replicate the assembly tricks because it does not have the architectural problems those tricks were invented to solve.

The question is not whether AI can match the performance of a hand optimised mainframe routine. The question is whether a modern domain architecture can meet the actual performance requirements of a modern bank. The answer to the second question has been demonstrated conclusively. The answer to the first question is irrelevant to anything anyone is actually trying to build.

8.2 The CAP Theorem Objection

The other objection that follows closely is the distributed systems consistency argument. ACID transactions are impossible on distributed systems. You cannot have the same transactional guarantees across domain boundaries that you have inside a monolith. Therefore domain driven architecture cannot replace a core banking system.

This one has the additional quality of being technically outdated.

ACID compliance within a single domain is not meaningfully different from ACID compliance within a monolith, because a well designed domain owns its own data store and processes its own transactions with full consistency guarantees. The complexity arises at domain boundaries, in operations that span multiple domains, and this is where the objection has historically had some validity.

What the objection misses is that this is a solved architectural problem, and has been for years. Saga patterns manage distributed transactions across domain boundaries by breaking them into a sequence of local transactions with compensating transactions for rollback. Event sourcing provides an immutable audit log of every state change, giving you the historical consistency that regulators require without forcing every domain to share a database. Eventual consistency, applied correctly to the parts of a banking system where it is appropriate, is not a concession. It is a design choice that matches the actual consistency requirements of the operation in question.

Not every banking operation requires synchronous ACID consistency across the entire system. A payment confirmation can be issued once the payments domain has committed its local transaction and published its event, even before the downstream ledger domain has processed that event. The money has moved. The question is only how quickly all systems agree that it has moved, and modern distributed systems close that window to milliseconds.

The banks that raise the CAP theorem objection as a reason not to migrate are not grappling with a genuine technical constraint. They are using a theoretical framework to avoid a difficult organisational decision. The constraint is not the theorem. The constraint is the willingness to make the transition.

8.3 The dual-book problem

You don’t need to run two books. The migration strategy isn’t a lift-and-shift of the book of record — you leave the existing ledger exactly where it is and use its own APIs to post debits and credits while you extract business logic and products out into separate domains incrementally. The core banking system becomes a dumb ledger temporarily, not something you have to replicate in parallel. The regulatory complexity argument collapses because you’re not running two books — you’re re-routing product logic while the same ledger of record continues to serve as the source of truth throughout. The UBS/Credit Suisse situation is actually a perfect illustration of what not to do: that was a forced, wholesale client migration across incompatible platforms under acquisition pressure. Domain extraction from a living system is a fundamentally different problem.

8.4 Neo-banks only doing the easy parts

Scale before complexity is rational product sequencing, not a ceiling. And neo-banks are already tackling things that universal banks genuinely struggle with: BNPL, crypto custody and rails, advanced payment infrastructure, real-time cross-border settlement. These aren’t simple — they’re just differently complex. Low-frequency, high-complexity products like commercial lending, mortgages, and IB aren’t being ignored; they’re next. When neo-banks get there, they’ll apply the same decomposed, domain-driven architectural philosophy they’ve already proven at scale — which gives them a structural advantage over incumbents who’ve been bolting those products onto monolithic cores for decades.

9. The Moment That Changes the Calculation

9.1 AI Dissolves the “Understanding Is Too Expensive” Argument

The AI announcement that rattled IBM’s stock this week is relevant to this argument in a specific and limited way. The claim that AI can compress the COBOL analysis phase from months to weeks is also a claim that it can compress the domain decomposition analysis of a core banking system. The same capability that traces data flows and business logic dependencies across hundreds of thousands of lines of COBOL can produce the domain boundary map that has historically cost millions in consulting fees before a single line of new architecture is written.

This matters because one of the most durable objections to domain driven migration has been that understanding what the current system actually does is itself prohibitively expensive. Nobody alive knows the full behaviour of a system built over forty years. The documentation is wrong or missing. The institutional knowledge has retired. The only way to know what the monolith does is to run it and watch it, which means the analysis phase alone is a multi year programme before migration even begins. If AI genuinely compresses that phase by an order of magnitude, it removes the single most credible technical objection to starting.

The hard problems remain hard. Data migration, regulatory validation, parallel running, cutover risk, the organisational change management required to shift a bank’s operating model from vendor dependency to domain ownership — none of that gets easier because a language model can read COBOL faster. But the argument that the problem is too complex to even understand clearly has just become significantly less convincing.

9.2 The Honest Conversation Cannot Be Deferred Indefinitely

For technology leaders at established banks, the variables are now shifting in a way that makes continued deferral harder to justify. The neobanks have moved from proof of concept to proven at scale — Monzo and Starling are no longer experiments, they are operational competitors with cost structures and change velocities that the monolithic architecture cannot match. AI is reducing the cost of understanding the problem. And the regulatory environment in most major markets is moving toward open banking requirements that a monolithic core serves badly and a domain architecture serves naturally.

The question is not whether the transition to domain driven banking architecture will happen. The neobank evidence has settled that. The question is whether established banks will lead that transition or react to it after competitors have used it to take market position they cannot recover.

Every year of continued dependency on a monolithic core is a year in which the cost of the eventual transition grows, the competitive gap widens, and the argument for delay gets slightly weaker. The switching cost is real. It has always been real. But it is not a permanent barrier. It is a cost that compounds the longer it is avoided.

9.3 The Architecture Reflects the Belief

The deepest reason core banking persisted is not technical and not commercial. It is a belief, held by successive generations of banking technology leaders, that banking is too complex and too regulated to be built any other way. That belief was never correct. It was a rationalisation that the vendors reinforced because it was commercially useful to them, and that technology organisations accepted because it released them from the responsibility of building genuine architectural capability.

The neobanks disproved it. They built domain driven banks, at scale, under the same regulatory frameworks, with teams a fraction of the size of the technology organisations at major incumbents. They did not discover a secret. They simply refused to accept the premise that the only architecture available to a bank was the one the vendors were selling.

The monolithic core had its era. That era was the 1970s. The question worth asking now is not how to replace it with a better monolith. It is how to build a bank whose architecture reflects what banking has actually become, rather than what it was when the architecture was first designed.

Andrew Baker is Chief Information Officer at Capitec Bank. He writes about enterprise architecture, banking technology, and the future of financial services technology at andrewbaker.ninja.

1. What Are Stablecoins?

Stablecoins are a type of cryptocurrency designed to maintain a stable value by pegging themselves to a reserve asset, typically a fiat currency like the US dollar. Unlike volatile cryptocurrencies such as Bitcoin or Ethereum, which can experience dramatic price swings, stablecoins aim to provide the benefits of digital currency without the price volatility.

The most common types of stablecoins include:

Fiat collateralized stablecoins are backed by traditional currencies held in reserve at a 1:1 ratio. Examples include Tether (USDT) and USD Coin (USDC), which maintain reserves in US dollars or dollar equivalent assets.

Crypto collateralized stablecoins use other cryptocurrencies as collateral, often over collateralized to account for volatility. DAI is a prominent example, backed by Ethereum and other crypto assets.

Algorithmic stablecoins attempt to maintain their peg through automated supply adjustments based on market demand, without traditional collateral backing. These have proven to be the most controversial and risky category.

2. Why Do Stablecoins Exist?

Stablecoins emerged to solve several critical problems in both traditional finance and the cryptocurrency ecosystem.

In the crypto world, they provide a stable store of value and medium of exchange. Traders use stablecoins to move in and out of volatile positions without converting back to fiat currency, avoiding the delays and fees associated with traditional banking. They serve as a safe harbor during market turbulence and enable seamless transactions across different blockchain platforms.

For cross border payments and remittances, stablecoins offer significant advantages over traditional methods. International transfers that typically take days and cost substantial fees can be completed in minutes for a fraction of the cost. This makes them particularly valuable for workers sending money to families in other countries or businesses conducting international trade.

Stablecoins also address financial inclusion challenges. In countries with unstable currencies or limited banking infrastructure, they provide access to a stable digital currency that can be held and transferred using just a smartphone. This opens up financial services to the unbanked and underbanked populations worldwide.

2.1 How Do Stablecoins Move Money?

Stablecoins move between countries by riding on public or permissioned blockchains rather than correspondent banking rails. When a sender in one country initiates a payment, their bank or payment provider converts local currency into a regulated stablecoin (for example a USD or EUR backed token) and sends that token directly to the recipient bank’s blockchain address. The transaction settles globally in minutes with finality provided by the blockchain, not by intermediaries. To participate, a bank joins a stablecoin network by becoming an authorised issuer or distributor, integrating custody and wallet infrastructure, and connecting its core banking systems to blockchain rails via APIs. On the receiving side, the bank accepts the stablecoin, performs compliance checks (KYC, AML, sanctions screening), and redeems it back into local currency for the client’s account. Because value moves as tokens on chain rather than as messages between correspondent banks, there is no need for SWIFT messaging, nostro/vostro accounts, or multi-day settlement, resulting in faster, cheaper, and more transparent cross border payments.

If a bank does not want the operational and regulatory burden of running its own digital asset custody, it can partner with specialist technology and infrastructure providers that offer custody, wallet management, compliance tooling, and blockchain connectivity as managed services. In this model, the bank retains the customer relationship and regulatory accountability, while the tech partner handles private key security, smart-contract interaction, transaction monitoring, and network operations under strict service-level and audit agreements. Commonly used players in this space include Fireblocks and Copper for institutional custody and secure transaction orchestration; Anchorage Digital and BitGo for regulated custody and settlement services; Circle for stablecoin issuance and on-/off-ramps (USDC); Coinbase Institutional for custody and liquidity; and Stripe or Visa for fiat to stablecoin on-ramps and payment integration. This partnership approach allows banks to move quickly into stablecoin based cross-border payments without rebuilding their core infrastructure or taking on unnecessary operational risk.

3. How Do Stablecoins Make Money?

Stablecoin issuers have developed several revenue models that can be remarkably profitable.

The primary revenue source for fiat backed stablecoins is interest on reserves. When issuers hold billions of dollars in US Treasury bills or other interest bearing assets backing their stablecoins, they earn substantial returns. For instance, with interest rates at 5%, a stablecoin issuer with $100 billion in reserves could generate $5 billion annually while still maintaining the 1:1 peg. Users typically receive no interest on their stablecoin holdings, allowing issuers to pocket the entire yield.

Transaction fees represent another revenue stream. While often minimal, the sheer volume of stablecoin transactions generates significant income. Some issuers charge fees for minting (creating) or redeeming stablecoins, particularly for large institutional transactions.

Premium services for institutional clients provide additional revenue. Banks, payment processors, and large enterprises often pay for faster settlement, higher transaction limits, dedicated support, and integration services.

Many stablecoin platforms also generate revenue through their broader ecosystem. This includes charging fees on decentralized exchanges, lending protocols, or other financial services built around the stablecoin.

3.1 The Pendle Revenue Model: Yield Trading Innovation

Pendle represents an innovative evolution in the DeFi stablecoin ecosystem through its yield trading protocol. Rather than issuing stablecoins directly, Pendle creates markets for trading future yield on stablecoin deposits and other interest bearing assets.

The Pendle revenue model operates through several mechanisms. The protocol charges trading fees on its automated market makers (AMMs), typically around 0.1% to 0.3% per swap. When users trade yield tokens on Pendle’s platform, a portion of these fees goes to the protocol treasury while another portion rewards liquidity providers who supply capital to the trading pools.

Pendle’s unique approach involves splitting interest bearing tokens into two components: the principal token (PT) representing the underlying asset, and the yield token (YT) representing the future interest. This separation allows sophisticated users to speculate on interest rates, hedge yield exposure, or lock in fixed returns on their stablecoin holdings.

The protocol generates revenue through swap fees, redemption fees when tokens mature, and potential governance token value capture as the protocol grows. This model demonstrates how stablecoin adjacent services can create profitable businesses by adding layers of financial sophistication on top of basic stablecoin infrastructure. Pendle particularly benefits during periods of high interest rates, when demand for yield trading increases and the potential returns from separating yield rights become more valuable.

4. Security and Fraud Concerns

Stablecoins face several critical security and fraud challenges that potential users and regulators must consider.

Reserve transparency and verification remain the most significant concern. Issuers must prove they actually hold the assets backing their stablecoins. Several controversies have erupted when stablecoin companies failed to provide clear, audited proof of reserves. The risk is that an issuer might not have sufficient backing, leading to a bank run scenario where the peg collapses and users cannot redeem their coins.

Smart contract vulnerabilities pose technical risks. Stablecoins built on blockchain platforms rely on code that, if flawed, can be exploited by hackers. Major hacks have resulted in hundreds of millions of dollars in losses, and once stolen, blockchain transactions are typically irreversible.

Regulatory uncertainty creates ongoing challenges. Different jurisdictions treat stablecoins differently, and the lack of clear, consistent regulation creates risks for both issuers and users. There’s potential for sudden regulatory action that could freeze assets or shut down operations.

Counterparty risk is inherent in centralized stablecoins. Users must trust the issuing company to maintain reserves, operate honestly, and remain solvent. If the company fails or acts fraudulently, users may lose their funds with limited recourse.

The algorithmic stablecoin model has proven particularly vulnerable. The catastrophic collapse of TerraUSD in 2022, which lost over $40 billion in value, demonstrated that algorithmic mechanisms can fail spectacularly under market stress, creating devastating losses for holders.

Money laundering and sanctions evasion concerns have drawn regulatory scrutiny. The pseudonymous nature of cryptocurrency transactions makes stablecoins attractive for illicit finance, though blockchain’s transparent ledger also makes transactions traceable with proper tools and cooperation.

4.1 Monitoring Stablecoin Flows

Effective monitoring of stablecoin flows has become critical for financial institutions, regulators, and the issuers themselves to ensure compliance, detect fraud, and understand market dynamics.

On Chain Analytics Tools provide the foundation for stablecoin monitoring. Since most stablecoins operate on public blockchains, every transaction is recorded and traceable. Companies like Chainalysis, Elliptic, and TRM Labs specialize in blockchain analytics, offering platforms that track stablecoin movements across wallets and exchanges. These tools can identify patterns, flag suspicious activities, and trace funds through complex transaction chains.

Real Time Transaction Monitoring systems alert institutions to potentially problematic flows. These systems track large transfers, unusual transaction patterns, rapid movement between exchanges (potentially indicating wash trading or manipulation), and interactions with known illicit addresses. Financial institutions integrating stablecoins must implement monitoring comparable to traditional payment systems.

Wallet Clustering and Entity Attribution techniques help identify the real world entities behind blockchain addresses. By analyzing transaction patterns, timing, and common input addresses, analytics firms can cluster related wallets and often attribute them to specific exchanges, services, or even individuals. This capability is crucial for understanding who holds stablecoins and where they’re being used.

Reserve Monitoring and Attestation focuses on the issuer side. Independent auditors and blockchain analysis firms track the total supply of stablecoins and verify that corresponding reserves exist. Circle, for instance, publishes monthly attestations from accounting firms. Some advanced monitoring systems provide real time transparency by linking on chain supply data with bank account verification.

Cross Chain Tracking has become essential as stablecoins exist across multiple blockchains. USDC and USDT operate on Ethereum, Tron, Solana, and other chains, requiring monitoring solutions that aggregate data across these ecosystems to provide a complete picture of flows.

Market Intelligence and Risk Assessment platforms combine on chain data with off chain information to assess concentration risk, identify potential market manipulation, and provide early warning of potential instability. When a small number of addresses hold large stablecoin positions, it creates systemic risk that monitoring can help quantify.

Banks and financial institutions implementing stablecoins typically deploy a combination of commercial blockchain analytics platforms, custom monitoring systems, and compliance teams trained in cryptocurrency investigation. The goal is achieving the same level of financial crime prevention and risk management that exists in traditional banking while adapting to the unique characteristics of blockchain technology.

5. How Regulators View Stablecoins

Regulatory attitudes toward stablecoins vary significantly across jurisdictions, but common themes and concerns have emerged globally.

United States Regulatory Approach involves multiple agencies with overlapping jurisdictions. The Securities and Exchange Commission (SEC) has taken the position that some stablecoins may be securities, particularly those offering yield or governed by investment contracts. The Commodity Futures Trading Commission (CFTC) views certain stablecoins as commodities. The Treasury Department and the Financial Stability Oversight Council have identified stablecoins as potential systemic risks requiring bank like regulation.

Proposed legislation in the US Congress has sought to create a comprehensive framework requiring stablecoin issuers to maintain high quality liquid reserves, submit to regular audits, and potentially obtain banking charters or trust company licenses. The regulatory preference is clearly toward treating major stablecoin issuers as financial institutions subject to banking supervision.

European Union Regulation has taken a more structured approach through the Markets in Crypto Assets (MiCA) regulation, which came into effect in 2024. MiCA establishes clear requirements for stablecoin issuers including reserve asset quality standards, redemption rights for holders, capital requirements, and governance standards. The regulation distinguishes between smaller stablecoin operations and “significant” stablecoins that require more stringent oversight due to their systemic importance.

United Kingdom Regulators are developing a framework that treats stablecoins used for payments as similar to traditional payment systems. The Bank of England and Financial Conduct Authority have indicated that stablecoin issuers should meet standards comparable to commercial banks, including holding reserves in central bank accounts or high quality government securities.

Asian Regulatory Perspectives vary widely. Singapore’s Monetary Authority has created a licensing regime for stablecoin issuers focused on reserve management and redemption guarantees. Hong Kong is developing similar frameworks. China has banned private stablecoins entirely while developing its own central bank digital currency. Japan requires stablecoin issuers to be licensed banks or trust companies.

Key Regulatory Concerns consistently include systemic risk (the failure of a major stablecoin could trigger broader financial instability), consumer protection (ensuring holders can redeem stablecoins for fiat currency), anti money laundering compliance, reserve adequacy and quality, concentration risk in the Treasury market (if stablecoin reserves significantly increase holdings of government securities), and the potential for stablecoins to facilitate capital flight or undermine monetary policy.

Central Bank Digital Currencies (CBDCs) represent a regulatory response to private stablecoins. Many central banks are developing or piloting digital currencies partly to provide a public alternative to private stablecoins, allowing governments to maintain monetary sovereignty while capturing the benefits of digital currency.

The regulatory trend is clearly toward treating stablecoins as systemically important financial infrastructure requiring oversight comparable to banks or payment systems, with an emphasis on reserve quality, redemption rights, and anti money laundering compliance.

5.1 How Stablecoins Impact the Correspondent Banking Model

Stablecoins pose both opportunities and existential challenges to the traditional correspondent banking system that has dominated international payments for decades.

The Traditional Correspondent Banking Model relies on a network of banking relationships where banks hold accounts with each other to facilitate international transfers. When a business in Brazil wants to pay a supplier in Thailand, the payment typically flows through multiple intermediary banks, each taking fees and adding delays. This system involves currency conversion, compliance checks at multiple points, and settlement risk, making international payments slow and expensive.

Stablecoins as Direct Competition offer a fundamentally different model. A business can send USDC directly to a recipient anywhere in the world in minutes, bypassing the correspondent banking network entirely. The recipient can then convert to local currency through a local exchange or payment processor. This disintermediation threatens the fee generating correspondent banking relationships that have been profitable for banks, particularly in remittance corridors and business to business payments.

Cost and Speed Advantages are significant. Traditional correspondent banking involves fees at multiple layers, often totaling 3-7% for remittances and 1-3% for business payments, with settlement taking 1-5 days. Stablecoin transfers can cost less than 1% including conversion fees, with settlement in minutes. This efficiency gap puts pressure on banks to either adopt stablecoin technology or risk losing payment volume.

The Disintermediation Threat extends beyond just payments. Correspondent banking generates substantial revenue for major international banks through foreign exchange spreads, service fees, and liquidity management. If businesses and individuals can hold and transfer value in stablecoins, they become less dependent on banks for international transactions. This is particularly threatening in high volume, low margin corridors where efficiency matters most.

Banks Adapting Through Integration represents one response to this threat. Rather than being displaced, some banks are incorporating stablecoins into their service offerings. They can issue their own stablecoins, partner with stablecoin issuers to provide on ramps and off ramps, or offer custody and transaction services for corporate clients wanting to use stablecoins. JPMorgan’s JPM Coin exemplifies this approach, using blockchain technology and stablecoin principles for institutional payments within a bank controlled system.

The Hybrid Model Emerging in practice combines stablecoins with traditional banking. Banks provide the fiat on ramps and off ramps, regulatory compliance, customer relationships, and local currency conversion, while stablecoins handle the actual transfer of value. This partnership model allows banks to maintain their customer relationships and regulatory compliance role while capturing efficiency gains from blockchain technology.

Regulatory Arbitrage Concerns arise because stablecoins can sometimes operate with less regulatory burden than traditional correspondent banking. Banks face extensive anti money laundering requirements, capital requirements, and regulatory scrutiny. If stablecoins provide similar services with lighter regulation, they gain a competitive advantage that regulators are increasingly seeking to eliminate through tighter stablecoin oversight.

Settlement Risk and Liquidity Management change fundamentally with stablecoins. Traditional correspondent banking requires banks to maintain nostro accounts (accounts held in foreign banks) prefunded with liquidity. Stablecoins allow for near instant settlement without prefunding requirements, potentially freeing up billions in trapped liquidity that banks currently must maintain across the correspondent network.

The long term impact will likely involve correspondent banking evolving rather than disappearing. Banks will increasingly serve as regulated gateways between fiat currency and stablecoins, while stablecoins handle the actual transfer of value. The most vulnerable players are mid tier correspondent banks that primarily provide routing services without strong customer relationships or value added services.

5.2 How FATF Standards Apply to Stablecoins

The Financial Action Task Force (FATF) provides international standards for combating money laundering and terrorist financing, and these standards have been extended to cover stablecoins and other virtual assets.

The Travel Rule represents the most significant FATF requirement affecting stablecoins. Originally designed for traditional wire transfers, the Travel Rule requires that information about the originator and beneficiary of transfers above a certain threshold (typically $1,000) must travel with the transaction. For stablecoins, this means that Virtual Asset Service Providers (VASPs) such as exchanges, wallet providers, and payment processors must collect and transmit customer information when facilitating stablecoin transfers.

Implementing the Travel Rule on public blockchains creates technical challenges. While bank wire transfers pass through controlled systems where information can be attached, blockchain transactions are peer to peer and pseudonymous. The industry has developed solutions like the Travel Rule Information Sharing Architecture (TRISA) and other protocols that allow VASPs to exchange customer information securely off chain while the stablecoin transaction occurs on chain.

Know Your Customer (KYC) and Customer Due Diligence requirements apply to any entity that provides services for stablecoin transactions. Exchanges, wallet providers, and payment processors must verify customer identities, assess risk levels, and maintain records of transactions. This requirement creates a tension with the permissionless nature of blockchain technology, where anyone can hold a self hosted wallet and transact directly without intermediaries.

VASP Registration and Licensing is required in most jurisdictions following FATF guidance. Any business providing stablecoin custody, exchange, or transfer services must register with financial authorities, implement anti money laundering programs, and submit to regulatory oversight. This has created significant compliance burdens for smaller operators and driven consolidation toward larger, well capitalized platforms.

Stablecoin Issuers as VASPs are generally classified as Virtual Asset Service Providers under FATF standards, subjecting them to the full range of anti money laundering and counter terrorist financing obligations. This includes transaction monitoring, suspicious activity reporting, and sanctions screening. Major issuers like Circle and Paxos have built sophisticated compliance programs comparable to traditional financial institutions.

The Self Hosted Wallet Challenge represents a key friction point. FATF has expressed concern about transactions involving self hosted (non custodial) wallets where users control their own private keys without intermediary oversight. Some jurisdictions have proposed restricting or requiring enhanced due diligence for transactions between VASPs and self hosted wallets, though this remains controversial and difficult to enforce technically.

Cross Border Coordination is essential but challenging. Stablecoins operate globally and instantly, but regulatory enforcement is jurisdictional. FATF promotes information sharing between national financial intelligence units and encourages mutual legal assistance. However, gaps in enforcement across jurisdictions create opportunities for regulatory arbitrage, where bad actors operate from jurisdictions with weak oversight.

Sanctions Screening is mandatory for stablecoin service providers. They must screen transactions against lists of sanctioned individuals, entities, and countries maintained by organizations like the US Office of Foreign Assets Control (OFAC). Several stablecoin issuers have demonstrated the ability to freeze funds in wallets associated with sanctioned addresses, showing that even decentralized systems can implement centralized controls when required by law.

Risk Based Approach is fundamental to FATF methodology. Service providers must assess the money laundering and terrorist financing risks specific to their operations and implement controls proportionate to those risks. For stablecoins, this means considering factors like transaction volumes, customer types, geographic exposure, and the underlying blockchain’s anonymity features.

Challenges in Implementation are significant. The pseudonymous nature of blockchain transactions makes it difficult to identify ultimate beneficial owners. The speed and global reach of stablecoin transfers compress the time window for intervention. The prevalence of decentralized exchanges and peer to peer transactions creates enforcement gaps. Some argue that excessive regulation will drive activity to unregulated platforms or privacy focused cryptocurrencies, making financial crime harder rather than easier to detect.

The FATF framework essentially attempts to impose traditional financial system controls on a technology designed to operate without intermediaries. While large, regulated stablecoin platforms can implement these requirements, the tension between regulatory compliance and the permissionless nature of blockchain technology remains unresolved and continues to drive both technological innovation and regulatory evolution.

6. Good Use Cases for Stablecoins

Despite the risks, stablecoins excel in several legitimate applications that offer clear advantages over traditional alternatives.

Cross border payments and remittances benefit enormously from stablecoins. Workers sending money home can avoid high fees and long delays, with transactions settling in minutes rather than days. Businesses conducting international trade can reduce costs and streamline operations significantly.

Treasury management for crypto native companies provides a practical use case. Cryptocurrency exchanges, blockchain projects, and Web3 companies need stable assets for operations while staying within the crypto ecosystem. Stablecoins let them hold working capital without exposure to crypto volatility.

Decentralized finance (DeFi) applications rely heavily on stablecoins. They enable lending and borrowing, yield farming, liquidity provision, and trading without the complications of volatile assets. Users can earn interest on stablecoin deposits or use them as collateral for loans.

Hedging against local currency instability makes stablecoins valuable in countries experiencing hyperinflation or currency crises. Citizens can preserve purchasing power by holding dollar backed stablecoins instead of rapidly devalating local currencies.

Programmable payments and smart contracts benefit from stablecoins. Businesses can automate payments based on conditions (such as releasing funds when goods are received) or create subscription services, escrow arrangements, and other complex payment structures that execute automatically.

Ecommerce and online payments increasingly accept stablecoins as they combine the low fees of cryptocurrency with price stability. This is particularly valuable for digital goods, online services, and merchant payments where volatility would be problematic.

6.1 Companies Specializing in Banking Stablecoin Integration

Several companies have emerged as leaders in helping traditional banks launch and integrate stablecoin solutions into their existing infrastructure.

Paxos is a regulated blockchain infrastructure company that provides white label stablecoin solutions for financial institutions. They’ve partnered with major companies to issue stablecoins and offer compliance focused infrastructure that meets banking regulatory requirements. Paxos handles the technical complexity while allowing banks to maintain their customer relationships.

Circle offers comprehensive business account services and APIs that enable banks to integrate USD Coin (USDC) into their platforms. Their developer friendly tools and banking partnerships have made them a go to provider for institutions wanting to offer stablecoin services. Circle emphasizes regulatory compliance and transparency with regular reserve attestations.

Fireblocks provides institutional grade infrastructure for banks looking to offer digital asset services, including stablecoins. Their platform handles custody, treasury operations, and connectivity to various blockchains, allowing banks to offer stablecoin functionality without building everything from scratch.

Taurus specializes in digital asset infrastructure for banks, wealth managers, and other financial institutions in Europe. They provide technology for custody, tokenization, and trading that enables traditional financial institutions to offer stablecoin services within existing regulatory frameworks.

Sygnum operates as a Swiss digital asset bank and offers banking as a service solutions. They help other banks integrate digital assets including stablecoins while ensuring compliance with Swiss banking regulations. Their approach combines traditional banking security with blockchain innovation.

Ripple has expanded beyond its cryptocurrency focus to offer enterprise blockchain solutions for banks, including infrastructure for stablecoin issuance and cross border payment solutions. Their partnerships with financial institutions worldwide position them as a bridge between traditional banking and blockchain technology.

BBVA and JPMorgan have also developed proprietary solutions (JPM Coin for JPMorgan) that other institutions might license or use as models, though these are typically more focused on their own operations and select partners.

7.1 The Bid Offer Spread Challenge: Liquidity vs. True 1:1 Conversions

One of the hidden costs in stablecoin adoption that significantly impacts user economics is the bid offer spread applied during conversions between fiat currency and stablecoins. While stablecoins are designed to maintain a 1:1 peg with their underlying asset (typically the US dollar), the reality of converting between fiat and crypto introduces market dynamics that can erode this theoretical parity.

7.1 Understanding the Spread Problem

When users convert fiat currency to stablecoins or vice versa through most platforms, they encounter a bid offer spread the difference between the buying price and selling price. Even though USDC or USDT theoretically equals $1.00, a platform might effectively charge $1.008 to buy a stablecoin and offer only $0.992 when selling it back. This 0.8% to 1.5% spread represents a significant friction cost, particularly for businesses making frequent conversions or moving large amounts.

This spread exists because most platforms operate market making models where they must maintain liquidity on both sides of the transaction. Holding inventory of both fiat and stablecoins involves costs: capital tied up in reserves, exposure to brief depegging events, regulatory compliance overhead, and the operational expense of managing banking relationships for fiat on ramps and off ramps. Platforms traditionally recover these costs through the spread rather than explicit fees.

For cryptocurrency exchanges and most fintech platforms, the spread also serves as their primary revenue mechanism for stablecoin conversions. When a platform facilitates thousands or millions of conversions daily, even small spreads generate substantial income. The spread compensates for the risk that during periods of market stress, stablecoins might temporarily trade below their peg, leaving the platform holding depreciated assets.

7.2 The Impact on Users and Business Operations

The cumulative effect of bid offer spreads becomes particularly painful for certain use cases. Small and medium sized businesses operating across borders face multiple conversion points: exchanging local currency to USD, converting USD to stablecoins for cross border transfer, then converting stablecoins back to USD or local currency at the destination. Each conversion compounds the cost, potentially consuming 2% to 4% of the transaction value when combined with traditional banking fees.

For businesses using stablecoins as working capital converting payroll, managing treasury operations, or settling international invoices the spread can eliminate much of the cost advantage that stablecoins are supposed to provide over traditional correspondent banking. A company converting $100,000 might effectively pay $1,500 in spread costs on a round trip conversion, comparable to traditional wire transfer fees that stablecoins aimed to disrupt.

Individual users in countries with unstable currencies face similar challenges. While holding USDT or USDC protects against local currency devaluation, the cost of frequently moving between local currency and stablecoins can be prohibitive. The spread becomes a “tax” on financial stability that disproportionately affects those who can least afford it.

7.3 Revolut’s 1:1 Model: Internalizing the Cost

Revolut’s recent introduction of true 1:1 conversions between USD and stablecoins (USDC and USDT) represents a fundamentally different approach to solving the spread problem. Rather than passing market making costs to users, Revolut absorbs the spread internally, guaranteeing that $1.00 in fiat equals exactly 1.00 stablecoin units in both directions, with no hidden markups.

This model is economically viable for Revolut because of several structural advantages. First, as a neobank with 65 million users and existing banking infrastructure, Revolut already maintains substantial fiat currency liquidity and doesn’t need to rely on external banking partners for every stablecoin conversion. Second, the company generates revenue from other services within its ecosystem subscription fees, interchange fees from card spending, interest on deposits allowing it to treat stablecoin conversions as a loss leader or break even feature that enhances customer retention and platform stickiness.

Third, by setting a monthly limit of approximately $578,000 per customer, Revolut manages its risk exposure while still accommodating the vast majority of retail and small business use cases. This prevents arbitrage traders from exploiting the zero spread model to make risk free profits by moving large volumes between Revolut and other platforms where spreads exist.

Revolut essentially bets that the value of removing friction from fiat crypto conversions thereby making stablecoins genuinely useful as working capital rather than speculative assets will drive sufficient user engagement and platform growth to justify the cost of eliminating spreads. For users, this transforms the economics of stablecoin usage, particularly for frequent converters or those operating in high currency volatility environments.

7.4 Why Not Everyone Can Offer 1:1 Conversions

The challenge for smaller platforms and pure cryptocurrency exchanges is that they lack Revolut’s structural advantages. A standalone crypto exchange without banking licenses and integrated fiat services must partner with banks for fiat on ramps, pay fees to those partners, maintain separate liquidity pools, and manage the regulatory complexity of operating in multiple jurisdictions. These costs don’t disappear simply because users want better rates they must be recovered somehow.

Additionally, maintaining tight spreads or true 1:1 conversions requires deep liquidity and sophisticated risk management. When thousands of users simultaneously want to exit stablecoins during market stress, a platform must have sufficient reserves to honor redemptions instantly without moving the price. Smaller platforms operating with thin liquidity buffers cannot safely eliminate spreads without risking insolvency during volatile periods.

The market structure for stablecoins also presents challenges. While stablecoins theoretically maintain 1:1 pegs, secondary market prices on decentralized exchanges and between different platforms can vary by small amounts. A platform offering guaranteed 1:1 conversions must either hold sufficient reserves to absorb these variations or accept that arbitrage traders will exploit any price discrepancies, potentially draining liquidity.

7.5 The Competitive Implications

Revolut’s move to zero spread stablecoin conversions could trigger a competitive dynamic in the fintech space, similar to how its original zero fee foreign exchange offering disrupted traditional currency conversion. Established players like Coinbase, Kraken, and other major exchanges will face pressure to reduce their spreads or explain why their costs remain higher.

For traditional banks contemplating stablecoin integration, the spread question becomes strategic. Banks could follow the Revolut model, absorbing spread costs to drive adoption and maintain customer relationships in an increasingly crypto integrated financial system. Alternatively, they might maintain spreads but offer other value added services that justify the cost, such as enhanced compliance, insurance on holdings, or integration with business treasury management systems.

The long term outcome may be market segmentation. Large, integrated fintech platforms with diverse revenue streams can offer true 1:1 conversions as a competitive advantage. Smaller, specialized platforms will continue operating with spreads but may differentiate through speed, blockchain coverage, or serving specific niches like high volume traders who value depth of liquidity over tight spreads.

For stablecoin issuers like Circle and Tether, the spread dynamics affect their business indirectly. Wider spreads on third party platforms create friction that slows stablecoin adoption, reducing the total assets under management that generate interest income for issuers. Partnerships with platforms offering tighter spreads or true 1:1 conversions could accelerate growth, even if those partnerships involve revenue sharing or other commercial arrangements.

Ultimately, the bid offer spread challenge highlights a fundamental tension in stablecoin economics: the gap between the theoretical promise of 1:1 value stability and the practical costs of maintaining liquidity, managing risk, and operating the infrastructure that connects fiat currency to blockchain based assets. Platforms that can bridge this gap efficiently whether through scale, integration, or innovative business models will have significant competitive advantages as stablecoins move from crypto native use cases into mainstream financial infrastructure.

8. Conclusion

Stablecoins represent a significant innovation in digital finance, offering the benefits of cryptocurrency without extreme volatility. They’ve found genuine utility in payments, remittances, and decentralized finance while generating substantial revenue for issuers through interest on reserves. However, they also carry real risks around reserve transparency, regulatory uncertainty, and potential fraud that users and institutions must carefully consider.

The regulatory landscape is rapidly evolving, with authorities worldwide moving toward treating stablecoins as systemically important financial infrastructure requiring bank like oversight. FATF standards impose traditional anti money laundering requirements on stablecoin service providers, creating compliance obligations comparable to traditional finance. Meanwhile, sophisticated monitoring tools have emerged to track flows, detect illicit activity, and ensure reserve adequacy.

For traditional banks, stablecoins represent both a competitive threat to correspondent banking models and an opportunity to modernize payment infrastructure. Rather than being displaced entirely, banks are increasingly positioning themselves as regulated gateways between fiat currency and stablecoins, maintaining customer relationships and compliance functions while leveraging blockchain efficiency.

For banks considering stablecoin integration, working with established infrastructure providers can mitigate technical and compliance challenges. The key is choosing use cases where stablecoins offer clear advantages, particularly in cross border payments and treasury management, while implementing robust risk management, transaction monitoring, and ensuring regulatory compliance with both traditional financial regulations and emerging crypto specific frameworks.

As the regulatory landscape evolves and technology matures, stablecoins are likely to become increasingly integrated into mainstream financial services. Their success will depend on maintaining trust through transparency, security, and regulatory cooperation while continuing to deliver value that traditional financial rails cannot match. The future likely involves a hybrid model where stablecoins and traditional banking coexist, each playing to their respective strengths in a more efficient, global financial system.