ARTICLE
Operating as a SEPA indirect participant
14 February 2023
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.
What is 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.
Operating as a SEPA indirect participant
A SEPA indirect participant must operate several workflows to send and receive SEPA payments in compliance with regulations and SEPA rulebooks.
Processing SEPA outgoing payments
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
Processing incoming SEPA payments
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
Payment status reports
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:
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. 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
Managing settlement and safeguarding accounts
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 can technically be held by any licensed 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’ customers 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.
How to get there
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 Mambu Payments exist to automate most of the processes described above.
© Mambu 2026