For years, the opening conversation with a bank considering payments modernisation went the same way: build it ourselves, or buy something off the shelf? Two doors. Pick one. No refunds.
Icon's answer was set out in Building your own payments solution. Applying a purpose-based alignment Model, payments sit squarely in the "differentiating" quadrant, mission-critical, and a genuine source of competitive advantage. That argues for build. But building from a blank page is punishing - our estimate is a ground-up platform needs at least 100 person-years and two years before it processes a single payment, and that assumes the team already carries deep payments domain knowledge rather than acquiring it live, in production, at speed.
So, build, but don't start from nothing, use a payments accelerator framework. That logic still holds. The assumption underneath it doesn't.
Build vs buy is a question about ownership. Bundled inside it is a second question about engineering capacity, one that, for years, seemed too obvious to be worth separating out.
Almost every bank we work with has excellent engineers. The question is rarely whether they could build a payments platform. It's whether payments infrastructure is where those particular people should be pointed this year, given they are already committed to regulatory mandates, customer propositions and a cloud migration whose deadline was set by someone who has since moved on.
Presented with a binary, banks in that position buy and inherit precisely what the paper warned about: a black box in a domain where regulators increasingly want to know how the box works, a single-vendor solution unlikely to be best-of-breed across the whole value chain, and upgrade cycles that leave you waiting on someone else's roadmap while the market strolls cheerfully past.
The appetite for control is nearly universal. The spare capacity to pursue it unaided is not. The question hasn't changed. The number of answers has.
We have made a narrower version of this point before, a framework is the middle ground between custom rewrites and monolithic vendor engines.
At one end, buy: IPF delivered as a packaged solution from ready-made components. At the other, build: your own solution, using IPF's framework tools. In between sit the layers of a payments platform - business functions and services, scheme or clearing specific functionality, the operational data store, the operator UI, integration, orchestration - with the shift from one palette to the other as you move along. Most banks land in the middle, which is a logical, sensible place to be. However, every institution dials in its own balance, using as many ready-made IPF components as it needs.
Worth restating why that's possible. IPF is not a fixed, off-the-shelf product. It is a toolkit for building modern payment solutions. Smart routing, value date management, clearing scheme packs that hide CSM protocol differences from your flows, payments observability, a connector framework, all orchestrated dynamically on an AI-native platform. Nothing called "IPF" ever goes into production. What goes into production is your solution, and it gets its own name.
Every one of those capabilities can come from IPF, or reuse whatever your bank already runs perfectly well: modular deployment means adopting IPF for individual processing layers without displacing systems that were never the problem. So, the real choice isn't build or buy. It is build, buy, or keep, applied capability by capability. Three doors. Still no refunds, but considerably better odds.
Where the dial can realistically sit has always been limited by how much engineering effort a bank can commit (and a clear view of the end state). AI is moving that limit, though not in the direction most of the marketing suggests.
Credit where it's due: building an individual project with an agent is easier than it has ever been, and anyone still insisting otherwise hasn't tried it lately.
The snag is that a bank's payments estate is not one project. It is many connected projects, owned by different teams, under different governance regimes, expected to interoperate for years. An agent without shared structure starts every one of them from scratch, carrying nothing across from the last. We warned in Refresh, Don't Rip that without guardrails, gradual transformation degenerates into a string of isolated projects. Agents don't fix that. They industrialise it.
There is precedent. We've said before that AI is only as good as the data it's fed: banks with fragmented infrastructure find AI's impact limited, while those on a unified, ISO 20022-native platform get considerably more out of it. The same logic applies one storey up. AI building payments software is only as good as the structure it builds within and as colleagues discovered on a far smaller project, guardrails matter more than ever, not to slow things down but to stop the acceleration heading somewhere unsupervised.
IPF supplies that structure: governance and guardrails that hold across connected projects rather than within one; standardised, validated flows giving each new flow a known-good starting shape, agent or otherwise; reusable building blocks, so teams extend instead of restarting; payment capabilities in consumable form rather than raw material every team interprets afresh.
Most importantly it provides context. An agent equipped with IPF's data model, flow conventions and design principles can do things it simply cannot do without them. The alternative is asking a general-purpose model to derive payments architecture from first principles, correctly, every time, in isolation and then finding out how that went at a later stage when it is more costly to fix.
The DSL still does what it always did, i.e., gives business and engineering a shared language. What has changed sits alongside it. IPF Studio has been rewritten in a format AI agents can consume and build with directly, so an agent works from the same structured definitions your engineers do which is why what comes back is something a payments SME can read and challenge, rather than several thousand lines nobody in the room wants to own. Banks bring their own agent of choice there is no mandated toolchain, no extra vendor in the AI stack.
None of this removes the need for payments domain judgement. Reviewing a flow against scheme rules and settlement obligations is still expert work. It removes most of the mechanical effort around that judgement, which means a bank whose engineers are already spoken for can sit further towards build than its headcount would suggest.
Component mix is one dial. Delivery model is another. Bank led with vendor enablement, joint co-development, or System Integrator led, turning on capability, appetite for ownership and how much knowledge you want transferred along the way. For banks towards the buy end, Icon now partners with system integrators to deliver something closer to a packaged outcome: a working payments solution rather than a framework and a set of manuals, backed by our assurance of continued support.
What separates that from a traditional packaged product is what you're holding once it is live. You own the IP of the implementation, and the flows describing how your payments are processed are visible, versioned and yours to change. Both dials keep moving: a bank that starts packaged and later frees up capacity or turns its own agents loose on a codebase it already owns, inside guardrails already established and can take components in-house without another re-platform.
Good design minimises irreversible decisions. That has always applied to architecture and applies equally to commercial and delivery choices - the whole argument for a dial over a switch. Better opening questions:
Answer those and the build-or-buy question largely answers itself. With IPF, the flexibility is yours.
Heading to Sibos? You'll find us at stand DISM18. Whether you have a question about payments transformation or just to say hello, we hope to see you there.