Half-time whistle – the ECB's first assessment of the two-year "digital euro" analysis phase

As reported in a previous blog post, the European Central Bank (ECB) has started a two-year analysis project in October 2021 to assess how the digital euro should be designed. The outcome of this analysis phase will be a decision on whether and in what form the ECB provides the digital euro.

At the halfway point of the two-year period, an interim report was published by the ECB on 29 September 2022. This report highlights many of the questions and theses we addressed in the previous blog series on the digital euro. Thus, the ECB report takes up the progress made and addresses the basic design options for the digital euro that were recently approved by the ECB Governing Council. In this article we would like to explain what these are in a compact way:

Online and offline payment execution
Currently, the ECB is focusing on the following two transaction options:

1. Execution of online transactions validated by an intermediary
2. Execution of offline transactions in a peer-to-peer context that are validated directly or without an intermediary

Data protection, anonymity and credit control
In terms of consumer confidence, the ECB Governing Council describes in its report that the digital euro is expected to have similar data protection provisions as current digital payment methods. Low value payments are to receive higher data protection than payments with comparable maximum amounts. A fully anonymous payment execution without amount limits is currently not planned.
In addition, it is being considered that limits be introduced to control the credit balances. The aim is to restrict the use of the digital euro so as not to artificially create an alternative form of investment for consumers.

Important milestones in 2023

1. In the first quarter of 2023 the European Commission will prepare a proposal for a regulation on the introduction of the digital euro.
2. By the end of October 2023 the ECB Governing Council is to decide whether and how the development of the digital euro will continue. The following phase can extend over three subsequent years.

Source: ECB
https://www.ecb.europa.eu/paym/digital_euro/investigation/governance/shared/files/ecb.degov220929.en.pdf

Public funds as a catalyst?
Even if the half-term review still leaves much room for interpretation and design, initial tendencies are becoming clear. Similar to what is described in the report, we as PPI see that public funds in digital form can make an important contribution to the digital age. The digital euro in the current consumer context would be an important first cornerstone. We are therefore continuing to follow this topic with great enthusiasm and will continue to follow developments on the digital euro closely in the EBICS blog.
Until next time.


Author: Philipp Schröder

Read more

EBICS real-time submission or: who transfers millions of euros with PayPal?

Admittedly, what the development of FinTechs has brought to the market in recent years is smart, lean and, above all, fast. Direct feedback on mobile devices while on the move at the point of sale or on the couch while shopping online is completely normal today, and modern shoppers no longer want to do without it.

However, imagine you have to transfer large amounts of funds or you have the responsibility for other people's money in your company. What standards do you set here for the security and reliable, transparent processing of your payments? Large volumes not only concerning the amount of funds but also the technical sizes of the file processing for bulk payments require other procedures that have long been tested and established with trusted partners of the financial institutions. EBICS with batch processing of large collective files is the European banking standard on which all payment experts rely and which is being introduced step-by-step in a binding manner by more European countries. These established EBICS concepts have now been adapted for the real-time submission and instant payments enabling an innovative online processing.

Security does not exclude speed
The communication with your established financial institutions and the secure transfer of your payment files is now also provided with EBICS as a real-time submission. Based on the WebSocket interface introduced with the EBICS real-time specification, created payments or uploaded payment files are submitted to the bank server with the order type WIP (or corresponding BTF with EBICS 3.0). In the EBICS client the user immediately receives an active success message as a push message about the processing of the payment at the financial institution as a C5N notification. The standard protocol return messages of the financial institution's pain.002 status report are of course also provided. All this is possible if all the products involved are perfectly coordinated and integrated in the continuous process. Mobile EBICS apps for a payment release on the go also map these real-time processes. 

Secure in the fast lane
The first financial institutions are using this feature in productive operation in order to provide their customers with the quality and security they are used to with innovative speed. It may take some time before the large funds transfers are "smart" and quickly transferred from the couch to the companies' accounting departments.

But who knows what habits have crept into some home offices in the meantime. In any case, decentralised work environments have reached a new dimension. Most companies now offer the possibility to work from home, and department heads and authorised signatories also work in their home office. Releases of large payments with distributed signatures are therefore submitted from home in real time and immediately confirmed.

Furthermore, the WebSocket protocol offers the additional option of push notifications sent from the financial institution to the users of the payment application. Apart from the simple status return messages for payments, the financial institution also communicates with its customers in the form of text messages. At the user's request, the messages appear as a flyout on the GUI and are collected in a separate mailbox for reading and downloading.

APIs or not: A smart and fast processing with the usual security standards of your financial institution is no problem with EBICS either!

Author: Christian Veith

Read more

DORA – Digital Operational Resilience Act Part 2: Outlook and objectives

DORA is intended to counter the growing cyber risks. What regulations are planned? Who will be affected by the regulations?

We want to highlight this in two separate and consecutive blog posts. In the first part, we gather information on governance and organisation and look at the extensive ICT risk management requirements, ICT-related incident reporting and risks from ICT third-party providers.

In the second part, we give an outlook on upcoming developments – up to the question of how US cloud providers can be motivated to consider establishing branches in the EU. 

Part 2 

The European Parliament and the Council are expected to adopt the official text of the regulation in autumn 2022, after which it will be published in the Official Journal of the European Union. It is expected that the DORA regulation will apply throughout the EU by the end of 2024. Already at this stage, financial institutions and financial service providers should think about the implementation of an adequate ICT risk management and consider appropriate measures.

Financial companies have an intrinsic interest in protecting their digital operational resilience and improving their resilience against cyber attacks, because operational disruptions can lead to significant revenue losses and – as a result – immense reputational damage. The fact that large financial institutions and Fin- and BigTechs represent a large projection surface for hacker attacks and that the exponentially advancing digitalisation is becoming increasingly relevant reinforce the need to implement EU measures to strengthen the digital operational resilience of financial companies.

Due to the fact that financial companies are usually very strongly interconnected, even a localised cyber incident can pose enormous systemic risks for the financial sector and endanger the financial stability. The products and services provided by financial companies are often fundamental to the functioning of a society. The costs incurred by a cyber attack often mean very high costs for the society and financial companies.

On the one hand, financial companies may be deterred from reporting cyber incidents to the relevant authorities in view of reporting costs and possible reputational damage. On the other hand, cyber incident reports could generate significant external benefits in that other financial companies could identify and close security gaps. However, the proposed regulation lacks proportionality. Financial companies' ICT risk management should focus only on critical elements of the digital operational resilience. DORA, meanwhile, includes all physical components, infrastructures, premises and data centres, regardless of their operational risk. 

