ISO 20022 in cross-border payments: time for change!

Nearly all major payment systems are in the process of introducing standardised, XML-based data formats. They make both cross-border and individual payments significantly faster and less susceptible to errors. But the conversion will not happen on its own and there is not much time left. What needs to be considered?

Card payments on holiday and cross-border payments are now taken for granted in everyday life. However, every electronic transaction requires highly-complex processes since, for a fast and smooth money transfer, all IT systems involved must be able to handle the generated data equally well. For this, standards such as ISO 20022, which will be the benchmark for foreign and individual payments in the coming years, are needed.

Proven standard for the future

More and more payments areas are converting their systems according to the ISO standard because it brings huge advantages: it is future-proof, allows the significantly faster processing of payment data and enables a considerably increased efficiency. Any conversions from one data format into another will no longer be necessary. The straight-through processing (STP) of data records without interactions or media discontinuity will increase.

Don't underestimate the effort

All the advantages come at a cost – the conversion to ISO 20022 requires both personnel and financial resources. Many financial institutions are currently underestimating the effort involved. They not only have to automate any existing manual processes, but also need to make their own software fit for ISO. If their software is in the form of grown legacy systems, the preparations for the processing of XML data packets become quite demanding. In addition, time is of the essence: the go-live for converting TARGET2 to the XML standard is the 21st of November 2021. At the same time for SWIFT a four-year phase of coexistence begins.

False sense of preparedness

Already, European financial institutions are working with ISO-based standards because SEPA is based on them. However, this does not mean that they can sit idly. Depending on the type of implementation, ultimately adjustments will need to be made in all important areas of the payments IT, from master data to e-banking and back-end systems. Not to mention the impact on the future architecture of the core banking system.

Different implementations of the ISO standard

We should also remember that this is a generic standard that only lays down the basic principles for payment messages. It is adapted as appropriate for each individual implementation, i.e. it may well differ for TARGET2, SWIFT and SEPA. From limiting the permissible ISO codes and data types to removing optional elements of the basic message that are not required, a wide range of options is available. That is why for the migration a one-size-fits-all solution is not realistic.

Many individual projects

As a result, it is actually wrong to talk about the ISO 20022 conversion when in truth there are many different projects. This makes it all the more important to involve the IT department at an early stage in order to support the business side in pointing out pitfalls and problems on time and, not least, to obtain an early cost estimate. The conversion of cross-border or individual payments from TARGET2 to the XML standard is likely to cost a seven- to eight-figure sum. This sum includes the preliminary study, the implementation and the IT adjustments themselves. Additionally to be budgeted are the training of the involved employees and the timely development of the necessary know-how, alternatively the integration of external partners.

What is next?

If it does not already exist, financial institutions need a roadmap as soon as possible - with all the required measures and milestones for the conversion to the ISO standard. The basis for this is an honest assessment of one's own current situation. This is something that everyone has to consider. In the course of this process, the question may well be raised as to whether the provision of in-house cross-border payments will still be economically reasonable in the future and whether an increased cooperation with external service providers is the better solution.

Embracing change as an opportunity

The conversion to ISO 20022 undoubtedly puts financial service providers under pressure, especially when we consider the almost simultaneous consolidation of TARGET2 and TARGET2-Securities. However, the regulatory changes are also an opportunity to critically examine one's own systems and to explore how agile and flexible they can be modelled. In the end, this also helps to push forward the digital transformation on the whole - because standing still is not an option in today's digital world.

Guest authors: Sabine Aigner, Raija Wehrli

EBICS 3.0 – a set of parameters instead of the order type. What must be taken into account when identifying business transactions?

With EBICS 3.0, the different business transactions are no longer mapped via order types, but via the new BTF parameters.

In order to enable the use of customer contracts with EBICS clients of different EBICS versions in combination with EBICS 3.0, special mapping rules were developed by the national specification bodies. These rules are generally oriented toward the five BTF parameters Service Name, Service Scope, Service Option, Service Message Name and Service Container. The important thing is that the combination of these BTF parameters must be unique in the EBICS bank server. This ensures that an order type can be assigned to the business transaction via BTF and vice versa.

In practice, identical orders of a certain format can be created for an order type in different format versions and submitted to the bank server. Although format adjustments are made regularly by the specification bodies, the format version used by the client system also depends on the software version of the client solution. Since the format version should be transparent to them in the clients, users have no influence on the submission in a particular format version when compiling their order files. In addition, financial institutions generally accept different format versions of a business transaction. Finally, for bank-side processing, the respective format version can also be read out from the namespace of the XML file, at least for XML formats. So far, bank servers are flexibly designed for different format versions.

