Don't fear standard software in the payments industry

Those who want to distinguish themselves from the competition develop their own software. This rule is becoming increasingly widespread among companies – and more and more "experts" advise financial institutions to increase in-house development of their own applications, or even to become tech companies. This philosophy starts to falter no later than when it comes to the payments platform.

For example, the supervisory authorities stipulate uninterrupted operation if the financial institution wants to process instant payments. We have experienced the resulting architectural challenges first-hand in our TRAVIC-Payment Hub. Add to this the numerous surrounding systems such as anti-money laundering or embargo and sanction lists, not to mention routing. Doing all of that in-house results in such high costs that many financial institutions would rather prefer not to do any payment processing at all and instead to have it done by a central institution within a large association. However, that is not an option if payments are to become a strategically important line of business.

Roundabout for payments

We have thus asked ourselves: what exactly is the "special ingredient" that financial institutions need to add to their payments systems in order to distinguish themselves from other competitors and be able to offer payment processing as their own product? This question is especially relevant if an institution applies as a service provider for corporate customers to process their payments in a specific region of the world. And lo and behold: in their core, many processes are quite similar from one financial institution to another. They mostly only differ with regard to the order the financial institutions perform them in. Following this insight, we have designed a payments platform that works like a roundabout. For each special function, there is an opportunity to "hop on" the platform in a different place, just like children on a fairground may hop on the roundabout anywhere they like (see Fig. 1).

TRAVIC-Payment Hub enables a financial institution to define any conceivable configuration. This applies both to the routing administration (which allows for almost any complexity of rule sets) and to the connected surrounding systems. But how does TRAVIC-Payment Hub know what is supposed to happen if, for example, the compliance system returns a certain status? Usually it is the surrounding systems that have to follow what the main system commands – so why should a financial institution, after possibly getting rid of one monolith in core processing, now acquire another in payments processing? The answer to this is an integrated workflow engine that has its own script language to connect the other systems comparatively easily – while also being independent of the manufacturer, i.e. of us.

The "Hub" in TRAVIC-Payment Hub is thus both a product name and a performance promise.

Software development inside out

In terms of technicality, we turn what would otherwise develop into "legacy" outwards. The implemented script language enables a financial institution to add its own business processes to TRAVIC-Payment Hub without having to open up the source code of the software. As technology and business aspects are separated, a significant part of software development thus moves from the sphere of the manufacturer into the sphere of the user. This means that the payments platform stays fit for release even though TRAVIC-Payment Hub may have to coordinate a complex network of surrounding systems. Additionally, the IT departments are not even tempted to develop too closely to the core payments processing and to run the risk of trying to modify something in one place and, in doing so, provoking a problem in another.