DORA requires financial companies to terminate contracts with critical ICT third-party providers if they violate laws, regulations, directives or contract terms, or if they are forced to do so by a financial supervisory authority.

This is likely to increase the operational risk for financial companies because it may be difficult to find suitable alternative providers on an ad hoc basis. Instead, DORA should promote a close coordination between the players concerned, articulate a catalogue of sanction levels and at least provide for transition periods. A strict contract termination mandate should be a last resort.

The restriction on concluding IT supply contracts with critical ICT third-party providers from third countries is a strong interference in the contractual freedom of European financial companies. This measure could paradoxically run counter to the strengthening of digital operational resilience, as financial companies could find themselves forced to contract providers that have a lower level of cyber maturity. This restriction has the potential to limit the selection and access to more cyber-secure and innovative ICT solutions, products and services.

The EU Commission's goals of reducing the European financial sector's dependence on US cloud providers should not turn into actionism. A more targeted measure would be to use regulatory measures to encourage these providers to establish branches in the EU so that they could be monitored more effectively by the local supervisory authorities in connection with operational risks.

In 2023 the European Banking Authority (EBA) will be responsible for the mandate to create the regulatory framework for MiCAR and DORA. In addition to its supervisory duties, the EBA is entrusted with the task of developing supervisory guidelines and procedures, as well as guidelines to ensure the exchange of information between all relevant parties. These include i.a. regulated issuers of crypto-assets, national competent authorities, the ECB and other relevant central banks. The time for this is tight, as everything has to happen before the date on which MiCAR and DORA are applied. The framework to be developed for DORA will provide a supervisory framework to ensure the monitoring and mitigation of cyber risks and ICT-related incidents. For the MiCAR regulation, on the other hand, the EBA will have to develop specific requirements for issuing crypto-assets and offering crypto-services.

Source of the figure: EU Digital Operational Resilience Act (DORA) | Compliance | Haufe

Authors:
Salar Hydary (working student, Consulting Payments)
Judith Petersen (Senior Manager, Consulting Payments)

Read more

DORA – Digital Operational Resilience Act: Part 1: Why digital operational resilience should be assessed uniformly at EU level

DORA is intended to counter the growing cyber risks. What regulations are planned? Who will be affected by the regulations?
We want to highlight this in two separate and consecutive blog posts. In the first part, we gather information on governance and organisation and look at the extensive ICT risk management requirements, ICT-related incident reporting and risks from ICT third-party providers.
In the second part, we give an outlook on upcoming developments – up to the question of how US cloud providers can be motivated to consider establishing branches in the EU.

Part 1

The European Commission, the Council of the European Union and the European Parliament reached a preliminary agreement on the Digital Operational Resilience Act (DORA) proposal on 22 May 2022. DORA thus moves to the centre stage as an integral part of the strategy to digitise the entire European financial sector. The European Commission first published the legislative proposal for DORA on 24 September 2020 as part of the digital finance package. The triumvirate of the Commission, Council and Parliament already adopted the digital finance package in September 2020 to realise the cross-border digitalisation.
The digital finance package includes the following parts:

• Strategy for the digitalisation of the financial sector
• Legislative proposals on crypto assets (markets in crypto-assets regulation, pilot regime for market infrastructures based on distributed ledger technology, transfer of funds regulation)
• Legislative proposals on the operational resilience of digital systems (DORA) of the financial sector
• Strategy for mass payments  

The European strategy for digital operational resilience was completed with the two important crypto regulations markets in crypto-assets regulation (MiCAR) and the transfer of funds regulation (ToFR). On 30 June 2022, the European Union gave the green light to the MiCAR regulation for the supervision of the crypto industry.
Already one day earlier, on 29 June 2022, the European Parliament had reached an agreement on the ToFR.
The aim of DORA is to ensure financial stability, consumer protection and market integrity on the one hand, and to effectively remove regulatory barriers in the financial sector through legal harmonisation on the other. It also creates an EU-wide, cross-sector framework to manage and mitigate the risks associated with information and communication technologies (ICT risks). The DORA regulation affects traditional financial players such as financial institutions, insurance companies and investment companies, but also FinTechs and BigTechs, crypto service providers and trading venues. Micro-enterprises that employ fewer than 10 people and whose annual turnover or annual balance sheet does not exceed EUR 2 million are excluded from the scope of application. (Art. 3 (1) No. 50 in conjunction with Article 2 (3) of the annex to the recommendation 2003/361/EC). 

Control and organisation
Financial institutions and financial service providers should have internal governance and control frameworks that ensure the effective and prudent management of all ICT risks (Art. 4 para. 1). Financial institutions and financial services providers should have a robust, comprehensive and well-documented ICT risk management framework that enables them to address ICT risks directly and effectively (Art. 5 para. 1). The governing body defines, approves and monitors the ICT risk management framework and is accountable for its implementation. To ensure a well-functioning governance, funds should be allocated for investments in ICT resources, including training on ICT risks for the employees (Art. 4 para. 2). 

Requirements for ICT risk management
The requirements listed in DORA to provide an adequate ICT risk management require specific functions. The ICT risk management framework is documented and reviewed at least annually, as well as when serious ICT-related incidents arise from digital operational resilience audits or audit procedures. The aim is to identify potential threats at an early stage, gain insights and ensure a continuous improvement of the IT risk management. (Art. 5 para. 9 DORA)
The ICT management must ensure protection and prevention against cyber attacks or minimise vulnerability to cyber incidents, and implement policies and procedures that ensure the "resilience, continuity and availability of ICT systems" and "high standards of security, confidentiality and integrity of data" (Art. 8 para. 2).
Financial institutions and financial service providers should implement an ICT strategy designed to respond promptly, effectively and appropriately to all ICT-related incidents, in particular cyber attacks, so as to minimise damage, ensure resumption of activities and restore operations as far as possible (Art. 10 para. 2). The implementation of mechanisms that both detect vulnerabilities and record all ICT-related incidents is essential.
As a market player with a strong customer focus and a reputation for integrity, financial institutions and financial service providers should have communication plans in place that "enable the responsible disclosure of ICT-related incidents or significant vulnerabilities to customers and other financial companies, as well as to the public" (DORA Art. 13 para. 1).