The other usable BTF parameters in EBICS 3.0 are Service Message Name Format, Service Message Name Variant, and Service Message Name Version. If a financial institution also includes these other parameters in the order type mappings and agreement details with the customer, a number of things should be taken into account. If not previously used more intensively via FileFormat parameters or necessary for processing reasons, these additional parameters should be considered in a more measured manner on the bank side for EBICS tests.

Ultimately, this additional parameter information is already part of the order file itself and can be read from it anyway. What to do with conflicting statements? The additional management in the bank server also means more time and effort in master data management. There would have to be a separate customer agreement for each format version of a business transaction. What's more, these format details are visible to the customer in the client software, and some of them cannot be controlled.

What would happen if, for example, the bank server supports versions 03 and 04 of an XML format for submissions, but the customer submits version 04 to the BTF instead of submitting a format in version 03? Taking into account the version, the order would be rejected, although the bank system could process the format version; the actual version is recognisable by the namespace.
It is even more complicated with provisions of download files. In this case, the provision would have to be generated synchronously in the requested version at the time of download and output as a file. The same applies to historical downloads.

Conclusion: financial institutions should not be too restrictive in their definitions of BTF agreements with the customer. This enables financial institutions to be more flexible and saves additional time and effort in contract and master data management.


Author: Michael Lembcke

Payments before Christmas – Christmas shopping with request to pay?

The Christmas season. Not quite as snow-white, not quite as calm and not quite as peaceful as the stories keep saying – but in its way quite charming. However, this time of year can be a little confusing, especially when the account statements show the pre-Christmas shopping adventures.

Most people will know this: The well-meaning “...but no gift-giving this year!” is even less valid than the shortly thereafter made New Year’s resolutions. And even though it feels like Christmas starts in autumn with the first gingerbread on the shelves, somehow buying the presents is always postponed until the last minute. That is exactly how this year I find myself caught in the shopping madness once more. Parents, sister, grandparents, family of the partner with five siblings – and the next generation is already at the door. Reconciling the various wish lists, shopping lists and plans with my account statements seems to be a job for Sisyphus himself.

My preferred online shops have my direct debit mandate, other digital shops accept only credit card payments, the concert tickets I paid via PayPal and the goods bought analogous and “offline” from the retailers were paid by Girocard.

Recognising all these positions on my much too long account statement reminds me that I still have to order a 3000-piece puzzle for my aunt. Has the tea set for grandma already been paid or will it still be debited? When will my telephone bill be deducted this month? That's usually around this week, isn't it? And what is that “XY shop” again, for what did they get € 90?

Like every year, I have the feeling that the shopping madness is slipping through my fingers and I lose track of things. The time lag between order and payment as well as the many different deadlines leave me with an unpleasant feeling in my stomach – especially in this time of unusual debits from my account something can quickly slip through. What use is it to me that I can reclaim a direct debit if I can no longer identify it? What credit card payment have I really authorised?

It should be easier. It should be better organised. It should be immediate. Next year around this time?
I imagine myself ordering the new radio for my mother and being asked in my banking app at the moment of ordering to release the exact amount for it. The corny Christmas sweaters with the reindeer nose are ordered in two different sizes, tried on. And at the moment of returning the much too large one, my online banking asks me whether I will release the payment for the matching sweater.

There are three packages waiting for me at the Packstation. In order to open the hatch, on request I authorise the payment. The XY shop again wants € 90? Rejected! I didn't order anything there. And my phone bill was apparently higher than usual in December and, therefore, the payment request was not automatically confirmed. I check the call statement and then authorise it manually - that's right, I called my relatives in England.

That is the request to pay. Who knows whether it will make my next Christmas calmer and more peaceful. But getting more control over my payments before they actually happen, and easing my confusion when it comes to my account, that sounds almost as nice as having a white Christmas.

Author: Anuschka Clasen

XS2A without third-party providers – well, why not?

As part of the PSD2 an interface for third-party service providers (XS2A API) was introduced across Europe. As the initiator, the EU aims to open the access to the customers' bank accounts to third parties and thus wants to promote competition in the market. By the due date on 14/09/2019 the XS2A API was put into operation by the financial institutions in Europe. Since then, market participants have been reorganising, adjusting the XS2A API to the needs of stakeholders and working intensively on services for both consumers and companies.

As a regulatory must-have, the XS2A API is initially a cost factor for financial institutions. However, value-added services have been considered right from the start and have already been specified by the Berlin Group, for example, in order to provide financial institutions with a source of income. But in the current API hype there are no limits to the fantasies about the sources of income.

So we are riding the hype wave for now and imagining the XS2A API as an alternative access channel for companies. And why not? From a technical point of view, the hurdles should be low. A company could identify itself as a third-party service provider by means of an eIDAS certificate. The certificate would only differ in the specific fields for third-party service providers. Similar to EBICS, submitted orders or enquiries can be provided with a signature which the recipient can use to check the integrity of the message. A secure transport channel is guaranteed by the use of TLS.

