Bacs and the Three-Day Cycle

35.0 What this chapter gives you#

1. You will be able to say what happens on each of the three Bacs days, and name the 22:30 deadline that decides which cycle a file belongs to.
2. You will be able to work out the latest input day for any payroll date, including the case where a bank holiday makes the answer Thursday rather than Friday.
3. You will be able to explain why five calendar days can pass inside a three-day cycle without anything having gone wrong.
4. You will be able to say where the money is on day one and day two, and why nothing is in transit.
5. You will be able to separate the clearing that happens on day two from the 09:30 settlement on day three, and say which kind of money each one moves.
6. You will be able to read a Standard 18 payment record by counting characters, and say what fields 7, 9, 10 and 11 carry.
7. You will be able to explain why a Bacs file must balance and what the contra record does for reconciliation.
8. You will be able to distinguish Direct Debit from Bacs Direct Credit by direction, authority, return mechanism and transaction code, and say what sending code 19 by accident does to a mandate.
9. You will be able to say what a Service User Number is, why one organisation may hold several, and how a facilities management arrangement differs from a bureau.
10. You will be able to describe what a Bacs Approved Bureau inspection covers, how the volume tier sets its cadence, and what a single Fail does to the result.

There is a system that moved 6.86 billion payments worth £6.05 trillion in a single year, that pays most of the salaries in Britain and collects most of the household bills, and that almost nobody outside the payments industry can name. It has been running since 1968. It has never been fast, it has never tried to be, and its slowness is not a defect.

Bacs is the oldest of the sterling rails in this volume and the least glamorous. Faster Payments arrives in seconds and gets the headlines. CHAPS carries the property transactions and gets the respect. Bacs carries the routine — the salary that arrives on the first of the month and the gas bill that leaves on the eighth — on a schedule so predictable that entire industries have been built on the assumption that it will not change.

That schedule is three working days long. Every technical decision in this chapter follows from it, and so does every operational mistake people make with it. The most common of those mistakes is to believe that “three days” means three days.

This chapter explains what happens on each of those days, what physically travels between the parties, what the six digits of a Service User Number authorise, and why a Monday in late August can push a payroll into September. It ends with the approval regime governing anyone who submits Bacs files on somebody else’s behalf.

The plain version#

Imagine a very large sorting office in the middle of a town.

Every business in the town — the electricity company, the water company, the factory that pays four hundred wages, the council — needs to move money in and out of thousands of ordinary bank accounts. The electricity company wants to take £61.40 from Mrs Okafor and £48.10 from Mr Reid and similar small amounts from two hundred thousand other people. The factory wants to put £1,842.16 into one worker’s account and £2,103.44 into another’s.

None of them talks to the banks directly. They all send their lists to the sorting office.

Here is the rule of the sorting office. If your list arrives before half past ten on Monday night, then on Tuesday the office sorts it, and on Wednesday morning the money moves. Not before. Not after. Wednesday, for everybody, at once.

That is the three-day cycle. Day one you hand in the list. Day two the office sorts. Day three the money moves.

What the sorting office actually does on day two#

You might think the sorting job is obvious: split the pile into “letters for Barclays”, “letters for Lloyds”, “letters for Nationwide”, and send each bank its bundle. The office does do that. But it does something cleverer as well, and the cleverer thing is the reason the whole arrangement exists.

Suppose that on Tuesday the office finds it is holding instructions worth £4,200,000 that must move from Barclays customers to Lloyds customers, and instructions worth £3,900,000 that must move from Lloyds customers to Barclays customers. It could send two lorries of cash in opposite directions. Instead it does the subtraction, and on Wednesday morning one payment of £300,000 goes from Barclays to Lloyds and the matter is closed.

Eight million instructions have become a couple of dozen numbers. That is what the office is for. It is not a courier. It is an accountant.

A worked example, with real numbers#

Barrow Lane Bakery employs fourteen people and pays them monthly. September’s pay date is Tuesday 1 September 2026. The total wage bill is £31,420.00.

On Thursday 27 August, some time between seven in the morning and half past ten at night, the bakery’s office manager sends one file to the sorting office. It contains fourteen lines. Each has a sort code, an account number, an amount in pence, and a short piece of text that will appear on the employee’s bank statement — “BARROW LANE PAY”, say. There is also a fifteenth line, which says that £31,420.00 in total is to come out of the bakery’s own account. That fifteenth line is what makes the file add up to zero.

Nothing happens on Thursday except that the bakery gets a receipt saying the file arrived and looked sensible.

On Friday 28 August the sorting office reads the file, checks it, and works out which bank each of the fourteen employees uses. Fourteen tiny instructions join a national pile of tens of millions. The bakery’s money has not moved. The employees have no idea anything is happening.