Reporting ICT-related incidents
DORA requires financial institutions and financial service providers to implement management procedures to monitor, identify, classify, track, log and report serious ICT-related incidents to the competent authorities (Art. 15 para. 1).
The addressees of reports of serious ICT incidents are the competent national authorities. Financial institutions and financial services providers must provide relevant details of incidents to other institutions or agencies, such as the European Supervisory Authorities (ESAs), the European Central Bank (ECB), or the central contact points designated in the directive on security of network and information systems (NIS Directive). Serious ICT-related incidents are to be reported by authorities in a centralised manner at Union level. Financial companies will be required to submit initial, interim and final reports. Should an ICT-related incident have an impact on the financial interests of service users and customers of the respective financial company, they should be informed immediately (Art. 17 para. 2).

An essential task of the ESA is to publish annually a comprehensive report in anonymous form, which provides information on the reports of competent authorities on serious ICT-related incidents. This concerns the minimum number of serious incidents, their nature, the impact on the business activities of financial companies or customers, as well as the costs (Art. 20 para. 2). In addition, the proposed regulation obliges financial institutions to ensure that contracts for the use of ICT services are terminated if ICT third-party providers violate applicable laws, regulations or contractual terms (Art. 25 para. 8). 

Check of the digital operational resilience
The ICT risk management of financial institutions and financial service providers needs to be regularly assessed for defence preparedness and detection of vulnerabilities, deficiencies or gaps and prompt implementation of corrective actions. ICT systems need to be thoroughly checked on a regular basis. Such a check must be performed at least once a year and documented accordingly. Conducting prevention, detection, response and recovery tests is essential to comprehensively address any vulnerabilities, deficiencies or gaps (Art. 21 para. 5).

The most important instruments for checking the digital operational resilience are the following (Art. 22):

• Vulnerability assessments and checks
• Analyses of open source software
• Network security assessments
• Gap analyses
• Physical security analyses
• Physical security checks
• Questionnaires and scan software solutions
• Source code checks, as far as practicable
• Scenario-based tests
• Compatibility tests
• Performance tests
• End-to-end tests
• Threat-driven penetration tests

How demanding the resilience tests have to be depends largely on the size of the business and risk profile of each financial company.
Particularly high requirements for digital operational resilience checks apply to major institutions in the payments sector, for example large financial institutions, large payment institutions and large e-money institutions. This also applies to sub-sectors that play a central role in payments, banking, clearing and settlement. 

Risks from ICT third-party providers
DORA places a special focus on the EU supervision of so-called ICT third-party providers and the associated ICT third-party risk. The outsourcing of digital functions plays an important role in the ICT strategy of financial companies today. This is where the ICT third-party providers come in. They offer financial companies the provision of storage space or computing power (infrastructure as a service) and the provision of software applications (platform as a service).
Outsourcing can only work if financial institutions can fully monitor and control the subcontracting processes. Financial companies that use ICT services from ICT third-party providers are responsible for ensuring that they comply with the DORA regulation (Art. 25 para. 1). However, if a financial company finds that the ICT third-party provider violates applicable laws, regulations or contractual conditions in the provision of IT services, the contract with the third-party provider must be terminated (Art. 25 para. 8). Financial companies need to put exit strategies in place to deal with failures of ICT third-party providers. The termination of the contract must not conflict with the compliance with regulatory requirements or impair the quality of the services offered (Art. 25 para. 9).
In summary, it can be stated that DORA aims to create an EU supervisory framework for "critical" ICT third parties (Art. 28 para. 1). DORA grants the financial company the right to fully monitor the services to be provided by the ICT third-party provider (Art. 27 para. 2). In doing so, the competent financial supervisory authorities may force financial companies to temporarily suspend some or all of their contracts with ICT third-party providers until the risks have been eliminated. Authorities may, if necessary, require financial companies to terminate, in whole or in part, the relevant contractual agreements concluded with critical ICT third-party providers (Art. 37 para. 3).
Before concluding a contract with an ICT third-party provider, financial institutions and financial service providers must check whether the respective IT supplier is to be classified as a critical provider or whether it covers important digital functions. Financial institutions and financial service providers should check whether their ICT third-party provider is substitutable or whether several contracts are concluded with it (Art. 25 para. 5). The assessment of these criteria is important in that financial companies are not allowed to have contractual relationships with critical ICT third-party providers that are based outside the EU and thus not established in the EU (Art. 28 para. 9).

Source of the figure: EU Digital Operational Resilience Act (DORA) | Compliance | Haufe

Authors:
Salar Hydary (working student, Consulting Payments)
Judith Petersen (Senior Manager, Consulting Payments)

Read more

SEPA 2.0 is in full swing – the migration to new format specifications is starting!

New format specifications of the German Banking Industry Committee (DK) have been in force since November 2021. The changes have not had too much impact on financial institutions and their customers so far. In November 2023, however, this will change abruptly!

The SEPA formats for credit transfers and direct debits are changing comprehensively and all payments processing service providers as well as their end customers must get ready and make preparations for those upcoming changes.
As SEPA 2.0 will de facto affect all components and all systems, dealing with the topic and all its dependencies at an early stage is of great importance for smooth processing and uninterrupted further processing of payments.

The EPC published implementation guidelines in June of this year, which, in addition to the corresponding specifications, provide further information about the anticipated changes. The use of structured address data is an essential topic of the upcoming adjustments. Whereas addresses could previously be submitted and processed unstructured by specifying the name and address, with SEPA 2.0 addresses must be specified in a structured manner. In future, there will be separate fields for the name, the street and house number, the postal code and the ISO country code. In addition to the use of structured address data, adjustments to individual fields, such as the batch booking flag, have far-reaching consequences. With the new default setting true of the batch booking flag, a batch booking will be executed in the future. Only if there is a corresponding agreement with the customer for single bookings, each transaction will be shown individually on the payer's (ordering party's) account statement if the value false is set. 

The upcoming changes will therefore not only have an impact on the payment file and payments systems themselves, but will also affect peripheral systems such as master data systems. Many banks that rely on converter solutions or older SEPA format versions now have the chance to take a holistic look at their systems and ensure smooth further processing of payments as part of a project. In this approach, it is advisable to make use of mapping tables, which make analyses, evaluations and implementation recommendations easier and more targeted. This way, separate rules and mechanisms can be established for each institution.

The TARGET2/T2S consolidation has already shown that the migration from the MT to the MX format should not be underestimated and that corresponding projects require more time than many institutions had thought. A postponement of the date by the ECB Governing Council suited many banks. However, postponement and new transition scenarios that go beyond the scenarios in the implementation guidelines should not be presumed for the migration to SEPA 2.0. Those who do not opt for an early start are accepting an enormous risk.

Author: Rebecca Stannull

Read more

Digitalisation in action – key exchange via INI letter procedure

Since the introduction of cryptographic keys in online banking, both for private and corporate customers, the process of exchanging the public keys of bank and user has always been a lengthy and complicated process. Admittedly, for the users it is particularly burdensome – and for the rest of humanity it is a riddle wrapped up in an enigma:

