Name matching for SEPA Instant Payments transactions

An article by

Andreas Wegmann

Published on


Updated on


Reading time

4 min

Since 26 October 2022, the proposal for a new regulation on SEPA instant payments has been available to the European Commission. This is intended to accelerate the spread of SEPA Instant Payments once again and to make the advantages more widely available. The draft also proposes some additional conditions that have a major impact on banks. This article outlines the technical implications of name matching (Article 5c), which is intended to alleviate the payer’s fear of the finality of SEPA real-time payments.

How is name matching used in SEPA credit transfers so far?

Short answer: not at all! Although the name of the recipient must be given when sending, the recipient’s bank does not check the name to see if it matches the account. This applies to the simple SEPA credit transfer (SCT) and the instant variant. To avoid payment errors, the check digit of the IBAN is sufficient in practice.

How does the name matching work?

The proposal (and the subsequent regulation) does not prescribe a solution for the players of course. Those who have delved a little deeper into the matter know that the banks are not directly connected to each other, but that a so-called Clearing & Settlement Mechanism (CSM) is necessary, i.e. in the case of SEPA Instant Payment either RT1 or TIPS. At this point the money is moved, i.e. the amount (in case of a successful transaction) is booked from the TIPS account of the debtor bank to the TIPS account of the creditor bank.
The diagram shows the process between the actors: the payment (pacs.008) is confirmed positively or negatively by the beneficiary bank (pacs.002).

The pacs.008 contains the recipient’s name and the pacs.002 could receive a (newly defined) error code such as “creditor name mismatch” as a reason for rejection. For reasons of data protection, the debtor should not be shown the actual name of the account holder in order to then simply confirm it. Rather, the payer would have to initiate a new payment with the then hopefully correct name.

The effort for banks

On the debtor bank side, the effort is less, since the field for the recipient’s name must already exist today. When dealing with the customer, it remains to be considered whether and how to price a SEPA Instant Payment transaction along with any failed attempts.
There are significantly more adjustments on the creditor side, because the name check must be carried out here. Since a SEPA Instant Payment payment may only take a total of 10 seconds, the check must be carried out very quickly.
Banks already have to check incoming payments to see whether the IBAN is admissible and whether the parties involved are on a sanctions list. It is not an option to accept the payment “provisionally” and possibly send it back later in order to circumvent the time limit. A further check will significantly increase the response time in some banking systems.
By their very nature, different spellings of names inevitably lead to blurring.

The use of fuzzy logic systems seems to be a sensible way out in order to take the edge off these uncertainties. On closer inspection, the creditor bank is taking a risk: according to the draft, the risk of a “wrong” transfer should remain with the bank.
Also included in the draft is the proposal that the payer must have the possibility to authorise the transaction despite a name mismatch. Otherwise, people with complicated names might not receive SEPA Instant Payment payments at all.

Fraud scenario

One motivation for introducing name matching is the use of SEPA Instant Payments for payments in retail shops or restaurants: the payer scans a QR code containing the IBAN of the payee (e.g. from a posted sign) with his banking app and carries out the SEPA Instant Payment transaction. The POS system calls up the incoming payment from the bank (e.g. via EBICS WebSocket) and gives feedback accordingly. But what if the employee at the checkout on the night shift puts up his own sign with the QR code of his IBAN? The payer transfers to the wrong account and has no possibility of revocation, as SCT Inst transactions are explicitly final. Here it seems to make sense to do a name match, as the QR code can of course provide IBAN and name. The hurdles for fraudsters to open name-like bank accounts are high, though not insurmountable.


Name matching seems less a practical solution to prevent fraud than a cosmetic trick to convince bank customers to use SEPA Instant Payments. Whether this will be successful is at least doubtful, because name matching also has disadvantages. It is certain that name matching will increase the effort for banks and will not make SEPA payments cheaper.

If you have any questions on this topic or are interested in our payment transaction solutions, please use our contact form.

Suchen Sie nach einer Lösung für den elektronischen Zahlungsverkehr?