Choosing the right system: a worked example

Consider a small business in Manchester that needs to make four payments on the same morning, fifty pounds to a local supplier for stationery, two thousand pounds to a consultant, one hundred and fifty thousand pounds as a deposit on a new office, and salaries to thirty employees on Friday. A good analyst would not send all four through the same system. The fifty pound supplier payment and the two thousand pound consultant payment would go through Faster Payments, because they are small, they need to arrive today, and they are free or cheap. The one hundred and fifty thousand pound deposit would go through CHAPS, because it is large, it must be final today, and the solicitor needs certainty that the money has settled before contracts are exchanged. The salaries would go through BACS, because there are thirty of them, they are routine, and they must arrive on Friday, which is three working days after the file is submitted on Tuesday. Follow each payment in turn. The fifty pound supplier payment is instructed at 9am, the sending bank runs Confirmation of Payee and fraud screening, sends a pacs.008 to the Faster Payments central infrastructure, and the supplier is credited within seconds. The two thousand pound consultant payment follows the same path and is credited within seconds. The one hundred and fifty thousand pound deposit is instructed at 10am, the sending bank runs the checks, sends a pacs.008 to the Bank of England, and the Bank of England debits the sending bank's settlement account and credits the receiving bank's settlement account in the same moment, so the payment is final. The solicitor confirms settlement with a pacs.002 and releases the contracts. The salaries are submitted as a BACS file on Tuesday with thirty payments totalling 45,000 pounds, and the employees are credited on Friday, the value date. Four payments, three systems, one morning, and each one arrives when it should. This example shows the decision logic an analyst should apply to every UK payment requirement. First, ask the value. Above the Faster Payments limit, CHAPS is the answer. Second, ask the urgency. If the credit must happen in seconds, choose Faster Payments; if it must be final in central bank money today, choose CHAPS; if it can wait three days, choose BACS. Third, ask the volume. If there are many payments, choose a batch system like BACS. Fourth, ask the operating hours. If the payment must move at midnight on a Sunday, choose Faster Payments, because CHAPS will be closed. Fifth, ask the cost sensitivity. If the payment is low value and high volume, choose the cheapest system that meets the timing need. Writing these five questions into the requirements document makes the system selection transparent and reviewable, which is exactly what a payments BA is expected to do. A second example shows the failure handling. The business instructs the 150,000 pound deposit through CHAPS at 2pm, but the bank's customer cut off is 1:30pm, so the payment will not settle today. The product warns the customer before submission, states that the payment will settle tomorrow, and offers Faster Payments as the alternative, because 150,000 pounds is within the Faster Payments limit. The customer chooses Faster Payments, the solicitor is credited within seconds, and the contracts are exchanged today. Without the warning, the customer would have submitted the CHAPS payment, assumed it had settled, and discovered the next morning that the contracts had not been exchanged. The warning is the difference between a product that works and a product that fails silently. The same logic applies to failure handling and customer communication. If a Faster Payments payment fails because the payee bank is not available, the app should explain the failure and offer to retry or to use another method. If a CHAPS payment is submitted after the cut off, the system should warn the user before submission and offer Faster Payments as the alternative if the amount fits, with a clear statement of when the credit will happen. If the BACS salary file has an error, the system should reject the file before submission with a clear list of the bad records, not after half the employees have been paid. These are the details that separate a payment product that works in a demo from a payment product that works in production, and they are the details this chapter has been building towards. A third example shows the property chain, which is the use case that explains CHAPS to a non specialist. A chain of three property purchases, each depending on the previous one completing, needs three CHAPS payments on the same day, each final before the next one is sent. The first buyer pays the second seller 300,000 pounds, the second seller pays the third seller 450,000 pounds, and the third seller pays the fourth 600,000 pounds. Each payment settles in central bank money through the Bank of England, each solicitor confirms settlement with a pacs.002 before releasing the keys, and the whole chain completes in a day. If any payment misses the cut off, the whole chain slips by a day, and four families, four solicitors and four removal companies are affected. That is why conveyancers insist on CHAPS, and why they confirm settlement, not just submission. The analyst's end to end checklist for any UK payment has five items. First, the system chosen and why, written down against the value, urgency, volume, operating hours and cost of the payment. Second, the message flow, naming each ISO 20022 message in order, or the BACS file steps where the payment is file based. Third, the settlement step, stating when the money is final and in what form of money. Fourth, the cut off, stated in local time, with the behaviour when it is missed and the alternative offered. Fifth, the exception paths, stating what happens on a reject, a return, a recall and a timeout, and who is told. A payment design that answers all five is a design an SME can defend in front of treasury, operations and audit, and it is the standard this chapter has been teaching. The final lesson is about the customer. The customer does not care which system moves the money; the customer cares about when the money arrives, what it costs, and whether it is certain. The analyst's job is to translate the customer's need into the right system, to make the choice visible where it matters, and to hide the complexity where it does not. A payment screen that asks the customer to choose between Faster Payments and CHAPS is a design failure; a payment screen that asks when the money must arrive and how much it is, and then picks the right rail, is a design success. That translation from business need to system choice, done well, is the core skill of a payments business analyst, and it is the skill this chapter has been building lesson by lesson.