Faster Payment Service Explained for UK Businesses

The popular advice on Faster Payments is to choose a provider, connect your platform and promise customers instant transfers. That's the wrong starting point for a regulated business. Before committing to a faster payment service, decide who carries settlement exposure, who can interrupt suspicious transactions and who funds reimbursement when a customer is scammed.

A convincing demonstration of payment speed won't answer those questions. A credible operating model will.

Table of Contents

• Why Faster Payments Is an Authorisation Story, Not a Speed Story
  • Separate permission from connectivity
  • Prepare for scrutiny, not presentation
• How Faster Payments Actually Moves Money
  • Clearing is not interbank settlement
  • Map the payment types separately
• Scale, Growth and What the Numbers Mean for Participants
• The £1 Million Limit and Why It Matters for Your Operating Model
  • Build a layered limit structure
  • Explain the rationale, not just the setting
• APP Fraud, Reimbursement and Who Decides When Things Go Wrong
  • Start with the decision, not the claim form
  • Low incidence still creates funded exposure
• From Speed to Governability, Controls, Resilience and the Modernisation Agenda
  • Faster Payments Risk Allocation at a Glance
  • Separate operational controls from intentions
  • Apply frameworks according to scope
• A Pre-Application Checklist for Offering Faster Payments
  • Establish the legal and operational foundation
  • Demonstrate financial and control readiness
  • Make the launch decision auditable

Why Faster Payments Is an Authorisation Story, Not a Speed Story

A founder approves a near-instant payments proposition. The technology team has a connectivity proposal, the commercial team has customer journeys, and compliance has a draft policy library. The unresolved question is whether those documents describe the same business.

Start with the regulatory route and allocation of responsibilities, not the integration timetable. Establish which entity provides the payment service, how it accesses the scheme, which activities require permissions and which responsibilities remain with your firm when another institution supplies connectivity. Treat these as decisions to resolve before signing material supplier commitments.

Separate permission from connectivity

Access to a payment rail and permission to conduct regulated activities are different questions. Your application narrative should distinguish your customer relationship, payment execution arrangements, funds flow and contractual dependencies. For founders considering an electronic-money model, the assessment of e-money institutions and their operating arrangements belongs upstream of product design.

My recommendation is to require a single operating-model diagram that identifies:

• The contracting entity: Show who owes each obligation to the customer.
• The access arrangement: Identify the institution providing connectivity and the boundaries of its service.
• The decision owners: Name who controls payment release, liquidity escalation, fraud intervention and customer remediation.
• The evidence trail: Connect each material decision to a system record, procedure or accountable role.

Practical rule: If management can't explain a failed payment without referring the entire question to its provider, the operating model isn't ready.

Prepare for scrutiny, not presentation

For an FCA application, don't assume polished policies demonstrate operational readiness. Prepare to explain how staff will apply them, which systems support them and what happens when a dependency fails. For PSR-related obligations, distinguish the applicable requirements from your chosen implementation controls.

A weak pack describes functions in isolation. A defensible pack connects business assumptions, contracts, technology, financial resources and management responsibilities.

That's the authorisation issue: can the firm govern the service it proposes to sell? Speed is a product feature. Responsibility must remain identifiable when the product stops behaving as expected.

How Faster Payments Actually Moves Money

The customer experience and the institutional settlement process aren't the same event. Faster Payments Service, operated by Pay.UK, combines rapid customer-facing processing with a separate settlement arrangement. Don't let a payment confirmation become shorthand for every obligation having been finally settled.

Think of a parcel network that confirms delivery immediately while participating carriers settle their accounts later. The analogy concerns the separation of events, not the timing of parcel delivery: the customer-facing outcome can precede the financial accounting between institutions.

Clearing is not interbank settlement

FPS provides near-real-time payments continuously, 24 hours a day, seven days a week, while participating institutions' obligations settle on a deferred net basis through three RTGS settlement cycles each business day, as explained in the Bank of England's payment settlement overview.

