The EU instant payments regulation¹ comes into force on the 5^th October this year. Importantly from a corporate perspective, it includes a VoP (verification of payee) regulation that requires the originating banking partner (Payment Service Provider) to validate one of the following data options with the beneficiary bank:

• IBAN and Beneficiary Name
• IBAN and Identification (for example LEI or VAT number)

This beneficiary verification must be carried out as part of the payment initiation process and be completed before the payment can be potentially reviewed and authorized by the corporate and finally processed by the originating banking partner. Now whilst this concept of beneficiary verification works perfectly in the instant payments world as only individual payment transactions are processed, a material challenge exists where a corporate operates a bulk/batch payment (file based) model.

Many large corporates will pay vendor invoices (commercial payments) on a weekly or fortnightly basis or salaries on a monthly basis. Their ERP (Enterprise Resource Planning) system will complete a payment run and generate a file of pre-approved payment transactions which are sent via a secure connection to their banking partners. Typically, this automated file-based transmission contains pre-authorized transactions which has been contractually agreed with the banking partners. The banking partners will complete file syntax validation and a more detailed payment validation before processing the payment through the relevant clearing system.

If we focus on euro denominated electronic payments, these must be fully compliant with the new EU regulation from 5^th October. This means the banking partners will need to verify the beneficiary information before the payment process can continue. So the banking partner will send an individual VoP check for each payment instruction contained within the payment file (batch of euro transactions) for the beneficiary bank to provide one of the following verification statuses:

• Match
• Close Match
• No Match
• Not applicable

The EU regulation then requires the banking partner to make the status available to the corporate to allow a review and approve or reject transactions based on the status that has been returned. This means there may be a ‘pause’ in the euro payments processing before the originating partner bank can proceed in processing the euro payment transactions. But this ‘pause’ may be exempted by contractual agreement, which is referred to as an  ‘Opt-Out’. This is only  available to corporates and covered in more detail below.

Key Considerations for the Corporate Community:

1- Notification of VoP Status: This new EU regulation will include the following status codes which will apply at a group and individual transaction level.

Group Status

RCVC  Received Verification Completed

RVCM  Received Verification Completed With Mismatches

Transaction Status

RCVC  Received Verification Completed

RVNA  Received Verification Completed Not Applicable

RVNM  Received Verification Completed No Match

RVMC  Received Verification Completed Match Closely

These new status codes have been designed to be provided in the ISO 20022 XML payment status message (pain.002.001.XX). However, a key question the corporate community need to ask their banking partners is around the flexibility that can be provided in supporting the communication of these VoP status codes. Does the corporate workflow already support the ISO XML payment status message and if so, can these new status codes be supported? At this stage, corporate community preference might be skewed towards leveraging a bank portal to access these new status codes, so an important area for discussion.

• Time to complete the VoP Check: The regulation includes a 5-second rule for a single payment transaction VoP request which includes the following activities:

• the time needed by the originating banking partner to identify the beneficiary bank based on the IBAN received,
• send the request to the beneficiary bank,
• beneficiary bank to check whether received info is associated to received IBAN,
• beneficiary bank to return the information,
• originating bank to return info to initiator.

If we now consider the timing based on a file of payments, the overall timing calculation becomes more challenging as it is expected originating banks will be executing multiple VoP requests in parallel. The EU regulation requires the originating banking partner to carry out the VoP check as soon as an individual transaction is ´unpacked´ from the associated batch of transactions. At this stage, a very rough estimate is that a file containing 100,000 transactions will take around 4 minutes to complete the full VoP process. But this is an approximate at this stage. The important point is that the corporate community will need to test the timings based on their specific euro payment logic to determine if existing file processing times need to be adjusted to respect existing  agreed cut-off times and reduce the risk of late payments.

Corporate Action on VoP Status: This will be another area for discussion between the corporate and its banking partners, but the current options include:

• Authorize Regardless: Pre-authorise all payments, including those with mismatches.  
• Review and Authorize: Review mismatches and provide explicit authorization for processing.  
• Reject: mismatched payments or the entire batch.  

The corporate discussion should also include how the review and approval can be undertaken. Given that the October deadline is fast approaching, the current expectation is that banking portals will be used to support this function, but this needs to be discussed including whether exceptions can be rejected individually, or if the whole file of transactions will need to be rejected. Whilst the corporate position is very clear that the exceptions only approach is required, it is still unclear if banks can support this flexibility.

