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




Structured addresses – or: the ostrich effect is rubbish

Time is running out, the next big IT challenge for the ISO 20022 formats is coming up. As often before, the first rules are already being tightened: As of November 2022, ISO 20022 payments submitted by the customer with unstructured address content of the Ultimate Creditor and Ultimate Debtor are rejected by the financial institutions.

Why were these two specifications in particular chosen? Quite simply – the fields that tend to be filled less frequently in the mass of payments are used as test subjects. Rather few transactions will be affected – therefore this issue can be approached from a small and calculated perspective.

"Not at all" does not work at all
For the applications and their developers, however, the small-scale approach is not a good one. There is a lot to be said for all or nothing – but the latter is not an option. If structured addresses are to be used, they should be used everywhere – including for the creditor, debtor and the other address details.

Too short-sighted
If you now think: "Oh, that's Switzerland, that doesn't affect me here in Germany or Austria", then you might be sorely mistaken. For the future SWIFT payments, too, only structured addresses are to be used as of 2025!
And anyone who believes that this does not affect the customer interface, i.e. the correct delivery of structured addresses by the many customer systems, is overlooking the fact that up to now there has been no system that can correctly break down any address delivered in an unstructured form and process it as a structured address. The diversity of international address data makes this impossible.

Needlework is needed
So now it’s up to all of us – customer product manufacturers as well as financial institutions themselves. Structured addresses have to be recorded everywhere and transported via the respective formats until they eventually end up in the SWIFT network. Records must be changed, database structures adapted and the content data must end up in a new place in the respective ISO 20022 format. Since, as already mentioned, an automatic and error-free migration/conversion of the previous unstructured address data to structured address data is not possible, we have to expect our customers and the employees in the financial institution to perform a manual check of the converted address data – thus a somewhat longer project. For Germany, this has already been defined for the new ISO cross-border payment in the ISO 20022 format pain.001.00.09, effective as of 2025.

Time periods are relative
Anyone who still believes that this change will somehow miraculously happen by itself is mistaken: time is of the essence! 3 years is a conceivably short time for software development, and the work is very extensive. Sticking your head in the sand may seem comfortable, but it leads to blindness in the short term. The early bird has budgets and orders in mind.

Author: Michael Schunk





EBICS and real-time notifications – time for a check-in

It has been more than two years since the Specification "Real-time notifications"  was published on the EBICS website www.ebics.org. I already addressed this topic in a blog post from October 2019. But what has actually become of it? And how has the use developed in practice?

The new interface for real-time notifications has in fact been implemented in the EBICS bank server by some institutions in Germany and is now being used productively by them. Of course, the associated new range of functions only makes sense if there are EBICS clients that use this interface. Under certain circumstances, this interface has thus also been implemented on the client side in corporate customer portals operated by financial institutions.

We remember: the added value of this new interface lies in the potentially faster feedback for SEPA instant payments in the EBICS channel as well as generally in needing fewer "hopeful queries" for download data. Where does that leave us?

Some financial institutions in Germany have implemented the concept. However, not every financial institution is able to offer this new service today. It may not or not yet be the focus for EBICS on the bank side. In addition to the new interface for real-time notifications in the direction of the customer, the prompt provision of the download data in the bank server is also one of the prerequisites for being able to offer customers added value for EBICS. To this end, continuous and timely provision from the back-end systems for the EBICS channel must be available at the financial institutions.

On the customer side, push notifications are of particular interest to corporate customers, for whom timeliness and proximity to real time are increasingly relevant. These EBICS customers have already partially implemented real-time notifications on the client side. Others who, for example, use a suitable corporate customer portal of the financial institution, may also be able to benefit from the new service without any action on their part. Nevertheless, not every EBICS client has the new WebSocket interface for real-time notifications.

The conclusion is that the real-time notification function has not yet reached the breadth of EBICS customers in 2022. So far, it is specialised corporate customers and institutional EBICS customers who rely on real-time notifications in the EBICS channel. For them, real time in payments processes represents a special added value for which an investment here and there is worthwhile. The financial institutions of these customers offer the appropriate service.

We can see that in general the topic of real time in payments still has some growth potential. It can therefore be assumed that real-time notifications in connection with EBICS will also become increasingly important. So let us stay tuned!

Author: Michael Lembcke