RTGS is the settlement infrastructure, not the customer payment channel. Your customer may receive confirmation while your institution, or its settlement provider, still needs to manage the resulting net obligation.

For an indirectly connected firm, don't assume these mechanics are irrelevant because a partner handles settlement. Translate the partner's arrangements into your own funding triggers, reporting requirements and escalation procedures.

Map the payment types separately

FPS supports individual payments, standing orders, forward-dated payments and direct corporate access payments, as described in the ONS methodology for industry-to-industry payments. Returns also need an explicit place in your processing design.

• Immediate instructions: Define when authentication, screening and release decisions occur.
• Scheduled instructions: Specify what is checked when an instruction is created and what is checked again before execution.
• Returns and exceptions: Establish how staff investigate the original transaction, update records and communicate with customers.

Build reconciliation around distinct transaction states. Your ledger should let an investigator distinguish an instruction received, a payment accepted, a customer account updated and an institutional obligation reconciled.

If your proposition spans jurisdictions, don't copy these assumptions into another rail. The operating-model assessment for a SEPA bank account should remain separate, even when the customer interface looks similar. A common interface doesn't establish common settlement mechanics, liability or exception handling.

Scale, Growth and What the Numbers Mean for Participants

Raw volume is the weakest argument for offering Faster Payments. The same figures that make the rail attractive as a distribution channel also set the bar for the capacity evidence an authorisation team will expect to see.

Pay.UK recorded 5,088,449 thousand payments in 2024, approximately 5.09 billion, up 9.0%, including 4,274,967 thousand Single Immediate Payments, 412,344 thousand forward-dated payments and 5,421 thousand returns, with 45 directly connected customers at year-end, in its annual payment statistics.

Scale like that kills casual capacity assumptions.

Category confusion is where most forecasts go wrong. UK Finance's figures put Faster Payments and other remote-banking payments at 5.6 billion transactions in 2024, up 14%, making that combined category the second most frequently used payment method, while 50% of UK business payments used Faster Payments; Pay.UK subsequently reported almost 1.4 billion FPS payments in the second quarter of 2025, up 8.9%, with value exceeding £1.2 trillion, up 13.6%, in its quarterly statistical reporting.

Keep the scheme total and the broader remote-banking category separate in your board paper. They describe different populations, and selecting whichever figure makes the opportunity appear larger is exactly the kind of framing reviewers notice.

The 50% business-payments finding supports a proposition built around payroll, supplier payments, refunds and account funding. It does not mean those use cases share a processing pattern. Pressure-test each on its own terms: payroll arrives in clustered instructions and creates a concentrated investigation workload if processing stalls; supplier settlement turns on payment values, approval chains and funding timing; refund activity depends on staff matching the original transaction and blocking duplicate execution; account funding links incoming and outgoing transfers that should be assessed together rather than as isolated events.

High adoption is a reason to strengthen contingency arrangements, not a reason to assume the infrastructure will make your service resilient.

Prepare evidence showing how forecast volumes translate into system capacity, staffing and provider commitments. I'd reject a business plan that forecasts payment revenue without explaining how operations will handle exceptions at the same scale.

The £1 Million Limit and Why It Matters for Your Operating Model

When the scheme raised its ceiling from £250,000 to £1 million on 8 February 2022, Barclays capped individual and some business customers at £50,000 and kept the full amount for certain high-value customers. The Bank of England describes that episode in its analysis of substitution between RTGS and instant payment schemes, which also found CHAPS volumes in that value range running 10.7% to 13.7% lower than the estimated counterfactual between February 2022 and September 2024.

Read those findings together and the ceiling's real function comes into view: it is the outer boundary of a limit architecture you have to design, justify and enforce.

The substitution data shows customers moved value onto instant rails once permitted. That migration relocates your operational dependencies, because staffing, funding timing and investigation workload follow the rail. CHAPS cannot be waved in as an automatic fallback without assessing availability, access arrangements, customer consent and staff procedures, and your contingency plan should name the customer outcomes that remain achievable when the preferred route is unavailable.