Then there is a weekend. Then Monday 31 August, the summer bank holiday, and the sorting office is shut.

On Tuesday 1 September, at half past nine in the morning at the very latest and usually a good deal earlier — most people see it before six — the fourteen employees are paid, and £31,420.00 leaves the bakery’s account. Both things happen on the same morning. The bakery’s money was in the bakery’s account, fully usable, right up until then.

Now do the same story backwards. The bakery has a broadband contract at £34.99 a month, and the broadband company collects by Direct Debit. The broadband company sends its file on day one; the office sorts on day two; and on day three £34.99 leaves the bakery’s account and arrives in the broadband company’s. Same three days, same sorting office, same file format. The only difference is which direction the arrow points and who is allowed to draw it.

That is genuinely the whole idea. One rail, two directions. Money out of your account on somebody else’s instruction is a Direct Debit. Money into somebody else’s account on your instruction is a Direct Credit.

Why anyone puts up with three days#

Because the alternative costs more and tells you less.

The broadband company has 220,000 customers on £34.99 a month. Collected by instant transfer, that is 220,000 separate real-time transactions to pay for and 220,000 confirmations to chase, and — crucially — it could not make the customer pay. Instant payments are pushed by the payer. Direct Debit is pulled by the biller, on an authority the customer signed once.

And a factory paying four hundred wages does not want them arriving at four hundred slightly different moments. It wants them all on the first, so that its statement shows one line of £742,000, its payroll report shows four hundred lines adding to £742,000, and reconciling the two takes a minute rather than a morning.

Predictability is the product. Three days is the price.

Where the plain version stops being true#

The three days are not days. They are English bank working days, which excludes Saturdays, Sundays and public holidays, and the definition is English regardless of where in the United Kingdom the money is going. A Scottish bank holiday that is not an English one does not stop the cycle; an English one does, even for money moving between two Scottish accounts. The bakery’s payroll above spent 27, 28, 29, 30 and 31 August somewhere between submitted and paid — five calendar days for a three-day cycle. That is not a delay. That is the cycle behaving exactly as specified.

Nothing is “in transit” on days one and two, because there is nothing to be in transit. The sorting-office image quietly suggests that your money is somewhere in the middle of the process, in a van, in a vault, in limbo. It is not. On day one and day two your money is in your account and it is entirely yours. What exists between day one and day three is not money, it is a record of an intention. The transfer of value happens once, on day three, and it happens in two different places at once: individual customer accounts are debited and credited at the banks, and separately a much smaller set of net amounts moves between the banks themselves at the Bank of England. Those are two different kinds of money and two different sets of books, and the technical section separates them properly.

Day three is not the end. The plain version ends when the money lands, which is when most people stop thinking about a payment. Bacs does not stop there. A Direct Debit that lands on day three can be returned unpaid afterwards, and the service user finds out through a report that arrives one or two working days later. A credit sent to a closed account bounces back the same way. And a Direct Debit can be reversed under the Guarantee long after everyone has forgotten it, through an indemnity claim that hits the collecting organisation, not the bank. Any system built on the assumption that entry day is final will eventually produce a reconciliation break that nobody can explain.

“Simultaneously debited and credited” is a phrase to be careful with. Bacs’ own published description of the cycle says, for Direct Credits, that on entry day “payments are simultaneously credited to the recipients’ accounts and debited from your account”, and for Direct Debits that they are “simultaneously debited from the recipients’ accounts and credited to your account” — where in the second case the party being debited is the payer, not any sort of recipient. The scheme’s plain-language copy blurs the direction, and so does most vendor documentation copied from it. Whenever you read a Bacs description, stop and ask which party is being debited, which is being credited, and which of them initiated the file. Those three answers, not the word “simultaneously”, are what distinguish the two products.

The technical version#

Who operates what#

Bacs is one of the retail payment systems owned and operated by Pay.UK, the company established as the New Payment System Operator in 2018. Bacs Payment Schemes Limited became a wholly owned subsidiary of the NPSO on 1 May 2018, and the NPSO was renamed Pay.UK on 18 October 2018. The scheme itself dates from 1968; Pay.UK reports that over 183.6 billion transactions have been debited or credited to British bank accounts through it since then.

Pay.UK owns the rules. It does not run the machines. The central infrastructure that physically processes Direct Debit and Bacs Direct Credit and maintains the network is operated by Vocalink, now part of Mastercard, under contract to Pay.UK. When practitioners say “Bacs went down” they mean the infrastructure; when they say “Bacs says you must” they mean the rulebook.

