Faster Payments vs Bacs vs CHAPS: UK API Guide

From November 2026, the Bank of England will reject any CHAPS payment whose creditor address is fully unstructured. If your payout service builds addresses by concatenating five free-text lines into AdrLine, those payments will fail at the scheme in about eight weeks, and your bank or BaaS provider will probably not warn you first.

None of the pages currently ranking for "Faster Payments vs Bacs vs CHAPS" mentions this. They are treasury explainers: Faster Payments is quick, Bacs is cheap, CHAPS is for houses. All true, and no help if you are writing the code that sends, tracks and reconciles money across all three. This guide covers what an engineer actually needs: message formats, limits, cut-offs, settlement, return handling, fraud liability, and how the main UK payment APIs decide which rail your payment takes.

What Is the Difference Between Faster Payments, Bacs and CHAPS?

All three are UK sterling interbank schemes that settle in central bank money at the Bank of England. Everything else about them differs, and each difference has a consequence for how you design a system.

The volume row explains the rest. Bacs still moves more payments than Faster Payments, mostly because 5.03bn of its 6.86bn items in 2025 were Direct Debits. CHAPS moves under 1% of the payments by count and roughly 90% of the value across the three schemes, at an average of £1.76m per payment. Pay.UK's 2025 annual statistics are the source for all three rows.

Faster Payments Limits, Settlement and Timing in 2026

The Faster Payments scheme limit is £1m per payment. It was raised from £250,000 on 8 February 2022 and has not changed since. That is a scheme ceiling, not what your customer gets: banks set their own limits by channel and account type, so a personal online payment at one high-street bank tops out at £25,000 while business channels elsewhere go to the full £1m. If you surface a limit in your UI, fetch it from your provider rather than hardcoding the scheme figure.

Faster Payments still runs on ISO 8583, not ISO 20022. The fields you care about map to numbered tags: the 18-character payment reference is tag 120, the 31-character end-to-end ID is tag 62, and 140 characters of remittance data sit in tag 121. Pay.UK publishes an 8583-to-20022 conversion library, but the live scheme has not migrated. That 18-character reference is the hard constraint most teams trip over. Put an invoice number plus a customer ID in it and you will truncate something.

The receiving bank must answer each payment in seconds with one of three responses. It can give an unqualified accept, a qualified accept with a code saying the funds will land same day, next calendar day or next working day, or a reject with a reason code. The payer must be told the outcome within 15 seconds. A qualified accept is not a failure, but most payout state machines I have reviewed treat "accepted" as "credited". Pay.UK itself only says funds are "usually available almost immediately, although they can sometimes take up to two hours". There is no hard two-hour rule in the scheme documents.

Returns are the other trap. A Faster Payments return is a new payment that references the original, sent one to three working days later. It is not a status change on your original record. Your ledger needs an inbound credit that it can match to a prior outbound debit, not a status = returned flag that flips on its own.

Standing orders and forward-dated payments behave differently from single immediate payments. The central infrastructure does not warehouse future-dated payments, so your bank holds them and sends them on the execution date, mostly between 00:00 and 06:00 on weekdays. In 2025 those two types made up about 803m of the 5.55bn Faster Payments.

Settlement is deferred net, three times per banking day. Each direct participant sets a Net Sender Cap and must hold the same amount in cash in a pre-funded account at the Bank of England: a £50m cap needs £50m prefunded. That is why only 47 institutions connect directly and everyone else goes through a sponsor.

How Bacs Direct Debit Works: The 3-Day Cycle Explained

Bacs is a file-based batch system, and its timing follows from that. Day 1 is input day: your file must reach Bacs between 07:00 and 22:30, and you can withdraw it until 22:30 the same day. Day 2 is processing day. Day 3 is entry day, when both accounts move at once. Only UK banking days count, so a file submitted on Friday is processed on Monday and settles on Tuesday. You can submit instructions up to 30 days ahead.

The file format is Standard 18. Data records are 100 characters wide for single-day files and 106 for multi-day files, and every field has a fixed position:

pos 1–6     destination sort code
pos 7–14    destination account number
pos 16–17   transaction code  (01 first DD, 17 recurring, 18 re-presented,
                               19 final, 99 credit, 0N/0C/0S AUDDIS)