Build a layered limit structure

The Barclays setting is dated and products have moved on since. What it demonstrates is permanent: a scheme maximum, a provider's technical capability and a particular customer's permitted amount are three different numbers, and your framework must account for each.

Work the layers in that order when an instruction arrives. An interface that accepts a payment before checking whether the proposed route can carry it has already failed the customer, and instructions above the ceiling need a different route entirely.

Explain the rationale, not just the setting

A limits paper should connect customer characteristics, expected payment purposes, fraud exposure and funding capacity. The value that looks routine for an established corporate treasury customer can warrant a review trigger on an account opened last month.

Three disciplines do most of the work. Exceptions need an owner: record who may approve an increase, what evidence they review and when the approval expires. Disclosures need alignment: the customer journey, contractual terms and support scripts should describe identical restrictions. Enforcement needs testing: API, portal and operational channels must apply the same controls.

Set each figure from your own risk assessment. "A competitor uses it" is the justification that unravels first under FCA questioning.

APP Fraud, Reimbursement and Who Decides When Things Go Wrong

APP fraud is where Faster Payments stops looking like a product feature and starts behaving like an evidence problem.

A customer authorises a transfer after a fraudster impersonates a supplier. The sending PSP holds the payment journey, warnings, authentication events and release decision. The receiving PSP holds the beneficiary's onboarding file, incoming-account activity and any restriction history. The claim crosses that boundary, so neither firm can prove the case from the other firm's ledger.

Start with the decision, not the claim form

Since 7 October 2024, mandatory reimbursement has applied to in-scope APP scams sent through Faster Payments, with the sending PSP assessing the claim, ordinarily processing it within five business days, and able to recover 50% from the receiving PSP under the PSR's consolidated reimbursement policy.

Treat that as a binding reimbursement arrangement for in-scope claims. Disputes outside scope still need a route, a clock and a named owner. Your procedure should separate four decisions cleanly: scope assessment, applicable exceptions, customer communication and inter-firm recovery.

In the supplier impersonation case, the sending firm should be able to reconstruct why the payment was released. The receiving firm should be able to explain why the beneficiary account was opened, what monitoring fired and what controls were applied. A liability challenge needs an evidential basis; “the customer authorised it” is an assertion, not an investigation.

Low incidence still creates funded exposure

The PSR's dataset covering approximately 95% of FPS value and volume in 2022 found that APP-fraud payments represented less than 0.1% of FPS volume, while Faster Payments accounted for 98% of APP-fraud payments, according to its APP-fraud performance report.

UK Finance recorded 486,050 APP-fraud payments through Faster Payments worth £460.9 million in 2025, increases of 17% in volume and 20% in value, in its UK Finance fraud report.

Reimbursement allocates loss after the event. Prevention sits earlier, in onboarding, warnings, intervention, recovery and complaint handling. Budget for investigation capacity and reimbursement funding before the first claim tests whether anyone owns the queue.

For a smaller PSP, give receiving-account controls the same management attention as outbound authentication. Strong customer-facing warnings will not compensate for weak beneficiary due diligence or an investigation inbox that three teams assume somebody else owns.

From Speed to Governability, Controls, Resilience and the Modernisation Agenda

A credible Faster Payments proposition joins treasury, fraud operations, customer support and technology under an explicit allocation of responsibility. The objective isn't maximum automation. It's controlled execution with evidence that management can reconstruct.

The settlement mechanics, limit architecture and reimbursement arrangements already described should appear in the same risk assessment. Otherwise, teams can approve individually reasonable controls that don't work together.

Faster Payments Risk Allocation at a Glance

The table below is a recommended evidence framework, not a statement that every artefact is a prescribed regulatory submission.

Separate operational controls from intentions

An application should distinguish implemented, tested, contracted, configured and planned arrangements. These statuses aren't interchangeable. A supplier roadmap doesn't establish that your firm has a functioning control.