Beneath Pay.UK sit the direct participants: the banks and payment institutions that clear and settle Bacs items in their own right. The published Bacs participant list ran to thirty-two institutions when last checked, Pay.UK’s page having been updated on 7 April 2026, and it is a more interesting list than it once was. Alongside Barclays, HSBC, Lloyds, NatWest, Santander and Nationwide sit ClearBank, Modulr, Monzo, Starling, PayrNet, The Bank of London and the Bank of England itself. Everyone else reaches Bacs indirectly, through an agency arrangement with a direct participant.

And beneath them sit the service users: the organisations that actually send files. A service user is sponsored into the scheme by a payment service provider, which is on the hook for the service user’s behaviour. This is the single most important structural fact about Bacs and it has no equivalent on the card rails. You do not sign up to Bacs. You are vouched for.

The three days, precisely#

Bacs’ own definition, as published, runs as follows.

Several precisions matter.

The input deadline is 22:30 on input day. A transmission completing at 22:31 belongs to the next cycle, whose entry day is a day later. Practitioners run payroll cut-offs hours before this, not minutes.

Input day is the latest day of submission, not the only one. Files may be sent up to 30 calendar days ahead of the processing day and held — the scheme term is warehousing — until the relevant input day arrives. Most large service users warehouse, because it converts a hard nightly deadline into a soft monthly one. Bacs’ glossary consequently describes the processing cycle as having four stages rather than three: arrival, input, processing and entry. Arrival is when your file physically reaches Bacs; input day is when the cycle formally starts for it. For a warehoused file those are different dates.

On input day the service user receives an input report confirming that the file was received and describing what was found in it. Collecting it is not optional in any practical sense: a file that failed validation and was never chased is a payroll that does not run.

On entry day, paying PSPs apply the debits and credits to customer accounts no later than 09:30. For Bacs Direct Credit specifically, Pay.UK states that “it is not possible to guarantee the exact time the payment will reach the recipient’s account, although at least 90% of Direct Credit payments are credited to beneficiary account by 06:00am”. That 90 per cent figure is the closest thing the scheme offers to a service-level promise on timing, and it is a statistical statement about the population, not a guarantee about your file.

What settles, and in what money#

Bacs is a deferred net settlement system. The distinction between clearing and settlement, laid out in Volume I, is load-bearing here and gets skipped constantly.

Clearing is the exchange and sorting of the payment instructions themselves, which happens on day two. Settlement is the movement of central bank money between the direct participants to discharge the obligations that the clearing created, and it happens on day three. Pay.UK’s own assessment against the international principles for financial market infrastructures states it precisely: “There is one Bacs settlement cycle each working day at 09:30 and this settles the values calculated at the end of day two.” Final settlement occurs at the Bank of England, over the Real-Time Gross Settlement infrastructure, in central bank money.

The netting is multilateral, not bilateral. Each direct participant ends day two with a single number: the net amount it owes to, or is owed by, the system as a whole. At 09:30 on day three those positions are posted across settlement accounts at the Bank of England, and a system that handled tens of millions of instructions discharges them with a few dozen entries.

The credit risk that netting would otherwise create — the risk that a participant with a large net debit fails between day two and settlement — is removed by prefunding. Pay.UK records that all direct participants hold a cash deposit sufficient to cover their own net transactions in a segregated account at the Bank of England, and that this removes credit risk between direct participants from the settlement process. Bacs is deferred, but it does not have to wonder whether it will be paid.

There is a consequence for the reader who is building something. On entry day your customers’ balances change in commercial bank money — an increase in what their bank owes them — while the banks square up in central bank money at the Bank of England. The two events are related by the rules, not by the same transaction. A payment can be applied to a customer account and appear on a statement before the interbank settlement that funds it has posted. This is normal, and it is one of the reasons prefunding exists.

Direct Debit and Bacs Direct Credit#

Two products, one rail, one file format, opposite directions.

Pay.UK describes a Direct Debit as “an occasional or regular payment instruction set up by the end user in advance, authorising an organisation to collect a pre-agreed amount of money from their account, on a prearranged date”, and Bacs Direct Credit as “a regular payment, normally B2C, that pays the beneficiary on a regular date (i.e. first of the month) and is mainly used for paying wages and salaries”.

The transaction codes are worth memorising because they carry meaning the amount field does not. Within Direct Debit, code 01 marks the first collection under an instruction; 17 marks a subsequent collection; 18 marks a collection represented after a failure; and 19 marks the final collection under the instruction. Code 19 is not decoration: it tells the paying PSP to delete the instruction from its records, and it may cause a “final collection” message to appear on the payer’s statement. Sending 19 by accident cancels the mandate.