The INI letter procedure that has become established for key exchanges. In use for over 15 years, it is a reoccurring hindrance to the use of EBICS. Generating keys, sending them, then printing the INI letter on paper, signing it and handing it over to the financial institution is complicated and tedious for many. Processing at the financial institution itself, where an employee receives the INI letter, then calls up the corresponding customer contact in the EBICS system and compares the values of the electronic transfer with the values on the INI letter or even has to type them out digit by digit, is also time-consuming. Of course, the signature provided on the account sheet or contract must also be verified. It doesn't sound at all like the digitalisation that is supposed to accompany our business processes today.       

Simplifying the release of EBICS keys
Everything would be much easier if financial institutions were to detach the above process from their own employees, digitalise it completely and thus delegate it to the users themselves. The first step to be implemented is the unambiguous recognition of the respective user by exchanging a mutually agreed secret (e.g. TAN) or – if already available – an activated online session that ensures that the user is actually the right person. As a rule, this already applies to every registered online banking session. If we assume that after a successful key submission, the bank system can reach the active user online, e.g. via smartphone by SMS or app or via an online banking session, then it would surely also be possible for this user to personally confirm the correctness of the key transfer and thus release the EBICS keys within a very short time.

Only the user!
The user may do this because the bank system has determined the identity of that user for release – for example, through the correctness of the requested TAN. The user then only compares the values of the INI letter and the display in the bank system and confirms their correctness. And maybe has to enter them again. In other words, exactly what the employee at the financial institution does. Of course, the bank system logs this release by the user in order to have proof later that the user has checked the process.

Digitalisation in action
Users of the EBICS protocol can use their new access within a few minutes. Time-consuming printouts and transfers to the respective financial institution will no longer be necessary. Days of waiting time are reduced to minutes. The financial institution saves itself lengthy and expensive manual in-house processes of key release. Transferred documents – the INI letter – no longer need to be archived. The digital logging of the new procedure is sufficient and no longer requires manual creation/digitalisation of the INI letter. Customer satisfaction and acceptance of the EBICS procedure are strengthened, financial institutions save costs for employees and manual post-processing. Digitalisation in action, an undeniable win-win situation!

Author: Michael Schunk

Read more

How are CESOP and VAT law related to cross-border payments?

Let’s be honest – when we hear the word tax law in our industry, we do not assume that anything relevant for payment transactions will follow. Of course, payment methods are used by all parties to settle tax liabilities, but this does not make them a subject of regulation under tax law. The bad news, however, is that in future we will always have to look a little closer when it comes to the EU VAT directive.

Overstrain as a background 

In the course of the action plan to create a single VAT area, the EU Commission inevitably encounters the issue of VAT evasion. The increasing use of e-commerce for the cross-border sale of goods and services in the member states particularly reinforces this situation. 

The investigating authorities are struggling with deficient information and limited information gathering possibilities. The required information is often held by third parties (such as payment service providers), usually located in another state. This is compounded by insufficient administrative capacity to cope with the high volume of data required to detect VAT fraud. This concerns both the exchange and the processing of corresponding amounts of data. 