Connect the assessment to the underlying banking core systems. Investigators need consistent records across the payment gateway, customer ledger, fraud engine and case-management system; a dashboard alone won't demonstrate that consistency.

• Intervention testing: Check whether staff can act on an alert before the relevant execution decision.
• Continuity testing: Establish who can suspend affected services, reconcile uncertain outcomes and authorise restoration.
• Management reporting: Distinguish blocked attempts, executed suspicious payments, customer losses and reimbursement expenditure.

Apply frameworks according to scope

Map senior accountability to the Senior Managers and Certification Regime where applicable, rather than assuming every payment firm has the same governance regime. Use DORA-style dependency, continuity and exit analysis as a design discipline, but don't label it a UK obligation without establishing applicability.

Treat the Payments Forward Plan and industry delivery-body proposals as modernisation matters to verify and monitor, not as evidence that a dependency has already changed. A policy announcement, implementation milestone and operational service are different things.

The strongest application narrative is candid: this is what works, this is what remains unfinished, and this is who can stop launch if the evidence isn't sufficient.

A Pre-Application Checklist for Offering Faster Payments

Bring a decision pack to the steering committee, not a folder of unapproved policies. Each workstream should end with an artefact, an owner and an explicit decision about readiness.

The workplan should match the relevant FCA authorisation route, variation of permission or internal product approval. Don't assume that adding a new payment capability fits within an existing regulatory assessment without reviewing the proposed activities.

Establish the legal and operational foundation

• Confirm the perimeter and entities. Document the services, customer types and role of each entity. Produce an activities assessment and funds-flow diagram that agree with the business plan and customer terms.
• Assign accountable management. Name the owners of liquidity, fraud, reimbursement, outsourcing and service continuity. Prepare a responsibility matrix, relevant SMF mapping where applicable, and deputising arrangements for material decisions.
• Validate participant and supplier arrangements. Record what your access provider, processor and other critical suppliers undertake. Prepare contracts, service descriptions, escalation contacts, oversight requirements and an exit assessment, with unresolved negotiations clearly identified.

Demonstrate financial and control readiness

Prepare a treasury pack that explains funding assumptions, the relationship with settlement arrangements and the response to constrained liquidity. Include the relevant prefunding or RTGS balance arrangements for your participation model, rather than borrowing terminology from a directly settling institution.

Your fraud evidence should demonstrate behaviour, not merely list purchased products:

• Test preventive controls. Show how confirmation-of-payee or equivalent name checking, authentication, device signals, behavioural analytics and velocity rules interact. Retain scenario results and approved changes.
• Exercise receiving-account monitoring. Test suspicious incoming flows, rapid onward movement and the escalation of beneficiary concerns. Record who can restrict activity and how staff preserve evidence.
• Rehearse reimbursement decisions. Run a hypothetical claim through intake, scope assessment, investigation, customer communication and inter-firm recovery. Produce a sample case file that exposes missing information before launch.

Make the launch decision auditable

Use a control-status register to distinguish functioning arrangements from future work. Attach evidence references, responsible owners, dependencies and the consequences of delay; don't hide unfinished controls in narrative appendices.

• Reconcile the application pack. Check that projections, staffing, system descriptions, contracts and policies reflect the same approved operating model.
• Prepare management for challenge. Ask responsible executives to explain failure scenarios without relying on the policy author to answer for them.
• Track regulatory change. Maintain a dated assessment of relevant PSR developments and payments-modernisation announcements. Record whether each item is binding, proposed, guidance or commentary, and what decision it requires.

Finish with a documented launch recommendation that states residual risks and conditions. If a material control remains untested, management should decide explicitly whether launch must wait. An unresolved issue isn't less significant because the application has been submitted.

---

Glentorion helps financial and crypto businesses scope regulatory routes, prepare and review application packs, and ready management teams for regulator interviews. For a Faster Payments proposition, that means connecting the business model, supplier responsibilities, control evidence and unresolved launch decisions. Visit Glentorion to discuss a clearly scoped authorisation-readiness review.