A companion piece to Core Banking Is a Terrible Idea. It Always Was.
It is 1972. A group of very serious men in very wide ties are gathered in a very beige conference room. They are about to make decisions that will haunt your change advisory board fifty years from now. The following is a faithful reconstruction of that meeting, because clearly someone needed to write it down.
CHAIRMAN: Gentlemen, we need to computerise the bank. The IBM salesman is outside. He’s been there since Tuesday. Security has tried to remove him twice. He seems to feed on rejection.
HEAD OF TECHNOLOGY (there is only one of him, and he is wearing a short-sleeved shirt, which everyone agrees is suspicious): We need a system that handles everything. Accounts, transactions, interest, fees, reporting. Everything.
CHAIRMAN: Everything?
HEAD OF TECHNOLOGY: Everything. In one place. One machine. One vendor.
CHAIRMAN: Should we perhaps have two vendors? For resilience?
HEAD OF TECHNOLOGY: Absolutely not. We want one vendor. Ideally one who makes hardware that only runs their software, so that if we ever want to leave we have to physically replace the building. That’s what I call commitment.
COMPLIANCE OFFICER: Will this system be easy to change when regulations evolve?
HEAD OF TECHNOLOGY: Change? Why would we change it? We’re going to write it in a language that reads like English was translated into German and then back into English by someone who had only ever read a tax return. That will ensure only a very specific kind of person can maintain it, and that person will be irreplaceable. That’s job security for everyone, really.
COMPLIANCE OFFICER: Visionary.
HEAD OF TECHNOLOGY: We’re going to run everything on a single box. All products. All customers. All transactions. Payments, lending, savings, reporting: one box, all of it, one throat to choke.
OPERATIONS MANAGER: What if the box falls over?
HEAD OF TECHNOLOGY: Then we have a disaster recovery plan.
OPERATIONS MANAGER: How long will recovery take?
HEAD OF TECHNOLOGY: Several hours. Possibly a day. We’re still working on the documentation. The recovery procedure will require a specialist who we will train exactly once and who will subsequently leave for a competitor. His successor will have the manual, which will be wrong by then, but written with such confidence that no one will question it until the actual disaster.
OPERATIONS MANAGER: And we need to test this?
HEAD OF TECHNOLOGY: We will test it once, during the original implementation, and then assume it still works forever. Testing it again would require a change freeze, three committees, a consultant from the vendor, and eight months. So: once.
CHAIRMAN: What about releases? How often will we update this system?
HEAD OF TECHNOLOGY: As rarely as possible. I’m thinking: annually. Maybe biennially if we can get away with it. Every release will be a full programme. Full regression testing across every function. Army of testers. Army of project managers managing the army of testers. A war room. Probably a dedicated floor.
FINANCE DIRECTOR: That sounds expensive.
HEAD OF TECHNOLOGY: It’s not expensive, it’s thorough. The release will take between six and eighteen months. We will begin change freeze approximately four months before the release date, which means the business cannot ship anything new for the better part of a year. This is a feature. It keeps everyone focused.
FINANCE DIRECTOR: Focused on what?
HEAD OF TECHNOLOGY: On not breaking anything. Which is the same as progress, if you think about it correctly.
CHAIRMAN: What do our customers get out of this release?
Silence.
HEAD OF TECHNOLOGY: Better MIS reports.
CHAIRMAN: They won’t see those.
HEAD OF TECHNOLOGY: No, but we will, and they are very clean reports. Very clean. Some of the cleanest reports you’ll ever see. Worth every penny of the hundred million we’re spending.
OPERATIONS MANAGER: How will the operators interact with this system?
HEAD OF TECHNOLOGY: Through a screen. One screen. The screen will have approximately four hundred fields. Many of them will be unlabelled, for security. The operator will learn which combinations of field values correspond to which operations through a combination of formal training, informal knowledge transfer, and trial and error with real money. Experienced operators will develop an almost mystical intuition for it. New operators will occasionally initiate a full principal repayment when they meant to process an interest charge, but that’s a training issue, not a system issue.
COMPLIANCE OFFICER: And there’s no confirmation step?
HEAD OF TECHNOLOGY: There’s a button. The button says OK. It always says OK. It says OK whether you’re creating a savings account or accidentally wiring nine hundred million dollars to the wrong counterparties. We felt a consistent user experience was important.
HEAD OF TECHNOLOGY: Now, about scaling. This system cannot scale horizontally. If we need more capacity we buy a bigger box. When the box reaches its limit we buy the biggest box IBM makes. When we exceed that box, we have a different kind of conversation.
OPERATIONS MANAGER: What kind of conversation?
HEAD OF TECHNOLOGY: The kind where we explain to the board that we need to run batch jobs overnight because we’ve run out of intraday capacity, and that customers cannot see their real balances until morning, and that this is normal and expected and completely fine. The batch run will begin at midnight. If it’s not finished by opening, we delay opening. This will never be a problem because it’s 1972 and banks open at ten.
CHAIRMAN: What happens in fifty years when banks operate around the clock and customers expect real time balances and instant payments from their pocket computers?
Long pause.
HEAD OF TECHNOLOGY: I’m going to stop you there. That is an unreasonable hypothetical and I think you should apologise for raising it.
FINANCE DIRECTOR: How long will implementation take?
HEAD OF TECHNOLOGY: Three years, minimum. Probably five if we want to do it properly.
FINANCE DIRECTOR: And what does ‘doing it properly’ deliver?
HEAD OF TECHNOLOGY: A working system. Same products as before. Same prices as before. Same service model as before. Customers will notice nothing has changed.
FINANCE DIRECTOR: That’s the success case?
HEAD OF TECHNOLOGY: That is the dream. If nobody notices, we’ve done it perfectly. If customers call in to say things are different, something has gone wrong.
FINANCE DIRECTOR: And when will we need to replace this system?
HEAD OF TECHNOLOGY: Never. This is the last system we’ll ever need.
Another long pause.
HEAD OF TECHNOLOGY: Or in about fifteen years, when the business has changed enough that this system can no longer accommodate it, and we’ll need to select a new vendor and begin a new three to five year programme that will produce the same products at the same prices that customers will not notice have changed.
CHAIRMAN: And then?
HEAD OF TECHNOLOGY: And then we’ll do it again. And then again. Each time, we’ll write a requirements document that captures everything the old system did plus everything the business has always wanted, and we’ll select the new vendor who covers the most requirements. And each time, we will have purchased a slightly more modern version of the same architectural mistake.
CHAIRMAN: That sounds like a treadmill.
HEAD OF TECHNOLOGY: I prefer the term upgrade cycle. Much more professional.
COMPLIANCE OFFICER: One final question. Could we instead build separate systems for each domain: payments, lending, identity: each independently deployable, each owning its own data, able to scale on its own terms and change without disrupting everything else?
The room goes very quiet.
HEAD OF TECHNOLOGY: That’s not how banking works.
COMPLIANCE OFFICER: Why not?
HEAD OF TECHNOLOGY: Because banking is complex. And regulated. And the vendors tell us it’s impossible. And frankly if it were possible someone would have done it already.
Forty-five years later, Monzo does exactly this with a team a fraction of the size. But that’s a different meeting.
CHAIRMAN: Very good. Let the IBM man in.
The IBM man has apparently already let himself in. He has been sitting at the head of the table for the last twenty minutes. Nobody is sure when he arrived.
IBM SALESMAN: Gentlemen. I understand you want one vendor, one box, one contract, a language only specialists can read, releases that take eighteen months, a user interface that requires interpretive experience, disaster recovery nobody has tested since 2003, and a licensing model that ensures leaving us is economically indistinguishable from burning the bank to the ground.
He opens his briefcase.
IBM SALESMAN: I have just the thing.
And that, more or less, is how we got here.
The remarkable thing is not that this meeting happened in 1972. The remarkable thing is that some version of it is still happening today, in banks that have had fifty years to notice the pattern, conducted by people clever enough to know better, producing requirements documents that run to hundreds of pages and conclude, with great confidence, that what the bank needs is a newer version of the same decision.
The neobanks walked in, ignored the IBM salesman entirely, and built banks that work. The architecture was never the mystery. The willingness to walk out of the meeting was.
Andrew Baker is Chief Information Officer at Capitec Bank. He writes about enterprise architecture, banking technology, and the infinite patience required to watch the same mistake happen in slow motion at andrewbaker.ninja.