Digitalisation in action – key exchange via INI letter procedure

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

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

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

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

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

Author: Michael Schunk

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

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

Overstrain as a background 

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

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

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


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

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

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

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

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

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


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

CESOP – payments data in data retention  

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

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


Which payments have to be reported by whom? 

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


European payment service providers

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

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


Supplying, but how? 

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

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

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

Conclusion 

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

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

Author: Benjamin Schreck

Project possible in cross-border payments

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

Showdown in November 2022

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

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

Too late to turn back

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

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

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

Author: Florian Stade

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

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

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

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

1. Direct CBDC

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

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

In addition to the effort and time factors, the current ecosystem would be undermined, as neither commercial banks nor financial service providers would act as distributors at the customer-bank interface.

The indirect CBDC scenario is therefore far more likely:

2. Indirect CBDC

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

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

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

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

An important step towards unity

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

 

  1. Mr Bargehr, in July 2020, the Austrian banking industry declared its accession to the EBICS Company, and since then the introduction at the banks has been underway. How far along is your bank, what is the further roadmap?
    We are currently coordinating the requirements for automatic migration interfaces in the PSA (Payment Service Austria). They are to be used to transport data and authorisation methods from the legacy programmes and the MBS master data. This enables a user-friendly switch from MBS to EBICS. The migration itself is to follow from November 2023 according to the national project plan. From then on, all business customers must also switch to EBICS.

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

The European Retail Payments Strategy – an update

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

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

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

EBICS blog:
What is the biggest challenge here?

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

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

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

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

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

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

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

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

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

Swaantje:
2023! (laughs)

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

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

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

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

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

Author: Andreas Löwe

 

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

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

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

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

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

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

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

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

Zaher Mahfouz

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

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

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

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

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

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

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

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

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

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


Thomas Riedel




Structured addresses – or: the ostrich effect is rubbish

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

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

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

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

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

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

Author: Michael Schunk





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

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

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

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

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

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

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

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

Author: Michael Lembcke


The digital euro as a basis for innovation in the economy

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

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

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

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

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

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

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

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

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

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

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

Author: Philipp Schröder

Payments 2022: setting the course

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

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

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

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

 

Decisive year for Request to Pay (RTP)

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

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

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

Little momentum expected for the European Payments Initiative (EPI)

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

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

One way or another: the digital euro is coming

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

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

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


The battle for talent

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


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

Tips for a smooth transition to EBICS 3.0

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

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

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

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

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


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

Author: Michael Lembcke

API opens doors for banking applications

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


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


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


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

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


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

Author: Christian Wenz