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. In this article, we explore how solutions like Numeral help SEPA indirect participants connect to the schemes and process SEPA payments per the regulation and rulebook requirements.
If you don’t know the flows involved in such a process, we strongly recommend you to read our dedicated article about what it takes to operate as a SEPA indirect participant.
Before we jump into the bank connectivity and payment solution part, we must address what these solutions, including Numeral, will most likely connect to on the SEPA indirect participant’s side: core banking systems or CBS.
Core banking systems are the core technological platforms for many financial institutions. Per Gartner, a core banking system 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 SEPA payments, a core banking system has several key roles.
First, it manages customer accounts, which include:
Operating the logical “split” of the safeguarding account into customer accounts
Assigning IBANs 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 IBAN included in the SEPA 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 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 Feedzai, SaS, and Marble
It will then withdraw the funds from the correct customer account in the ledger when funds are transferred from the safeguarding account to the settlement account.
Also, sponsor banks can offer off-the-shelf solutions to indirect participants that do not have the teams and tools to handle these regulatory requirements in-house.
CBSs can have native payment solutions and native bank integrations with some sponsor banks. Still, the SEPA indirect participant might want to work with unsupported sponsor banks or a CBS that does not have a native payment solution. Payment and bank connectivity solutions like Numeral help SEPA indirect participants in three ways.
First, in order to send and receive SEPA payments, a SEPA indirect participant needs to be connected to SEPA. It does it through its SEPA sponsor bank, through which it will exchange SEPA messages with the clearing and settlement mechanism (CSM).
Connecting to the SEPA sponsor bank means establishing a secure and stable connection with the SEPA sponsor bank interfaces (whether SFTP servers or APIs), and packaging SEPA messages into a format accepted by the bank (whether XML files, specific API calls or message queue processors).
For this connection to be robust, it must authenticate with the sponsor bank’s server or APIs automatically, have a retry logic when technical exchanges fail, and account for CSMs’ cut-off time.
All that connectivity and its associated logic are included in the Numeral platform.
A solution like Numeral would be very limited in a silo if it could only be operated via a web interface.
Most of its value comes from the fact that payments can be sent following instructions from the SEPA indirect participant’s systems, ultimately coming from the end-customers, and that received payments can trigger actions in the SEPA indirect participant’s systems.
That’s why Numeral is accessible via an API that can be easily integrated with the SEPA indirect participants, whether a CSB or other, and also provides webhooks that SEPA indirect participants can subscribe to in order to receive notifications of any event happening in the platform.
That’s the core of a solution like Numeral. While a CBS can perform a part of the payment processing, SEPA indirect participants need a solution to create and read the SEPA messages they will exchange with the CSM.
In this section, we describe the technical workflows required to do so, and that Numeral enables SEPA indirect participants to manage.
Managing outgoing payments
When a payment instruction is given, here are the steps Numeral performs to effectively send the SEPA payment in compliance with the rulebook and regulation:
Receive payment instructions, whether initially generated from an end-user interface or automatically from a third-party solution
Turn the payment instructions into financial institution to financial institution SEPA messages that the sponsor bank will forward to the CSM
Package the SEPA messages into API calls or files supported by the sponsor bank
Send API calls or files to the sponsor bank via the sponsor bank connectivity systems (API, SFTP server, message broker…)
Managing incoming payments
As a SEPA indirect participant, you must be able to process incoming payments, which are payments sent to your or your customers’ accounts from other financial institutions. Here are the steps Numeral performs to do so:
Download the payment files or receive the API calls from the sponsor bank via the sponsor bank connectivity system
Parse the API calls or payment files to identify SEPA messages and related payments
Turn the SEPA messages into instructions understood by the CSB
Send the instructions to the CBS
Managing payment errors and exceptions via R-transactions
Payment errors and exceptions might happen for various reasons. In SEPA, these errors are managed via messages called R-transactions, that SEPA indirect participants must be able to send and receive.
Numeral helps SEPA indirect participants manage these exceptions by both sending and receiving R-transactions.
When Numeral receives exceptions from the CBS, it turns them into R-transaction messages. These messages are then packaged into API calls or files supported by the sponsor bank, and sent to the sponsor bank.
When necessary, for instance in the case of a return, Numeral reconciles the settlement and safeguarding accounts transactions with the transfers related to the R-transactions.
Receiving and processing R-transactions
When a SEPA indirect participant receives R-transaction messages from its CSM through its sponsor bank, Numeral downloads the files containing these messages and parses them to identify the said R-transaction.
Numeral then displays the R-transactions in its dashboard to enable the SEPA indirect participant’s compliance and banking teams to review and accept, deny or challenge them.
Numeral also turns R-transactions into instructions understood by the CBS, before sending them to the CBS.
When necessary, similarly to when sending R-transactions, Numeral reconciles the settlement and safeguarding accounts accordingly.
Transactions monitoring and errors resolution
Other errors than the ones linked to R transactions can happen, and while Numeral usually automates most of the workflows described above, human intervention can still be required.
High-level monitoring and reporting
SEPA indirect participants need a view of their payment operations to make sure their payments are processed correctly, in a timely manner and identify when repeated errors happen to optimise their operations.
Specific payment issues investigation
SEPA indirect participants need to identify payment issues when they happen and identify their root causes. To do so, they need access to all the linked information to such payments, including the linked creditor and debtor bank accounts, files related to the payment, or transfers between the settlement and safeguarding account linked to the payment.
Manual tasks to solve the issues
When the SEPA indirect participant’s team has identified the root cause of a payment issue, they might need to perform manual tasks to resolve it, such as manually sending or approving a payment, or performing a manual reconciliation.
That’s why Numeral comes with a dashboard allowing non-technical teams to have the required visibility and manually resolve the issues when necessary.
As we have covered in this article, a solution like Numeral helps SEPA indirect participants connect with their sponsor bank and automate the workflows involved in SEPA payments processing.
Having already integrated with leading sponsor banks and supported financial institutions in their SEPA indirect participation project, Numeral’s platform accelerates the technical side of such projects, enabling fintech companies to be technically able to process SEPA payments by simply connecting to our API.
As highlighted in the article, the chosen sponsor bank will become a key partner of the SEPA indirect participant. That’s why we are building a growing number of partnerships with Europe’s leading sponsor banks. We believe that the success of a SEPA indirect participation relies on much more than technology. We want to ensure we offer our customers and prospects the right guidance.
If you are a financial institution exploring a SEPA indirect participation or a bank looking at expanding its SEPA indirect participation offer, feel free to contact us.