From a business point of view, you can use the use case "Initiate payment" to execute both individual and collective payments. For the release, consumers are offered the usual authorisation procedures known from online banking (e. g. photoTAN, pushTAN). This would probably be unsuitable for companies. Therefore, the use of corporate seals would be more likely, which has to be specified. The query of account information (balances, transactions, details) is also possible via the XS2A API. In this particular case, where a relationship of trust exists between the company and the financial institution, the consent required for this could be given via a permanently valid consent.

Seen from an average vantage point, the XS2A API would thus be a valid alternative, which is already being considered in various forums. Here, the idea is assigned attributes such as "cheaper, more convenient, real-time capable and more flexible in adjustments". However, the status quo brings us down to earth. The defining specification of the Berlin Group gives the financial institutions a lot of freedom to implement the API. In the effort to reach all financial institutions in Europe via XS2A, this freedom is currently a challenge for all market participants. A state that is not inviting for companies, not yet. However, the foundation for an alternative has been laid.


Author: Christian Wenz

Notifications for incoming SEPA instant payments – an elementary part of the payment process chain

In addition to the short duration of a final real-time credit transfer, the immediate notification of the payment recipient about received payments is a core element of the SCT Inst payment process and the associated further process steps.

What is now well feasible in online transaction processing between consumers or in the merchant-customer relationship poses challenges for the players involved in the EBICS corporate field – as described in Michael Lembcke's blog article "Real-time notifications and EBICS – no more ‘hopeful queries’ for downloads": although transaction notifications have now found their way into Appendix 3 of the DFÜ Agreement, which will be valid as of November 2019, and are specified there as camt.054 messages that can be downloaded using EBICS order type C5N, they must be actively downloaded from the bank by the payment recipient. An active push notification of the payment recipient was so far not planned. In the meantime, however, this functional gap was filled by an extension of the EBICS specification – a notification based on the WebSocket protocol that is sent from the bank server to the customer. Thus transaction information can be downloaded shortly after the corresponding payment has been received. Unsuccessful "hopeful queries" are no longer required.

As a direct notification about the payment receipt also allows for faster and more efficient overall processes in the corporate field, the time has come to take a closer look at this important function.
The starting point of our journey into the instant notification world is the globalisation of society. Almost at any time and place in the world, digital services are available: increasingly in real time – "always on, always instant". In the past, process-related waiting times due to classic payment processes (which could take several days depending on the recipient country) and slow logistical processes during the dispatch of goods were the standard. Now, the progressing digitisation enables more and more continuous process chains without media disruptions and waiting times and ensures rapid growth in the area of new digital offers.

Some of the consecutive steps of the process chain cannot be easily migrated to the instant world, as there are procedural dependencies on the non-digital domain. Other steps, however, are already available 24/7/365 in the present day – and are sometimes even finalised within a few seconds. This includes, among other things, the ordering and the subsequent payment process.

The magic word here is instant payments. Instant payments enable an immediate credit booking of the payment amount to the recipient and thus can also allow for an immediate provision of the service after payment. What works in terms of digital products is more difficult in the mail order trade sector: although it is possible to speed up the overall process through a fast payment receipt at the merchant, direct availability of the ordered goods is difficult to achieve and the customer pays in advance for a short period of time.

A purchase on account would be the least risky option from the customer's point of view. However, it carries increased risks for the merchant/supplier, as they provide services in advance and it cannot be assumed that the outstanding claim will be settled in a timely manner. Advance payment by means of classic payment methods, including cards, only leads to a reversal of the risk position, but not to an optimal risk distribution between the merchant and the buyer. At present, this circumstance can only be dealt with by an intermediary who, as an authority trusted by both the merchant and the buyer, handles the handover of the goods and the payment process at the same time. No payment – no goods; and vice versa. Classic cash on delivery process.

What is the role of the payment recipient notification in this? Without immediate notification of the beneficiary about the received payment, accelerated processes and associated innovative products based on direct payment are unthinkable. Only by means of information for the beneficiary integrated into the payment process or directly connected to it can the underlying transaction be concluded or at least the next step in the process chain be taken – whether through an online process via an API provided by the bank, or by using the EBICS channel combined with a push service.

Up to now, transaction notifications have generally been sent via intraday account information (MT942 transaction report) or in the account statement (MT940) provided with a one-day offset. It is only due to the mandatory immediate response to an instant payment receipt, which is anchored in SCT Inst, that the payment process can be fully completed. This is particularly crucial for the use of instant payments at the POS. Long waiting times until the transaction is completed would prevent customer acceptance. The benchmark for this process is the duration of a card payment.

