Bacs powers the UK’s most critical payment flows, processing billions of transactions annually. In 2025 alone, it processed 6.864 billion payments worth £6.049 trillion. From salaries and subscriptions to pensions and loan repayments, it’s the invisible engine behind recurring domestic payments. Operated by Pay.UK, Bacs processes Direct Debits and Direct Credits in approximately three days.

For most organisations, Bacs is essential to collect or disburse funds, even if it’s not visible in their product experience. This applies across industries. Lenders use it to collect repayments. Subscription businesses rely on it for recurring billing. Payment institutions integrate it into their core offerings. This is reflected in usage patterns: approximately 73% of Bacs volume comes from Direct Debits, making recurring collections its primary use case.

Bacs itself is stable and widely understood. Its core processing model, which is based on batch file submission and a three-day cycle, has remained consistent over time. What has changed is how institutions are expected to run payment operations around it. Payment operations and product teams now expect integration, visibility, and automation as part of their day-to-day workflows.

Most institutions focus on how to access Bacs and the easiest path to connectivity. Few consider how that choice will fit into their operations. This gap tends to appear later, once volumes increase and workflows become more complex. Teams end up managing files, tracking failures manually, and stitching together siloed systems and processes that are difficult to scale.

Bacs access should therefore be evaluated through the lens of operational design, not just connectivity.

To send Bacs Direct Credits or collect Direct Debits, institutions rely on a combination of sponsor banks, secure infrastructure, and file-based processes.

The first step is obtaining a Service User Number (SUN). A SUN is required to send or collect payments via Bacs. It is issued by one of the Bacs sponsoring banks, which are direct Bacs participants, and identifies the organisation within the scheme. Even when using a third party to connect to Bacs, institutions still need their own SUN and remain responsible for the payment activity associated with it.

At the heart of Bacs operations sits Bacstel-IP, the secure channel used to submit payment files and receive reports. It is the only way to exchange data with the Bacs scheme and requires setup for authentication, encryption, and file handling. While this infrastructure is not visible to end users, it drives a large part of the operational workload. How institutions interact with it depends on the access model they choose, whether through a bureau, a software provider, or a sponsor bank.

In practice, many teams experience Bacs through operational workflows such as:

These workflows may hold at low volumes but quickly become difficult to manage as payment volumes grow or products evolve. Payment teams often find themselves tracing failures across files, emails, and internal systems just to understand what went wrong. This slows down operations and makes it harder to improve workflows over time.

There are four main ways to access Bacs and submit payment instructions, each with its own characteristics:

Direct participation: The institution is a direct participant to the scheme, and therefore connects via Bacstel-IP. Similar to direct access in other schemes, this path provides full control, but requires managing infrastructure, certification, and compliance internally. Direct participation is typically limited to a small number of regulated financial institutions, many of which also act as Bacs sponsoring banks for indirect participants. Smaller banks and financial institutions generally rely on bureaux or software providers instead.

Sponsor bank: A sponsor bank submits Bacs files on behalf of the institution, typically through a portal or file upload process. This reduces technical complexity but limits flexibility, automation, and visibility.

Bacs-approved bureau: A bureau submits and receives Bacs files on behalf of the institution. The institution keeps its SUN, while the bureau manages connectivity, security, and file processing. This provides a more packaged and operationally managed approach to Bacs access, with varying levels of automation, tooling, and support depending on the bureau. Bacs bureaux rely on Bacstel-IP–certified software provided by approved vendors to submit and receive files.

Bacs-approved software provider: The institution uses a Bacs approved software provider to generate, submit, and receive payment files via Bacstel-IP. This provides more direct interaction with Bacs messaging, but requires the institution to manage file creation, infrastructure, and the full submission lifecycle.

Sponsor banks can often provide the first route to Bacs, offering a familiar path to market. The bank handles submission, and the institution interacts through a portal or file-based interface. This can work well at the beginning, but over time the limits become visible. Workflows remain manual, integration with internal systems is limited, and visibility into payment status is delayed. Ultimately, every change depends on the bank’s processes and timelines.

Bacs is rarely the only scheme an institution uses. In the UK, Faster Payments and CHAPS are often part of the same setup, with Swift commonly used for cross-border flows. UK institutions with European operations will also have to access SEPA schemes.

When each scheme is handled through separate systems, as advanced as they may be, connectivity and operations become fragmented. Workflows vary by payment type, reconciliation efforts are duplicated, and visibility across schemes becomes inconsistent. This increases operational overhead as institutions scale. The real challenge lies in integrating and operating Bacs alongside other payment schemes without creating silos.

A smarter approach is to embed Bacs within a broader payments layer that brings connectivity and payment operations together. In this model, payment instructions follow consistent patterns across schemes. Lifecycle events can be handled through a common model, which means reconciliation is centralised and visibility spans all payment flows.

This is also where capabilities such as Direct Debit mandate management become more valuable. Mandates sit alongside payment execution rather than being handled through a separate process or disconnected tool. That shifts Bacs from a standalone capability to part of a wider operating model.

For institutions that need to support multiple schemes, this distinction matters. It reduces duplication, lowers maintenance overhead, and makes payment operations easier to scale.

A more modern approach to Bacs starts with using an API-first bureau that is designed to fit into a broader payments architecture.

With Mambu Payments, Bacs connectivity is handled through a Pay.UK-authorised bureau that is fully integrated into its Payments Hub. This means institutions can access Bacs Direct Debit and Direct Credit without managing Bacstel-IP connectivity, security infrastructure, smartcards or file processing, while operating Bacs alongside FPS, CHAPS, Swift, SEPA, and more from the same API and dashboard.

This setup removes the need to manage manual workflows and fragmented processes, giving teams direct control over how payment operations are built and run.

Traditional Bacs workflows require generating and parsing Standard 18 files, handling report files, and managing submission cycles manually. These processes are tightly coupled to the scheme and often require dedicated infrastructure. With Mambu Payments, these interactions are abstracted into structured objects and workflows.

Payment instructions and mandates are managed as structured objects within the platform, which is designed for bank/scheme-agnostic usage. With return files parsed and delivered as structured data, status can be tracked in real time, and updates received through webhooks or accessed through the dashboard.

This setup allows teams to build and operate payment workflows in a consistent way across schemes, rather than adapting to the constraints of each one. Most importantly, it allows them to integrate Bacs flows directly into their products with no workarounds.

Bacs is a mature, high-volume UK scheme used primarily for recurring collections. With most institutions relying on indirect models to access it, the question is how to choose one in a way that supports their operations, not just initial connectivity.

Different access models lead to different outcomes over time. Some prioritise speed of onboarding, while others reduce operational workload and support automation from the start. The right choice depends on how the institution plans to run payment operations as volumes grow and workflows become more complex.

A model that removes infrastructure but leaves manual workflows in place will still create friction. A model that combines access, automation, and broader payment lifecycle management will reduce that friction over time.

A model that removes infrastructure but leaves manual workflows in place will still create friction. A model that combines access, automation, and broader payment lifecycle management reduces that friction and enables more consistent operations across use cases such as lending. Ultimately, the most effective approach is one that allows institutions to scale without increasing fragmentation or operational complexity.