pos 36–46   amount in pence, zero-padded
pos 65–82   reference (18 chars; DDs need 6+ alphanumerics, not all the same)
pos 83–100  destination account name (18 chars)
pos 101–106 processing day as bYYDDD (multi-day files only)

You submit under a six-digit Service User Number (SUN), issued through a sponsoring bank, over Bacstel-IP or through an approved bureau. AUDDIS and non-AUDDIS instructions need separate SUNs.

Almost nobody should build this directly today. Stripe and GoCardless wrap Bacs Direct Debit behind a mandate API, and the timings they document are the ones you will actually experience. Stripe takes four business days to confirm success or failure on an existing mandate and seven on a new one, with a 20:00 London cut-off. GoCardless needs the payment created by 16:00 three working days before the charge date, and pays out two working days after it. Its payment status enum runs pending_customer_approval, pending_submission, submitted, confirmed, paid_out, failed, charged_back, cancelled and customer_approval_denied. Its docs admit that a payment can fail after confirmed if the banks send the failure late. Design for that: confirmed is not final.

Bacs ARUDD, ADDACS and AUDDIS Reason Codes

Bacs reports failures through a set of report types, each with its own single-character codes. The ones that matter most:

Two rules are easy to miss. You must act on an ADDACS advice within three working days of it being made available. And mandates go dormant: the paying bank holds a mandate for a minimum of 24 months from receipt or last collection. Many older guides still say 13 months, but Bacs raised the figure in June 2020 and the current FAQ says 24. Your retry and dunning logic should read these codes directly. Retrying an ARUDD 0 makes sense, while retrying a B or 2 is a complaint waiting to happen.

The Direct Debit Guarantee has no time limit on indemnity claims, and Stripe's docs say plainly that Bacs disputes cannot be contested with evidence. That shapes the product decision: Bacs Direct Debit suits collecting a known amount from a known customer, and it is dangerous for anything where the goods cannot be recovered.

CHAPS Cut-Off Times and ISO 20022 Enhanced Data Rules

CHAPS runs in the Bank of England's RTGS system from 06:00 to 18:00, Monday to Friday, with a 17:40 cut-off for customer payments (pacs.008). Your provider's window will be narrower. ClearBank documents 08:00 to 17:00; Modulr's CHAPS cut-off is 16:00, after which payments go the next business day. Opening moves to 01:30 from September 2027, and the Bank's May 2026 consultation puts weekend settlement no earlier than 2029.

CHAPS migrated to ISO 20022 in June 2023, and the enhanced-data rules are now tightening. The dates below come from the Bank of England's ISO 20022 pages as updated in August 2026:

Structured remittance data was also meant to become mandatory in November 2026. In July 2026 the Bank dropped that and did not set a new date. I have covered the underlying message types in the ISO 20022 guide to pain.001 vs pacs.008.

You can see this change in real APIs. ClearBank deprecated its v5 CHAPS endpoints on 13 May 2026, and they stop working on 13 November 2026. The v6 customer-payments endpoint makes creditor.postalAddress mandatory, requires purpose and categoryPurpose, and renames instructedAmount to interBankSettlementAmount. If you are on v5, that is your deadline.

On cost, the Bank charges participants 48.7p per CHAPS payment in 2026. What a bank charges its customers is typically quoted at £20 to £35. None of the BaaS providers I checked publishes its CHAPS price in its developer docs.

How Do Payment APIs Choose Between FPS, Bacs and CHAPS?

This is the question the ranking articles skip entirely, and the answer varies more than you would expect. There are three models: you pick the rail, the endpoint picks it, or the provider picks it.

Where the provider auto-routes, the rail becomes something you infer after the fact, and your reconciliation has to cope. A £1.2m Modulr payment to an FPS-reachable account goes CHAPS and misses the 16:00 cut-off. A £1.2m Stripe payout cannot go at all.

The same abstraction applies to failures. None of these providers passes the raw FPS reject code through. Modulr maps returns to its own list (BENACCCLOSED, BENSCANUNKNOWN, BENDECEASED); Wise sends failure_reason_code values such as ACCOUNT_CLOSED and WRONG_NAME on a transfers#payout-failure webhook, possibly while the transfer still reads outgoing_payment_sent. If you run more than one provider, which I would recommend for any serious payout volume, you need your own normalised return-reason enum and a mapping table per provider. For request retries across them, the patterns in the payment API idempotency keys guide apply unchanged.

