Payment Infrastructure UK: The Full Stack from Rails to Regulation

Every payment a platform processes touches infrastructure it did not build and regulation it did not choose. The routing decision – which rail, which provider category, which regulatory framework – determines cost, speed, settlement certainty, and how easily the setup changes when product requirements do.

Most platforms make that decision once, early, based on whoever they integrated first. That works until it does not: when a new payment use case requires a different rail, when regulatory requirements shift, or when a competitor offers the same journey at a fraction of the infrastructure cost.

This covers the full UK payment infrastructure stack – the rails that move money, the provider categories that sit above them, and the regulation that governs the whole system – before getting to where each category fits.

“The platforms that build well on payment infrastructure are the ones that understand what layer they are actually operating at. Most of the costly mistakes we see come from confusing a provider category with the underlying rail.” – Yuri, Finexer

TL;DR

UK payment infrastructure has three layers: the rails (Faster Payments, BACS, CHAPS, card schemes), the provider categories above them (gateways, PSPs, BaaS, Open Banking), and the regulation governing access. No single provider accesses all rails equally. Choosing a payment infrastructure provider means choosing which rails, at what latency, under which regulatory framework.

What Is Payment Infrastructure?

Payment infrastructure is the combination of rails, systems, and regulated providers that move money between bank accounts and settle transactions. In the UK, it spans four main payment rails – Faster Payments, BACS, CHAPS, and card schemes – alongside the layer of regulated providers that platforms use to access those rails.

For platforms building financial products, payment infrastructure is not a single thing they integrate. It is a stack of decisions: which rail moves the money, which provider category accesses that rail, and which regulatory framework governs the relationship between them.

Getting that stack right from the start tends to save significant re-engineering time later.

The UK Payment Rails

UK payment infrastructure runs on four main rails. Each is a separate clearing and settlement system with different operators, latency, cost profiles, and access models.

Note: Open Banking PIS and AIS are service layers that sit above these rails - not payment rails in themselves. PIS initiates payments that route via Faster Payments. AIS accesses bank account data via the Open Banking API layer. Both are FCA-regulated services, covered in the provider categories section below.

Faster Payments

Faster Payments is the UK’s real-time interbank payment rail, operated by Pay.UK with Vocalink as the infrastructure provider. Payments settle in seconds, round the clock, seven days a week. The scheme transaction limit is £1 million per payment.

Open Banking Payment Initiation Services ride on Faster Payments – when a platform triggers an Open Banking payment, the underlying settlement is a Faster Payment. This makes FPS the rail behind the most commercially interesting Open Banking use cases –pay by bank checkout, instant payroll disbursement, A2A transfers, and supplier payments.

BACS

BACS processes bulk payments in batches that take three business days to clear. It is the rail behind most UK salary payments, standing orders, and direct debits. In 2025, BACS processed 6.86 billion transactions with a total value of approximately £6 trillion (Pay.UK Annual Statistics 2025).

BACS is not a real-time system and was not designed to be. The delay is a feature for high-volume predictable flows where same-day settlement is not required. The operational problem is when platforms need to confirm individual payment status before that three-day window closes – which is where BACS shows its age as a reconciliation tool.

CHAPS

CHAPS is the Bank of England’s same-day high-value payment system. It processes property completions, wholesale financial settlements, and large corporate payments – transactions where irrevocable same-day settlement in central bank funds is required.

In 2025, CHAPS settled approximately £25.1 trillion in value (Pay.UK Annual Statistics 2025). It is not a volume rail – it is a certain rail.

CHAPS migrated to ISO 20022 messaging in June 2023, enabling richer structured payment data across high-value flows. The same standard is being adopted across Open Banking and Faster Payments rails – where it reduces reconciliation exceptions by carrying structured reference data through the full payment chain.

Card Schemes

Visa and Mastercard operate card payment infrastructure in the UK, covering consumer debit, consumer credit, and business card transactions. Card schemes are designated payment systems regulated by the PSR, which caps consumer debit card interchange at 0.2% and consumer credit at 0.3%.