Separately, the AUDDIS service carries the instructions themselves rather than money: 0N lodges a new Direct Debit Instruction electronically at the payer’s PSP, 0S converts an existing manually lodged instruction to AUDDIS, and 0C cancels one. AUDDIS is mandatory for all new service users that submit direct to Bacs. It travels on the same three-day cycle in the same file format, which is why a new customer’s instruction and their first collection cannot sensibly be sent in the same submission.

The advance notice rule is the other thing to know. A Direct Debit service user must tell the payer, before collecting, the date and amount to be debited. The default notice period recorded against the service user is 10 working days plus postal time, and it can be varied downwards by agreement with the sponsoring PSP. Shorter notice periods are common for utilities and rare for anything unusual. The mandate, the Guarantee and the indemnity mechanism are the subject of the next chapter; here it is enough to say that they attach to Direct Debit and have no counterpart for Direct Credit.

Why payroll and utility billing run on this#

Four reasons, in decreasing order of how often they get mentioned and increasing order of how much they matter.

The cheap reason is unit cost. A Bacs item is priced by the sponsoring PSP as a bulk item and a Faster Payment is priced as a transaction. Over 220,000 collections a month the difference is the whole business case.

The better reason is direction. Direct Debit is the only sterling mechanism in common use that lets the person owed money initiate the transfer under a standing authority. Everything else — Faster Payments, CHAPS, Open Banking payment initiation — is a push, which requires the payer to act, which means a proportion of payers will not act. For a utility with millions of accounts, the difference between pull and push is the difference between a collections department and a call centre.

The third reason is that the value date is knowable in advance and identical for everyone in the file. Payroll is not only a payments problem, it is a fairness problem: everybody must be paid on the same day, and a system where 3 per cent of staff are paid four hours late is worse than one where everybody is paid at 09:00. Over 150,000 organisations use Bacs Direct Credit, and the reason they do not migrate to instant rails is not inertia; it is that a batch with a fixed value date is the correct shape for the problem.

The fourth reason is reconciliation, and it is the one that gets fintechs killed. A Bacs file is self-balancing. The contra record forces the sum of the payment records to equal the single amount that hits the service user’s own bank account, so the bank statement shows one figure that must reconcile to one file. A thousand individual Faster Payments show a thousand statement lines with a thousand chances of a mismatch. Batch is not an old-fashioned way of doing real time. It is a different, and for these purposes better, control structure.

Payroll carries one extra thread, because it explains a field in the file format. Under Real Time Information, HMRC for some years asked employers paying by Bacs to include a hash cross-reference on the Full Payment Submission, built partly from a four-character random string inserted into field 7 of the Bacs payment record, so that HMRC could match reported payroll data to payments actually made. HMRC withdrew the requirement for that field, data item 118, from the 2023/24 tax year onwards. The Service User Number remains reportable on the FPS. The field in the file is still there and payroll software still fills it, which is a small monument to the rule that payment formats accumulate requirements faster than they shed them.

What a Bacs file physically is#

The format is called Standard 18, and Bacs’ glossary defines it in one line as “the Bacs standard file/record format used by the Direct Debit and Bacs Direct Credit schemes”. It is a flat, fixed-width, fixed-length text file. There is no XML, no JSON, no delimiter, no escaping. Every field is found by counting characters from the start of the line, exactly as it was when these files travelled on magnetic tape.

Two record lengths coexist. The label records that wrap the file are 80 characters. The payment records inside it are 100 characters, and there is a longer 106-character variant that appends a processing date to each record.

A submission is a sandwich:

The label records are declarative rather than interesting, with the exception of UHL1, which carries the processing date as five Julian digits preceded by a space, in the form YYDDD. The work code sits in the same record and reads 1 DAILY . Bacs’ glossary defines the Julian convention exactly: “Julian dates run serially throughout the year. 1 January is always 001 and 31 December is 365 (366 if a leap year).” Thursday 27 August 2026 is Julian 239. Tuesday 1 September 2026 is Julian 244.

The payment record is where the work is. Counting characters from position 1:

Bacs’ glossary names fields 9, 10 and 11 individually, which tells you which three the scheme considers most likely to be got wrong. Field 9 is the short name of the service user, up to 18 characters, and is what may appear on the payer’s statement. Field 10 carries the reference, and the glossary calls it “a critical field for both credits and debits allowing the recipient to identify what the payment relates to”. Field 11 is the destination account name, and for Direct Debits it “must be the name of the person who is paying the Direct Debit and has authorised the Direct Debit Instruction”. Field 7, the four-character free-format field, is the one HMRC borrowed for the RTI hash.

Three properties of this layout deserve emphasis.