However, immediate notification is not only relevant at the POS: existing payment methods such as settlement of invoices via instant payments in online banking or the classic cash on delivery at the front door benefit from this. In the first case, the advantage lies in an accelerated overall process for all parties involved, and in the latter it is mainly the substitution of classic payment instruments such as cash or cards.

Notifications will also play a key role in the development of future payment procedures such as Request to Pay. In this context, I would like to refer you to another EBICS blog article dealing with this topic by my colleague Eric Waller: "Request to Pay is changing payments – first use cases".

Author: René Keller

Formatting errors in EBICS orders – test services can help

EBICS has been specifically designed for secure, high-performance data transfers with files of any size between banks and corporate customers. For payment orders, the content of a file that is uploaded to the EBICS server must match the defined business transaction (order type, FileFormat parameter or BTF) and the respective format specifications. When payments are submitted, collection files with single transactions grouped by ordering party accounts are common practice. The protocol creation (HAC and PTK) for server-side EBICS processes is partly format-specific for payment orders. The authorisation checks and the protocol creation therefore require that the EBICS bank server knows and can read the submitted format at least in the relevant places (for example, ordering party account and amount). In order to read the information, the EBICS bank server performs a format check. The EBICS bank server usually aborts the check as soon as the first formatting error is detected. The order is rejected due to the formatting error and documented in the customer protocol.
Why is the file not fully checked and why are the error details not written into the customer protocol?
There are several reasons for this. First of all, the usual service agreement for e-banking via EBICS includes the upload and fast processing of correct files. Extensive format verification with an error protocol is not included and also not the core task of an EBICS bank server. Furthermore, the bank server capacities are to be used for the immediate processing of format-compliant orders and not for the analysis of incorrect files.

But how can a bank offer its corporate customers a service that increases the quality of payment orders in terms of format and content without adding unnecessary load onto the EBICS bank server?
Customers could use test services such as the ISO 20022 test platform for this purpose. As part of the harmonisation of Swiss payments, Swiss banks already offer their customers a test platform for testing incoming and outgoing payment transaction formats.

The test platform mimics the specific production conditions of the bank. It can validate XML-based customer-bank messages and simulate the bank-to-customer interface.

An extension of the ISO 20022 test platform towards payment order checks for specific formatting conventions and content can improve the quality of the file even further. A comprehensive format verification of payment orders carried out in advance enables errors to be identified quickly and easily using a detailed error log.

Files that are invalid with regard to format and content can be detected and corrected in a preliminary check by a test service before they are uploaded to the EBICS server.


Authors: Aline Wendler and Michael Lembcke

Request to Pay is changing payments – first use cases

The payment request or, in business terms, Request to Pay (R2P), is a new payment instrument that is set to change payments for the long term. In the whitepaper “Request to Pay completes the electronic payment process”, I have already explained the relation between electronic billing, instant payments and the hitherto missing payment instrument Request to Pay.

I will use this blog entry to present the first few of many use cases which can be easily addressed to an existing bank account via Request to Pay:

  • Request to Pay in case of an already sent commercial invoice: an easy use case is that the invoice has already been sent in a classic way and a Request to Pay is additionally sent afterwards. This use case primarily focuses on speeding up the settlement of the due invoice by facilitating the invoice data processing for the debtor. The Request to Pay related to the invoice that the debtor has already received is displayed to him in his online or mobile banking application with the recipient data, the payment amount and the remittance information already filled out. The debtor only needs to confirm the data and sign the execution with his credentials.

  • Request to Pay combined with a commercial invoice: of course, the previously described use case is also conceivable if both an electronic invoice and the associated Request to Pay are to be presented to the debtor at the same time in his online or mobile banking application. The conventional postal dispatch is thus eliminated and the debtor can view his invoice digitally and pay it in a simple manner. This method also offers the option to digitally store the invoice in a banking archive and to digitally match it with a payment at any time.

  • Request to Pay in step-by-step transactions: needless to say, Request for Pay is useful for more than just scenarios with separate locations. It is thus also conceivable to digitise the previous cash on delivery method. The supplier addresses a Request to Pay message to the recipient who then verifies the product delivery and initiates an instant payments order as response to the request. The supplier is informed via a notification that the payment has been received and releases the product.

  • Request to Pay in stationary trade: similar to the previously described case, Request to Pay could also be used with instant payments and notifications in stationary trade. In this case, it is not the invoice but the purchase receipt that is transported with the Request to Pay message and can be stored in a digital archive at the account together with the booking. The cashier personnel release the purchase only once the notification has come in.

As demonstrated, payment requests are applicable in many sectors and I therefore believe that the new payment instrument Request to Pay is bound to change payments as we know them on a lasting basis. I will continue to post frequent updates on current developments and additional use cases on this blog.

Author: Eric Waller