Payments are at the core of any fintech company. Whether its core product is lending, investments or payments themselves, fintech companies must offer their customers complete and seamless payment options. In the UK, it means supporting Bacs and FPS payments.

There are different ways to access Bacs and FPS and send and receive Bacs and FPS payments on behalf of customers, depending on fintech companies’ activities, maturity and strategy.

We’ve covered these access models in the context of SEPA, but the models are similar in the UK for Bacs and FPS payment systems.

One of these access models is to become a Bacs and FPS indirect participant. This model, also called “agency banking”, unlocks many benefits for fintech companies but still represents a significant investment.

This article explores when fintech companies should consider this model to address the UK market, how they can access it, operating as a Bacs/FPS participant, as well as the required tech stack to do so. We also describe how a solution like Mambu Payments helps you during these steps.

When should fintechs become Bacs and FPS participants

When sending and receiving Bacs and FPS payments through a bank or a PSP isn’t enough

Most companies access Bacs and FPS as “corporate customers” of their payment services provider (PSP). Being a corporate customer means that a company will rely on one or several PSPs, such as banks or BaaS providers, to hold their customer accounts and send and receive payments from and to those accounts.

When fintech companies enable their customers to deposit funds on an online account and send and receive payments from these accounts rely on a bank or a BaaS to do so, it means that the bank or BaaS will actually perform these operations. On behalf of the fintech, which itself does it on behalf of the end customers.

In the case of fintech companies working with banks, these companies will work with the corporate cash management department of the bank, and the bank will hold the accounts of the fintech.

When being a corporate customer falls short

We already explored why and when successful fintech companies leave their BaaS provider.

Growing fintech companies will also hit limitations as bank corporate customers.

First, only some companies can even consider becoming Bacs and FPS participants. Indeed, only regulated electronic money institutions, payment institutions, or credit Institutions (i.e., banks), referred to as “financial institutions” as a whole, can apply to participate in UK payment systems. For those regulated companies, the question arises when their volumes grow.

In the corporate customer model, companies are bound to use their bank’s sort code, in their bank’s name.

In addition, more payments mean more edge cases, potential errors, and scenarios to manage. As corporate customers, companies don’t have direct control over the mechanisms to handle these cases and have to rely on their banks. Banks can take time and charge significant fees to manage these exceptions or failed payments.

Finally, companies using the corporate customer model rely on one or more intermediaries to process their payments, meaning as many payment speed overhead, potential points of failure and business counterparts with their own compliance requirements and margins to preserve.

To overcome those limitations, regulated fintech companies can choose to become Bacs and FPS participants.

The benefits of becoming a Bacs and FPS indirect participant

Becoming a Bacs and FPS participant is a significant project for a financial institution. Operating as a Bacs and FPS participant is also more complex than relying on a PSP to send and receive Bacs and FPS payments.

Financial institutions decide to go through such a project because being a Bacs and FPS indirect participant brings the following advantages.

1. Own account numbers and sort code

Bacs and FPS participants have their own sort code and issue their own account numbers, providing the following benefits.

a) Use a sort code associated with your company name

As Bacs and FPS participants, PIs and EMIs will issue account numbers in their name for held accounts. It means that when counterparties receive credit transfers or direct debits from PIs and EMIs or send them credit transfers, they will see the PIs and EMIs’ sort codes with the payment. In other models, these counterparties would instead see the bank’s sort code for corporate customers or PSP’s sort code for PSP agents.

Using official sort code checker tools, end customers can know which institution the sort code belongs to. In an industry where trust is paramount, this can be a game changer regarding user experience and brand credibility.

b) Easier customers migration

Bacs and FPS participants have their own sort code. Their account numbers are tied to their sort code instead of their bank’s in the corporate customer model. This enables them to change sponsor banks without migrating their customers’ accounts and, therefore, without any impact on their customers.

2. Increased control over customer onboarding

PIs and EMIs relying on third-party PSPs to send and receive Bacs and FPS payments on behalf of their customers can only partially choose the customers they work with.

As PSP agents, companies will be tied to their PSP onboarding rules. These PSPs might refuse to onboard and deliver services to customers from entire industries. They might also refuse to onboard specific customers or execute certain payments for compliance reasons that might not be known to the fintech company.

PSPs offering their services to agents usually refuse specific types of end customers because they work with a wide variety of agents and cannot adapt their onboarding rules to each agent’s specific use case.

By becoming a BACS and FPS participant, PIs and EMIs will be fully responsible for the onboarding of their customers and can define their own onboarding rules that fit their specific use case while complying with the regulation.