The digital euro as a basis for innovation in the economy

The digital euro as a basis for innovation in the economy
The digitalisation of economy and society is advancing at a rapid pace. The Internet of Things (IoT) in particular promises revolutionary business models in which European industry can position itself as a global market leader. The term IoT refers to the increasing interconnectedness of machines and devices. This involves equipping devices with a digital identity so that they can communicate with each other and autonomously execute processes without human intervention. This trend will become more and more relevant in the future.

In order to realise the full potential of digitalisation of the industry, the entire process, including payment transactions, must be optimised and adapted to IoT payments so that payments related to these new business models can also be processed efficiently, automatically and in real time.

However, today's payments system still has the following inefficiencies in the context of IoT:

  1. Limited feasibility of Internet of Things (IoT) business models
    Pay-per-use and machine-to-machine payments require human intervention.

  2. No end-to-end standardisation
    Suitable standards for continuous automated processing are still lacking.

  3. Lack of automation in onboarding
    With the establishment of autonomous machines, automated onboarding is necessary.

  4. High transaction costs
    Cross-border transactions and micro payments in particular are associated with high costs.

  5. Slow settlement mechanisms
    Real-time payments are possible with instant payments, but their spread is limited.

  6. Lack of know-your-object processes
    Appropriate compliance processes for recognising and checking machine identities still need to be created.

To minimise these process inefficiencies and limitations of the payments system, establishing an innovative monetary system would be of great advantage. Thus, during the two-year analysis phase of the digital euro, the European Central Bank (ECB) should not only consider the impact on the consumer, but also develop solutions for the advancing digital transformation of economic processes. However, as it is currently unclear what results the analysis phase will yield for the economy, the private sector has already started to digitise the euro so that (transitional) technologies for economic processes can take hold.

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 throughout the year.

Author: Philipp Schröder

Payments 2022: setting the course

The multitude of tasks in payments remains enormous. For many projects, 2022 will be a decisive year. However, in view of the difficult framework conditions – not least due to the ongoing pandemic – the question arises as to whether all of them can really cross the finish line on schedule or be substantially advanced.

Among the most significant initiatives of 2022 are certainly the major projects in international and high-value payments; the go-live of the TARGET2 consolidation and the start of the SWIFT migration to the ISO 20022 format, both in November 2022. The user tests and their monitoring by the central banks, which will pick up speed in the spring, will provide reliable information on how far the financial services industry has really come in its preparations for the TARGET2 migration.

In addition, two further international payments projects are already waiting in the wings: the processing of cross-border payments in real time and the simplification and improvement of international payments for smaller companies and consumers. The drivers behind this development are the G20 countries and the success of alternative providers such as Wise.

In mass payments (SEPA), payment service providers must prepare themselves this year for the migration of SEPA schemes to the newer ISO version, which is due to take place in 2023. They also need to assess the concrete impact of the EU directive against VAT fraud on their business operations. Background: the EU is taking massive legislative measures to curb the VAT gap within the Union by introducing a kind of tax database in payments. The new reporting obligations will affect financial service providers from January 2024.

 

Decisive year for Request to Pay (RTP)

With regard to SEPA procedures, the focus this year will be on whether Request to Pay (RTP) can be successfully introduced into the market. There are plenty of application scenarios. Among other things, RTP can be used in e-commerce, in the e-billing process and for recurring payments, even at the point of sale. Nevertheless, financial service providers seem to be hesitant about the concrete implementation. So far, hardly any efforts to launch products based on RTP use are discernible. Possible reasons for this are a lack of demand as well as economic or technical hurdles:

  • Customer-bank interface: there is currently no central register of which customer has their account at which institution.
  • RTP clearing: so far, only EBA CLEARING offers processes that are compliant with RTP. In order to cover as many payment recipients and payers as possible, other clearing houses must follow suit.
  • Payment process: on the one hand, a technical solution is required for matching, i.e. for assigning response messages to the payment recipient's bank to the original RTP. Secondly, it must be decided which payment options are to be offered.