The amount has no decimal point and no currency symbol. It is eleven digits of pence, right-justified and zero-filled, so £34.99 is written 00000003499 and £31,420.00 is written 00003142000. Eleven digits will express any amount below one thousand million pounds; the limits that actually bite are the account limits set by the sponsoring PSP, not the width of the field.

The names and references are eighteen characters and no more. Not eighteen and a continuation, not eighteen displayed characters of a longer stored value. Eighteen. Every organisation that has wondered why its customers’ statements say THAMESIDE PROPERTY rather than the full company name is looking at field 9 doing exactly what it was built to do in 1968.

And the file must balance. Alongside the payment records sits a contra record, the mirror entry against the service user’s own account. In a Bacs Direct Credit file the individual credits carry transaction code 99 and the contra carries a debit code; in a Direct Debit collection file the individual debits carry 01, 17, 18 or 19 and the contra carries 99. The UTL1 trailer then states total debits, total credits and the counts of each, right-justified and zero-filled. Bacs’ glossary defines a file, tersely and correctly, as “a self balancing set of records from a service user”. If it does not balance it is not a file, it is a rejection.

The definitive specification is the Service User’s Guide and Rules to Bacstel-IP, which the glossary describes as “the technical specification for submission to Bacs”. It is issued to sponsored service users by their PSP and is not public, so no publicly available scheme document sets out the internal offsets of the reserved and system fields inside the eighty-character labels. Two things fill the gap, and neither is the scheme speaking. The labels are not a Bacs invention at all: they are the American national standard for the file structure and labelling of magnetic tapes, ANSI X3.27, which is why VOL1 and HDR1 carry serial numbers, generation numbers, block counts and buffer offsets that no payment system has ever had a use for. And several sponsoring banks publish their own Standard 18 message implementation guides, HSBC’s February 2022 edition among them, which do give the character position of every reserved field in VOL1, HDR1 and HDR2. Those guides agree with one another on the payment record and very largely on the labels, but they are the bank’s document rather than the scheme’s, and a sponsor is free to impose requirements of its own or to read a field differently. Take the offsets from the guide your own sponsor hands you, not from any book, including this one.

Pay.UK also publishes an ISO 20022 to Bacs translation guide and a translation specification with XSDs covering all Bacs Standard 18 messages, so that organisations speaking ISO 20022 internally can generate compliant submissions. As of writing, the format on the wire is still Standard 18; ISO 20022 is a translation layer over it, not a replacement.

Service User Numbers#

A Service User Number is, in Bacs’ own words, “the unique six digit number allocated to organisations authorised to use the Bacs service”. Six digits. That is the entire identifier, and it is doing more work than its size suggests.

The SUN is not an account number and it is not a customer reference. It is the scheme’s identity for a sponsored originator, and it is what a paying PSP matches against when a Direct Debit arrives claiming authority to take money from one of its customers. The Direct Debit Originator database holds the record behind it: contact details, advance notice period, dormancy period, AUDDIS status. When a payer telephones their bank to dispute a collection, the SUN is how the bank knows who to point at.

One organisation may hold several SUNs. Large groups routinely run a separate SUN per operating company, per brand, or per application — one for payroll credits, one for subscription collections — because the SUN is the unit against which scheme configuration, reporting and, eventually, blame are recorded. In-house group bureaux, Bacs notes explicitly, may cover “a single organisation that has different Service User Numbers for different applications”.

An organisation that cannot obtain its own SUN is not shut out. Under a facilities management arrangement, a registered FM provider acts as the service user, using its own SUN, and collects Direct Debits on behalf of an FM client that has not been sponsored into the scheme. The client’s customers see the provider’s short name in field 9. Pay.UK maintains a directory of sponsored FM providers, and the arrangement is fundamentally different from a bureau: a bureau transmits your file under your SUN, an FM provider collects under its own.

The SUN also appears inside the file, in the owner identification area of the VOL1 label. A file whose VOL1 SUN does not match the submitter’s credentials does not get processed.

Getting the file to Bacs: Bacstel-IP, smartcards and the Payment Services Website#

Bacstel-IP is the channel. The glossary describes it as “a service providing a highly secure access channel into Bacs” using internet technologies and public key infrastructure to allow access to payment services, and notes that it “carries out some online validation of submissions”. That last clause is the one practitioners live by: some errors are caught at submission, and the rest are caught later and reported.

Access to Bacstel-IP requires software that Bacs has approved for the purpose, and it requires cryptographic credentials. Direct submitters are issued smartcards, which authenticate approved personnel to the Payment Services Website and sign and send the payment files themselves. Bacs’ guidance is strict: cards cannot be transferred between people, a new card must be applied for through the sponsoring PSP when staff change, and the old card must be returned to the PSP to be destroyed. Other staff, and organisations that submit through a bureau, may instead be given a password and ID granting access to the Payment Services Website for reports only, without the ability to sign a submission.