Card payments settle on a T+1 basis – the merchant receives funds the next business day after authorisation, not at the point of payment. The payment authorisation is immediate; the settlement is deferred.

For B2B platforms building outbound payment workflows, card rails add interchange fees and chargeback exposure that account-to-account alternatives via Faster Payments do not carry.

Who Are the UK Payment Infrastructure Providers?

UK payment infrastructure providers sit above the rail layer. Each category accesses different rails, operates under different regulatory frameworks, and suits a different platform use case. The provider category a platform chooses determines how it accesses those rails.

Payment Gateways and PSPs

Payment gateways handle the technical routing of payment data between merchants, acquiring banks, and card schemes. The distinction between a payment gateway vs PSP matters when scoping what layer a platform is actually integrating.

Stripe, Adyen, and Worldpay are PSPs in this category. They excel at inbound card payment acceptance – consumer checkout, subscription billing, marketplace inbound flows. Their access to Faster Payments or BACS for outbound flows is indirect, typically via a bank partner rather than direct scheme access.

For platforms that primarily need inbound card acceptance at scale, PSPs are typically the natural starting point. For platforms where outbound bank transfers, direct debits, or Open Banking payments are the primary function, PSPs may not be the best-matched category.

Banking-as-a-Service

Banking-as-a-Service providers – Modulr, ClearBank, and Griffin are UK examples – offer direct scheme access to Faster Payments and BACS via API, alongside e-money or banking licence infrastructure. They enable platforms to issue sort codes, hold funds, and initiate payments directly via scheme, without building the regulatory and technical infrastructure from scratch.

BaaS tends to be the better fit for platforms that need to own the full payment flow – creating account infrastructure, holding client money, or offering financial products under their own brand. It carries more regulatory complexity than a simple API integration and typically requires a longer onboarding process.

Open Banking Infrastructure

Open Banking infrastructure providers are FCA-authorised firms operating as Account Information Service Providers (AISPs) and Payment Initiation Service Providers (PISPs) under PSD2.

AISPs access live bank account data – balances, transactions, account details – with customer consent. PISPs initiate payments directly from a customer’s bank account via Faster Payments – the Open Banking payment flow from consent to settlement runs within seconds.

The FCA became the lead regulator for Open Banking in the UK following the wind-down of JROC in 2025 and the April 2026 HM Treasury announcement on the Open Banking regulatory framework. The Future Entity for UK Open Banking – confirmed in the FCA’s August 2025 feedback statement – will become the primary standard-setting body for Open Banking APIs.

The main Open Banking API providers in the UK include Finexer, TrueLayer, GoCardless, and Yapily, among others. Each holds FCA authorisation as AISP, PISP, or both. Provider selection within this category depends on UK bank coverage, data product depth, payout geography, and commercial structure – not on the regulatory category, which is standardised.

One distinction worth flagging: Open Banking PIS handles A2A transfers reliably today – payroll, supplier payments, B2B disbursements.

A2A as a consumer card alternative at retail point of sale is a separate, still-developing capability. Trust frameworks, liability allocation, and consumer protection mechanisms are still being designed.

This is about expanding payment choice, not replacing card infrastructure. Platforms building retail checkout flows should plan cautiously – A2A POS is unlikely to be operationally ready across the UK market in 2026.

What We See in Practice

Most platforms we work with at Finexer come in having already integrated one provider – typically a payment gateway or PSP – and are now discovering the constraints of that choice for a new use case.

The pattern is consistent: card gateway works for inbound consumer payments but adds too much cost for outbound B2B payouts. Or a BACS-based payroll setup struggles to confirm individual payment status before payday queries arrive. Or a third-party data aggregator provides bank transaction data with a latency that breaks the reconciliation workflow.