In the RTP payment process, many use cases rely on the use of SEPA instant payments. 2022 will bring clarity as to whether the EU Commission will make instant payments mandatory for all payment institutions as part of an amendment to the SEPA regulation or the Payment Services Directive (PSD) – at least with regard to accessibility. Because by the end of 2021, only around 60 per cent of all European payment service providers had subscribed to the corresponding scheme. Accordingly, only – or at least – a good ten per cent of all transfers in the SEPA area are made on the basis of the SEPA instant credit transfer (SCT Inst) scheme.

Little momentum expected for the European Payments Initiative (EPI)

The spread of RTP and instant payments will also play an important role in the realisation of the European Payments Initiative (EPI). At the moment, however, it is questionable whether a uniform pan-European payments solution can be created as an alternative to existing international payments solutions and systems. In Germany, only the Sparkassen-Finanzgruppe (German Savings Banks) and Deutsche Bank seem to still be following the initiative. If the EPI fails, Europeans will ultimately make themselves dependent on US procedures and probably Chinese procedures as well. Hope remains that both politics and the public sector will once again significantly increase the pressure on but also the support for the financial sector. Perhaps a French-German core will form the central part for the EPI.

And what will happen with the digital euro in 2022? The future project is still under scrutiny. The premise is that the digital euro should not replace cash, but complement it. From the consumer's point of view, the digital alternative must ensure the highest level of anonymity and security. Furthermore, provision, availability and interoperability are of high importance. According to current information, the ECB wants to involve commercial banks and payment service providers (PSPs) in the plan. They are to act as intermediaries between central banks and consumers.

One way or another: the digital euro is coming

But digital money does not necessarily have to be issued by a central bank. Financial institutions can also create solutions for so-called programmable payments. One example are euro-based stablecoins; digital tokens backed by a specific monetary value. Progress in these procedures is also expected in 2022.

In whichever form it happens, the digital currency will become reality. This is the only way for the German industry to fully benefit from the potential of the Internet of Things (IoT). Especially the progressing automation in goods logistics or increasingly popular asset-as-a-service models are hardly conceivable in the long term without fully autonomous payments in real time.

In view of the costs associated with aforementioned changes, financial institutions – mainly tier 2 institutions – will increasingly outsource payments or at least purchase payments software as a service in 2022 as well.


The battle for talent

Last but not least, a trend in society as a whole in recent years will continue to intensify: the lack of – and the battle for – resources. Prices for experts and services in IT will continue to rise. Because the question is increasingly no longer who can take on a task, but whether anyone can be found to do it at all. The procurement departments of financial institutions will be headhunting external resources.


Author: Hubertus von Poser, Head of Consulting Payments, PPI AG

Tips for a smooth transition to EBICS 3.0

EBICS 3.0 has been officially introduced at the financial institutions since November 2021 and can be used by corporate customers. In addition, the last previous version is still valid. One of the changes in EBICS 3.0 concerns the omission of the three-digit order types or the FileFormat parameters in France for operative business transactions. These are now mapped via the so-called business transaction formats (BTFs). BTFs include eight parameters each: Service Name, Service Scope, Service Option, Service Message Name, Service Message Name Version, Service Message Name Format, Service Message Name Variant and Service Container.

Within a customer agreement, it must be possible to take into account the central agreement for the respective business transaction, regardless of the EBICS version. Compatibility and interoperability between the previous versions are predefined for EBICS. If two electronic signatures are agreed for a SEPA credit transfer, it is irrelevant, for example, whether submissions for this are made via BTF, order type or FileFormat parameter. This condition requires an internal mapping of old and new business transactions in the bank server and possibly also in client systems. So far, these mappings have been officially specified for the standard business transactions.

The processing upstream and downstream of EBICS at the financial institutions and at the corporate customers is generally still based on the previous EBICS IDs, such as the three-digit order types and in France on the up to 40-digit FileFormat parameters. As long as a mapping exists, there is no need to change anything. However, what if no more order types/FileFormat parameters are specified for a business transaction and the business transactions apply exclusively with BTF? If one does not want to adapt one's adjacent processing operations to the BTFs, a mapping can of course be retained. For the unspecified mappings, however, custom suitable IDs should then be defined.

In external relations in the customer-bank relationship, it should be noted that the customer or client system is informed of the bank server's specifications regarding business transactions and mappings in various ways. In addition, the different representations from the point of view of the customer, participant and time come into play. A participant always uses a specific EBICS version, while the customer agreement must map all valid versions. In addition, the time of the information plays a role. For example, before the EBICS user is initialised, the financial institution usually does not know which EBICS version the user will use.