The checklist to become a Bacs and FPS indirect participant

By becoming a Bacs and FPS indirect participant, a regulated fintech company can unlock many advantages including an increased control on payments and customer onboarding, increased speed of payments, reduced payment costs and getting its own sort code and account numbers. However, becoming a Bacs and FPS indirect participant represents a significant project for a growing company.

In this section, we aim at helping decision makers make the right decision for their company by exploring the steps for a regulated payment institution (PI) or electronic money institution (EMI) to become a Bacs and FPS indirect participant.

​There are three main work streams to become a Bacs and FPS indirect participant, which can be run in parallel: sort code acquisition, selection of and commercial discussions with a sponsor bank, and technical integration with a sponsor bank.

1. Sort code

Sort codes identify PSPs across the UK and are used by payment systems for routing and settlement of payments. Sort codes are registered and managed by Pay.UK.

To be reachable from other Bacs and FPS participants, a Bacs and FPS indirect participant needs its own sort code.

In the case of indirect participants, the sponsor bank is responsible for allocating one of its owned sort codes to the indirect participant and registering it with Bacs and FPS payment systems as well as the Bank Reference Data. A sort code should be registered for the Bacs scheme at least six weeks prior to any transaction from or to said sort code.

2. Sponsor bank

The Bacs and FPS sponsor bank is the most critical partner for an indirect participant. As such, it is present at several steps of a Bacs and FPS indirect participant’s project.

a) Choose a Bacs and FPS sponsor bank

As of the publication of this article, known Bacs and FPS sponsor banks include:

• Barclays

• ClearBank

• HSBC

Operating as a Bacs and FPS indirect participant

A Bacs and FPS indirect participant must manage multiple workflows to send and receive Bacs and FPS payments in compliance with regulations and payment systems rules. In this section, we explore the different payment workflows and technical requirements involved in operating as a Bacs and FPS indirect participant.

1. Processing outgoing Bacs and FPS payments

a) Sending a Bacs Direct Credit

When a Bacs indirect participant receives the instruction from a customer to send a Bacs Direct Credit (Bacs DC), it needs to:

• Ensure the instruction complies with its internal rules (e.g., amount, frequency, and destination country) and anti-money laundering (AML) / countering the financing of terrorism (CFT) checks

• Make sure the customer’s account has sufficient funds

• Queue the payment and add it to the next payment batch, which takes the form of one or multiple "cleared credits" PSP to PSP messages

• Create the corresponding "credit contra" PSP to PSP message

• Package these messages in a file

• Send this file to the sponsor bank, which will, in turn, run its AML and CFT checks and forward it to the Bacs payment system

• After the payments have been processed by Bacs, receive the "credit contra" PSP to PSP message

• Reconcile this message with the sent payments

• Update the customer balance accordingly

For FPS, these reports are called the fate of payment. Sending Participants must inform their customer of the status of the payment after receiving a Qualified Accept, Unqualified Accept or Reject response from the Receiving Participant.

4. Processing payment errors and exceptions

The flows described above are the flows when everything goes right, or “happy flows”. But for various reasons, errors and exceptions might happen.

Bacs and FPS documentations specify and standardise how to handle these errors, and indirect participants must be able to send, receive, and process the messages related to these cases.

Causes of such errors or exceptions might be: The beneficiary account of an incoming FPS payment does not exist or is blocked The debtor account of an incoming Bacs DD does not exist, is blocked, does not have sufficient funds, or cancelled the DDI The originator of an incoming Bacs direct credit must recall the payment because of a technical error that sent the payment by mistake or detected that the payment was fraudulent

When such cases happen, Bacs and FPS indirect participants must be able to: Receive and parse the incoming message from the payment system via the sponsor bank or generate and send the message to the payment system via the sponsor bank Process the message, for instance, accept a Recall and send a corresponding Return When the message involves a money movement, process the incoming or outgoing payment and reconcile settlement and safeguarding accounts accordingly

Bacs and FPS error and exception messages include:

5. Confirmation of Payee

The UK’s Payment System Regulator requires all directed FPS participants to provide Confirmation of Payee (CoP) to their customers by October 2024.

Confirmation of Payee is a name-checking service for UK-based payments launched by Pay.UK in 2020. It aims at reducing certain types of payment fraud and payment errors.

Confirmation of Payee allows a payer to check that the name (including a personal / business account indicator) they give for a new payee is the same as the account name/type held by the payee’s PSP.

FPS participant PSPs can either build their own CoP solution following its specifications or use a third-party solution provider.

6. Managing settlement and safeguarding accounts

