FinTech and the Bank That Still Runs on COBOL

There is a moment in most FinTech pitch decks where the founding team shows a slide of a legacy bank's technology stack and uses it as evidence that disruption is inevitable. The point lands because it is not wrong. A meaningful portion of the core banking systems still running in large financial institutions today were written in COBOL, a language designed in the late 1950s and standardized in the early 1960s. The machines running some of this code are IBM mainframes that have been in continuous operation since before most people working in technology today were born. This is not a rumor. It is well-documented in public reporting, in industry surveys, and occasionally in the banks' own investor materials when they discuss technology modernization costs.

The FinTechs looked at this situation and built from scratch. Stripe, founded in 2010, built a payments API that made it trivial to accept credit cards on the internet. Before Stripe, doing this required a merchant account, a payment gateway, and a process that took weeks. Stripe reduced it to a few lines of code and an afternoon. Square did something similar for in-person payments with a card reader that plugged into a phone. Plaid built the data layer that connected consumer bank accounts to financial apps, essentially reverse-engineering access to the banking system's data through screen-scraping and later through more formal API integrations. Chime built a consumer bank account on top of existing banking infrastructure without a bank charter of its own.

What all of these companies share is that they did not try to change the legacy system from the inside. They built new layers on top of existing infrastructure, or they found ways to route around the old infrastructure entirely, and they moved at software-company speed rather than bank speed. A bank releases new software features on a quarterly cycle because the core banking system requires careful testing and a formal change management process. A FinTech releases software multiple times a day.

The IS challenge for incumbent banks is not really a technology problem, which is what makes it hard. The banks know their technology is old. They have known for decades. The problem is that modernizing a core banking system is one of the most dangerous technology projects any organization can attempt. The core banking system is the ledger. It records every transaction, every account balance, every loan. It has been accumulating data and business logic for forty or fifty years. It is connected to every other system in the bank. Replacing it means replacing the foundation while the building is occupied, while millions of transactions run through it every day, with regulatory scrutiny on every step, and with personal financial data that cannot be corrupted or lost under any circumstances. The risk tolerance required for that project is essentially zero.

The "strangler fig" pattern is the standard engineering response to this problem. The name comes from Martin Fowler's description of the strangler fig tree, which grows around another tree until eventually the host is completely replaced. In software terms, you build new functionality in a modern system and gradually migrate pieces of the old system to it, routing traffic to the new system one function at a time. The old system shrinks, the new system grows, and eventually the old system is retired. This is slower and more expensive than a "big bang" replacement, but it is far less likely to fail catastrophically. A number of large banks have been executing strangler fig migrations for years. Some have been at it for decades.

Open banking adds another layer of complexity and opportunity. The EU's Payment Services Directive 2 (PSD2), which took effect in 2018, required banks operating in the EU to open their account data and payment initiation services to licensed third parties through APIs. This was a regulatory mandate for interoperability: banks had to let accredited FinTechs and other banks access customer data (with customer consent) through standardized interfaces. The UK implemented its own Open Banking framework with similar goals. The United States has moved more slowly here, with less prescriptive regulation and more market-led API adoption, though the Consumer Financial Protection Bureau has been working on related data sharing rules.

Banking as a Service (BaaS) is the model that some banks have built on this opening. A BaaS provider holds the banking license, maintains the regulatory compliance infrastructure, and offers other companies the ability to embed financial services into their products. Chime, for most of its history, offered accounts that were actually held at partner banks that held FDIC insurance on the deposits. Chime was the user interface and the brand. This arrangement works until it runs into regulatory scrutiny. Chime's situation has been publicly reported: the company faced questions from regulators about its practices around account closures and has navigated an evolving relationship with its banking partners. The regulatory moat that banks have historically enjoyed is real, and FinTechs that grow large enough eventually have to engage with it.

The "bank-in-a-box" narrative, the idea that any startup can now spin up a fully functional bank using off-the-shelf BaaS components, is more complicated than it sounds. The technology layer is more accessible than it was. But banking regulation is not going away. Know Your Customer (KYC) requirements, Anti-Money Laundering (AML) compliance, capital requirements, and consumer protection rules apply whether the bank is 150 years old or two years old. FinTechs that build on top of bank partners inherit those requirements indirectly. FinTechs that seek bank charters of their own face a years-long regulatory process. The moat is lower than it was but it is still there.

What the FinTech wave has actually changed is not that banks are obsolete. It is that the monopoly banks held on the user experience layer has broken. The customer relationship, the app, the product, the brand: these can now be owned by a company that does not have a banking charter. The actual banking infrastructure underneath it is still largely the same mainframes and the same COBOL. The question is whether the incumbents can modernize fast enough to reclaim the user experience layer before they become purely wholesale infrastructure providers to the FinTechs that are now their retail competitors.