BACS: the three day cycle that pays the nation

BACS is the batch system that has moved most UK regular payments since the late 1960s. It is still the highest volume system in the country, and it processes direct debits, direct credits and standing orders in a three day cycle. On day one, the file is submitted. On day two, the file is processed and the receiving banks are notified. On day three, the payments are debited and credited. This three day cycle is slow by modern standards, but it is predictable, cheap and reliable, and it suits payments on a schedule that do not need to arrive in seconds. Salaries, pensions, state benefits, utility bills, insurance premiums and mortgage payments all move through BACS. The three day cycle is worth walking through with a calendar. An employer runs payroll for 500 employees, 1.2 million pounds in total, to be paid on Friday. On Tuesday, day one, the employer sends the BACS file to its bank, which submits it to BACS. On Wednesday, day two, BACS validates the file, sorts the payments by receiving bank, and notifies the receiving banks. On Thursday, day three, the sending accounts are debited and the receiving accounts are credited on the value date, and the originator receives reports confirming which payments applied. The three days are working days, so a file submitted on Friday for a Monday payday will not work: the cycle needs three working days, and the payroll team must submit the file three working days before payday, not three calendar days. Bank holidays extend the timetable, and the analyst must design for the calendar, not just the cycle. If Friday is a bank holiday, a file submitted on Tuesday for a Friday payday will be credited on the following Tuesday, because the three working days are Wednesday, Thursday and the next Tuesday. The payroll team must submit the file earlier, or the employees will be paid late. The analyst must build the bank holiday calendar into the product, show the value date clearly on every screen, and warn when a bank holiday falls inside the cycle. Showing the value date clearly prevents the most common BACS failure: a payment that arrives a day late because the file went in a day late. The happy flow is file based. An originator, such as an employer running payroll or a biller collecting direct debits, builds a BACS file of many payments, and sends it to its bank, which submits it to BACS on day one. BACS validates the file, sorts the payments by receiving bank, and on day two the receiving banks are notified. On day three, the sending accounts are debited and the receiving accounts are credited on the value date, and the originator receives reports confirming which payments applied. Each file has control totals, and the number of payments and the total value must match at every step. A file with a wrong total is rejected before any payment is made, and the originator must correct and resubmit it. A file with a correct total but a bad record inside it is processed, and the bad record is reported back as an unpaid item. The direct debit is the most important product that runs on BACS, and it is the model for recurring payments in the UK. A customer gives a direct debit instruction, known as a mandate, to a biller, authorising the biller to collect variable amounts on agreed dates. The biller stores the instruction, notifies the customer before each collection, and presents the collection through BACS in the three day cycle. The mandate is set up through the Automated Direct Debit Instruction Service, known as AUDDIS, and changes and cancellations travel through the Automated Direct Debit Amendment and Cancellation Service, known as ADDACS. The customer is protected by the Direct Debit Guarantee: if a collection is wrong, the customer can get an immediate refund from their bank, and the bank then recovers the money from the biller. A worked example shows the direct debit cycle. A utility company collects 120 pounds a month from a customer for electricity. The customer signed the mandate a year ago, and the utility notified the customer ten working days before the collection, as the scheme requires. On day one the utility submits the BACS file with the collection. On day two the customer's bank is notified. On day three the customer's account is debited 120 pounds and the utility's account is credited. If the customer had insufficient funds, the collection would be reported as unpaid through ARUDD, the Automated Return of Unpaid Direct Debits, with a reason code, and the utility would decide whether to represent the collection or contact the customer. The three day cycle gives the customer time to see the collection coming and to make sure the funds are there. BACS Direct Credit is the other side of the system, and it pays most UK salaries. An employer sends a file of salary payments to its bank, the bank sends the file to BACS, and the employees are credited on the third day, on the value date. The employer must submit the file three working days before payday, so payroll teams work to a strict timetable, and a file submitted late means salaries arrive late. The analyst must design for the calendar, not just the cycle: bank holidays and weekends extend the timetable, because the three days are working days. Showing the value date clearly prevents the most common BACS failure: a payment that arrives a day late because the file went in a day late. A salary that arrives a day late is not a minor inconvenience; it is a missed mortgage payment for the employee. Exceptions in BACS arrive as reports, each with a distinct handling path. Unpaid direct debits are reported through the Automated Return of Unpaid Direct Debits, known as ARUDD, which carries a reason code for each unpaid item, for example the instruction was cancelled, the account had insufficient funds, or the payer asked the bank to refer the item. The biller must read the ARUDD report, stop collections where the instruction is cancelled, and decide whether to represent the payment or contact the customer. A recall reverses a payment already applied, and it is handled through the scheme's recall process with the receiving bank, not by sending a second file. A duplicate file is a real risk: if the same file is submitted twice, the payments are collected twice, so the originator must use unique file references and the bank must check for duplicates before the file enters the cycle. The Direct Debit indemnity is the path to understand best. If a customer claims a direct debit was taken in error, or without authority, the bank refunds the customer immediately under the Direct Debit Guarantee, with no investigation first, and then raises an indemnity claim against the biller's bank, which recovers the money from the biller. The biller can dispute the claim only if it can show the collection was properly authorised, which is why it must keep the mandate, the advance notice and the collection history. A worked example: the utility collects 120 pounds from a customer who cancelled the mandate a month ago. The customer claims under the Guarantee, the bank refunds 120 pounds immediately, the bank raises an indemnity claim, and the utility must repay 120 pounds unless it can show the mandate was still valid. The utility's defence is its records, and the analyst must make sure those records exist. A worked example with the file totals shows the reconciliation. The employer submits a payroll file on Tuesday with 500 payments totalling 1.2 million pounds. BACS acknowledges the file with the same totals, so the employer knows the file was accepted. On Thursday the employer receives a report confirming 498 payments applied and 2 unpaid, totalling 1,195,000 pounds credited and 5,000 pounds unpaid. The 2 unpaid items are employees whose accounts were closed, and the employer pays them by cheque. The reconciliation is: 1.2 million pounds submitted, 1,195,000 pounds credited, 5,000 pounds unpaid, and the three numbers add up. If they do not add up, the payroll team has a problem that must be investigated before the next payroll, because a file that does not reconcile is a file that has lost money. The analyst checklist is practical: confirm the three working day cycle and the bank holiday calendar, build the value date into every screen, reconcile file totals against acknowledgements and ARUDD reports, and document the indemnity and recall paths. The checklist should also include the advance notice rule for direct debits, the AUDDIS and ADDACS flows for setting up and changing mandates, and the duplicate file check. BACS is the oldest system in this chapter and the most forgiving of slow design, but it is unforgiving of a file submitted a day late or a mandate that cannot be produced, and the analyst who designs for the calendar and the records will not be caught out by either.