Payments is at an inflection point

There’s something that nobody in payments will say out loud. Not vendors. Not systems integrators. Not banks. They have different reasons (which we will explore later) to ignore, look the other way, or willingly deny, that the complexity of enterprise payment platforms exceeds anything a vendor, a large SI (systems integrator), or banks can deliver on time, in budget, defect free and to spec.

I’ve spent the last few months talking to banks, large SIs, and platform vendors about the modernization projects they’re running. I looked past conventional payment flow builders to the thousands of other groups out there trying to wrangle account-to-account payments into their ecosystems. Organizations like card providers, processors, government departments, and large corporations.

The revolution of instant payments, alternative rails and the coming wave of payments innovations in digital assets (like tokenized deposits and stablecoins) has created demand for payment flows beyond anything we have ever seen.

Yet the picture that came back was strange. Not bad, exactly, just strange. Everyone’s working hard and spending money. But there’s no common approach to coalescing on how to solve the dual issues of the pace of change in, and the complexity of, payments. The status quo felt broken. What wouldn’t work yesterday has no hope of working tomorrow.

Andy Grove had a name for moments like this. In ‘Only the Paranoid Survive’ he called them “strategic inflection points”. His warning was that you almost never spot them from the inside. Looking back, they’re obvious. Living through them, they just feel turbulent. Confusing. Like the industry has lost the plot.

I think payments has arrived at one. Here’s why.

How we got here

Let’s rewind a few decades, when payments ran on mainframes and AS400s. IBM’s kit was legendary for reliability, and it did part of the flow, with the bank building its own separate systems around it, then filling the gaps with manual work.

Then came the big idea: the enterprise payment platform. Bring every flow into one place. That way you could run one AML check flow instead of ten, a single sanctions check interface and one pricing engine. Companies formed around that idea and grew at astounding speed.

Dovetail went to Fiserv. Clear2Pay and OPF went to FIS. Fundtech’s GPP went through D+H (Davis and Henderson) which merged with Misys, to become Finastra. In twenty years, a handful of platform vendors became some of the biggest names in banking technology.

Then, a few years ago, the mood turned. Banks complained about the platforms: “It doesn’t do what you said. You oversold and underdelivered.” Vendors were saying: “You told us twenty customizations. There were a hundred.” As large SIs threw more and more bodies at the problem, they moved those bodies further from the client to cheaper locations. None of the players involved were more right or wrong than the other, but the frustration was definitely real.

So, the industry moved again. Vendors proposed vanilla payment platforms, surrounded by microservices that payment providers or SIs would build. The idea was to keep the core untouched then pop changes in and out at the edges. New companies like Icon with IPF formed, giving banks the frameworks to manage those microservices themselves.

Some of it landed. But then banks did the arithmetic: “I’m paying the same for my platform, and now I’m doing half the work myself.” Some took the next step and asked why they shouldn’t do all of it. Others told the vendor: give me the code, I’ll run it myself on your platform.

But all this missed one key element. The industry developed instant payments and new rails, bringing with them expectations of higher speed, and lower costs. New innovation to move money faster, more regulation in anti-money laundering, sanctions, and consumer protections. This all led to an unmatched and essentially undeliverable complexity.

An industry out of sync

Saying the quiet part out loud – “this is too hard” – never got anyone promoted. No bank, no SI, no vendor was incentivized to admit what is mathematically proven and true: not only are there more allowable variations in a cross-border pacs.008 than there are atoms in the observable universe (true!), but that is further multiplied many, many times when you add in different rails, schemes, payment providers’ specific systems, rules, features.

A payments platform is better understood through the science of complexity. It has more in common with a rainforest ecosystem. It is better understood like an anthill. Every action itself is simple and understood. Compile them and the complexity is overwhelming. It far exceeds what a single human, never mind an army of poorly coordinated people, can hold.

The nature of the industry’s Software Development Lifecycle (SDLC) is a multi-million dollar game of telephone:

• The expectation that a simple business requirement will survive the path from business requirement, to epic, to user story, to technical designs and Jira tickets.
• The assumption that it will maintain the original intention as it moves from words into Java or Python then a platform with millions of existing lines of code.
• The hope that it will work under the stress of all those allowable variations of payments.
• The belief that it will do so on a platform with other schemes, currencies, and surrounded by 20, 50, or even 100 related systems.

And that’s where we stand. There is no market agreement on the way forward.

We see some players, unhappy with their big enterprise platform, choosing to switch to another. As if the problem was the vendor, not the complexity that the platform was handling. Others are writing their own rails from scratch. No longer the purview of just the largest banks. We see new rails being built as their own flows, in a manner similar to 20 years ago (i.e. addressing complexity with single, simple flows).

Some are in the middle, building off lightweight scaffolding. We even see some so keen to believe that new cloud-native, AI-native products will somehow solve this complexity in the way that established vendors can’t.

After 25 years of modernization, the industry agrees on less than when it started. That should tell us something. When every answer keeps failing, it’s usually because we’re asking the wrong question (and unfairly blaming the wrong people).

So, now what?

If payments is more complex than any of us will admit, now what?

The troubles were never really vendor problems, or bank problems, or down to the integrators’ armies of bodies. While many could spell payments, few truly knew payments. The problems, delays, and high defects were complexity problems wearing different costumes.

It’s in everyone’s interests to understate, ignore, or believe the same thing. Which is: our system is so simple, our humans and spreadsheets can handle it. Or at best an alliance with generic AI is the answer.

So every project starts on a false premise of simplicity, eventually hits the same pothole as the last one, and we conclude the platform was wrong, or the vendor was wrong, or the operating model was wrong. And we lurch to the next alternative. Which doesn’t solve it either, because true complexity was never on the table.

Want to go to the moon? Want to predict a hurricane? It starts with accepting that the complexity of the problem exceeds what humans alone can do, and that the current methods we are using will need re-inventing. We didn’t propose to fly an airplane to the moon. We built rockets. Until we understood that sandstorms in the Sahara were where we should look first if we wanted to predict a hurricane in Texas, we had no hope.

Which really leads us to the second thing we won’t say: the current methods and SDLC (waterfall, or agile, or RUP) haven’t worked. Not properly. Which means doing it the same way and hoping for a different outcome isn’t a strategy.

But watch what happens when deeply applied payments AI enters that conversation. Not just using the latest GPT or Claude model, or writing a few skills. But deeply applied payments AI.

I keep having the same three exchanges:

A vendor: “We love the idea of AI. But until it’s proven, I can’t get rid of the armies of people implementing the platform. However inefficient they are, at least something comes out eventually. Cut them for AI, and if AI doesn’t deliver, we’ve got nothing.”

An SI: “I’d love to embrace AI. I tell the world we have. But I can’t walk away from this revenue or my quarterly bonus. My CEO talks to the market every quarter.”

A bank: “I would love to use AI, but this is not my problem. The vendor has failed again to update, upgrade, and deliver. I will use it to test, but the end-to-end problem is not mine. I have too much to do.”

All are completely rational. And all are polar bears on icebergs. Melting, drifting out to sea, holding on because the ice is at least familiar and the water is not.

So here is the honest position, and it’s uncomfortable: payments is more complex than we’ll admit, the new technology isn’t proven enough to bet everything on, but doing nothing means slowly drowning in the mess we already have. All three at once. That’s the diagnosis.

Next week, in part two: what has to change. For vendors, for banks (or anyone building payment flows), for SIs. Because we’ve been in a corner like this before, and the way out looks nothing like the way in.