The Payment Services Website is separate from the public bacs.co.uk site, a distinction Bacs itself makes in capitals because people confuse the two. It is where reports and advices are collected. Bacs’ own submission checklist reduces to this: submit the file; collect the input report, available on the day of submission; monitor regularly for ADDACS and AWACS advices, ideally daily; and collect any ARUDD and ARUCS reports, which are available within one to two PSP working days after the payment or collection date.

Acting on those advices is a rule, not a courtesy. Service users must action them within three working days. An ADDACS advice saying a customer has cancelled their instruction, ignored for a month, produces a stream of collections that will fail and may produce indemnity claims. If a bureau or software supplier collects the reports for you, you are still the party required to act on them.

Why bank holidays extend the cycle#

Bacs defines working days, for scheme purposes, as “English PSP working days excluding Saturdays, Sundays and Public Holidays”. The three-day cycle counts in those days and only those days. It follows mechanically that a public holiday does not delay a Bacs payment by one day; it removes one of the three slots, and whether that costs you one day or four depends entirely on where in the week the holiday falls.

Take the summer bank holiday in England and Wales in 2026, which falls on Monday 31 August.

Read the middle row carefully, because it is the one that catches people. A payroll with a value date of Tuesday 1 September 2026 must be submitted by 22:30 on Thursday 27 August, not Friday. The Friday is the processing day. An organisation that has internalised “submit two days before” as “submit on the Friday for the Tuesday” will find its staff unpaid, and will find out on Tuesday morning, which is the worst possible moment to find out.

Note also that there is no entry day at all on Monday 31 August. Pay.UK’s rule for Bacs Direct Credit is that payments can be sent Monday to Friday excluding bank holidays, and “if the prearranged date falls on a weekend or bank holiday, the payment is made on the next working day”. A salary contractually payable on the last day of August 2026 is paid on 1 September.

Christmas compresses this further. In England and Wales in 2026 both Christmas Day, Friday 25 December, and the Boxing Day substitute, Monday 28 December, are holidays, and New Year’s Day 2027 falls on the Friday. A payment dated Thursday 31 December 2026 requires input on Tuesday 29 December, and the next available entry day after that is Monday 4 January 2027.

For exactly this reason Pay.UK publishes an annual Bacs processing calendar, in landscape and portrait, marking non-processing days and giving the Julian date for every day of the year. The 2026 calendar’s legend distinguishes non-input and non-processing days from days that are a banking holiday in Northern Ireland only, and carries a standing instruction to consult your payment service provider for entry date and processing day arrangements for accounts held in Northern Ireland. That footnote is the honest admission that “English bank working days” is a simplification of a United Kingdom with four sets of holidays, and that where it matters you ask your sponsor rather than a calendar.

If you build software that schedules Bacs submissions, hard-code nothing. Load the processing calendar as data, refresh it annually, and treat “is this a Bacs processing day” as a lookup rather than a computation. Every engineer who has tried to derive English bank holidays algorithmically has eventually met the substitute day rule, the royal proclamation, or a one-off national holiday, and has lost.

Bacs approved bureaux and Bacs approved software#

Most organisations that use these schemes never submit anything themselves. Pay.UK states that over half of those making Direct Debit, Bacs Direct Credit and Faster Payment submissions do so through approved bureaux rather than directly, and that there are approximately 700 approved bureaux worldwide.

A bureau is defined by the scheme as an organisation that sends payments to Bacs on behalf of another organisation. Pay.UK distinguishes commercial bureaux, which submit on behalf of independent third parties; PSP bureaux, offering participant services direct to service users; in-house commercial group bureaux, working solely within their own group; and a residual “other” category. The distinction that matters for approval is between in-house and commercial: an in-house bureau submitting only for entities within the same legal organisation need not register, while a commercial bureau submitting for third-party service users that are separate legal entities must achieve Bacs Approved Bureau status. Pay.UK must approve any organisation that submits Direct Debits, Bacs Direct Credits or Faster Payments transactions on behalf of third parties.

The route in runs through a sponsor. An applicant must first be authorised by its sponsoring participant; Pay.UK’s Bureau Inspection team then formalises the process; a one-off registration fee is payable; a questionnaire, supporting documents and a signed agreement follow; an inspection must be passed; and only then does Pay.UK issue a certificate and the sponsor enable the live service. An application not completed within 12 months expires.

Approved bureaux are tiered by annual transaction volume, and the tier sets the inspection cadence.

