Faster Payments Service (FPS): Definition and Use in Compliance

What is Faster Payments Service (FPS)?

Faster Payments Service (FPS) is the UK's real-time payment scheme for sterling transfers between bank accounts. Launched in May 2008 and run by Pay.UK, it clears most payments in under 15 seconds and operates every hour of every day, including weekends and holidays.

Before FPS, a standard electronic transfer through Bacs took three working days. A payment sent Friday afternoon would not arrive until the following Wednesday. FPS collapsed that to near-instant, which changed both customer expectations and the fraud threat model.

The scheme handles single immediate payments, standing orders, and future-dated transfers. It carries everything from a £20 split-the-bill transfer to a £900,000 property deposit. The scheme-level cap is £1 million, though banks routinely set lower limits for retail customers. A high-street bank might cap app-based transfers at £25,000 per day while letting customers raise it temporarily through identity checks.

Settlement happens centrally. Participants hold accounts at the Bank of England, and net positions settle several times a day, while the customer sees the money arrive instantly. That gap between instant customer credit and deferred interbank settlement is part of why the scheme works at scale.

For a compliance officer, the defining feature is irreversibility. Once funds credit the recipient, pulling them back requires the receiving bank's cooperation and the money still being there. In practice it usually is not. This single fact drives most of the control design around FPS, and it is why real-time scoring matters more here than on slower rails like SEPA credit transfers or card payments with chargeback rights.

How is Faster Payments Service (FPS) used in practice?

Banks and fintechs use FPS as the default rail for UK consumer and small-business payments. When you pay a friend through your banking app and the money lands before you lock your phone, that is Faster Payments.

The compliance work happens in the milliseconds before the payment leaves. A real-time scoring engine evaluates the transaction against device fingerprint, login behavior, payee history, amount, and time of day. A first payment to a new payee for £8,000 at 2 a.m. looks very different from a £40 transfer to a saved contact.

Consider a concrete case. A customer receives a call from someone claiming to be the bank's fraud team, who convinces them to move savings to a "safe account." This is classic APP fraud. The customer authorizes the payment willingly, so traditional authentication passes. The control that catches it is behavioral: an out-of-pattern transfer, a new payee, a round-number amount, often preceded by the customer disabling other safeguards.

Receiving banks run their own controls. Money landing in a recently opened account, then immediately forwarded to three other accounts, is textbook mule network activity. Confirmation of Payee, which checks whether the account name matches the number, blocks a chunk of misdirected and impersonation payments at the point of setup.

Fraud teams also tune thresholds constantly. Set them tight and you block legitimate customers, generating complaints and abandoned payments. Set them loose and losses climb. Most firms accept some friction on high-risk profiles and keep trusted, low-value flows frictionless.

Faster Payments Service (FPS) in regulatory context

FPS sits under several overlapping UK regimes, and the regulatory pressure has grown sharply. The scheme itself is overseen by the Bank of England as systemically important, while the Payment Systems Regulator handles competition and consumer protection.

The defining recent change is the PSR's mandatory reimbursement rule, effective October 2024. For in-scope APP scam claims on Faster Payments, victims must be reimbursed, and liability splits 50/50 between the sending and receiving firms. The Payment Systems Regulator set this up to force both sides of a payment to invest in prevention, since the receiving bank now shares the cost of letting a mule account operate.

That liability split reshaped controls. A receiving bank that previously had little incentive to scrutinize inbound credits now carries direct financial exposure for hosting mules. Many firms tightened account opening, ramped up KYC checks, and built monitoring for rapid in-and-out fund flows.

FPS payments also fall under UK money laundering regulations and the Strong Customer Authentication requirements carried over from PSD2. Suspicious activity still routes through the standard SAR process to the National Crime Agency.

Take a practical example: a bank reimburses a £30,000 APP fraud victim, recovers £15,000 from the receiving bank under the split, and files a SAR documenting the mule account. The whole sequence, reimbursement decision, liability claim, and intelligence report, has to be evidenced and auditable, because both the PSR and the FCA can ask to see it.

Common challenges and how to address them

The core challenge is time. A monitoring system that needs two minutes to reach a decision is useless on a rail that settles in fifteen seconds. Firms that bolt batch-era controls onto FPS lose money and miss fraud.

The fix is real-time scoring with a clear action hierarchy. Score every payment in-flight, then route by risk: auto-approve the safe majority, warn or step up the uncertain middle, hold or block the clear threats. The trick is keeping the friction band narrow so most customers never feel it.

False positives are the second problem. Aggressive rules block legitimate payments, and every blocked payment is a complaint, a call, and a frustrated customer who may leave. Tuning false positive rates without opening gaps for fraud is constant work. Behavioral models that learn each customer's normal pattern beat static rules here, because a £5,000 payment is routine for one customer and a red flag for another.

A third challenge is the two-sided nature of the new liability rule. You can run excellent outbound controls and still pay out because your inbound mule detection is weak. Receiving-side monitoring, fast account-opening checks, entity resolution to spot synthetic identities, and rapid-dispersal alerts all matter now in a way they did not before 2024.

Then there is data fragmentation. Fraud signals, KYC records, and transaction history often live in separate systems. A scoring engine that cannot see the customer's full picture in real time will make worse calls. Unifying that data, or at least exposing it to the decision engine at payment time, is where many firms still struggle. Confirmation of Payee adoption and shared industry intelligence on mule accounts help close the gap.

Related terms and concepts

FPS belongs to a family of real-time payment systems that share the same compliance headache: speed plus irreversibility. The US equivalents are RTP and the newer FedNow Service, India runs UPI, and the eurozone has SEPA Instant Credit Transfer. Each forces the same shift from overnight batch review to in-flight decisioning.

The fraud typologies most associated with FPS are APP fraud and the mule account networks that receive and disperse stolen funds. Understanding these typologies is the starting point for designing FPS controls.

On the detection side, the relevant concepts are transaction monitoring, behavioral analytics, and network analysis for tracing how money moves through layered accounts. When monitoring flags something, the output is an alert that may escalate to a SAR.

Authentication ties in through Strong Customer Authentication, and onboarding controls draw on KYC and identity verification. Anyone building or auditing FPS controls should also read up on real-time payment fraud detection more broadly, since the same patterns recur across every instant rail. The regulatory anchor remains the PSR reimbursement regime, which makes both sending and receiving firms accountable for what happens on the network.