Safeguarding customer funds is not a requirement limited to Bacs and FPS participants. Any payment and electronic money institution sending or receiving payments on behalf of customers must either safeguard customer funds in a safeguarding account or contract insurance to cover customer funds. The latter option appears to be rarely chosen. Most PIs and EMIs work with a settlement and a safeguarding account.

We describe here how this process works for Bacs and FPS indirect participants.

The settlement account, sometimes called a payment account, is an account held by the sponsor bank for the Bacs and FPS indirect participants. It is separate from the settlement account a direct participant, including the sponsor bank, has at the Bank of England to settle its payments via the RTGS payment system CHAPS.

The settlement account is the account where:

• Funds will be debited by the Bacs and FPS sponsor bank to settle outgoing payments (sent FPS payments and Bacs DC, received Bacs DD)

• Funds will be credited to the Bacs and FPS sponsor bank to settle incoming payments (incoming FPS payments and Bacs DC, and sent Bacs DD)

• Funds will be credited to or debited from by the Bacs and FPS sponsor bank to handle recalls and refunds.

The safeguarding account is usually held by the sponsor bank of the Bacs and FPS indirect participant for practical reasons, including intraday safeguarding movements, but can technically be held by any licenced credit institution. It is the account that holds the Bacs and FPS indirect participant’s customers’ funds.

The required tech stack for Bacs and FPS indirect participants

Processing Bacs and FPS payments as an indirect participant involves complex and strictly codified operations. Manually managing these workflows is not realistic. However, building the systems that automate them can be a daunting project. In this section, we break down the tech stack required to process Bacs and FPS payments as an indirect participant, and how solutions like Mambu Payments help.

The core banking system

Core banking systems are the core technological platforms for many financial institutions. Gartner’s definition of a Core Banking System (or CBS) is a back-end system that processes daily banking transactions and posts updates to accounts and other financial records. Core banking systems typically include deposit, loan and credit processing capabilities, with interfaces to general ledger systems and reporting tools.

In the scope of Bacs and FPS payments, a core banking system has several key roles.

First, it manages customer accounts, which includes:

• Operating the logical “split” of the safeguarding account into customer accounts

• Assigning account numbers to accounts

• Operating ledger tasks such as calculating balance for the customer accounts and assigning transactions to customer accounts

• Generating account statements

It also performs part of the payment processing. For both incoming and outgoing payments, the CBS will check that corresponding accounts have sufficient funds, exist, and are not blocked.

For incoming payments, the CBS will identify the customer account linked to the payment using the account number in the Bacs or FPS payment messages and assign the funds to the correct customer account when these funds are transferred from the settlement account to the safeguarding account.

For outgoing payments, the CBS will first run regulatory checks:

• It will perform Confirmation of Payee check

• It will check the payment destination against a list of sanctioned countries or entities, using solutions like Thomson Reuters or Comply advantage

• It will run anti-money laundering (AML), countering the financing of terrorism (CFT) and anti-bribery checks. Note that these checks can be performed by third-party solutions connected to the CBS, such as Hawk.ai Salv Feedzai, SaS and Marble

Summary

Becoming a UK payment systems indirect participant not only solves major pains for relevant fintech companies, it opens strategic opportunities. While it is a lighter process than becoming a direct participant, it still represents a sizable project.

On the operational side, indirect participants are responsible for running the proper anti-money laundering checks on their customers, whereas the bank manages this process for corporate customers.

In addition, some administrative steps are required, such as getting a sort code from a sponsor bank.

Finally, Bacs and FPS indirect participant applicants will need to connect to their sponsor bank connectivity systems, which always differ from the corporate customer ones in terms of file formats, and sometimes in terms of technical integration.

Mambu Payments helps Bacs and FPS indirect participants connect with their sponsor bank and automate the workflows involved in Bacs and FPS payments processing.

Having already integrated with leading sponsor banks and supported financial institutions in their indirect participation project, Mambu Payments’ platform accelerates the technical side of such projects, virtually enabling fintech companies to be technically able to process Bacs and FPS payments by simply connecting to our API.

The chosen sponsor bank will become a key partner of the Bacs and FPS indirect participant. That’s why we are building a growing number of relationships with the UK’s leading sponsor banks. We believe that the success of Bacs and FPS indirect participation relies on much more than technology. We want to ensure we offer our customers and prospects the correct guidance.

If you are a financial institution exploring a Bacs and FPS indirect participation or a bank looking at expanding its Bacs and FPS indirect participation offer, learn more in our Guide to becoming Bacs and FPS participant.