An inspection assesses end-to-end payment processing, from the receipt of Bacs-related information through to the point of transmission to the Bacs clearing system. The questionnaire is structured around ISO/IEC 27001 and covers eight areas: organisation and policy; professional services and commercial arrangements; physical security; network environment; systems management; logical access control; business continuity and disaster recovery; and Bacs processing and data controls. Two annexes attach where relevant: Annex A for third-party risk management where outsourcing is material, and Annex B for hardware security module and cryptographic key management.

An on-site visit typically runs five to seven hours: a business overview, a tour of processing and server areas, a walk through the questionnaire responses with the staff who own them, observation of operations, and review of supporting documents — security policies, process guides, customer agreements, business continuity plans.

Each category is rated Pass, Pass with requirements, Fail, or Not Applicable. A Fail in any single category fails the whole inspection, and a failed bureau must be re-inspected within a maximum of six months. Requirements are mandatory and time-bound; recommendations are best practice, and one ignored may be restated as a requirement next time. The report follows within five working days. Cancelling an inspection with less than ten working days’ notice attracts a fee. Annual fees are levied in April at bureau number level, based on the transactions submitted during the previous calendar year, with new bureaux exempt for their joining year; invoices are payable within 30 calendar days. Terminating BAB status requires three months’ notice.

Approved bureaux receive the BAB logo. Pay.UK is careful about what it means: bureaux awarded it “have been inspected and have met appropriate standards of business, security, technical and operational competence at the time of the inspection”, status “is based upon point in time inspections”, and Pay.UK “does not make any representation in respect of the suitability, or otherwise, of organisations approved under the scheme for any purpose”. It is an attestation about a date, not a warranty.

Running in parallel is the Bacs Approved Software Service. A Bacs approved software supplier is a developer and supplier providing software, hardware and consultancy services to Bacs Payment System customers to enable them to use the service. Testing under BASS examines authentication of parties communicating with Bacstel-IP or Secure-IP; secure communication, meaning confidentiality and integrity, between those channels and the approved software; correct formatting of submissions and reports; handling of errors and warnings; and trademark usage. Approval requires an application, mandatory testing, training for named staff on the Bacs Payment System and the relevant interfaces, an approval fee and an ongoing annual maintenance fee. Full business and technical specifications, including a sorting code directory, are released to applicants.

The two schemes answer different questions. BASS asks whether a piece of software constructs and transmits submissions correctly. The Bacs Approved Bureau Scheme asks whether an organisation can be trusted to operate the process around that software — who holds the smartcards, what happens when the building is unavailable, how third-party clients are onboarded and offboarded, whether someone is reading the ADDACS advices. A vendor can hold approved software status and not be a bureau; a bureau can be approved while running somebody else’s approved software. An organisation intending to do both applies to both, and should expect the bureau inspection to look hardest at the questionnaire areas that have nothing to do with code.

The scale of it, as of writing#

Set that against the rails on either side. Faster Payments settles in seconds, runs 24 hours a day, and carries a maximum of £1 million per transaction under the central scheme limit, with individual institutions imposing lower limits of their own. CHAPS settles same-day, irrevocably, gross, one payment at a time across the Bank of England’s RTGS system, with an early-afternoon cut-off for the same-day guarantee, and carries the large majority of sterling value on a tiny fraction of the volume. Bacs sits between them and does something neither can: it moves enormous numbers of small, scheduled, two-directional payments at a known value date, cheaply, in a format that reconciles itself.

Three days is what that costs. It has been three days since 1968, and the reason it is still three days is not that nobody has thought about it. It is that the three days buy the netting, the netting buys the cost, and the cost is why your salary and your gas bill both arrive without anybody thinking about them at all.

35.98 Common wrong ideas#

Wrong: three days means three days. Right: it means three English bank working days, so a file submitted on Thursday 27 August 2026 enters accounts on Tuesday 1 September — five calendar days later, and exactly as specified.

Wrong: a Scottish or Northern Irish bank holiday moves the cycle. Right: the definition is English working days regardless of where in the United Kingdom the money is going, and Pay.UK’s calendar tells you to ask your sponsor about accounts held in Northern Ireland.

Wrong: the money is somewhere in the middle of the process on days one and two. Right: nothing is in transit, because what exists between input and entry is a record of an intention, and value moves once, on day three.

Wrong: “submit two days before” is a safe rule of thumb. Right: for entry on Tuesday 1 September 2026 the file must be in by 22:30 on Thursday 27 August, because the Friday is the processing day and the Monday is a holiday.

Wrong: entry day is the end of the payment. Right: Direct Debits come back through ARUDD and credits through ARUCS one or two working days later, and a collection can be reversed by indemnity claim long after everyone has forgotten it.

