T2/T2S big bang: banks risk exclusion from payment transactions

Payment transactions are invisible and reliable for the general public. But it does not have to stay that way: the biggest current topic that is unknown to the general public is the TARGET2/TARGET2 Securities consolidation, and with it the ISO 20022 migration and a new account model. Banks that cannot deal with this in time are in danger of being cut off from payment transactions – and customers will feel the consequences.

The migration affects all participants in the current TARGET2 system and takes place within the infrastructure of the financial institutions, central banks and the European Central Bank (ECB). Since the migration will happen as a big bang, i.e. simultaneously for all financial institutions in Europe on 21 November 2021, delays at individual institutions may also have a negative economic impact. At worst, complications in the often outdated IT systems or delays in project implementation can lead to exclusion from individual payments if the switch cannot be performed by the cut-off date.

The consequences of a failed T2/T2S consolidation for banks:
  • Exclusion from individual payments with central bank money
  • Exclusion from conducting monetary policy operations, which means in particular:
  • Open market operations cannot be used.
  • Standing facilities cannot be used.
  • The minimum reserve requirements cannot be met.

If an ancillary system connected to TARGET2, such as the SEPA-Clearer, is used for mass payments, the bank would also be excluded from the relevant clearing channels and would no longer be able to process payments.

The consequences are therefore dramatic and practically threaten the viability of the bank itself. The only remaining alternative is establishing a direct connection via another institution. However, it would also have to be decided and planned at an early stage and cannot be done just before November 2021. If this also fails, the bank's future is at risk. Relying or speculating on a possible postponement of the migration would be negligent.

However, the major challenge of the TARGET2 consolidation is not only the redesign of the account structure, but also the technical standardisation of the access for the existing TIPS and T2S systems to TARGET2, as well as the upcoming migration of the message formats.

Future access to TARGET2

The connection to TARGET2 will change. So far, SWIFT's FIN Copy service (called Y Copy mode) is used. In the future, there will be a separate dedicated communication architecture provided by the ECB that will run with the Eurosystem Single Market Infrastructure Gateway (ESMIG) as the central access point to all TARGET2 services. For this access, a Network Service Provider (NSP) that communicates with ESMIG will be required as a new participant.

Message formats

The future speaks ISO 20022, and so does TARGET2. So far, TARGET2 still uses MT messages for communication. The MT messages will be replaced by ISO 20022 messages in XML format (MX), which will be significantly more comprehensive and able to compile more information. The MX messages are not introduced in a like-for-like approach, where it would still be relatively easy to transform MT messages into MX messages; instead, the potential of the new formats will be exploited from the beginning.

This, as well as the complete rearrangement of the infrastructure, means that parallel use or an interim solution with both formats will not be possible.

Taken on too much?

New message formats, new connection channels, new players and new processes – all of it across Europe by one cut-off date. Can that work?

Due to the topicality of the subject, detailed reporting via the central banks is carried out on a strict time schedule. Project milestones are set centrally by the ECB and the achievement of objectives is regularly monitored. Each bank is responsible for its own implementation. Currently, seven participating markets (including Germany) have reported the status yellow, while 18 have reported green. At first glance, this looks as if everything is still going well - but banks that underestimate the consequences and the effort required to be compliant in time are likely to slide from yellow to red faster than they would like.

To keep things interesting, in addition to the TARGET2 consolidation, SWIFT will also switch from MT formats to MX formats. The latter will, however, allow for a four year transition phase during which financial institutions will still be able to use both formats. Given the topical proximity, it makes sense to address this issue together with TARGET2.

The list of tasks is rather long and will tie up the institutions' capacities for the next few years. Executive board members must come to understand this as well. We are not just dealing with a "compulsory exercise" here, but with the sustainability of each individual institution.

Authors: Swaantje Anneke Völkel, Thomas Ambühler

EBICS for clearing and settlement of SEPA instant payments – the new Delta document as a milestone

Since the introduction of SEPA in January 2008, the EBICS transfer protocol has also been used in interbank payments for the bilateral clearing and settlement and for the exchange of SEPA payments with the Deutsche Bundesbank. Over the years the number of European institutions which use EBICS has further expanded. Therefore, it comes as no surprise that as of November 2013 the EBA CLEARING also offers EBICS as an alternative access for so-called "garage clearing" and STEP2.

The introduction of SEPA instant payments was the next step after the conversion to SEPA for a standardisation in the European payments sector. However, due to the real-time approach, this new payment method brings a special challenge for the use with EBICS. Whereas in conventional EBICS use file-based data transfer has so far been the main focus, for interbank payments the SEPA instant payments procedure requires a message-based approach related to transactions. Thus, in November of 2017 the EBA CLEARING successfully introduced RT1 based on SEPA instant payments.

