When becoming regulated as a payment institution (PI) or electronic money institution (EMI), fintech companies have several options to access SEPA and send and receive SEPA payments on behalf of their customers.
One of these options is to become a SEPA 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 SEPA and process payments.
In this article, we explore the different payment workflows and technical requirements involved in operating as a SEPA indirect participant.
Before we detail how a SEPA indirect participant operates, we must first understand what a SEPA indirect participant is.
A SEPA indirect participant is a regulated financial institution (payment institution, electronic money institution, or credit institution, i.e. a bank) that connects to SEPA via a sponsor bank instead of connecting directly to a clearing and settlement mechanism (CSM).
There are various advantages for regulated financial institutions to become SEPA indirect participants, including having their own BIC and issuing their own IBANs, increased control on their payment flows and lower payment fees.
A SEPA indirect participant must operate several workflows to send and receive SEPA payments in compliance with regulations and SEPA rulebooks.
Sending a SEPA credit transfer When a SEPA indirect participant receives the instruction from a customer to send a SEPA credit transfer (SCT), it needs to:
Ensure the instruction complies with its internal rules (e.g. amount, frequency, 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 financial institution-to-financial institution credit transfer messages (pacs.008), and 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 CSM
Sending a SEPA instant credit transfer When a SEPA indirect participant receives the instruction from a customer to send a SEPA instant credit transfer (SCT Inst), it needs to:
Ensure the instruction complies with its internal rules (e.g. amount, frequency, destination country…) and AML ad CFT checks
Make sure the customer’s account has sufficient funds
Reserve the funds in the customer’s account.
Generate the financial institution-to-financial institution credit transfer message (pacs.008) and create a new file or API call
Send this file or API call to the sponsor bank, which will forward it to the CSM
Sending a SEPA direct debit When a SEPA indirect participant receives the instruction from a customer to send SEPA direct debit (SDD), it needs to:
Ensure the instruction complies with its internal rules (e.g. amount, frequency, destination country, mandate reference …)
Generate the corresponding SEPA message (pacs.003) and create a new and add it to an existing file to batch payments
Send this file to the sponsor bank, which will, in turn, forward it to the CSM.
If the debtor bank accepts the SDD, the creditor SEPA indirect participant will receive the corresponding funds in its settlement account on the day of the execution of the SDD.
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
Receiving a SEPA credit transfer When a SEPA indirect participant receives an SCT message (pacs.008) 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 SEPA 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
Receiving a SEPA instant credit transfer When a SEPA indirect participant receives an SCT Inst message (pacs.008) from another financial institution via its SEPA sponsor bank, it needs to, within 10 seconds, in order to comply with the rulebook:
Parse the received message to identify the customer account to credit
Check if the payment complies with the SEPA indirect participant’s rules
Make sure the customer account exists and is not blocked
Send back a confirmation 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
Accepting a SEPA direct debit When a SEPA indirect participant receives a SEPA direct debit (SDD) message (pacs.003) 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 SDD
In the case of SDD B2B, check that the SDD originator’s mandate has been registered and authorised
If all checks are successful, the SEPA indirect participant doesn’t have to send a message in return but needs to transfer the corresponding amount from the safeguarding account to the settlement account
In addition to SEPA payment messages themselves, SEPA indirect participants must be able to exchange payment status reports (PSRs) with their sponsor bank. The information included in PSRs includes:
Status Code | |
---|---|
ACCP | Payments have passed technical and functional validations. |
ACSP | Payments have been accepted and processed. |
PNDG | Payments have been put on hold. A reason is included. |
RJCT | Payments have been rejected by the bank. |
ACSC | Payments have been processed and settled. |
PART | At least one payment of the file is accepted and processed, and at least one payment of the file is rejected. |
The flows described above are the flows when everything goes right, or “happy flows”. But for various reasons, errors and exceptions might happen.
SEPA rulebooks specify and standardise how to handle these errors, and SEPA indirect participants must be able to send, receive, and process the messages related to these cases. Those messages are called R-transactions.
Causes of such errors or exceptions might be:
The beneficiary account of an incoming SEPA payment doesn’t exist or is blocked
The debtor account of an incoming SDD doesn’t exist, is blocked, doesn’t have sufficient funds, or cancelled to mandate
The originator of an incoming SEPA payment 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, SEPA indirect participants must be able to
Receive and parse the incoming message from the CSM via the sponsor bank or generate and send the message to CSM 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
Safeguarding customer funds is not a requirement limited to SEPA direct or indirect participants. Any financial institution sending or receiving payments on behalf of customers has to do it.
We describe here how this process works for SEPA indirect participants.
The settlement account is an account held by the sponsor bank for the SEPA indirect participant. The settlement account is the account where:
Funds will be debited by the SEPA sponsor bank to honour outgoing payments (SCTs sent, SCTs Inst sent, and SDDs received)
Funds will be credited to by the SEPA sponsor bank to honour incoming payments (incoming SCTs, incoming SCTs Inst, and SDDs sent)
Funds will be credited to or debited from by the SEPA sponsor bank to handle recalls and refunds. We will cover that in more detail later.
The safeguarding account is usually held by the sponsor bank of the SEPA indirect participant for practical reasons, including intraday safeguarding movements, but it can technically be held by any licenced credit institution. It is the account that holds the SEPA indirect participant’s customer funds.
Customer accounts held by the SEPA indirect participant are a logical representation of the safeguarding account that “splits” and allocates the funds and transactions of the safeguarding account to the customer accounts.
For a SEPA indirect participant, managing settlement and safeguarding accounts mainly means two things:
Being able to honour outgoing payments: Making sure there are enough funds on the settlement account that the SEPA sponsor bank can debit to honour outgoing payments at settlement time for SCTs sent and SDDs received or at any time for SCTs Inst sent.
Regulatory compliance: Regulation requires that PIs and EMIs’ customer funds cannot be held on the settlement account after the end of the business day following the day the funds have been received and should be transferred to a safeguarding account held by an authorised credit institution (in our case most often the sponsor bank). The SEPA indirect participant needs to make sure they transfer all funds received (incoming SCTs, incoming SCTs Inst, and SDDs sent) from their settlement account to their safeguarding account in that timeframe.
As we’ve covered, operating as a SEPA 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 SEPA indirect participant and have questions about what it involves, feel free to contact us.
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.