Building faster isn’t the same as delivering value

Rethinking the payment delivery operating model 

There’s no shortage of opinion on AI in payments, and I didn’t want to add to it. This piece is about something more fundamental: how banks organise business, product and engineering to deliver payment services. But it’s impossible to ignore that AI has shifted the balance. When engineering can move this fast, the operating model around it becomes the real constraint.

Engineering is accelerating. Is the business keeping pace?

AI-assisted development tools are compressing delivery timelines across the industry, and payment platforms are no exception. Work that once took a sprint can now be produced in days.

But speed of build exposes a different constraint. If business and product teams can’t define what should be built – with clear direction, prioritised requirements and architectural guardrails – faster engineering simply produces more point-in-time solutions, more quickly. Each may work on its own, yet lack the business context, reusability and interoperability that make it valuable beyond its first use.

This isn’t an engineering problem. It’s an operating model problem, and it sits as much with business and product as it does with technology.

Speed only matters if customers feel it

Faster engineering is only worth something if it turns into outcomes customers notice: new propositions reaching market sooner, value-added services launched across markets rather than one country at a time, and a more consistent experience wherever a customer banks.

That conversion doesn’t happen automatically. It depends on business, product and engineering teams working in harmony towards a shared view of what matters – rather than engineering racing ahead of a business that is still defining the problem.

Why global banks feel this most

Large international banks operate across many countries, payment rails, regulators and market-specific timelines. Historically, many adopted federated operating models, with local business, product and technology teams owning individual markets and payment schemes.

Local autonomy has its merits, but the costs have accumulated:

• Duplicated capabilities and services

• Inconsistent business definitions, taxonomies and data models

• Fragmented payment flows and tightly coupled solutions

• Limited reuse and interoperability across markets

• Growing complexity and cost from maintaining multiple implementations of the same thing

Take digital assets. Adoption is growing across markets, yet in a federated model each country risks treating it as its own initiative – its own business case, its own integration, its own interpretation of the rules. The result is several versions of the same capability, none easily reused, and a bank that moves at the pace of its slowest market. With regulatory change, new payment methods and competitive pressure all accelerating, that model is increasingly hard to sustain.

The direction: a common model, not a central bottleneck

The answer is a common product and engineering operating model: central ownership of shared capabilities, with clear, governed room for local needs. It rests on five principles.

• Centralised product ownership. Clear owners for payment products, capabilities and roadmaps, accountable for how they evolve across every market – not just the first one to ask.

• A common payment architecture on a common platform. A shared architecture that separates channels, payment initiation, orchestration and execution, so market- or rail-specific logic isn’t hard-wired into individual channels and new markets can be served from the same foundations.

• Reusable services by default. Services designed once and consumed across markets, payment rails and channels.

• Global standards, governed local variation. Common capabilities are standardised, while local regulatory and scheme requirements are handled through an agreed process: what may vary locally, who approves it, and how it is fed back into the common model.

• Clear operational ownership. Accountability doesn’t stop at go-live. When something goes wrong in production, everyone knows who owns the service, who owns the fix and who owns the conversation with the business.

Common pitfalls – and how to avoid them

“Global” can set off alarm bells, and for good reason. Done badly, a common model simply swaps old problems for new ones. These are the pitfalls we see most often:

• The central bottleneck. Every decision routed to a group committee slows delivery to a crawl. Avoid it by defining decision rights clearly: what is decided centrally, what is delegated to markets, and how quickly decisions are made.

• A global model that doesn’t match local reality. We have seen local entities asked to adopt a group architecture model that describes capabilities working in ways they simply don’t in that market. Teams then spend their effort reconciling documentation with reality rather than delivering. A common model must be validated with local teams and be honest about where markets differ.

• A catalogue nobody uses. Capability and service catalogues only drive reuse if they are discoverable, current and trusted. Make checking the catalogue a standard step before any new development is requested.

• Reuse as an afterthought. Services built for one market and “generalised later” rarely are. Design for interoperability, scalability and future consumption from the outset.

• Requirements that arrive half-formed. If business needs are still being worked out inside delivery sprints, faster engineering just means faster rework. Capture, elaborate, validate and prioritise requirements before they enter delivery.

• Unclear roles and decision-making. Without explicit ownership across business, product, architecture, engineering and operations, prioritisation defaults to whoever shouts loudest.

What good looks like

When the model works, the benefits are tangible:

• Faster time to market. New propositions and value-added services are built once and rolled out across markets, rather than rebuilt country by country.

• Lower cost. Retiring duplicate implementations reduces the cost of both change and run.

• Repeatable service onboarding. A standard engagement framework for bringing new services, payment rails and consumers onto the common platform, so each rollout is easier than the last.

• End-to-end traceability. Clear lineage from business capabilities and products through to services, features and technical implementation, so the business can see what it has, what it is getting and why.

• Better collaboration. Shared priorities and a common language between business, product and engineering teams.

Progress should be measured with business-driven KPIs, not just delivery metrics: time to market for new services, levels of reuse, onboarding effort per service or market, cost to serve, operational performance and platform maturity

Where AI fits

The biggest untapped opportunity for AI in this picture isn’t on the engineering side – it’s in closing the gap on the business side. Used well, AI can help teams generate, elaborate and validate requirements, check them for consistency and completeness, and maintain traceability from business intent through to delivery.

That raises both the quality and the speed of the conversation between business and engineering, and helps ensure that what gets built is what was actually needed.

How Icon helps

Icon combines strategic, business and engineering experience to help banks design and implement payment delivery operating models that last.

• Capitalising on opportunities, faster. We go beyond platform migration and regulatory deadlines, helping banks identify and launch value-added services and make the most of their platform capabilities – reaching market sooner and at lower cost.

• Proven at global scale. Experience supporting a Tier-1 global bank in rolling out common payment services across more than 60 countries.

• Blueprints that accelerate. Practical payment capability frameworks, reference architectures and model payment flows that accelerate transformation.

• Both sides of the table. Experience across both business and delivery organisations, understanding the priorities, challenges and dependencies on each side.

• Practical AI adoption. Applying best practice and tooling to AI-supported requirements generation, elaboration and validation, strengthening the link between business intent and engineering delivery.

The bottom line

AI will keep accelerating engineering. The question for banks is whether their business and product operating models will evolve at the same pace.

The goal isn’t simply to build faster. It’s to make sure that what gets built is aligned with business strategy, reusable across markets and able to evolve with the payments landscape. The banks that succeed will put business and product in the driving seat, working hand in hand with engineering to turn the ability to build faster into the ability to deliver greater value for their customers.