Understanding the ‘Opt-Out’ Option:

Whilst the EU regulation does include an ‘opt-out’ option, meaning a VoP check will not be performed by the originating banking partners on euro transactions, this option currently only applies to bulk/batch payments and not a file containing a single payment transaction. Whilst the option to use a bank portal to make individual transactions has been suggested as a possible workaround, there is increasing corporate resistance to using bank portals given the automated secure file based processing that is now in place across many corporates.

The opt-out option needs to be contractually agreed with the relevant partner banks, so the corporate community will need to discuss this point in addition to understanding the options available for files containing single transactions, which will still be subject to the VoP verification requirement.   

In conclusion

Whilst the industry continues to discuss the file based VoP model, the CGI-MP (common global implementation market practice) group which is an industry collaboration, is now recommending corporates to opt-out at this stage due to the various workflow challenges that currently exist. However, corporate and partner bank discussions will still be required around files containing single payment transactions.

There is no doubt VoP provides benefits in terms of mitigating the risk of fraudulent and misdirected payments, but the current EU design introduces material logistical challenges that require further broader discussion at an industry level.

Historically, SAP faced limitations in this area, but recent innovations have addressed these challenges. This article explores how the XML framework within SAP’s Advanced Payment Management (APM) now effectively handles complex payment formats, streamlining and optimizing treasury functions.

SAP Bank Communication Management (BCM) has been SAP’s solution for integrating a corporate’s SAP system with their banks. It is offering a seamless and secure connection to either a payment network or directly to the bank’s host-to-host solution. Payment and collection files generated from the Payment Medium Workbench can be transferred directly to the external systems, and status messages and bank statements can be received and processed into the SAP application.

The BCM solution has proven to be successful, and corporates wanted to leverage the solution also for transferring messages that do not have their origin in the SAP itself. For example, payment files coming from an HR system or from a legacy ERP system need to be transferred via the same connection that has been established with the BCM setup. For this requirement, SAP introduced the SAP Bank Communication Management option for multisystem payment consolidation, more commonly referred to as the BCM Connector. This add-on made it possible to process payment files generated in external modules or systems into SAP BCM.

However, the BCM Connector has an important limitation: it can only forward the exact format received to external parties. This means that if a legacy system provides a payment file in a proprietary format, it cannot be converted to a more commonly accepted (e.g., XML) format. As a result, compliance with bank requirements regarding payment formats lies with the originating application, limiting the ability to manage payment formats centrally from within the SAP system.

SAP has recognized this limitation and has been focusing on developing a new module to support organizations with a need for centralized payment processing. This solution is called SAP Advanced Payment Management (APM) and offers support for several scenarios for managing payments and payment formats in a centralized environment.

One of the main features of the APM solution is the file handling, which is implemented through an XML Framework. In short, this means that all payment files that need to be processed are handled as an XML message in a canonical data model.  This allows for standardized payment processing across various incoming formats.

The main advantages of the XML framework are:

• Parsing into easy formats
  • Complex message structures are mapped into generic XML structures that are aligned to the most used message standards (ISO20022). These structures also match to a large extent to the internal data structure of the business objects within SAP APM.
• Embedded XML schema validation
  • The XSD schema files for the input structures can be loaded into APM to be used for validation of incoming messages. This takes a way the burden of defining and implementing custom-built validations for these files.
• Interface for easy implementation
  • Transferring the data elements from the incoming messages into the canonical data structures can be achieved via predefined Badi's and using several easy-to-use methods for retrieving and analyzing the source message.
• Parallel processing for large messages
  • The XML Framework offers functionality to divide large messages into smaller building blocks and process them in parallel. This makes APM a very powerful solution that is able to process large numbers of payments in a timely manner.
    

The solution can also be used for non-XML messages. This requires a preprocessing step where the source file is converted to an XML representation of the file. After this step, the message can be processed like any other XML file including the validation and parallel processing options.

Implementing this solution for XML and non-XML formats is a technical exercise that requires ABAP-skills and knowledge of the SAP enhancement framework . However, SAP has made it easier to implement custom formats with the framework while fully utilizing the capabilities of the APM module.

For organizations seeking to enhance their payment processing capabilities through centralized management and innovative solutions like SAP Advanced Payment Management, our team is equipped to provide expert guidance. To explore how APM can support your treasury operations and ensure seamless financial integration, please reach out to us at r.claassen@zandersgroup.com.