Wrong: input day is the day you send the file. Right: input day is the latest day you may send it, files may be warehoused up to thirty calendar days ahead, and the scheme’s own glossary therefore counts four stages rather than three.

Wrong: Pay.UK runs the Bacs machines. Right: Pay.UK owns the rulebook and Vocalink, now part of Mastercard, operates the central infrastructure under contract, so “Bacs went down” and “Bacs says you must” are statements about different organisations.

Wrong: you sign up to Bacs. Right: you are vouched for, because a service user is sponsored into the scheme by a payment service provider that is on the hook for its behaviour.

Wrong: the 90 per cent by 06:00 figure is a promise about your file. Right: it is a statistical statement about the population of Direct Credit payments, and the only commitment is that paying PSPs apply entries no later than 09:30.

Wrong: the Standard 18 offsets in a vendor or bank guide are authoritative. Right: the definitive specification is the Service User’s Guide and Rules to Bacstel-IP, issued by your sponsor and not public, and a sponsor may impose requirements of its own.

35.99 Chapter summary in 20 lines#

1. Bacs has run since 1968, moved 6.86 billion payments worth £6.05 trillion in 2025, and pays most of the salaries and collects most of the household bills in Britain.
2. It behaves like a sorting office: lists arrive by 22:30 on day one, are sorted on day two, and money moves on day three for everybody at once.
3. The clever part of day two is not sorting but subtraction, because millions of instructions are netted down to a few dozen interbank figures.
4. One rail carries two products in opposite directions: Direct Debit pulls under a standing authority, and Bacs Direct Credit pushes.
5. The three days are English bank working days, so a payroll dated Tuesday 1 September 2026 must be submitted by 22:30 on Thursday 27 August.
6. Nothing is in transit during the cycle, because the payer’s money stays in the payer’s account and fully usable until entry day.
7. On entry day two different things happen in two kinds of money: customer accounts move in commercial bank money, and the netted interbank positions settle at 09:30 in central bank money at the Bank of England.
8. Prefunding removes the credit risk that deferral would otherwise create, because every direct participant holds a segregated cash deposit covering its own net position.
9. Entry day is not the end, since ARUDD, ARUCS, ADDACS and AWACS all arrive afterwards and an indemnity claim can reverse a collection much later still.
10. Pay.UK owns the rules, Vocalink runs the infrastructure, thirty-two direct participants clear and settle, and everyone else reaches Bacs through an agency arrangement or a sponsor.
11. Input day is the latest day of submission rather than the only one, and warehousing up to thirty calendar days ahead is why the glossary describes arrival, input, processing and entry.
12. Standard 18 is a flat, fixed-width text file inherited from magnetic tape, with 80-character labels wrapped around 100-character payment records and no delimiters of any kind.
13. Every field is found by counting characters: amounts are eleven digits of pence with no decimal point, and names and references are eighteen characters and no more.
14. The file must balance, because a contra record mirrors the payment records against the service user’s own account, which is why one bank statement line reconciles to one file.
15. Transaction codes carry meaning the amount field does not — 01, 17, 18 and 19 for collections, 99 for credits, and 0N, 0S and 0C for AUDDIS instructions.
16. A Service User Number is six digits, is the scheme’s identity for a sponsored originator, and is what a paying bank matches against and eventually attributes blame to.
17. Files travel over Bacstel-IP using approved software and non-transferable smartcards, while reports are collected from the Payment Services Website and must be actioned within three working days.
18. Bank holidays do not delay the cycle by a day; they remove a slot, and where the holiday falls decides whether that costs one day or four.
19. Anyone submitting for third parties must hold Bacs Approved Bureau status, inspected on a cadence set by volume tier, and a Fail in any single category fails the whole inspection.
20. Three days is what the netting costs, the netting is what makes the payments cheap, and the cheapness is why a salary and a gas bill both arrive without anybody thinking about them.

Sources: Pay.UK and Bacs published scheme material (bacs.co.uk processing cycle, glossary, processing calendar 2026 and The Little Bacs Book; wearepay.uk Bacs Payment System pages, participant list, Bacs Approved Bureau Scheme supporting guidelines and Bacs Approved Software Service), Pay.UK’s PFMI self-assessment report, the Bank of England’s payment and settlement pages, GOV.UK bank holidays, and CIPP guidance on the withdrawal of the RTI Bacs hash. Standard 18 record layouts cross-checked against independent implementation documentation; the authoritative specification is the Service User’s Guide and Rules to Bacstel-IP, issued by sponsoring PSPs. All timings, limits and figures accurate at time of writing.