Ahead of the launch of his much anticipated book, “Rip Out the Core: A DIY Guide to Platform-Enabled Banking Transformation,” we sat down with Pål Krogdahl to talk core banking transformation, and why he thinks most of the industry is getting it wrong.
Pål was mid-flight, somewhere over the Nordics, still half in vendor-pitch mode from the presentation he’d just delivered, when the analogy hit him.
A few hours earlier his daughter had called, panicking about a broken pipe that was causing the kitchen in their family home to flood. He’d set the dishwasher’s delay timer wrong that morning before rushing to the airport. The machine, old and already flagged for replacement more in more than one occasion, had switched itself on with nobody home. By the time anyone noticed, disaster had struck, the floor was soaked and the damage was already done.
He couldn’t fly home. He had a presentation to finish, a room full of bankers to convince that his firm could lead their core transformation. So he sat there, talking through modernization roadmaps, while his own house flooded four hundred kilometers away.
Somewhere on the flight back, it clicked. He’d been ignoring the dishwasher the same way banks ignore their cores. It works, more or less. It’s been patched before, so just leave it. He has a name for it: The duct tape economy, which is also the spine of the book. Something breaks, you patch it, it holds, and you move on because it’s still working, more or less. Nobody rips out a system that hasn’t failed yet. Boards don’t fund what looks fine on the surface, and IT teams don’t get budget to fix something nobody’s complaining about. So the patches pile up, one after another, until the whole thing is held together by fixes nobody remembers making. That’s the thread running through the whole book. Banks don’t act because something is wrong. They act because something finally breaks, and by then the fix costs ten times what it would have if they’d moved when the first crack showed. His kitchen didn’t get renovated because he decided it needed updating. It got renovated because the floor was underwater.
We asked Pål what makes his take on core transformation different from everything else already written on the subject. Most of what gets called transformation, he told us, is actually modernization wearing a nicer suit. Swap the mainframe for something cloud native, keep every process exactly as it was, and you haven’t transformed anything. You’ve just moved the furniture into a newer room.
So where should a bank actually start? Not with the legacy, he told us. With the strategy. What does the bank need to become? What capabilities does that require? Only after answering that should anyone go near a vendor shortlist. Most programs do it backwards, he said. They spend a year mapping what they already have, hire the usual consultants to document the mainframe, and call that progress. It’s comfortable. It’s also the wrong place to start, because you end up building a future shaped by a past you were supposed to be leaving behind.
We asked him why these programs keep failing, and he gave us three reasons. First, transformation gets treated as a technology project instead of a business one, so it lands on IT departments that have done this once, maybe twice, in their careers and don’t know what’s coming. Second, banks lock a five year plan in place on day one, when the industry, AI, customer behavior and competitors will have moved so far by month twelve that the plan is already out of date. Third, control of the outcome slips away because the old systems keep changing underneath the new build, and scope creep eats the project alive.
There’s a financial trap in all of this too, he explained. Boards expect costs to drop as soon as a transformation starts. The opposite happens. You’re running two environments, old and new, side by side, and the bill goes up before it comes down. He compares it to building a new house in your back garden while still living in the old one. You don’t save on electricity halfway through construction. You save once the old house comes down.
We asked him how banks should fix this. It isn’t a bigger plan, he said. It’s a shorter one. Twelve month cycles, not five year roadmaps. Pick the business capability with the least dependency on the legacy, launch it as what he calls a speedboat, and let it prove value fast. Fail, and you’ve lost twelve months, not five years and your credibility with the board.
We also asked what he thought of the traditional RFI-RFP process. Theater, he called it. Five hundred questions, and vendors who’ll find a way to answer yes to every one of them, whether the platform can actually deliver or not. Bring the finalists in to prove it instead. Pilot it. Watch what breaks.
We brought the conversation back to the kitchen and asked what his quick win would have looked like if he’d acted before the flood instead of after it. Pål paused. He wasn’t sure, he admitted. Most banks don’t get to choose the moment they start taking their core seriously. Usually, something has to flood first.
“Rip Out the Core: A DIY Guide to Platform-Enabled Banking Transformation” is now available on Amazon.