Each of these is a rail problem wearing a provider problem’s clothing. The underlying rail was not chosen for the new use case – it was inherited from the original integration. Understanding which rail sits underneath which provider tends to make the switch to a better-matched solution more straightforward than starting from scratch.

The Regulatory Framework

UK payment infrastructure sits across two primary regulatory bodies with distinct remits.

The Payment Systems Regulator (PSR) regulates designated payment systems – Faster Payments, BACS, CHAPS, LINK, Visa, Mastercard, and cheque clearing. Its statutory objectives are to promote competition, promote innovation, and ensure payment systems operate in the interests of users. The PSR enforces interchange fee caps, the APP fraud mandatory reimbursement requirement (effective October 2024, up to £85,000), and scheme access rules.

The Financial Conduct Authority (FCA) regulates payment service providers – firms that initiate, execute, or facilitate payments as a service. PSPs, e-money institutions, AISPs, and PISPs are all FCA-regulated categories. The FCA became the UK’s lead Open Banking regulator following the NPV in 2025, taking over primary responsibilities previously shared with the PSR under the JROC structure.

Two developments currently shaping the regulatory landscape:

Commercial VRPs (cVRP). The first live payments under the UK Payments Initiative commercial VRP scheme began in Q1 2026. cVRPs allow platforms to initiate recurring payments from customer accounts with customer consent, without requiring a new payment authorisation each time. This is distinct from sweeping VRPs (which move money between a customer’s own accounts). Commercial VRP is the mechanism that makes Open Banking viable for subscription and recurring billing use cases.

FPS infrastructure review and DeliveryCo. The Payments Vision Delivery Committee – led by the Bank of England, FCA, and PSR – established that the New Payments Architecture programme was not sufficiently agile. In July 2025, at Mansion House, the government announced DeliveryCo as the new industry-led entity responsible for designing and delivering next-generation UK retail payments infrastructure. DeliveryCo represents a structural change: a dedicated delivery vehicle separate from Pay.UK’s existing scheme operation.

This modernisation is running on two parallel tracks. In the short term, enhancements to the existing Faster Payments System are delivering improved resilience and functionality. In parallel, DeliveryCo is working on next-generation infrastructure. Some capabilities will arrive via FPS enhancements; others require the next-generation build. Platforms making infrastructure commitments in 2026 should plan for a multi-year transition.

Common Mistakes When Building on Payment Infrastructure

Choosing a provider category before choosing the rail. A platform that needs real-time account-to-account outbound payments should first identify that Faster Payments is the correct rail, then find an FCA-authorised PISP that routes via Faster Payments. Starting with “which gateway should I use” skips the rail question and often leads to a mismatched choice.

Assuming one provider handles all rails equally. PSPs handle card rails well. BaaS providers handle Faster Payments and BACS directly. Open Banking providers access Faster Payments via PIS and add the data layer via AIS. No single provider category is equally strong across all rails – the product architecture should reflect that.

Conflating data access with payment initiation. AIS and PIS are separate FCA-regulated activities, often provided by the same firm but architecturally distinct. A platform that uses AIS for bank data and then needs to initiate payments should not assume the same provider’s PIS product has equivalent coverage or quality. Validate both independently.

Underestimating the regulatory burden of BaaS. Platforms attracted by direct scheme access via BaaS sometimes underestimate the onboarding complexity, ongoing compliance requirements, and minimum volume commitments involved. For most platforms, starting with a regulated PISP or PSP and moving to BaaS when volume justifies it is the lower-risk path.

Where Finexer Fits in the UK Payment Infrastructure Stack

Most of the problems described in this blog – choosing the wrong provider category, assuming AIS and PIS are interchangeable, discovering that BACS reconciliation breaks at volume – trace back to the same root: the platform picked a provider before understanding which rail the job actually required.

Finexer operates as the Open Banking infrastructure layer within the broader UK payment infrastructure stack. Not as a general-purpose payment infrastructure provider, and not as a replacement for the PSP or BaaS decisions a platform might also need to make – but as the specific layer where AIS and PIS, data access and payment initiation, connect through a single FCA-authorised API integration. That combination matters for three of the problems this blog surfaces:

The AIS and PIS validation problem. Earlier, we noted that AIS and PIS are separate regulated activities and that platforms should validate them independently even when provided by the same firm. Finexer holds FCA authorisation as both AISP and PISP. The data layer and the payment initiation layer share the same API contract, the same consent flow, and the same bank coverage – almost all major UK banks. In practice, the AIS and PIS layers share the same bank coverage – divergence between the two is unlikely rather than structurally impossible.

The BACS delay and reconciliation problem. BACS takes three business days. For platforms that currently use BACS for salary disbursement or supplier payments, switching the outbound flow to Faster Payments via Open Banking PIS removes the clearing window and puts per-payment confirmation against bank records – via AIS – in the same integration. The reconciliation output no longer depends on waiting for BACS to clear before matching.

The fragmentation problem. Platforms managing two providers for data access and payment initiation – a common pattern when the PSP handles inbound card flows and a separate AIS provider handles bank data – add a third operational dependency. Finexer’s AIS and PIS through one integration does not solve all of that, but it removes the split between the data layer and the outbound payment layer for the Open Banking portion of the stack.

What Finexer does not solve: card acceptance, high-value CHAPS flows, BACS bulk file management, or the account infrastructure that BaaS provides. Those remain separate decisions, separate provider categories, separate regulatory engagements. Finexer is the Open Banking layer – it does that job well, and it does not pretend to be the others.

For platforms that have mapped the rail question first and landed on Faster Payments for outbound flows and live bank data for reconciliation or onboarding, Finexer’s AIS and PIS integration is the operationally efficient choice at that layer.

Open Banking Limited recorded 37.46 million payment transactions in March 2026. Platforms building on Open Banking API integration find the AIS and PIS layers connect more cleanly when they sit under the same authorisation.

• FCA-authorised (FRN 925695)
• 3 to 5 weeks of hands-on onboarding support
• Usage-based pricing, commercial terms agreed based on use case

“The integration question we get most often is not ‘what does Finexer do’ – it is ‘which of our existing infrastructure problems does Finexer actually solve’. The answer is specific: the AIS-to-PIS gap, the BACS-to-Faster-Payments transition, and the data layer that makes outbound payment reconciliation reliable. Everything outside that is a different provider category conversation.” – Yuri, Finexer

How to Choose the Right Payment Infrastructure Provider

The decision narrows to four questions:

What is the primary payment job? 

Inbound card: PSP. High-value same-day: CHAPS via bank or BaaS. Bulk salary or direct debit: BACS via bank or BaaS. Real-time A2A outbound: PISP. Bank data access: AISP.

What does the regulatory model require? 

Holding client money needs an e-money or banking licence (BaaS). Initiating payments on behalf of customers needs an FCA-authorised PISP. Accessing bank data needs an FCA-authorised AISP.

What onboarding timeline is acceptable? 

BaaS: typically 3-6 months. PSP or gateway: days to weeks. Open Banking: Finexer’s 3 to 5 weeks is typical for this category.

At what volume does the pricing model break? 

Validate the commercial model at 12-month and 36-month projected volumes, not just current run rate.

For platforms building across multiple payment jobs – inbound card acceptance and outbound bank transfers, or data access and payment initiation – the answer is typically two providers from two different categories, integrated cleanly at the platform layer. Technical teams combining provider categories will find the payment integration via API architecture decision shapes how cleanly each rail sits within the platform layer.

About the Author

Yuri

Yuriy Yakushko is the Founder of Finexer, an FCA-authorised Open Banking platform that enables businesses to access real-time bank data and Pay-by-Bank payments through secure API infrastructure. With more than 20 years of experience in fintech and software engineering, he focuses on building scalable financial technology that helps businesses modernise payments and financial data workflows.