Guide

Operating as a Bacs and FPS indirect participant

Matthieu Blandineau
5
October 2023
0
min read

When becoming regulated as a payment institution (PI) or electronic money institution (EMI), fintech companies have several options to access Bacs and FPS and send and receive Bacs and FPS payments on behalf of their customers.

One of these options is to become a Bacs and FPS indirect participant. This can represent a significant project for fintech companies to undertake, particularly when it comes to setting up the proper infrastructure to correctly and efficiently connect to Bacs and FPS and process payments.

In this article, we explore the different payment workflows and technical requirements involved in operating as a Bacs and FPS indirect participant. If you need to explore the topic further, you can also explore our article about the tech stack needed for Bacs and FPS indirect participants.

Operating as an 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.

Processing outgoing Bacs and FPS payments

1. 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

2. Sending an FPS payment

When an FPS indirect participant receives the instruction from a customer to send an FPS immediate payment or standing order, it needs to:

  • Ensure the instruction complies with its internal rules (e.g., amount, frequency, and destination country) and AML and CFT checks

  • Make sure the customer’s account has sufficient funds

  • Reserve the funds in the customer’s account

  • Generate the "payment request 9100 agency to member" message and create a new file or API call

  • Send this file or API call to the sponsor bank, which will forward it to the FPS payment system

  • After the payments have been processed by FPS, receive the agency "payment response 9110 member to agency" message

  • Reconcile this message with the sent payments

  • Update the customer balance accordingly

3. Sending a Bacs Direct Debit

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

  • Ensure the instruction complies with its internal rules (e.g., amount, frequency, destination country)

  • Ensure a direct debit instruction (DDI) has previously successfully been lodged with the debtor bank

  • Queue the collection and add it to the next collections' batch, which takes the form of one or multiple "cleared debits" PSP to PSP messages,

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

  • Package these messages in a file

  • Send this file to the sponsor bank, which will, in turn, forward it to the Bacs payment system

  • After the payments have been processed by Bacs and accepted by the debtor bank, the creditor Bacs indirect participant will receive the corresponding funds in its settlement account on the day of the execution of the "Bacs DD" and "debit contra" PSP to PSP message

  • Reconcile the received message with the funds received on the settlement account

  • Transfer corresponding funds from the settlement account to the safeguarding account

  • Reconcile the transaction with the payment from the settlement account to  the safeguarding account

Processing incoming Bacs and FPS payments

1. Receiving a Bacs Direct Credit

When a Bacs indirect participant receives a Bacs "cleared credits" PSP to PSP message from another financial institution, it needs to:

  • Parse the received message to identify the customer account to credit

  • Check if the payment complies with the Bacs indirect participant rules

  • Make sure the customer account exists and is not blocked

  • Reconcile the received message with the funds received on the settlement account

  • Transfer corresponding funds from the settlement account to the safeguarding account

  • Reconcile the transaction with the payment from the settlement account to the safeguarding account

2. Receiving an FPS payment

When an FPS indirect participant receives an FPS "payment request 9100 member to agency" from another financial institution via its sponsor bank, it needs to do the following “within a few seconds” in order to comply with FPS requirements:

  • Parse the received message to identify the customer account to credit

  • Check if the payment complies with the FPS indirect participant’s rules

  • Make sure the customer account exists and is not blocked

  • Send back a "payment response 9110" message

  • Transfer funds from the settlement account to the safeguarding account

After these initial steps, the participant needs to:

  • Reconcile the received message with the funds received on the settlement account

  • Reconcile the transaction with the payment from the settlement account to the safeguarding account

3. Accepting a Bacs Direct Debit

When a Bacs indirect participant receives a Bacs Direct Debit (Bacs DD) "cleared debits" PSP to PSP message from another financial institution, it needs to:

  • Parse the message to identify the customer’s account to debit

  • Make sure the customer’s account exists, is not blocked, has sufficient funds

  • and has not blocked the originator of the Bacs DD

  • Make sure that the direct debit instruction (DDI) has been previously successfully lodged and is still valid

  • If all checks are successful, the Bacs indirect participant does not have to send a message in return but needs to transfer the corresponding amount from the safeguarding account to the settlement account