Confirmation of Payee and APP Fraud Reimbursement in the UK

Since 7 October 2024 the PSR's APP scam rules make the sending and receiving PSP split reimbursement 50:50, up to £85,000 per claim, with an excess of up to £100 and a five-business-day refund clock. The rules cover Faster Payments and CHAPS. Bacs is outside scope. The PSR is being folded into the FCA, but it keeps these powers until the transfer happens.

That liability is why banks now hold payments. Since 9 October 2024, regulation 86 of the Payment Services Regulations 2017 lets a bank delay an outbound payment on reasonable suspicion of fraud until the end of the fourth business day after receipt. For your system, that means an "instant" payment can sit in a provider's held state for four days. ClearBank raises OutboundHeldTransaction, and Modulr raises a PAYMENTCOMPLIANCESTATUS webhook. If your product promises instant payouts, that promise needs a caveat and a UI state for "held by bank".

Confirmation of Payee is the other fraud control you integrate. The protocol returns Matched: true, or Matched: false with a reason code, and the codes are more granular than most UIs show:

ANNM  no match                MBAM  close match (name returned)
BANM  match, but business     PANM  match, but personal
BAMM  close, but business     PAMM  close, but personal
AC01  account does not exist  OPTO  payee opted out
ACNS  account not supported   CASS  account switched
IVCR  secondary ref not found SCNS  sort code not owned by responder

Providers repackage these codes. Griffin returns match | close-match | no-match with a reason such as match-name-personal-business. Modulr has 14 result values, including ACCOUNT_SWITCHED and NOT_ENROLLED. BANM and PANM are Matched: false on the wire, even though some providers show them as close matches. Under the reimbursement rules, what you showed the payer and whether they overrode a warning can decide who pays, so store the raw code, not just a traffic-light colour.

Will Faster Payments Replace Bacs? My Prediction for 2030

My view: Bacs Direct Debit will still be the default for UK recurring payments in 2030, and anyone planning a Bacs sunset in their architecture is planning for something that is not coming.

The evidence is institutional, not technical. Pay.UK extended the Vocalink contracts for Faster Payments, Bacs and cheque imaging "into the early 2030s" in December 2025. The New Payments Architecture, the programme meant to replace both, has in effect been wound up. Its successor is a Retail Payments Infrastructure Board that finished consulting on 11 September 2026 and has no go-live date and no named message standard. Meanwhile Direct Debit hit a record 5 billion transactions in 2025.

Commercial variable recurring payments are the credible challenger, and I have written about where VRP beats Direct Debit. But VRP wins on the edges, such as variable amounts, instant settlement and in-app revocation, not on utility bills. The practical consequence is that you should build a rail-agnostic payments core now. Model mandates, instructions, settlements and returns as separate entities, key everything on your own IDs, and treat the scheme as an attribute. You will be running three schemes for the rest of this decade, plus whatever the new infrastructure turns out to be.

What This Means for Payments Teams in the UK

1. Audit CHAPS address construction this week. Check every code path that builds a creditor address for a structured TwnNm and Ctry. November 2026 rejections will come from the scheme, not your provider. 2. If you are on ClearBank CHAPS v5, migrate to v6 before 13 November 2026. Map purpose and categoryPurpose now, even though the all-payments purpose code mandate is not until November 2027. 3. Stop treating "sent" as "credited". FPS qualified accepts, Wise's outgoing_payment_sent and GoCardless's late failures after confirmed all break that assumption. 4. Model returns as new inbound payments linked to the original, not as status flips. That holds for Faster Payments returns and for Bacs ARUDD alike. 5. Add a "held" state for the four-business-day fraud delay, with customer-facing copy. 6. Keep a normalised failure enum across providers, and persist raw CoP reason codes alongside the payer's response. 7. Validate the 18-character FPS reference at input, not at submission.

None of this is exotic. A reference truncated at 18 characters and a payout marked final because an API said "sent" are the two failures I would check for first in any UK payouts service, and both are written into the scheme rules above. More on UK payment infrastructure from Tom Wang.