How to scale BACS payments: bureaus, SUNs and the volume trap

BACS is boring in exactly the right ways — cheap, predictable, built for volume — right up until you’re running it at real scale. Then the boredom turns into a month-end operation: files to prepare three days ahead, cut-offs to hit, returns to chase, and client money to keep separate and correct. For accountancy practices, investment firms and platforms pushing regular payouts, “scaling BACS” isn’t about the rail’s speed; it’s about the machinery around it. Here’s how that machinery actually works.

Why hand-keyed BACS stops working

A few BACS payments a month, you can submit by hand. A few hundred across a dozen client entities, and manual submission becomes the bottleneck: someone assembling files days in advance, re-keying payee details, watching cut-off windows, and reconciling what came back. BACS runs on a three-business-day cycle — submit day one, process day two, credit day three — so every error is expensive precisely because you find out about it late.

Scaling BACS means industrialising three things: how files get submitted, whose money is whose, and how returns get reconciled.

Bureaus and SUNs: how submission actually happens

To submit to the BACS scheme you need a Service User Number (SUN) and an approved route in. There are two ways to get one:

• Your own SUN. Sponsored by your bank, with the scheme’s requirements to meet. You appear on payees’ statements under your own identity and keep full control — worth it at high volume or where the statement branding matters.
• A bureau’s SUN. A BACS-approved bureau is an organisation permitted to submit files on behalf of others. Submitting under its SUN is faster to start and offloads much of the compliance overhead — the usual starting point for a business scaling into BACS.

Most operations begin on a provider’s or bureau’s SUN and only pursue their own once volume, control or branding justify the setup effort.

The accountancy case: many entities, one operation

For an accountancy or bookkeeping practice, the hard part isn’t one payroll — it’s many. Client A’s payroll, Client B’s supplier run, Client C’s expenses, each a separate entity whose funds must never mix, all on the same three-day cadence. Scaling here is about multi-entity segregation and clean per-client reconciliation: every run attributable to the right client, every return matched back, no commingling. Do it on spreadsheets and it’s a standing month-end fire; do it on a platform that holds and separates client funds and reconciles returns automatically, and it’s a scheduled, boring job again — which is what you want.

The investment-firm case: regular distributions, tight controls

Investment firms push scheduled distributions and redemptions to many recipients, and the pressure is control and audit as much as volume. Validated payee details (a failed distribution is a three-day round trip and an unhappy investor), a clean audit trail on every run, and reconciliation that flags failures the moment they return rather than at period close.

The regulated-platform case: Faster Payments and BACS

Platforms — including in regulated sectors like iGaming — usually need both rails: BACS Direct Credit for cheap scheduled runs, Faster Payments for anything instant or ad hoc. But at that level the harder questions are upstream of the rails: KYC/AML on payees, safeguarding of client funds, and holding money on behalf of others compliantly. Processing Faster Payments and BACS at scale in a regulated vertical is a licensing-and-controls problem wearing a payments-rail costume. (For the rail mechanics themselves, see Faster Payments vs BACS vs CHAPS.)

The failure mode nobody plans for: returns

The single biggest source of BACS pain at scale is bad bank details. A wrong sort code or account number doesn’t fail loudly at submission — it bounces on the three-day cycle, so you learn about it days later, after you thought the run was done. Reduce it with validation on the way in (modulus checks, account verification), disciplined payee-data hygiene, and automatic reconciliation of returns so a failed item surfaces immediately and gets re-issued, instead of surviving as an unexplained gap in someone’s account.

Where Fynex fits

Scaling BACS is a money-operations problem, which is the layer Fynex runs. Rather than treating submission, segregation and reconciliation as three manual jobs, Fynex holds funds safeguarded at an FCA-authorised EMI, keeps each client’s or entity’s money cleanly separated, validates payee details before a run rather than after it bounces, and reconciles BACS returns back to the originating payment automatically — while routing anything time-sensitive over Faster Payments instead when the three-day cycle won’t do. The result is that a large BACS run behaves like the boring, scheduled thing it’s supposed to be, across as many entities as you serve — not a month-end operation that needs a person babysitting files and chasing returns.

BACS scales fine. It’s the operation around BACS that either scales with it or becomes the job.