The EU Commission speaks of a three-digit billion loss of tax revenue (https://op.europa.eu/en/publication-detail/-/publication/bd27de7e-5323-11ec-91ac-01aa75ed71a1/language-en/). In order to counteract this situation from the perspective of the European legislator, the previously existing regulations were amended accordingly on 18/02/2020.

Council Regulation (EU) 2020/283 of 18 February 2020 amending Regulation (EU) No 904/2010 as regards measures to strengthen administrative cooperation in order to combat VAT fraud.

• Establishing cooperation between national tax authorities to detect VAT fraud and ensure compliance with VAT obligations.

Council Directive (EU) 2020/284 of 18 February 2020 amending Directive 2006/112/EC as regards introducing certain requirements for payment service providers.
Amendments to the VAT directive:

• Payment service providers will be required to keep records of cross-border payments related to e-commerce.
• Data must be made available to the national tax authorities. Strict conditions (among others for data protection) have to be taken into account.
  

Council Directive (EU) 2020/285 of 18 February 2020 amending Directive 2006/112/EC on the common system of value added tax as regards the special scheme for small enterprises and Regulation (EU) No 904/2010 as regards the administrative cooperation and exchange of information for the purpose of monitoring the correct application of the special scheme for small enterprises.
In addition to further regulations on administrative cooperation, there were new EU-wide special regulations for small businesses:

• Small businesses based in other member states (MS) may benefit from the small business regulation in the future.
• This applies provided that their annual turnover does not exceed a maximum of 85,000 euros (limit set by MS).
• If certain conditions apply, this can even be up to 100,000 euros, provided that this turnover was achieved throughout the EU.

 
As of 1 January 2024, Directive 2020/284/EU will oblige payment service providers to share their information with the tax authorities, i.e. to improve information accessibility from the authorities' point of view. To this end, it prescribes a central reporting of certain payments data by payment service providers, which authorities are to use in cases of suspicion to carry out their investigation without obstacles.

CESOP – payments data in data retention  

The keyword for the storage of this supplied data is CESOP (Central Electronic System of Payment Information). A central system of the EU which is supervised by EUROFISC. It shall not only record the supplied data, but also make it searchable, intelligently search for redundant data records, make correlations visible etc.

Only the tax authorities of the member states will have access – all in accordance with other rights, of course. The general interest in avoiding damage from tax evasion amounting to billions outweighs the individual's right to data confidentiality here.


Which payments have to be reported by whom? 

Whenever payment service providers provide payment services for more than 25 cross-border payments within a calendar quarter to the same payment recipient, regardless of the amount of the transaction, these must be reported. The data must be kept for at least three calendar years.

European payment service providers

If the payment is made to a payment recipient in the EU, the recording obligation lies with the payment recipient's payment service provider.

If the payment is made by a payer in the EU to a payment recipient in a non-EU country, the recording obligation lies with the payment recipient's payment service provider.

Supplying, but how? 

The by now hopefully inclined readers will surely now ask themselves: "Okay, we have a new reporting obligation. But how do we get the data into CESOP?". The good news is that you as a PSP do not have to do this at all, because CESOP is "fed" via the national authorities. It is also already clear what the interface and format for supply and the data format look like. What is unclear, however, and this is the bad news, is how payment service providers for their part will have to hand over the information to the national authorities after they have compiled it from their systems (if they even have this data already). 

Directives require implementation by national legislators. They therefore differ (indirectly) from regulations in their mode of effect. The latter are effective immediately and must be applied directly. The German legislators have not yet dealt with the amendments to the VAT directive; in other words, they have not even begun to implement them. After all, they still have until 31/12/2023 (as a reminder: the start is on 01/01/2024) and are currently still waiting for further developments at EU level (which is not necessarily wrong). 

In the course of implementation, however, the German legislators are free to decide whether to implement 1:1 or to adopt stricter rules. A deviation from the wording of the directive would also be legitimate. The finer details could therefore still depend on the implementation by the German legislators.

Conclusion 

European VAT law is now very much related to payments and makes payment service providers responsible for providing information to the tax authorities of the member states. 

The legal situation at national level and the manner of implementation remain unclear. It is also still uncertain which technical means will be used to transfer the information to the responsible national authority. However, this does not mean that payment service providers can now sit back and relax, because data aggregation, orchestration and the implementation for reporting are not to be underestimated.

Author: Benjamin Schreck

Read more

Project possible in cross-border payments

Have you ever tried to convince your international network of 11,000 participants to climb Mount Everest together? An impossible project, you say. To be honest, for most of us it would probably already fail on account of the network. But the Society for Worldwide Interbank Financial Telecommunication (SWIFT) has managed to build up a correspondingly large network since its foundation in 1973 and has started such a "project (im)possible" – except that the aim is not actually to climb Mount Everest, but to renew the messaging interface in international payments.

Showdown in November 2022

So if you look into the payments offices of global financial institutions these days, you will find this project (im)possible everywhere. Let me briefly summarise what it is all about:
 
SWIFT will change the current communication basis as of 2022. While MT transactions in accordance with ISO 15022 are currently used for communication in international payments, a migration to MX transactions will take place as of 2022. The MX transactions were defined by an international working group Cross-Border Payments and Reporting (CBPR+) and are based on the ISO 20022 standard. This is why we often speak of CBPR+ transactions or MX transactions. The scope includes the transaction formats from payments, reporting and investigation. In the "old MT world", this corresponds to the categories MT1xx, MT2xx and MT9xx.  

The new transactions are also sent via a new interface. The InterAct (FIN+) channel will be opened for payments as of November 2022. A complete changeover from the FIN to the InterAct (FIN+) channel is forced as of November 2025. SWIFT refers to the period between November 2022 and November 2025 as the "co-existence phase" and speaks of a "user-driven" migration. Each financial institution in the SWIFT network may decide for itself when to switch to outgoing MX. However, incoming MX messages must be expected as of November 2022.
 
A supposedly small migration project that has turned into one of the biggest challenges in payments in recent years. Old host systems, the processing of new data fields, the coordination with partner banks and the constantly changing conditions keep bringing new challenges and questions that need to be solved:
 
As a financial institution, when exactly should one make the switch? What happens to rich data elements? Should all sub-elements be saved or can we perhaps do without Garnishment Remittance after all? What exactly happens between November 2022 and November 2025? What is the minimum required in November 2022?
 
SWIFT has set November 2022 as the first possible go-live date. The first-mover banks still have three months to answer the last urgent questions, fix the last defects and inform the last customers. The first-mover banks, which SWIFT says account for more than 50% of the total cross-border transaction volume, are ready to go – and yet there are still changes and recommendations that may jeopardise a go-live.

Too late to turn back

The postponement of SWIFT's Transaction Manager to the end of Q1 2023 instead of November 2022 was one of the major shock moments. For a long time, the Transaction Manager was presented as the "redeeming SWIFT application" that was supposed to ensure a truncation-free transaction exchange across the entire payments chain by storing a so-called golden copy. Regardless of whether information-rich MX transactions or rudimentary MT transactions are sent or further processed, the Transaction Manager was to expand the transactions with the respective data variety originally sent and thus to ensure the consistent forwarding of all information. Now, with the delay, comes the fear that important information will be lost.
 
In order to get a grip on the problem, the PMPG (Payment Market Practice Group) published a recommendation in July to dispense with rich data by November 2023 (https://www.swift.com/swift-resource/251867/download). The term rich data refers to the information that is newly provided with the MX transactions. A financial institution can rightly ask itself whether it makes sense to carry on with the project if such uncertainty continues to prevail.
 
But it is too late to turn back. The project budget has been allocated, the development teams are in the middle of development, the first releases have already been made, the internal go-live plan is in place, the communication campaigns are running hot and the project timeline for the next few months is already set. No matter how agile a financial institution wants to be, a migration project that occupies the entire bank, from e-banking to core processing to account reconciliation, cannot simply be stopped.

We have reached base camp – the ascent is yet to come

With regulatory and market-driven rigour, SWIFT is pushing its participants up Mount Everest and, as is usual on any hike, some are further ahead and some are slightly behind. What is certain is that a number of financial institutions will be sending MX transactions starting November 2022. But have they already reached the summit they were aiming for? If one takes a look at what has been achieved and the scope intended by SWIFT, one can only speak of reaching the base camp – the ascent itself is yet to come. Monitoring of production, additional operation efforts, conversion of reporting messages, conversion of investigation messages, processing of rich data elements and any changes and suggestions by SWIFT are likely to keep project (im)possible a fixed part of the project agenda at many financial institutions.
 
In conclusion, it must be said: the SWIFT community is currently transforming cross-border payments and, with the migration to ISO 20022, is building a basis that should improve and optimise payments in the long term. Even if the promised benefits of structured and granular data, higher data quality, better analysis options and international interoperability will not yet materialise in 2022 or 2023, the foundation for more is being laid. We can be curious about what else will happen in international payments in the next few years.
 
Where do you currently stand with your SWIFT MX migration project and how do you perceive the current situation? Let us know or leave a comment.
 

Author: Florian Stade

Read more

Will financial institutions play a role in the implementation of the digital euro?

The European Central Bank's (ECB) two-year analysis phase on the digital euro is not yet over and many questions are still unanswered. However, there are already initial tendencies on some issues, such as the implementation model or the distribution of roles.

Considering the basic prerequisites of a central bank digital currency (CBDC), such as cash-like security, privacy protection, user-friendly peer-to-peer payments and widespread distribution, various implementation scenarios are currently being discussed.

In this article we will look at two common implementation scenarios:

1. Direct CBDC

In the direct approach, the European Central Bank would develop the digital euro on its own and be the interface to the users.

Consequently, the ECB is responsible for setting up the infrastructure, operating the system, performing the customer onboarding and processing the payments.
All of these issues result in enormous efforts on the part of the ECB, since in addition to the development of the back and front end, the subsequent administration and management also await the ECB. For example, customers need to be guided through processes such as KYC and AML checks. Furthermore, it remains open whether users in this model would receive a separate account at the ECB for payment activities.

In addition to the effort and time factors, the current ecosystem would be undermined, as neither commercial banks nor financial service providers would act as distributors at the customer-bank interface.
 
The indirect CBDC scenario is therefore far more likely:

2. Indirect CBDC

In this model, the digital euro is issued by the ECB and distributed to the end consumer via verified intermediaries, for example financial institutions and payment service providers. The distribution would be similar to the current cash system but in digital form. Consequently, the user has no direct contact with the central bank, but has a direct legal claim against it.

The model would strengthen the existing ecosystem by securing the role of intermediaries and involving them in the provision of the digital euro.
In addition to the administration, intermediaries would be able to build on established processes (including KYC and AML checks), onboarding mechanisms and front-end developments.
In this model it must also be considered that the further development of value-added services can arise in connection with existing use cases of the financial institutions and the digital euro. The ability to innovate is increased and consumers can hope for an optimised user experience.

For the reasons mentioned, we currently assume that the commercial banks will be involved in the distribution of the digital euro in order to use established processes and strengthen the direct customer contact. However, the question remains open as to whether other providers besides classic commercial banks can also take on the role of an intermediary.

At PPI, we are following this topic with great enthusiasm and consider the innovative capacity of the payments system as indispensable for the economy. To keep you up to date on current developments, we will use this blog to regularly inform you about news on the digital euro.

Read more

An important step towards unity

From the end of 2023, the range of users of the Electronic Banking Internet Communication Standard (EBICS) will expand: in November of next year, the migration of payments systems from the proprietary Multi Bank Standard (MBS) used up to now will begin in Austria. For the companies in the Alpine republic, the changeover means work at first, but in the end it has clear advantages. Because with EBICS, there is a seamless connection to the largest European payments area around Germany and France. Obviously the banks do not leave their customers to make the switch on their own. First, however, the institutions themselves have to do their homework. In a joint interview, Thomas Bargehr, Product Manager Banking Solutions and Payment Services at Hypo Vorarlberg Bank AG, and Michael Lembcke, Leading Product Manager at PPI AG, talk about the schedule, advantages and procedures.

 

1. Mr Bargehr, in July 2020, the Austrian banking industry declared its accession to the EBICS Company, and since then the introduction at the banks has been underway. How far along is your bank, what is the further roadmap?
   We are currently coordinating the requirements for automatic migration interfaces in the PSA (Payment Service Austria). They are to be used to transport data and authorisation methods from the legacy programmes and the MBS master data. This enables a user-friendly switch from MBS to EBICS. The migration itself is to follow from November 2023 according to the national project plan. From then on, all business customers must also switch to EBICS.
   
   
2. Mr Lembcke, German financial institutions have been using EBICS for quite some time, and we have not heard of any problems. What advantages does this standard have for financial institutions compared to MBS?
   For corporate clients, cross-border multi-bank capability is particularly important. Too many different national standards or procedures cause additional work and disrupt processes. Standardisation also promotes possible process automation in the sense of straight-through processing (STP). At the architectural level, EBICS enables an innovative, contemporary design of payments systems.
    
3. Mr Bargehr, the further development of MBS has been discontinued, so corporate customers will have to switch to EBICS at some point. This causes work for your corporate customers; what can be used to justify this?
   Since the introduction of the euro, payments and the formats to be supported by the customer software have been subject to constant change. So companies are already used to the fact that something changes every few years. The manufacturers of enterprise resource planning software usually accompany these developments in a timely and qualitatively excellent manner. Of course, the same also applies to our own house, which always sees itself as a reliable partner at our customers’ side.
    
4.  Mr Lembcke, PPI AG is the market leader for EBICS solutions and has been involved in the standard from the very beginning. From a payments advisor's point of view, how is the introduction in Austria going?
   So far, no significant problems have been identified. The challenge, at best, is to make the transition as smooth as possible for all parties involved. Of course, as a manufacturer of EBICS software, it is our job to provide solutions. Obviously there was already a functioning e-banking standard in Austria with MBS. But in the future, the institutions and corporate customers in Austria will have a European multi-bank standard that is based on state-of-the-art architectures and will make payments in the country future-proof in the long term.
    
5. Mr Bargehr, such a migration of data processing standards is by no means a trivial matter. How do you ensure that nothing goes wrong and there are no downtimes?
   We ascertain the current status of the customer well before the start of migration and thus determine any special requirements in terms of technology and support at an early stage. Accordingly, we then provide support for the companies until the migration. The keys to success are a clean transfer of customer accesses to the EBICS server, a short and at the same time manageable transition period as well as high-quality customer service.
    
6.  Mr Lembcke, PPI AG has accompanied numerous migration projects towards EBICS. What approach do you recommend to a financial institution?
   There is no one-size-fits-all solution here. The procedure depends strongly on the strategy and customer structure of the individual institution. A big-bang migration, in which all customers are migrated at once, is quite conceivable. However, step-by-step migration scenarios are just as justified, even if parallel operation of EBICS and MBS becomes necessary. It is important to exchange information with the institution's corporate customers, whose migration plans should be queried. In any case, there is no reason for downtimes; migration during ongoing operation is absolutely feasible.
    
7.  Mr Bargehr, EBICS does have regional differences; for example, France has insisted on some local adjustments. Are there also deviations from the EBICS standard case in Austria?
   Even though EBICS is not yet a standard in Austria, most banks already operate corresponding servers and clients due to market requirements. However, they have different strategies: some buy off-the-shelf solutions and operate them without further adaptation to national specifics. Others – and Hypo Vorarlberg is one of them – analyse precisely those local requirements and take them into account when designing their customer systems. For us, PPI has implemented the respective special cases into the payments solutions. Therefore, we have already been fully EBICS-ready since 2017.
    
8. Mr Lembcke, does EBICS 3.0 have the potential to end the discussion about the need for additional, PSD2-compliant APIs?
   This is ultimately a discussion in which there can be no result in the sense of a decision. Because just as EBICS is an established standard mastered by all institutions, APIs are also an integral part of the IT landscape due to their number. Both will coexist for some time to come.
    
9.  Mr Bargehr, what path will Hypo Vorarlberg Bank take? Do you offer additional interfaces or are you relying fully on EBICS for the time being?
   The smallest customers can continue to use our online banking as usual. However, small and medium-sized companies as well as large customers will work with us exclusively via EBICS in the future. We are taking the EBICS migration as an opportunity to gradually switch off old payments and banking systems and thus avoid double-tracking.
    
10. Mr Lembcke, a lot is happening in European payments at the moment anyway; examples include the SWIFT migration or Request to Pay (RTP). How is EBICS to be classified in this context?
    The standard fulfils all the important requirements for harmonising the foreseeable changes in European payments with each other. For this reason alone, everything should be done to officially introduce EBICS in other countries. Attention should also be paid to standardising the way of use in order to increase acceptance. The areas of application are already diverse. For example, SEPA instant payments can be processed with EBICS, and RTP is supported in interbank communication. EBICS is the ticket for participation in payments of the future!

Read more

The European Retail Payments Strategy – an update

In today's article, we go into the development of the European payments strategy in a short interview. What is already in motion, what is new and what is on the horizon? We invited our colleague Swaantje – an expert in this field – to talk to us.

EBICS blog:
Hello Swaantje! Thank you for taking the time to be here. Would you like to tell us something about yourself first?

Swaantje:
Hi! Yes, it's my pleasure. I am Swaantje Völkel, Managing Consultant in the Consulting Payments division of PPI AG in Hamburg and I focus on adjustments that are initiated at European level. This includes the EU Digital Finance Strategy and, more specifically, the EU Retail Payments Strategy.

EBICS blog:
What is the biggest challenge here?

Swaantje:
Well, first things first – a strategy is not a law, but only a kind of declaration of intent, a framework plan for the future, for future events. There are no compulsory guidelines or deadlines, it is a process of growth, where observation, interpretation, experience and judgement are required.

EBICS blog:
So the desire for autonomy is strong, but the willingness to make it mandatory less so?

Swaantje:
The EU Retail Payments Strategy is part of the EU Digital Finance Strategy. Both are driven by, among other things, the EU's Open Strategic Autonomy, and are intended to support it. Yes, that's right – the focus is clearly on promoting the EU's Open Strategic Autonomy. The EU Retail Payments Strategy describes 17 measures of varying scale and impact. One main topic is the review of PSD2 – this is where we start at PPI.

EBICS blog:
Does this mean that things are becoming more concrete here and that changes can be expected?

Swaantje:
Indeed. The subject is slowly becoming more tangible: two current consultations are asking for feedback on the objectives of PSD2, including the question on how successful PSD2 has been in achieving its goals. Feedback should also include opinions on the enforcement of PSD2 by national regulatory authorities and any proposed changes that respondents believe should be made to the directive. There is also the question of whether the application scope, measures and procedures of PSD2 are appropriate, taking a forward-looking approach. Responses to these consultations are due to be submitted in the summer.

EBICS blog:
As the effort estimate is what's decisive – can any kind of prediction be made?

Swaantje:
PSD2 has brought massive changes with the introduction of account access by third-party providers and new requirements for strong customer authentication. After the review and amendment of PSD2, we expect changes, but not quite such serious ones. There can still be big and important changes – just not as big as the initial introduction of PSD2. The bottom line is that we have a lot of work to do – because small changes can have a huge impact and vice versa, so I am reluctant to make predictions.
 
EBICS blog:
Is it helpful to take such a vague approach?

Swaantje:
It grants us a valuable creative phase that has always provided useful insights so far. I refer to the difficult wayfinding last time. Secretly, however, we hope that the road to PSD3 won’t be quite as long as it was back then. In particular, delays are encouraged by the continuous lobbying, which on the one hand ensures progress on the strategy, but on the other hand unfortunately also means pointing out many competing wishes, evaluating them and trying to reconcile them. This is not an accelerating aspect.

EBICS blog:
In that case, be honest – when will the drafting of a PSD3 be achieved?

Swaantje:
2023! (laughs)

Read more

Big moment at the TRAVIC User Group 2022 - payments as a service in double pack

After a three-year forced break the TRAVIC user group finally took place live again. Innovations of the TRAVIC suite and product-related workshops were presented, and any resulting needs and questions were addressed in the deep dive in a collaborative setting. However, that was not all – the eagerly awaited guest speakers Alexander Merkel (Deutsche Bundesbank) and Nico Frommholz (Hamburg Commercial Bank) made people sit up and take notice: Mr Merkel outlined the status quo and dared to look over the rim by shedding light on the expectations, opportunities and risks that need to be kept in mind when dealing with the topic of "crypto currencies / digital euro". Mr Frommholz, Director Head of Payment Operations, opened the main topic of payments as a service for discussion with the presentation "SEPA is live" – a topic that PPI AG is increasingly focusing on and, in addition to EBICS, is a major drive and cause for consideration.

With the go-live of HCOB, PPI AG has demonstrably succeeded in filling a significant gap in the payments as a service market. However, it gets even better: the British Internet direct bank Revolut relies on the data exchange solution TRAVIC-Interbank and also on the payment-as-a-service model – cloud-based and by PPI AG – for its expansion into the EU region. Founded in London in 2015, neobank Revolut currently has around 18 million private customers who use the company's finance app. In January of 2022 Revolut launched its banking service offering in Germany and nine other European countries. For the aggressive development of the EU market, Revolut, as a non-EU bank, needs a connection to the European Banking Authority (EBA) as well as the technical connection to EBA CLEARING – in particular to the real-time payments system RT1 for SEPA instant payments and the STEP2 platform for regular SEPA payments. This connection is realised through the TRAVIC-Interbank data exchange solution and the payments-as-a-service model. 

The Hamburg-based consulting and software company PPI AG thus becomes an all-round service provider in the European payments business. The payments as a service solution expands the consulting and software products divisions to include a complete offering and thus rounds off the service portfolio of the Hamburg-based company. PPI, with its teams of specialised consultants and its TRAVIC suite, is therefore one of the European market leaders in the payments sector. "We are now able to offer payments as a service across the full spectrum of the payments processing for financial institutions. This enables them to relieve their IT departments, use their resources efficiently and thus improve their competitiveness," said Dr Thorsten Völkel, CEO of PPI AG. It constitutes a prime example that the TRAVIC suite not only provides the central software solution for this, but above all serves as the future for a standardised, multi-client-capable, modern and hosted payments platform for the European banking market! With these services PPI AG enables financial institutions and insurance companies to operate entire value chains as a software as a service. The modular portfolio ranges from the provision and operation of the IT infrastructure to a wide variety of services and inspires not only because of its internationality, its technical complexity, but above all on the compliance and legal level.

These success stories clearly show what we have in common: a passion for excellent payments software and consulting services. We are very pleased to have shared this aspiration on the User Group 2022. As we have all learned, sharing facts and solutions to issues in digital meetings and calls has been a matter of course. But it was precisely the mutual and collaborative inspiration from which the further development of TRAVIC products has always benefited, characterised by the lively and face-to-face exchange, that we missed. All the greater was the pleasure of being able to continue this close cooperation in a festive manner and to honour the esteemed PPI customers for two days with a packed and varied programme: from the presentation of new TRAVIC product releases, to use cases and the latest treasure troves of experience, to in-depth discussions with customers in the context of the product-specific workshops.

Author: Andreas Löwe

 

Read more

Check of EBICS certificates in France without trusted third-party providers

Electronic certificate and applications
The electronic certificate is an essential element in setting up protected areas. It allows its holder to authenticate (authentication certificate), provide a signature (signature certificate), establish a secure connection, etc. For access and signature control functions, applications use a certificate to authenticate the holder and control information integrity. There are numerous certificate issuers today (banking sector, administration, companies ...).

The applications for the digitalisation of data streams are diverse and affect all sectors of the economy. They require the establishment of protected areas where it must be possible to technically identify and authenticate the various actors and verify the quality of the transactions and their issuers.
 
As a rule, an application must be able to accept certificates from different certification authorities, because in a global world it would be too costly and equally too restrictive to require one certificate per application from a holder.

EBICS and signed certificates
To communicate with financial institutions, EBICS users with a T or TS profile must use X.509 certificates. If the user has certificates signed by a certification authority (CA), these must be validated when downloading the keys and, for example, for orders of the order type FUL. The order types for the submission and amendment of certificates (INI, HIA, H3K, PUB, HCA and HCS) support both a single certificate and certificate chains.

Validation of the CA-based certificate
The validation of the CA-based certificate can be performed externally or internally (for EBICS TS). It is now possible to check internally submitted certificates in TRAVIC-Corporate. For this, the revocation list annotations are checked using certificate revocation lists (CRL). The certificate revocation lists must be downloaded from the Internet. To download the SWIFT certificate revocation lists, a client certificate is usually required for TLS communication.

Interface for checking internal certificates of TRAVIC-Corporate for EBICS TS
Among other parameters, TRAVIC-Corporate's provider interface includes the check of certificate, a caching strategy, the storage of non-repudiation files and a preliminary check of ES authorisations (EBICS TS) according to CFONB specifications. The provider can be specified and activated via the name of its class.

The certificates are checked against a truststore stored in TRAVIC-Corporate. The entire certificate chain is checked up to the valid root certificate. No external services are used to check certificates.
As components of TRAVIC-Corporate, a job server and a parser control this processing. The payment order is released if the signature profile of the EBICS user matches the signature profile configured at the level of the customer's order type.

The financial institution can thus rely entirely on its TRAVIC-Corporate solution without having to resort to third parties, thus simplifying the system architecture and reducing costs.

Zaher Mahfouz

Sources: PPI TRAVIC-Corporate, CFONB, X.509 standards

Read more

ISO migration for cross-border payments - a wake-up call

Worldwide, payments systems are being migrated to the ISO 20022 standard UNIFI (Universal Financial Industry Message Scheme). In the euro area, this process began with the introduction of SEPA in 2007. Next November, the time will come for high-value and cross-border payments as well. The financial world expects a lot from the migration. In a survey by msgGillardon and Unifits, 99 % of the experts questioned had a highly or rather positive view of the ISO migration. And indeed, the new standard offers many advantages once it is supported as comprehensively as possible.

The topic is anything but new, and yet the road to it is difficult and the introduction had to be postponed several times. In this context, the Eurosystem of the European Central Bank relies on a big-bang approach, while SWIFT envisages a three-year coexistence phase of MT and MX formats for global payments via the SWIFT network. Although the big-bang migration seems like the more difficult project, as all banks in Europe with TARGET2 or EBA EURO1 connections have to switch over at the same time and without any delay tolerance, the coexistence phase of MT and MX also has its pitfalls.

The TARGET MX migration is much more than just a format change. At the same time, technical access will be switched to ESMIG (Eurosystem Single Market Infrastructure Gateway). An ISO-based recall process and central liquidity management (CLM) with new liquidity accounts (MCA/DCA) will be introduced. The ECB has stipulated a test period of around one year for the banks and is continuously monitoring the transition – at quite a few banks, their own TGT MX projects are in yellow or red status. The secure operation of high-value payments in Europe appears to be at risk at some institutions.
 
However, this wake-up call is for the migration in cross-border payments. The SWIFT initiative CBPR+ (Cross-Border Payments and Reporting Plus) tries to facilitate a soft transition through the 3-year transition period. Each financial institution should be able to meet the goal of the ISO migration at its own pace. As a result, conversion takes place in many places instead of end-to-end processing of the ISO data. Some financial institutions continue to send and receive MT messages for payments, others are already using the ISO formats. Furthermore, the migration takes place in stages per message type anyway.

A closer look shows that the transition period is expected to cause huge problems both for financial institutions that have not yet migrated to ISO and for financial institutions that are technically ISO-ready:
Financial institutions that can only process MT risk slower processes due to conversions and have to invest in, for example, transitional solutions for compliance reasons as in some processes the original ISO formats have to still be retrieved and checked. The worst problem: the threat of losing data such as addresses...

Other problems lie ahead for all SWIFT participants: the MT/MX transition period leads to a multitude of new scenarios and use cases due to the possible formats in messages of a transaction – notification in MT, cover in MX, fee request in MT, recall in MX, etc. – which can be used in different ways. Transaction monitoring becomes more difficult and different mapping at participating financial institutions can lead to misinterpretations.

I would like to briefly outline a particularly critical scenario: a payment ordered in ISO format is executed via a longer chain of correspondent banks, one of which can only send MT formats. The MT correspondent receives the converted ISO payment and is obliged to retrieve the original ISO format, but cannot pass on the truncated data in MT format. The SWIFT Transaction Monitor does not yet contain a "golden copy" of the original payment, and thus the recipient bank can now neither read out or query the lost data from the MT message nor from SWIFT. In this scenario, the information is therefore not completely transported from the ordering party to the recipient, although both the ordering party's bank and the recipient's bank can already process ISO formats.

My recommendation is therefore, despite the acute shortage of expert staff, to make use of the remaining time and test the cross-border payments migration with all its many scenarios (which are actually new in this context). Ideally, you should test together with your correspondents in particular and check whether the mapping of bilaterally agreed MT assignments still fits in the ISO world.
After all, all financial institutions that act as transaction banks should be able to process the ISO data end-to-end without conversion.

Otherwise, international payments will be faced with a three-year long ordeal.

Thomas Riedel

Read more