In practice, the procedure is as follows: TRAVIC-Payment Hub receives various statuses by the surrounding systems. The script language is used by in-house IT employees or the integration partner to define how payments with the respective statuses shall be handled. As soon as the workflow is fully defined, the system compiles the code so that TRAVIC-Payment Hub can start working. To this end, the workflow engine generates tasks which are then processed by an internal task engine. Here is a very simple example of how the script language developed by PPI for TRAVIC-Payment Hub handles OUR charges, i.e. determines whether the charges due may be enclosed with a payment and retained or whether a payment request must be created.  

    if payment is inbound and (payment is ourCharges) then {
        if payment is ourChargesReceived then {
            just set status VALIDATERECEIVCHGS and leave step
        if payment is correspondentChargeExpected then {
            if payment is debitAuthorized then {
                just set status CREATEADVICEOFCHGS and leave step
            just set status CREATECHARGEREQ and leave step
    just set status DONE and leave step

Introducing TRAVIC-Payment Hub

With the TRAVIC product suite, PPI covers the entire payments process of a financial institution, from incoming payments over interbank communication up to clearing. TRAVIC-Payment Hub handles the core processing of payments. Our solution works as customer bank and as clearing bank – even in parallel operation – and can process instant payments. Moreover, the solution can be operated on site and as outsourced high-availability software in cooperation with our infrastructure partners.

Author: Thomas Riedel

Further information:

SEPA 2.0: the ISO 20022 update could lead to a triple migration

SEPA and the ISO 20022 standard it's based on can well be considered a pioneer amongst the global ISO 20022 initiatives. Very early on, they presented themselves as the rulebook for many different payment formats in the Euro zone, using a common format standard to enable cross-border and cross-system interoperability. Despite some local dialects, SEPA has enabled continuous end-to-end processing without media discontinuities and conversions over the past years - not least by harmonising national characteristics with a uniform EPC specification. End-to-end, in this case, refers not only to the interbank relationship but also to the relationship between ordering party and recipient. This is made possible by the consistent use of the uniform data dictionary in the ISO 20022 format standard, which provides a uniform basis for data exchange by transporting data elements from customer-bank messages (pain) to interbank messages (pacs) and all the way to bank-customer messages (camt) without conversions.

Where SEPA is evolving (for example, due to the introduction of instant payments), the ISO 20022 standard used for SEPA still needs to catch up: namely regarding the 2009 basis defined by the EPC. As this ISO standard is also constantly evolving to reflect current developments, the EPC working group responsible for further development of the SEPA scheme plans to migrate all schemes (SCT, SCT Inst, SDD Core, SDD B2B) to version 2019 of the ISO 20022 standard. The transition is to be announced in 2020 and will come into final effect in November 2022 within the scope of a big bang migration (of the interbank formats). This change, amongst others, is currently subject to public consultation as a major change request. During this phase, remarks are requested from the circle of parties participating in the consultation.

One of the reasons for deeming this CR important is the future support of Request to Pay, which cannot be provided with the current ISO version as future required elements are not available in its format. However, an up-to-date version of the ISO standard is also required for other future developments, especially in light of the TARGET2 and SWIFT MX migrations, which are also based on the 2019 version of the ISO standard.

The good news is: the ISO 20022 standard is already well established in the world of SEPA. Unlike with the SEPA introduction, there is no need to introduce a new format and no need to replace old formats on a large scale. Existing systems must "only" be adjusted and learn to process changes such as new data elements. Nevertheless, the challenge is to master a big bang migration with effects on interbank payments and formats at the customer-bank interface.

The bad news: due to current developments, the SEPA migration date now coincides with the beginning of the SWIFT transition phase from MT to MX. The original approach of setting the date for the SEPA migration to 2022 had been chosen in order to avoid having to carry out the three major migrations – TARGET2, SWIFT MX and SEPA ISO 20022 version 2019 – almost simultaneously and to distribute the necessary efforts onto different time frames. Should TARGET2 now also postpone the planned big bang migration by one year, as first demands from the market suggest, all migrations will once again coincide in time. This will pose immense challenges for the financial service providers involved and wreck the original approach of distribution. The blame for this is easily placed on the global coronavirus pandemic, which is currently putting a severe strain on our lives and the economy.

In this situation, financial institutions must keep an eye on further developments and adapt to the forthcoming changes. We will also closely monitor ongoing events and will continue to report on the SEPA ISO changes after the market consultation is completed.

Author: René Keller

PSD2: securing bulk payments via EBICS

The security of bulk payments has always been an issue. The early attempts to establish a simple protection against manipulation for this were rather half-hearted and therefore never led to reliable security. For example, the total of all recipient account numbers was formed to prevent criminals from subsequently changing the payments. But when the IBAN came along, even this extremely simple method was no longer useful – the financial institutions eventually abandoned it altogether simply because of the mathematical challenges involved.

All that remains to this day is the number of included payments and the total amount. Nobody claims that such values offer an effective protection.

More promising was the use of the PSD2 and RTS to provide more security for payments. However, they did not lead to a breakthrough for the bulk payments which are particularly common among corporate customers. The reason: displaying the recipient, account and amount and having the client check all the data contained, for example via dynamic linking, is hardly feasible for salary payments in a company with more than 10,000 employees. This is impossible from an organisational point of view alone and can hardly be realised using the established channels on the technical side.

So how do you make sure that the payment file, once created, is executed unchanged by the financial institution?


EBICS has been the standard in European corporate customer payments for years – available in all major countries with high transaction volumes, such as Germany, France, Austria and Switzerland. More countries will follow.

So why does the EBICS company not define a general and mandatory auditing standard based on international hash value procedures (e.g. SHA-256) and establish the corresponding set of rules? The principle: all applications which generate payment bulk files always generate the matching hash value and pass it to the financial institution together with the payment file. There, this check value can be recalculated as soon as the payment file arrives and presented to the customer for checking before release. That's it.

Simple and very effective, because the identical hash value guarantees that no manipulation has taken place between the creation of the bulk file and the processing of the bulk by the financial institution.

If, for the definition of the hash value procedure by the EBICS company, we then also consider the end customer, instead of the 32-double-value comparison an algorithm could be found which turns the hash value into a number consisting of 8-10 digits – similar to a TAN. Customers and users are already using these types of values today. A comparison of the check values only requires a minimal amount of time and is easy to do.

By the way, simply leaving the establishment of this definition to the market is not a good idea. If all of the players involved do their own thing, a multitude of different procedures are created, which confuse customers rather than provide additional security.

Therefore, it is one of the tasks of the EBICS company to provide a binding solution at this point and to, that way, also meet the demands of the PSD2 for bulk payments.

Author: Michael Schunk

eBAM – building block for digitisation

A crisis can also be a catalyst for progress. The current corona crisis is probably different from many others before because it forces us into the digital realm – from home schooling to the home office, the pressure is on to re-evaluate many activities regarding many aspects. Gaps are becoming apparent that were not perceived as such in an analogue world without contact limitations and other restrictions. Application processes, authorisations and releases are part of this.

And when we talk about cash management solutions here on the blog, I think the topic of bank account management is also part of it. This does not only include the exchange of messages at the customer-bank interface, but also the management of bank and account master data and their signature authorisations (not only the digital ones) as well as all related documents, the processes in the entire account life cycle and the tiresome balance confirmation. This is where all the requirements in the KYC area as well as authorisations and digital identities come into play.

These topics could have long since been moved to the digital world as part of eBAM – the electronic bank account management. Standardisation is needed here and it starts with the correct spelling. EBAM or eBAM or e-BAM?

The time has come – many building blocks are available. Some manufacturers in the area of cash management or treasury offer modules especially for the administration of data on the corporate customer side. Success stories can already be reported for the first purely digital account opening processes. There have also been encouraging developments regarding KYC and digital identities. Even the messages at the customer-bank interface in XML according to the ISO 20022 standard are in principle available. The further development of the standard is also being discussed by a working group of the CGI-MP (common global implementation – market practice) – a global initiative of corporate customers, financial institutions and manufacturers for the harmonisation of the use of ISO 20022 at the customer-bank interface. The standards are the basis for digitalisation. They create security for manufacturers and users.

In Germany, with the appendix 3 of the DFÜ agreement there has been a long-standing multi-banking tradition – i.e. one standard that reaches many financial institutions. For this, by now, optional topics can also be integrated such as the bank service billing (BSB). Not everyone needs to support the topic – but if they do, they need to comply with the standard. And I would like to plead for such an option on the subject of eBAM. For EBICS it is easy to transport the XML messages in the message group camt (account management) – the (harmonised) standards must be agreed upon. The simple use case of a signature authorisations overview shows a first step in this direction with EBICS using the order type HKD, but – see above – this is still only the start.

Of course, the customer-bank communication part of eBAM does not have to be realised via EBICS, SWIFT as a transport route is also possible. Even APIs open up many possibilities. Independent of the channel the basis should be a standardisation of the content (XML in harmony with json) and the basic processes. And for content in the XML format according to ISO 20022, a further chapter should be added to the appendix 3 of the DFÜ agreement.

On this basis, the above-mentioned manufacturers can then expand their products for "multi-banking" and financial institutions can offer new services to many customers with similar systems – enabling them to fit very well into the digital world with these services.

Author: Dr. Mario Reichel

Machines paying machines: how machine economy is changing payments

The machine economy (Internet of Things) is growing rapidly. More and more machines and devices are connected to each other. In 2025, a worldwide network of 75 billion devices can be expected. According to figures of the American IoT provider BizIntellia, IoT-related solutions are expected to contribute a total of about 14.2 trillion dollars to the global GDP by 2030.

IoT will thus play an increasingly big part in our life and society. This raises the question how IoT will affect payments and which potentials can be uncovered in implementations of machine-to-machine payments (M2M payments).

How are IoT and payments connected? Machines are enabled to transfer not only identities and information, but also values. They send payments to other machines autonomously, without the need for authorisation by a human. However, if these business transactions cannot run without interruptions (say, for example, the machines have to wait for a manual action such as a payment confirmation), freeze periods or even abnormal terminations can be the result – both scenarios would have to be avoided in order to fully exploit the potentials of M2M payments.

But M2M payments are not merely visionary dreams of the future. Concrete solutions are already being developed, for example, in the automotive industry. Some companies are already establishing the required ecosystems. The idea is for automobiles to have their own wallets with electronic money and thus be able to pay for fuel or toll charges without human interaction.

To analyse these effects, challenges and opportunities, we have conducted a study on the subject "Machines paying machines" that deals with the following questions in particular:
  1. Which prerequisites must be met in order to enable implementation of M2M payments?
  2. What are the challenges of implementing M2M payments?
  3. How strongly will payment transaction numbers increase due to M2M payments?
  4. Which payment methods are best suited for M2M payments?
  5. Which impact do M2M payments have on payment service providers?
  6. How should payment service providers respond to M2M payments?
For M2M payments to become reality, the participating machines must first receive their own machine identity with individual attributes distinguishing them from other machines. A secure machine identity cannot be manipulated, forged or misused. The machine is given a unique, secure identity it can use to authenticate itself within the productive network towards other machines, instances and participants.

The current legal framework is not prepared for autonomous machines either and must thus undergo further development. Both clear assignment rules for actions of autonomous systems and specific allocations of the risks involved in using autonomous systems are required. Last but not least, new liability systems are needed that take into account the particularities of autonomous machines.

In terms of practical implementation, we have identified the following fields of action, the solution to which will be especially challenging:
  1. Mapping the identification of machine payments
  2. Compliance checks in relation to a machine (KYO instead of KYC)
  3. Processing returned information (including disruptions of the processes)
  4. Taking into account a more complex and comprehensive reporting
  5. Increased security of machines and interfaces
  6. Consistent implementation of digital onboarding and digital processes
Many analyses suggest that the number of transactions will rise dramatically with M2M payments. We agree with this assessment and also expect a significant increase. Taking into account compensation effects, we estimate that by 2027, there will be about 12 billion additional machine-to-machine payment transactions in Germany and about 50 billion in the EU.

Not all currently common electronic payment methods are suited equally well for M2M payments. We believe that digital money (stablecoins, "unbacked" coins and e-currencies) and e-money are the most suitable for M2M payments.

Established payment methods generally have more or less high transaction fees. Crypto money and e-money solutions, in contrast, enable inexpensive transactions even for the smallest amounts and make them appealing for use in the IoT. After all, they offer the opportunity to economically settle even small payments for services, as far as below one cent; such as, for example, the use of a light bulb in a smart home. E-money solutions and crypto money can also be integrated independently of traditional financial service providers.
This leaves the question how the payment service providers should position themselves in the future. The Internet of Things will further reinforce the trend towards differentiation of specialist providers with a data-based business model and infrastructure providers.

Specialist providers can use the data volume increase due to the IoT to their advantage in market competition and develop additional business potentials or completely new business models. For example, precisely customised additional services can be offered to customers on the basis of detailed usage data. This depends on whether the payment service providers can manage to place themselves "on top" of the machines or at least to act as data aggregators that compile the relevant usage data into figures and transfer it.

Regarding the positioning as data aggregator or data hub, payment service providers could also ensure the necessary trust between the participating persons, companies and machines, and act as a sort of clearing instance for secure digital identities and valid data.

In summary this means that the traditional payment service providers must overcome considerable challenges. The functional and above all the technical requirements for the infrastructure of payment service providers will entail massive changes. They must meet the following prerequisites:
Completely uninterrupted availability, increasing the importance of 24/7/365 operating models and real-time transaction processing
  • Downtimes for the installation of new releases are no longer possible.
  • Ability to handle very high loads due to billions of additional transactions
  • Possibility of distinguishing between automatic and non-automatic payments, as they will be processed by different rules
  • Possibility of complete digitisation and machine onboarding
  • Future compliance with KYO for machines, which is currently not yet regulated, in combination with KYC, mapping in the corresponding systems and, in particular, organisational regulation
  • Possibility not only to trigger payments, but also to process feedback information from system and process disruptions accordingly. Based on the feedback, the machines must be able to draw the right "conclusions" in real time and select alternatives if necessary.
In addition, payment service providers must decide how they want to position themselves and adjust sales structures, as ecosystems in IoT will become increasingly important.

Author: Michael Titsch

EBICS security – when is the time to update your customer system?

With EBICS communication, various security features and regulations are specified that must be adhered to by customers and financial institutions alike. The financial institutions must always ensure that the current specifications are available and supported in their EBICS bank server. EBICS customers themselves and each individual EBICS users are, however, also responsible for ensuring the use of customer software that is continuously up to date and that meets the current EBICS security standards. It is therefore paramount both due to functional adjustments and for security reasons to frequently update the software of the EBICS client systems.

Once an existing EBICS client software has been brought up to date via updates, however, it does not mean that the EBICS software in question automatically starts to communicate with the financial institution using the most recent EBICS version and the latest security procedure. Depending on the previously used EBICS version and client functionality, this requires an update of the various application keys for encryption (E002), authentication (X002) and authorisation (A004, A005 or A006) and of the new EBICS version to be used, followed by an exchange of this data with the EBICS bank servers. It may also be necessary to update the Internet encryption (TLS) to a more recent and secure version by means of a renewed certificate exchange. Such updates usually require a proactive approach and manual adjustments by the EBICS user.

Why are these updates important?

EBICS communication via the Internet has its own specifications for security procedures. The EBICS society continuously updates and adapts them to current security requirements by means of new EBICS versions. One example are key lengths. Older EBICS versions still permit key lengths of 1024 bits for encryption (E002), authentication (X002) and authorisation (A004, A005 or A006). That length no longer meets the current security requirements as too short key lengths are considered unsafe. Newer EBICS versions only permit keys with a minimum length of 2048 bits. Another example is evident in the procedures and versions of the TLS encryption that are in use. To be able to follow security recommendations such as the ones by the BSI in Germany more flexibly, the EBICS society has created a separate annex of the EBICS 3.0 specification called Transport Layer Security, which contains the respective guidelines. As the EBICS 2.5 specification could not be adapted retroactively, the DK (Deutsche Kreditwirtschaft) has additionally issued its own recommendation document in 2019 titled Empfehlungen zu EBICS-Sicherheitsverfahren und Schlüssellängen (recommendations on EBICS security procedures and key-lengths). It contains information on the security procedures to be used in EBICS communication. See also and

To allow EBICS users a smooth transition to newer EBICS versions and security standards, most financial institutions still offer their customers the older procedures in parallel with the new ones. Unfortunately, it has become clear that in many cases this leads to customers not taking the opportunity to update their EBICS communication. Many keep using older systems and procedures. This, in turn, makes it hard for the financial institutions to discontinue those old procedures.

In the end, every participant in EBICS communication expects a secure data exchange to be ensured. Nobody wants to sustain losses. Which means that everyone should take care to contribute their part. Of course, EBICS security is not the only thing financial institutions need to keep an eye on. Ultimately, all parties involved must take all possible security measures in their infrastructure and software solutions to prevent misuse and losses.

So why wait any longer? Let's do this.

Author: Michael Lembcke

Open banking: EBICS versus API

Open banking is one of the mega trends that many banks supposedly risk missing out on. As hardly any PSD2 interface seems to be market-ready, the banking supervisory authorities have granted a transition period until December 2020. However, the problem is elsewhere: many institutions are not too keen on spending their money to make the lives of open banking interface providers easier – especially considering that established protocols like FinTS and EBICS have much more to offer than has been brought to the table by the "APIsation" of banking so far.

Both protocols, FinTS and EBICS, already cover almost all areas of banking, from payment transactions and securities trading to credit business. Overall, far more than 200 processes are available which bindingly describe both the business interfaces and the technical communication between the participating partners. HBCI and FinTS have been leading the way regarding open standards in communication with financial institutions since the 90s. EBICS was introduced by the Deutsche Kreditwirtschaft (DK), or its predecessor, more than ten years ago as a binding standard for communication with corporate customers. Open banking has thus been a reality in Germany for many years already.

No uniform PSD2 interface in sight

As good as the idea of open banking may be; the debate forced by PSD2 (among other things) leaves many financial institutions at a loss, including the willing ones. On the one hand, PSD2 is supposed to bring about an open banking standard for all of Europe. Then again, legal authorities have deliberately left open the question of how exactly communication should take place and how it should be secured. As a result, providers of open banking APIs are urging the banks to implement their solutions and adopt their own interpretations of open banking, just so they won’t be left behind. On top of that, various initiatives in various countries are developing protocols for technical/business application aspects, which is bound to lead to an uncontrolled number of API dialects. Cross-country concepts, on the other hand, are still a long way off.

All of this could develop into a bottomless pit for the institutions unless a uniform PSD2 specification that every bank can follow becomes available soon. As long as this does not happen, many open banking dreams will likely remain unfulfilled. After all, by law, the opening must be free of charge and free of discrimination. Earning money with it is for others. So what should be a bank’s motivation to keep adding new API dialects free of charge, just so that third-party providers can more easily spread their apps among the people? This would reduce the institutions themselves to the status of mere service providers. It is much more reasonable to fall back on long established standards.

EBICS: open banking for corporate customers

One such standard is EBICS. It is widely spread: aside from Germany, EBICS is also popular in France. A cooperation agreement exists between the Deutsche Kreditwirtschaft and its French counterpart, the CFONB. These two largest payments markets in the Euro zone use EBICS for the corporate customer and interbank business. Switzerland (SIX) is also a fan of EBICS, and Austria (STUZZA) is thinking about joining in. Instead of drowning in the API swamp, the question should be how EBICS can be expanded to comply with PSD2. And the answer is: with a remote signature (see Fig. 1). A modern EBICS portal can generate the signature from incoming data such as the code of a PhotoTAN or a QR TAN using hardware-based methods and send it to the EBICS bank server.
Fig. 1: How remote signatures expand EBICS towards a PSD2 compliant open banking solution
EBICS offers many advantages for corporate customers. Companies that have an EBICS client can conduct secure multibanking and also use the electronic distributed signature (EDS). This enables the use of roles and rights concepts (T, A, B and E signatures) to determine, for example, whether submitted payment orders originate from authorised persons and whether the respective person has the appropriate rights to release these payment orders. Similar to FinTS, the following also applies for EBICS: the necessary infrastructure to implement open banking already exists. For this reason alone it is understandable that many institutions are reluctant to invest at the moment. There is no guarantee that they will choose the right API provider or that legislators will not issue new regulations that will render existing investments obsolete.

Author: Michael Schunk

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, 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