Payment reports

In addition to Bacs and FPS payment messages themselves, indirect participants must be able to exchange payment report messages with both their sponsor bank and customers.

Payment report messages notify payment systems’ participants and their users of the processing status of their payments.

For Bacs, these reports are called input reports. Consumer grade input reports are exchanged between a PSP and its customers, while bank grade input reports are exchanged between PSPs.

                                                 
StatusDescription
AcceptedPayments have been accepted and processed by Bacs.
AmendedPayments contain certain exceptions that cause an item to be amended. The destination and/or originating account details may be amended if they are invalid. For example, if the originating account details of a direct credit item are invalid, they are amended to be the service user’s main account details.
ReturnedPayments have been returned to the originating account.
RejectedPayments have been rejected by the originating bank.

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.

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:

                                                                                                       
Payment systemMessageDescription
BacsBank grade credit returns
(ARUCS items)
Automated Return of Unapplied Credit Service items allows the receiving bank to return Bacs DC automatically to the originating bank
BacsBank grade debit returns
(ARUDD items)
Automated Return of Unapplied Credit Service items allows the receiving bank to return Bacs DD automatically to the originating bank
BacsUnapplied credit
notifications (ARUCS
report)
Automated Return of Unpaid Direct Debits Service reports allow the receiving bank to notify the originating bank that the payment has not been applied and provide reasons why
BacsUnapplied debit
notifications (ARUDD
report)
Automated Return of Unpaid Direct Debits Service reports allow the receiving bank to notify the originating bank that the payment has not been applied and provide reasons why
FPSBank Error Recover (BER)If a participant sends a large number of payments in error, they may choose to make use of FPS Procedures to send a BER file to the Receiving Participant(s) that received the (BER) payments in error
FPSCredit
Payment
Recovery
(CPR)
The CPR process may be used to attempt to recover payments sent to the wrong account due to customer error or bank error
FPS ReturnsIf, following acceptance, it is not possible to make the funds available to the Beneficiary Customer (e.g. the payment is found to have been made fraudulently, or has failed an AML check), the funds should be returned. A ‘Return Payment’ may then be sent returning the funds
– this is a new payment that references the original payment, and where possible, should be sent via FPS

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.

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.

When a payment arrives on the settlement account, it is allocated to the corresponding customer’s account, and funds are then transferred to the safeguarding account.

For a Bacs and FPS indirect participant, managing settlement and safeguarding accounts mainly means two things:

  • Being able to settle outgoing payments: Making sure there are enough funds on the settlement account that the sponsor bank can debit to settle outgoing payments at settlement time for sent Bacs DC and received Bacs DD or at any time for sent FPS payments.

  • Regulatory compliance: Regulation requires that PIs and EMIs’ customers’ funds cannot be held on the settlement account after the end of the business day the funds have been received. They should be transferred to a safeguarding account held by an authorized credit institution (in our case, most often the sponsor bank) within that time frame. The indirect participant needs to make sure they transfer all funds received (incoming FPS payments and Bacs DC, and sent Bacs DD) from their settlement account to their safeguarding account in that timeframe

How to get there

As we’ve covered, operating as a Bacs and FPS indirect participant involves complex, extremely codified and sometimes time-boxed operations. While manually managing these operations certainly is not realistic, building the systems that automate them can be a daunting project.

Fortunately, software solutions, including core banking systems and payment solutions such as Numeral, exist to automate most of the processes described above. These systems and their specific role will be covered in another article.

If you’re exploring the opportunity to become a Bacs and FPS indirect participant and have questions about what it involves, feel free to contact us.

Not sure where to start?

Let’s talk about how we can work together to accelerate your payment flows. Get a demo of our platform, explore our pricing, or get started right away.

Contact us