For the support of EBICS in connection with the transfer and clearing of SEPA instant payments, in October of 2019 the EBICS company officially published a Delta document for the EBICS specification (see Use of EBICS for the Clearing & Settlement of Instant Payment Transactions, www.ebics.org). It describes the modifications to be considered for the processing of instant payments using EBICS 3.0. To meet the new requirements resulting from the real-time behaviour, the new schema ebics_inst_request_H005.xsd has been added. However, for the administrative business transactions of the instant payments the file-based EBICS behaviour and, therefore, the standard schema are still required. For the use of SEPA instant payments in combination with EBICS the new schema must be added to the overall schema.

Nothing changes when using EBICS in a customer-bank relationship or for interbank payments that do not include instant payments.

The Delta document Use of EBICS for the Clearing & Settlement of Instant Payment Transactions is a welcome development. In practice, EBICS is widely in use and many other scenarios are conceivable. In order to ensure the comprehensive and uniform use of EBICS, standards and their compliance are essential. Still, it must be possible to react with flexibility to new market challenges. This document meets both objectives equally well. Another milestone has been set on the way to standardising the European payments sector.

Author: Michael Lembcke

Request to Pay (R2P) is changing payments – technical challenges

Our last blog entry on Request to Pay showed us how peaceful the Christmas season could be and how R2P could make all the associated shopping perfectly organised. Now it is still a while until next Christmas, which leaves us time to deal with the challenges of establishing R2P based payment systems.

The first aspect that warrants mentioning is the technical component. In December 2019, EBA CLEARING published format specifications that describe both the payment request (pain.013) and the response to the payment request (pain.014). Thus, the clearing part is technically defined and the "only" challenge left is to prepare the incoming and outgoing interfaces of the payment system for these processes and formats. This may sound trivial at first, but is in fact quite challenging for a payment system: both the outgoing payment request and the returning response to the request must be routed from a customer system through the payment system, the relevant clearing systems and the receiving and/or responding customer system within the shortest possible time.

This, of course, also raises the question of how customers should transport the payment request to their bank to begin with. The technical aspect is currently being discussed by the European Payments Council and the Deutsche Kreditwirtschaft (DK). A corresponding technical specification for the customer-bank interface will be created.

This is where the business component comes into play. It should involve a conceptual revision of existing systems with regard to which system shall accept incoming payment requests and which system shall respond to them. This leads to immediate follow-up questions; for example, if customers can choose whether they want to pay via SEPA or SCT Inst (provided they are given the choice at all by the design of the payment request). No less important is the question of how they shall authorise the payment request. Suitable authorisation methods are, for example, a mobile device with an established TAN system or a submission to the EBICS signature folder for signing via electronic distributed signature.

Meanwhile, information on a payment receipt from an instantly settled payment request can be provided rather easily thanks to the specified "Credit Notification for SEPA instant credit transfers".
With the right combination of technical possibilities, R2P will certainly give Instant Payments an immense boost. Admittedly, mastering the challenges along the way will require a considerable amount of effort, but in view of the numerous design possibilities, it will pay off if the implementation is handled correctly. Find out more about the application scenarios and use cases that result from the technical possibilities in the white paper "Request to Pay and its versatile applications" we created for you . Please also feel free to contact us any time for both content-related and technical discussions.

Author: Eric Waller

Multibanking – all in one portal

Standards as the basis for networked process automation

Data is the oil of the 21st century. For years this has been preached at all digital conferences. The more data a provider has from a customer, the better the customer can be clustered and classified into target group segments. This knowledge of the customer's needs allows the creation of interesting additional offers for them.

When, as part of the digitisation, the access channels are increasingly realised via the Internet, the decisive point of contact between financial institution and corporate customer will be "digital branches" such as the web-based corporate customer portal TRAVIC-Port. If the operator succeeds in aggregating all the customer's bank accounts, including those of other banks, at the digital point of sale and bundling them in an own portal, the operator has the best prerequisites for a holistic overview of the customer's payment transactions. The more accounts that are bundled here, the better service offers the operator can create for his customers.

The keyword "multi-banking" refers to this functionality of bundling the optimal payment transactions of a customer. Both sides - customer and financial institution - benefit from this combination under one roof. The customers are given a comprehensive overview of their transactions. The aggregation considers both submissions of all types of payments and downloads of the account information of all connected accounts. The multi-banking portal offers the users a unified, easy-to-use GUI for various payment providers using one secure access - and that way provides efficient internal processes. However, the benefit of this smooth automation of multiple payment transactions stands and falls with the speed of processing and the clean implementation of the bank servers from various providers. A high degree of networked transactions in both directions requires uniform interfaces and the compliance with the valid specifications. The EBICS-based communication of TRAVIC-Port provides the most secure, Internet-based, technical protocol for the SEPA area. All too generous adjustments and deviations from the specification prevent smooth processes on the part of the providers and stand in the way of a comprehensive, seamless consolidation of payments. Here, both the clients of the portal providers and the suppliers or software houses should pull together. In contrast, APIs with proprietary interfaces enable individual adaptation to the financial institution's technical environment. However, any deviation from the standards delays the smooth integration of the complex data traffic. An imprecise interpretation of the specification reduces the degree of automation and the data volume of each connection. The more gaps there are in the complex network of multi-banking connections, the lower the customer benefit and the quality of the analyses.

Guest author: Christian Veith

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