The BPD sheet (BPD = bank parameter data), which is created in the bank server when the EBICS user is set up, must therefore map the options of all supported EBICS versions including any BTF mapping specifications. The same applies at least to the order type HKD, with which the client-level agreements can be retrieved by the client. If mapping is no longer offered for certain business transactions in the customer-bank relationship, irrespective of internal use, the information should represent the mapping accordingly exclusively via BTF. For internal administration and maintenance, it is helpful if the individual IDs used exclusively for internal purposes are visible in an internal mapping (e.g. individual order types with their own BTF mapping), but are different from the external IDs. 


In summary, the challenge is to make the transition to EBICS 3.0 as easy as possible for all parties involved with the new variety of information. However, with the right configuration and by observing a few guidelines for operation, the migration to the new EBICS version is not difficult at all. If you need help with the migration to EBICS 3.0 or have any questions, please do not hesitate to contact us.

Author: Michael Lembcke

API opens doors for banking applications

The abbreviation API seems to be everywhere at the moment. The three letters stand for application programming interface. All APIs are associated with the hope of being able to implement many banking use cases as simply and quickly as possible via a standardised interface. The number of use cases for this is growing steadily. A variety of players are fuelling this development, meaning that APIs could fundamentally change the banking market.


The PSD2 as a focal point for APIs in recent years has led to various initiatives in Europe specifying an access-to-account API. The most important of these initiatives are undoubtedly "The Berlin Group", "STET" and "PolishAPI". But the PSD2 has also had an impact outside Europe. In Switzerland, the "OpenBankingProject" was launched, with its SwissNextGenAPI being based on the Berlin Group's API. In the United Kingdom, the "Open Banking" initiative has emerged. All initiatives and their APIs rely on the PSD2, and all are united by the desire for high efficiency gains.


Reality dampens this hope somewhat. The standardisation initiatives described above do exist, of course. However – firstly, there is no single "true" specification. Secondly, banks are not obliged to adhere to the available specifications, either. And thirdly, the specifications grant plenty of liberties in terms of implementation (think implementor options). Now if a market participant, be it a bank or a third-party service provider, wants to use the banks' access-to-account APIs, they face a challenge. PPI has taken on this challenge and with the product TRAVIC-Payment-Client-API created a library that conceals the outlined heterogeneity behind a single interface. By using TRAVIC-Payment-Client-API, risks can be minimised and development time reduced while connecting the banks' access-to-account interfaces. The product is in productive use at Atruvia AG. Read more about this and how Atruvia AG has benefited from it at (https://www.ppi.de/banken/success-stories-banken/success-story-atruvia/).


From PPI's point of view, it is impossible to imagine payments without APIs. Driven in part by the PSD2, the first steps on the banking side have already been taken. But it will likely not stop there. The Berlin Group has long since specified the openFinance API framework, which extends the use cases of the access-to-account interface. As far as we know, further extensions to the specification are planned for 2022. These value-added services, which are of course provided via APIs, are being offered to an increasing extent on the developer portals of major banks. Some of these APIs are no longer only aimed at third-party service providers, but also directly at companies. This makes it clear that the topic of APIs is not limited to PSD2-relevant use cases, but will increasingly establish itself as an independent channel for different stakeholders. Consequently, there will probably be other APIs in addition to EBICS, FinTS and access-to-account sooner or later.

The Berlin Group is not alone in its API activities. The European Payments Council (EPC) has set up a working group for the European sphere to develop a rulebook for accessing SEPA payment accounts via APIs (https://www.europeanpaymentscouncil.eu/news-insights/news/call-candidates-sepa-payment-account-access-multi-stakeholder-group-spaa-msg), in which PPI participates. Furthermore, in the recently published announcement on the "SEPA Request to Pay scheme rulebook 2.0", the EPC even stated that the exchange of SRTP messages via APIs will be mandatory in the future. 


There is lot of movement in the market, but one thing is clear: the list of existing and future initiatives around APIs is long, and a number of innovations are conceivable in this environment. PPI has taken the first step with the product TRAVIC-Payment-Client-API and offers it particularly as a service. In addition, PPI is designing further offers around the topic of API.

Author: Christian Wenz