Will the „Payment Account Verification“ be based on acmt Messages?

Before SEPA was introduced in Germany, the account number and the account holder’s name had to be matched to prevent transposed digits from leading to erroneous transfers. With the introduction of SEPA, a check digit was built into the IBAN, effectively preventing transposed digits. Unfortunately some fraudsters have now successfully carried out so-called “authorised payment fraud” or “push payment fraud” attacks, in which the account holder is induced to make a payment. However, the recipient account is not that of the desired person, but that of the fraudster gang. The Instant Payment Regulation therefore makes „Payment Account Verification“ (PAV) mandatory.

Centralised and decentralised solutions

Of course, there are several service providers with different solutions for name matching, as “participation” in SEPA credit transfers is a permanent source of income. The most obvious solution is to set up a database with IBANs and names to which all banks submit their data. However, such a central database harbours many risks and complexities, so that the current discussion points more towards a decentralised solution.
Decentralised processing means that each institution sets up an interface for name matching requests or connects to the systems of service providers. However, even with decentralised solutions, intermediaries should be avoided for strategic reasons. In the interests of the EU, a provider-independent message format in combination with an EU-owned system is desirable.

The acmt message format

The acmt message format is part of the ISO 20022 message formats and belongs to the class of account management messages. It is therefore not a message format from payment transactions, but from account management. Within this message class there is the acmt.023 `IdentificationVerificationRequest‘, as well as the acmt.024 `IdentificationVerificationReport‘ as the associated response, which could be used for PAV of SEPA Payments. The sending bank therefore asks via acmt.023 whether the name (or other detail) of the account is XYZ and receives a “match”, “does not match”, “almost matches” or “no check possible” back via acmt.024.
In the pure ISO acmt message contains numerous fields with any detail of an account. Therefore not only the name but also all details of an account can be used for PAV. For companies in particular, a comparison can be made using the company registration number or tax number.

How do pacs.008 and acmt messages fit together?

If the PAV is carried out via acmt message format, processing via TIPS or RT1 is not possible, as clearing systems should not be “clogged” with account management messages. Instead, a solution similar to SEPA Request to Pay is recommended, in which an upstream service (SRTP is using pain.013 and pain.014) “prepares” a subsequent SEPA payment transaction. The actual payment then takes place as usual and the rules for the clearing system remain unchanged. The time required for the PAV would thus also be clearly separated from the time required for the SCT Inst transaction.
In this way, the separate PAV service can also be used later for conventional SEPA credit transfers without the need to adapt the Deutsche Bundesbank’s SEPA clearer in any way, for example.

If you have any questions on this topic or are looking for a PAV solution, we look forward to hearing from you here.