Faster Payments: near real time for everyday payments

Faster Payments moves sterling between UK bank accounts in seconds. It was launched in 2008 because a routine payment between two UK banks could still take three days through BACS. Today a customer can send sterling to another UK bank account at any hour, on any day, including weekends and bank holidays, and the beneficiary account is normally credited within seconds. The payment is addressed with a sort code, which identifies the receiving bank and branch, and an account number, which identifies the beneficiary account. The scheme requires a payment to complete within two hours, although in practice it normally completes in seconds, and a payment that has not completed within that window must be investigated rather than assumed lost. Follow one payment end to end. A customer in Manchester needs to pay a supplier in London 1,250 pounds at 21:30 on a Saturday, and the supplier needs the money tonight. The customer enters the sort code, account number, amount and reference in the banking app. The sending bank checks the balance, the daily limit and the payee details. The bank runs a Confirmation of Payee check, comparing the name the customer typed with the name held on the receiving account, and it runs sanctions and fraud screening before anything leaves the bank. If every check passes, the sending bank sends the payment instruction to the Faster Payments central infrastructure. In ISO 20022 terms the instruction is a pacs.008 customer credit transfer; the live Faster Payments service runs on its own message format today, and ISO 20022 adoption is part of the Interbank Infrastructure Renewal programme. The receiving bank validates the account, credits the supplier 1,250 pounds within seconds, and returns a pacs.002 payment status report confirming acceptance, and the sending bank then shows the customer a confirmation. The supplier sees the money before 21:31, on a Saturday night. Settlement between banks is deferred and netted, and the distinction between customer credit and interbank settlement is the key to the design. The customer sees instant credit, but the banks do not settle each payment one by one. Instead, Faster Payments calculates each bank's net position against all the other banks at defined settlement times during the day, and those net amounts settle in central bank money through the Bank of England. Netting keeps the liquidity each bank needs far lower than gross settlement would. For reconciliation, the analyst must match three things: the customer payments sent, the pacs.002 confirmations received, and the net settlement amounts at each settlement cycle. A payment with a pacs.002 but no net settlement entry is a payment the settlement has not yet caught up with, not a payment that has failed. A worked example shows the netting. During one settlement cycle, Bank A sends 200 million pounds of Faster Payments to Bank B, and Bank B sends 160 million pounds to Bank A. Instead of settling 360 million pounds in two gross movements, Faster Payments calculates the net position: Bank A owes Bank B 40 million pounds. A single settlement of 40 million pounds moves through the Bank of England, and the cycle is complete. The netting saved 320 million pounds of liquidity, and the final settlement is in central bank money, so there is no settlement risk between the two banks. The analyst must design the reconciliation around the net settlement, not the gross payments, because the Bank of England statement will show the net amount, not the individual payments. Limits and timing rules decide which payments can use Faster Payments. The scheme limit is currently one million pounds per payment, but most banks set lower limits for their own customers, and the limit can depend on the channel, so mobile banking may allow less than online banking, and a payment to a new payee may allow less than a payment to an existing payee. The scheme requires a payment to complete within two hours, although in practice it normally completes in seconds. A payment that has not completed within that window must be investigated rather than assumed lost. A payment above the limit must be routed to CHAPS, and the screen should explain that it will cost more and will be processed as a high value payment. The analyst must show the applicable limit before the customer types the amount, because a customer who types 1.2 million pounds and is then told the limit is 1 million has wasted their time. The debit and credit entries are straightforward but worth writing down. On the books of the sending bank, the customer's account is debited 1,250 pounds and the bank's settlement account is credited. On the books of the Faster Payments central infrastructure, the sending bank's net position is debited and the receiving bank's net position is credited. On the books of the receiving bank, the settlement account is debited and the supplier's account is credited 1,250 pounds. At the settlement cycle, the Bank of England debits the sending bank's settlement account for its net position and credits the receiving bank's settlement account. Every entry balances, and the full amount arrives because no bank in the chain deducts a charge from a Faster Payments payment. Exceptions follow the ISO 20022 message set, and each one has a distinct handling path. A reject happens before the money moves, when the sending bank or the scheme refuses the payment, for example an invalid sort code, a closed account, or a failed sanctions screen, and it is reported with a pacs.002 status report carrying a reject code. A return happens after receipt, when the receiving bank cannot apply the payment, and the money comes back with a pacs.004 payment return message. A recall is a request to get the money back after it was credited, sent as a camt.056 cancellation request, and the receiving bank answers with a camt.029 resolution of investigation, which can accept or refuse the recall. A timeout is different again: if no pacs.002 arrives within the expected window, the payment is in an unknown state, and operations must trace it before deciding whether to resend, because resending blindly risks a duplicate payment. A timeout deserves a worked example, because it is the exception analysts handle worst. The customer sends 1,250 pounds at 21:30 on a Saturday. The sending bank sends the instruction, but no confirmation arrives within the expected window. The payment is in an unknown state: it may have been credited and the confirmation lost, or it may never have been sent. The correct procedure is to query the Faster Payments central infrastructure for the payment status using the end to end reference, wait for a definitive answer, and only then decide whether to resend. The product must show the payment as under investigation, not as failed, until that answer arrives, and the customer communication must say the same. Resending blindly risks paying the supplier twice, and the recovery then depends on the supplier's goodwill. Fraud is the risk the analyst must design for, because speed leaves little time to recover a payment. Authorised push payment fraud is the main threat, where a customer is tricked into sending money to a fraudster's account. Confirmation of Payee is the first defence: a full match gives confidence, a close match asks the customer to check the spelling, and no match is a clear warning to stop and verify the payee by a trusted route. The reimbursement rules require banks to refund victims in defined circumstances, with the cost shared between the sending and receiving banks, and the maximum reimbursement is 85,000 pounds. The flow must record the Confirmation of Payee result, the warning shown, and the customer's decision, because that record is the evidence the bank needs if the customer later claims a refund. A worked example with the fraud case shows the design. The customer sets up a new payee, a builder, and types the sort code, account number and the builder's name. Confirmation of Payee returns no match. The screen warns the customer that the name does not match the account, and the customer realises they transposed two digits in the sort code. They correct it, the check returns a match, and the payment goes through. Without the check, the 1,250 pounds would have gone to a stranger's account, and the recall would have depended on that stranger's consent. The analyst must design the no match warning to be impossible to miss and hard to dismiss, because a warning the customer clicks through without reading is no warning at all. The analyst must also confirm the limits per bank and channel, handle timeouts and duplicates without resending blindly, and reconcile every payment against its pacs.002 confirmation and the net settlement. The reconciliation has three legs: the customer payments sent, the pacs.002 confirmations received, and the net settlement amounts at each cycle. A payment with a pacs.002 but no net settlement entry is waiting for the next cycle. A payment with no pacs.002 is under investigation. A payment in the net settlement but with no pacs.002 is a defect that operations must raise immediately. The analyst checklist for Faster Payments is therefore: the limit per channel, the Confirmation of Payee result recorded, the timeout procedure, the duplicate check, and the three legged reconciliation.