Payments 2021: no time to rest

For European payment service providers, a challenging year is coming to an end. The coronavirus was the predominant topic in this sphere, as well. In in-dividual payments, understood as interbank and international payment trans-actions, the coronavirus is partly responsible for the postponement of the TARGET2 consolidation and the SWIFT ISO 20022 migration. For card-based payments, the pandemic had both negative and positive effects: On the one hand, the coronavirus has led to a massive boost in card-based transactions, especially contactless transactions. Such a development would normally have taken several years and would also require significant marketing investments of the large card schemes. On the other hand, many market participants in the card business suffered massive sales declines due to the pandemic – especially those who are heavily involved in the area of gastronomy, travel and events. 

Anyone who thinks that there will be any respite for the payments industry in 2021 is mistaken. After all, two concrete projects will go live next year. Other projects need to be prepared, even if the actual market launch is not planned until 2022 or later. Add to that the already grave structural market changes, and this reinforces the impression that the industry is facing a Herculean task under difficult conditions.

But let us go by order: among the concrete topics of the coming year is the forthcoming introduction of Request to Pay (RTP). With the launch of this standard in summer 2021, payments will be supplemented by an important component (see also our whitepaper part 1 and part 2). Many companies have long been urging the financial services industry to make rapid progress with the establishment and expansion of RTP (see also the EBA survey), as RTP can be used to close application gaps in or between the existing procedures. This includes enabling the linking of invoice and payment data. It considerably facilitates the reconciliation processes in accounting for many companies. Also made possible is the previously missing option to accept payments electronically at the point of sale (POS) without a terminal structure. RTP makes setting up a POS easier and more mobile. 

In order to further boost real-time credit transfers according to the SCT Inst scheme, the ECB council has decided that all payment service providers that can be reached in TARGET2 and have signed the SCT Inst scheme must be accessible in TIPS (TARGET Instant Payment Settlement). Accordingly, the accessibility in TIPS must be ensured either by direct participation with an own ac-count or via the reachable party functionality. On top of that, the ACHs (automated clearing houses) offering instant payments shall move their technical accounts from TARGET2 to TIPS. The implementation of these decisions is scheduled for the end of 2021. 

At least not all of the 2021 issues require payment service providers to be quite so active: the adaptation requirements from the November changes of the EPC are rather manageable. It is not yet clear whether this can be said for the RDT and SWIFT changes. However, it seems very likely – at least as far as merely payments are concerned. There are also no major legal due dates.

But of course, this still leaves all the payments plans that have to be implemented in 2022 and the following years – and thus have to be prepared in 2021. One of the most important projects is the pending global migration of payments to the ISO 20022 format.

In individual payments, for example, the TARGET2 migration due in 2022 and the SWIFT migration starting in 2022 must be prepared. In addition to the pure format conversion, extensive changes in the processes, such as changed access mechanisms to the corresponding platforms, are still to be made in both areas. According to common estimates, each of these projects goes beyond the scope of SEPA.
In mass payments (SEPA), payment service providers must prepare themselves for the migration of the SEPA schemes to the (newer) ISO version 2019, which is due to take place in 2023. 

In view of the costs associated with these changes, financial institutions – mainly tier 2 – will increasingly outsource payments or at least purchase payments software "as a service" in 2021. The corresponding demand is already noticeable. In addition, demands for low-cost, central offers for cross-bank services, such as sanctions screening or KYC are likely to increase.

Finally, in 2021, financial institutions and financial service providers will have to find solutions for upcoming structural market changes:

• The further development of the European Payment Initiative (EPI): is it possible to create a uniform, innovative pan-European payments solu-tion as an alternative to existing international payments solutions and systems?
• The everincreasing pressure from the EU commission and the EU par-liament on interchange fees: how can issuers react to a possible zero-interchange regulation? What do future business models look like?
• The apparently imminent obligation of all financial institutions by the EU legislature to offer instant payments and the greater consideration of consumer interests in the reversal of instant payments. Are the existing processing systems able to process the additional quantity struc-tures?
• The significant consolidation of processing service providers, in particu-lar the formation of two conglomerates by EquensWordline on the one hand and NEXI/SIA/Nets on the other: what does this mean for the fu-ture of small and medium-sized service providers, especially in acquiring? 
• The increasing blurring of the boundaries between card-based and classic payment transactions, such as the activities of Mastercard (via Vocalink) in the clearing of classic payment procedures: will there be an additional clearing infrastructure in mass payments in the long term? 
• The forthcoming introduction of digital money, in the form of digital central bank money, but also in the form of Libra: what effects does this have on cash or card-based payments? What does it mean for the role and business model of financial institutions?
• The consequences of the increasing spread of the Internet of Things (IoT) for payments. Only with fully autonomous, uninterrupted payment flows between the connected devices can the potential of IoT be fully realised (see our study on the Internet of Payments). How can compliance requirements and IT security aspects be met within this scope? How do processing systems need to be upgraded for additional billions of transactions?

The year of the Ox begins on Chinese New Year's Day 2021. Chinese astrology ascribes patience and diligence to the Ox: it is strong and overcomes all difficulties. The payment industry can definitely use those characteristics.

Author: Hubertus von Poser (Head of Consulting Payments)

Read more

Request to Pay (RTP): Added value for the e-commerce customer experience?

Every day, many customers browse online shops and add a variety of items to their shopping carts to buy and pay for them. The last step of the customer journey, the checkout process, is a very sensitive point in online shopping. At this point, the customer expects suitable payment options that are as simple and intuitive as possible. Therefore, one of the most important tasks of the online retailer is to always offer the customer a variety of payment options. 

According to a study by EHI Retail Institute, the payment methods purchase on account, Paypal and direct debit were the biggest sales drivers in the German e-commerce market in 2019. For example, their share was almost three quarters of total turnover (purchase on account 32.8%, Paypal 20.2%, direct debit 18.3%) (source: https://www.ehi.org/de/studien/online-payment-2020/). With the purchase on account payment method, the online retailer sends the ordered goods and an invoice to the customer before payment. The customer can check out quickly and is only asked to pay the invoice to the online retailer within a certain payment period. In addition, the customer has until the payment due date to decide whether to really keep and pay for the goods. The Paypal payment method also scores points with its fast checkout process. The customer only has to sign in with his registered e-mail address and can complete the purchase. The third method of payment, direct debit, is a well-known and popular method. The customer gives the online retailer permission to withdraw the invoice amount from his bank account. No further steps are required.

So why are these payment methods so popular? All three have similar characteristics: They offer intuitive handling, the possibility of a quick checkout process, a payment overview and a wide acceptance by retailers. 

However, in the status quo, the process of these payment methods ends with the completion of the payment. Additional information such as billing, warranty notes and shipping information (tracking number) are made available to the customer via the retailer portal or via e-mail communication afterwards. 

In the end, today's online shopping process often lacks a consolidated overview of the payment details for the ordered goods as well as the invoice, the warranty and the shipping information.

Can Request to Pay be the missing puzzle piece for a successful user experience in e-commerce?

A glance at the concept of the Request to Pay process reveals the possibilities of a holistic ordering process in the banking ecosystem. The following process can be initiated using RTP: 

Figure: RTP process (source: own image)

After the customer has confirmed the order in the retailer's online shop, an electronic payment request in form of an RTP data record is initiated by the retailer. This data record is automatically sent to the customer's financial institution and then to the customer (debtor). Payment information such as invoices and shipping information can be initially attached to the RTP data record or made available to the customer via an attached link at a later point in time.
The RTP process provides the customer with flexible options to complete their payment after receiving the payment request:

• Accept now and pay now 
• For example, when purchasing a movie in an online video store that is to be consumed directly
• Accept now and pay later 
•  For example, when purchasing shoes to be tried on first
• Accept later and pay later 
• For example, when the goods are shipped before payment data is provided. The first retailers are currently piloting the shipment of goods (e.g. clothing) to the customer without the customer having to provide payment data. Only after a certain period of time does the retailer ask for data and payment via a payment request.

If the customer accepts the payment request upon receipt and pays directly with an (instant) payments order, the customer bank sends a direct payment confirmation to the retailer bank. The retailer (payment recipient) receives a confirmation of receipt from the retailer bank. This completes the process from the payment request to the payment.
This "pure" payment process does not offer the consumer a significant added value compared to the three payment methods listed above. However, if the payment process in the banking app is supplemented with payment information such as invoices, warranty slip and shipping information, the banking ecosystem becomes the central repository of online orders and creates a new customer experience.

In addition, if the Request to Pay process is to become a successful payment process in e-commerce, the following factors must be interconnected:

1. Comprehensive (retailer) acceptance of electronic payment requests and payments
2. Integration of the entire process into the existing banking ecosystem (banking app)
3. Creation of options for partial payments as well as payments at a later date
4. Possibility of reverse processing, for example, in case of cancellation or parcel loss
5. Extension of the payment transaction to include the overview of purchases supplemented, for example, by invoice history, shipping numbers and warranty slips

Taking these factors into account, and in connection with instant payments, Request to Pay can be the puzzle piece that is still missing for a successful user experience in today's e-commerce. In this context, the following applies: for successful implementation, a holistic and customer-centred approach is required.
 

Author: Philipp Schröder

Read more

New data formats and the need for an EBICS update in Switzerland – what should be considered?

With the SIX EBICS V3.0 publication Swiss Market Practice Guidelines EBICS from June 2020, which contains recommendations for the implementation of the EBICS standard for the Swiss financial market, Switzerland is now also adapting the standard to the European harmonised protocol. The main drivers of the harmonisation were the members of the EBICS society, in particular the financial markets of Germany, France and Switzerland (the newest member is Austria).

By definition, two versions of EBICS are also supported in Switzerland, i.e. version 2.5 and version 3.0 in the future. At first glance, one could think that there is no urgent need for action on the part of customers and software manufacturers since the previous version is still being offered. If only in Switzerland the SIX document did not include the paragraph 2.2.1 EBICS Timeline with the following note: "To support the ISO 20022 schema migration to version 2019, the use of EBICS 3.0 is required."

As well-informed experts know, the ISO version 2019 is to be introduced for the customer-bank interface as of 2022. The current versions shall no longer be supported by 2024. This corresponds to the trend of global migration to this new version, e.g. in the projects SEPA, SWIFT MX or TARGET2 migration. This migration is of great importance, not least in view of the planned introduction of instant payments in Switzerland as of 2023.

The Swiss financial market has therefore decided to link the upgrade of the EBICS version with the upgrade of the ISO version. Against this background, customers and software manufacturers are faced with a few questions and challenges that should not be underestimated. The most important points are examined in the following paragraphs, and solutions are shown – wherever possible.

EBICS 3.0 will be available in Switzerland as of November 2021 at the latest

EBICS communication has now been fully established in Switzerland and is an indispensable part of the financial sector. So far, the EBICS version 2.5 is offered by the majority of financial institutions in Switzerland.

As already mentioned at the beginning, the Swiss Market Practice Guidelines EBICS (version 1.0 from 01/06/2020 by SIX, www.six-group.com) will officially introduce the new EBICS version 3.0 in Switzerland for corporate customer business with financial institutions as of November 2021.

Specifications by Switzerland for handling the new business transactions in EBICS

With the introduction of the new EBICS version 3.0, the previous version EBICS 2.5 will still be officially supported by financial institutions until the end of 2024. In addition, the acceptance of the new Swiss ISO 20020 formats in version 2019 requires EBICS 3.0. For corporate customers, this means that once they have updated their Swiss ISO formats, they can no longer easily use EBICS 2.5 for this purpose.

It is time to plan

These upcoming updates require that an adaptation of the software solutions be planned and implemented in good time. This is where financial institutions, corporate customers and software manufacturers must act.

Updating the ISO 20022 data formats to version 2019 is just one aspect. However, the changes to the EBICS protocol that are to be implemented with version 3.0 should not be underestimated. The most important requirements are:

• The new business transaction format (BTF) replaces the previous order types and FileFormat parameters.
• The transport of the public keys is now carried out uniformly with certificates.
• The cryptographic procedures are improved.
• The handling of bank keys is improved.
• There are additional control parameters for electronic signatures.
• A double submission check at file level is introduced.

So how to deal with these new requirements?

It is not only the financial institutions but also the software manufacturers of EBICS clients who have the task of extending their software solutions by EBICS 3.0, so that corporate customers can carry out updates and put them into production at an early stage.

All special features of EBICS 3.0 must be taken into account in the client, and it may be necessary to enable a mixed operation with different EBICS versions depending on the bank access and the EBICS users. In addition, the user should be offered migration options for the EBICS migration which avoid reinitialisation if possible (keyword increase of minimum key lengths).

The EBICS API – decoupling of business aspects and technology

From our own experience, we know that the migration to version 3.0 is not simply a matter of mapping order types to BTF combinations. There are many more challenges to overcome and aspects to reprogram respectively. This is especially the case if the financial institution, the software manufacturer and the customer want the migration to be as automated as possible. PPI has long been offering TRAVIC-EBICS-Kernel, an API solution for integration into proprietary EBICS clients. It is the central component for the handling of EBICS communication in almost every second EBICS client software in Europe.

With the latest version, the new specifics of EBICS 3.0 are, of course, already implemented. Correctly connected, the API transparently handles e-banking in all its variants and versions for the client. TRAVIC-EBICS-Kernel thus relieves the software manufacturers of e-banking and payments applications in the implementation of the standard protocol and its syntax as well as in security procedures. This solution fully reflects the EBICS specification and provides an easy-to-integrate interface that software manufacturers can connect to their software products as a convenient and quickly usable communication component.

Considering the cost/income ratio for the integration of TRAVIC-EBICS-Kernel, it is not surprising that this product is such a bestseller. Software manufacturers who do not use the TRAVIC-EBICS-Kernel can contact us at any time and request a test licence. The time for it has never been better than now, before the upcoming migration to EBICS 3.0.

Authors: Carsten Miehling and Michael Lembcke

Further information: Do you speak EBICS 3.0?

Read more

Setting up EBICS – simply step by step

As a standard, EBICS offers maximum security for smooth European payment transactions. However, this also demands effort by all parties involved. The necessary initialisation and setup of bank accesses, EBICS users and rights requires careful configuration steps. To utilise the high potential of multi-banking, repeated steps must be performed which are usually distributed onto different places and executed in a decentralised manner. Reducing complex, networked applications to linear, simple sequences for business users is the art of designing user-oriented software.
The compact setup wizard that PPI has developed for its corporate customer portal TRAVIC-Port proves that this can be done conveniently, easily, and quickly. The target group is administrators on the customer side - because self-service is a key asset in modern customer-bank relationships. Allowing direct access to essential administration processes creates fast workflows without any detours to the provider.

Granted, if you want to create a new EBICS user, you will have to go through quite a few clicks; however, it is a purposefully guided, step-by-step process. The same is true for the PPI product world, i.e. TRAVIC-Port. The system requires from each individual user an ID, the master data, the initial password, and a security medium which will be used for login later on. On top of that, the user takes on different roles, has different authorisations and often more than one bank connection. As TRAVIC-Port is multi-bank capable, the respective bank accesses must also be set up. Often the main bank takes over this task for its EBICS corporate customers - and this usually means long phone calls during which the bank employee has to query all this information.

The user of the portal finds a new entry directly on the start page (see Fig. 1). This link can be used to go directly to the setup wizard and greatly facilitates the introduction to the secure world of EBICS. Via a series of dialogs, the wizard queries all necessary data in order to create a new EBICS user.

The wizard also ensures that the data is entered in the correct places. This is particularly convenient because the system sets up the download agents via a different menu item than bank accesses and users, for example. Although this makes sense logically, it complicates quick input and makes new setups error-prone and tedious. Dialogs prevent important data from being omitted and enable you to see at a glance what information is actually required. For instance, the first thing to do is to set up a new bank account - whether this is done by the bank or an administrator on the customer side is irrelevant. The dialogue asks for all required information and shows how much work still lies ahead. As many as seven dialogs come together for the setup of a new bank access (see Fig. 2).

Once all bank accesses are set up, it's usually time for the individual users. For example, a small law firm wants to set up account authorisations for the owner, two employed lawyers and an assistant - specifically different ones for each individual. The owner naturally wants to have all rights, be able to order and release transactions without limits and, for example, issue releases for her colleagues via an electronic distributed signature. The two employed lawyers, on the other hand, are only allowed to release transactions up to a certain amount on their own - and the assistant may create payments but not release them. All four in turn should be able to see the account statements which are downloaded from the EBICS bank server. All these configurations are facilitated by a dialog that can create new colleagues for an already created corporate client (see Fig. 3).

 

Starting and working with EBICS in payments can thus be simplified rather easily without sacrificing security and compliance with standards. The setup wizard has been tested in practice and is in use at well-known major customers. If you would like to know more about this feature in TRAVIC-Port, please contact us. Together, we make EBICS easier.


Author: Christian Veith 

Read more

SWIFT gpi – from obligation to opportunity

For November of 2020, the SWIFT release does not require any format changes for payment transactions for once. These were postponed until next year because of COVID-19. Still, the requirement for the so-called "universal confirmation" as part of SWIFT gpi remains. In simplified terms this means: for the credit in the MT103 format on the account of the beneficiary all FIN participants must send a response to SWIFT, specifically to the tracker. Rejections must also be reported, however, this does not replace the actual return. Thus, the payment sector once more has to cope with a (regulatory) mandatory project, which results in less resources for customer projects. But does it have to be like that? To answer this question, let us first look at what SWIFT gpi means.

Since 2016 the topic SWIFT gpi (global payment innovation) has become increasingly important. The core is a unique end-to-end reference, the UETR, which is given to the payment at the beginning of the correspondent banking chain and is maintained throughout all stages. This enables the tracking & tracing of payments, which had long been demanded for cross-border payments. The information is collected in the tracker. The tracker is a central database in the FIN cloud at SWIFT, which automatically reads the necessary information for each payment in FIN and is completed by further messages from the gpi financial institutions.

At first, UETR existed only within the CUG (closed user group) of the financial institutions participating in the gpi initiative, and only for customer payments (MT103). The standard service is also called gCCT (gpi for Customer Credit Transfer), which was soon completed by gCOV (gpi for Cover Payments). As of 2018, all FIN financial institutions are required to support the UETR, in addition to customer payments (MT103), for all bank-to-bank payments (MT202/205) – i.e. for all payments. First positive effects can be reported. With the UETR it is now possible to make statements such as "40 % of all gpi payments are final within 5 minutes" or "75 % of all gpi payments are final within 6 hours". Previously, there were only examples of payments that arrived very late (or not at all) or with no remittance information, but with high deductions for fees (including OUR), which led to many complaints with corresponding enquiries. A somewhat unexpected effect of the introduction of gpi was the drastic reduction in investigations.

If possible, a gpi financial institution undertakes to process the data on the same day, to waive the deduction of fees for OUR, to pass on the remittance information in full and unchanged (analogous to SEPA) – which should all go without saying – and of course to exchange information with the tracker (as soon as possible) not only on the status but also on fees and exchange rates. This information is then available to the payer bank as gpi bank. In this way, a further shortcoming of the cross-border payments – the lack of fee transparency – can be reduced. These benefits and in particular this information can then be communicated to the payer.

And then there is the issue of recalls. If need be, it should be possible to stop payments along the executing bank chain. However, same as the payment along the chain, the recall message is processed step-by-step by each involved financial institution. This is where the gpi additional service gSRP (gpi Stop and Recall Payments) comes in. The recall is reported to the tracker and the next attempt to transfer a payment to FIN with the relevant UETR is rejected. The long chain is skipped.

Now, with the "universal confirmation" the transparency is completed. This means that the payer bank not only receives the information "payment arrived at the last bank in the FIN chain", but also the status "payment arrived at the recipient". An acknowledgement was an integral part of the definition of SEPA instant payments from the beginning, but that was almost 50 years after the first SWIFT messages.

The FIN financial institutions are now required to report a "universal confirmation". This only applies to customer payments (MT103) and not to all payment receipts (M202/205). Reports must also be submitted for TARGET2 incomings, as these are transported via FINCopy. A "goodie" is the (manual) web access to this tracker, which was previously only available to gpi financial institutions.

The financial institution has up to 2 working days to report the "universal confirmation" (own public holidays are therefore excluded). This SLA will also be measured and the conduct of other financial institutions will be reported, but this will not start until mid-2021. Web access to the tracker is also made dependent on good behaviour.

Financial institutions with the smallest volume could consider manual reporting in the tracker. For automated solutions the payments platform should, for example, support one of the routes offered by SWIFT (MT199 or API). In addition, there is a so-called CSV solution in which corresponding messages are then generated to the tracker from a specific CSV report in the SWIFT interface.

Thus, a non-gpi bank must meet almost all the requirements that a gpi bank must fulfil. The missing step is no longer a big one, but the benefit for your own customers can be enormous. And with the options for gpi bank-to-bank payments (MT202/205 – called gFIT, which stands for Financial Institution Transfer service, an option for gpi banks), the financial institution's internal departments like treasury or money trading can also be given the security that the "payment has arrived".

However, for a financial institution it is not as important to receive the status messages from the tracker for sent payments, but rather to provide the customer with added value – in the best case the receipt "Payments received" (including information on fees and exchange rate). The service levels that a financial institution can offer range from the minimal version of manual access to the tracker via an own (corporate customer) hotline, to self-service offers in the online banking portal, to active information through notification with status reports to the corporate customer. And this is actually only possible by taking the step from the "universal confirmation" to the gpi standard service and opting for gpi. In the future, financial institutions with corporate banking will have to measure themselves against this.

Cross-departmental cooperation is required here; the services cannot be provided by the central administration department alone or even only by IT itself, as is often expected in "regulatory" projects during a SWIFT release. This can be achieved with a consultation that focuses on the overall process.

In summary, one can therefore state that it is not a long road from the mandatory requirements to enormous opportunities, and the prospects for additional services for corporate customers and also for internal bank departments are exiting.



Author: Mario Reichel

Read more

ISO 20022 – more topical than ever despite the dates being postponed

The decision has been made: on 27/07/2020, the European Central Bank has agreed with the vote of the European banking community to postpone the go-live date for the T2 and T2S consolidation by one year to November 2022. Similarly, the migration date for the Eurosystem Collateral Management System (ECMS) was postponed from November 2022 to no earlier than June 2023.

In the survey conducted in May, the European banks had declared themselves in favour of postponing the migration. In addition to the effects of the Corona pandemic, the main reasons for this include the postponement of the ISO migration for cross-border payments already announced by SWIFT. At many financial institutions, both migration scenarios converge in one project, since it is simply not possible to separate payments via TARGET2 from cross-border payments. Large financial institutions with extensive correspondent banking operations in particular saw major risks in the divergence of migration dates. With this decision both events have now been synchronised again. EBA Clearing has also joined in and postponed its migration to 2022.

The relief about the postponement was certainly great – but what does this decision mean for the financial institutions and their projects? The last thing that should happen now is for financial institutions to sit back and slow down their projects, as there is now an extra year’s time to implement them. That would be the worst solution at this stage. Many financial institutions have underestimated the effort that the TARGET2 migration entails. On the contrary, the postponement now offers the opportunity to continue with the projects at full speed in order to make up for lost time. Leaning back and leaving off now only to pick up the process in early 2021 is not an option. It should also be noted that the start phase of the user tests was only postponed by nine months from March 2021 to December 2021. Releasing external resources will mean that the people who previously worked in the projects and acquired knowledge will no longer be available.

It should also be borne in mind that the specifications, which have already undergone two new adjustments this year, will continue to be adapted. The ECB still has pending change requests which were not yet relevant for the November 2021 migration. This will certainly change with the postponement. It can be expected that with the new UDFS in November further functionalities will be offered, which will have to be evaluated and implemented.

The objective of SWIFT is also not yet clearly defined. So far, it is known that a transaction management platform is to be built, which will act as a central "hub" to handle cross-border payments. There are no published specifications for this yet. In addition, new ISO message types are currently being defined, for example for fees and cheques, which must also be considered and implemented. Thus, there is still much movement and uncertainty in the upcoming ISO migration. As such, might one not wonder whether there could be an even further postponement for SWIFT? How would the ECB react then? Could there also be a further postponement of TARGET2, or would we then have to accept that the migration dates diverge? How does one deal with changes in already harmonised message formats, such as pacs.004?

And as if that were not enough, the ECB's decision on instant payments is also causing a stir. Based on discussions with market participants of the AMI-Pay, the ECB council has decided that, on the one hand, all PSPs with TARGET2 that have subscribed to the SCT Inst scheme (i.e. instant payments) must be reachable in TIPS. On the other hand, all ACHs offering instant payments should move their technical accounts from TARGET2 to TIPS. The implementation is scheduled for the end of 2021. The ECB will thus make TIPS virtually obligatory for those who are already participating in the instant payments procedure. This is important because a large number of financial institutions today are using the EBA's RT1 procedure.

Also, so far only the decision itself has been made and announced. Further descriptions such as technical details are still unknown and will be published sometime later. One must also ask what a future pricing model will look like, especially if fees are charged for cross-ACH transactions. What can a transaction fee look like and what effect does this have on the pricing of the clearing houses? The question also arises whether there is an increased settlement risk for the settlement of positions such as RT1, as TIPS involves an additional participant in the chain.

What's more, SEPA will also switch to the new 2019 ISO version in 2023 - according to the currently announced plans of the EPC. The current gap of more than one year with regard to the migration of TARGET2 and SWIFT may seem a long time off. However, it has to be considered that a lot needs to be done before: reading specifications, writing business concepts and preparing systems. Despite the migration being postponed to 2023, it may not be underestimated and we recommend to deal with this issue as early as possible.

As is evident, the next three years will bring many topics related to ISO 20022 for financial institutions, and every institution would be well advised to use the time gained by the postponement to realign its priorities.

This requires highly specific know-how, and one should not indulge in short-term budget considerations and cut back on resources that will then be urgently needed again in 2021.

Authors: Sabine Aigner, Thomas Ambühler

Read more

Less stress with an “EBICS self-service”?

In my last EBICS blog post, I wrote about the difficulties that new EBICS customers face during initialisation (and how they could be alleviated). What makes it even more cumbersome is that new customers have to deal with the whole ordeal not just once – the same procedure has to be repeated for every single EBICS user.

Does it have to be like that? How about granting the first registered EBICS user, let's call them User 0, the right to create further EBICS users – and to authenticate them immediately? What would that look like?

Let us imagine a new administrative EBICS order type to which we give the exemplary name HUC (EBICS User Create). HUC would be an upload; the included EBICS message would contain the necessary master data of the new EBICS user as well as that user’s three certificates. The message is signed by User 0. With the data and the signature, the EBICS server can immediately set up the user; INI and HIA orders, letters and waiting times are eliminated. We get another ready-to-go user without any initialisation hassle. There are signs of a customer-side need for such an "EBICS self-service": after all, efforts are being made with EBAM to promote a very similar service for accounts.

If it were that simple, we would probably have done it already. However, one is immediately faced with two questions:

1. How do we control such a powerful EBICS user as User 0?

2. What kind of master data is actually necessary?

The first question is surprisingly easy to answer: because if there is one thing EBICS is really good at, it is checking authorisations. In order to prevent an overly powerful User 0, a User 1 is set up at the very beginning and it is specified that a HUC order requires several signatures. Thus a four-eyes principle is in place and the familiar mechanisms of E, A and B signatures enable a very precise configuration of who can set up additional employees along with whom.

The much more difficult question is: what kind of master data is required? Most people will agree that a name is probably necessary, but after that it becomes tricky. Do we want to know the address, telephone number and e-mail address of the user? Are they perhaps even mandatory? Or is it better not to burden oneself with unnecessary personal data considering the GDPR? So far, every financial institution can decide for itself, but HUC would set a standard for everyone. And nobody is helped if a standard essentially consists of a vast number of optional fields. The financial institutions would be called upon to agree on a meaningful set of binding data.

The difficulty of this can be seen in EBICS itself – with the order types HKD and HDT. Designed to enable a customer system to obtain information on the customer, the associated EBICS users and their authorisations from the financial institution, these two order types lead a rather shadowy existence as it was not possible to reconcile the historically developed authorisation models of the various financial institutions. On the contrary, many financial institutions see their special degrees of freedom in the allocation of rights as a unique selling point. This is not compatible with standardisation.

Therefore it seems that the inconsistent rights models mean the premature and certain death of an EBICS self-service. However, it really only seems that way. In reality, a financial institution needs the many ways of assigning rights to do justice to all its customers; the individual customer does not tend to need them or at least not all at once: how many roles are there for a typical corporate customer anyway? There are those who may submit orders but are not allowed to authorise them, those with limited or extensive signing authority for this or that account, and then there are those who may set up new EBICS users. All in all, about a handful of roles which are created at the same time as the EBICS agreement is set up and which can be used to play around with the full range of the financial institution's authorisation configuration. The role is then given a name which the customer can use (e.g. authorised signatory) and which can then be easily specified in the HUC request for the new authorised signatory.

Such a role model has even more advantages. It is possible to adapt the role to the new conditions of the company (an account has been added) without having to look at the authorisations of all EBICS users. The roles can also be reassigned. And it is easier to get an overview of who actually has which role and therefore which authorisation.

While the definition of the roles will inevitably remain a manual task, the assignment of the roles can be carried out in the EBICS self-service. Aside from creation, the service would then still be missing the possibility to read, update and delete the EBICS user, i.e. the R, the U and the D from CRUD. The corresponding order types could be called HUR, HUU and HUD. That would make for a nice first draft for the EBICS self-service.

And all the initialisation troubles would almost completely disappear into thin air.


Author: Curd Reinert

Read more

EBICS and EDS: weaknesses of salary payments with confidential information

For many years the electronic distributed signature (EDS) has been an important functionality used by various people to upload and release payments even from different locations.

The order types and their business content intended for this from the EBICS protocol permit a release based on the total data available – via the accompanying note – or based on the content payment data. For this purpose, the EBICS servers provide the most important information for each of the contained single payments already in prepared form. A customer system that shall display this data must not even know the specific payment format. That is what makes the software so convenient. As an exception, even a complete payment file can be transmitted. However, especially for large bulk payments this counters the convenience just described.

In payments practice, not only are simple payments and direct debits included in the ES folder but special payments with very personal data that requires special protection must be included as well. This includes pension and salary payments as well as bonuses and gratuities which are not intended for the general public and certainly not for inspection by the staff of a company.

This is exactly where a weakness of the EBICS specification becomes apparent: the business transaction code or purpose code that specifies the type of payment is missing when the single payments are transferred. That is why the EBICS products used by the customer are not able to protect the confidential data in a payment order, even if this was what the company wanted. The software lacks the criterion to decide whether payment details should be displayed or hidden.

Without an identifier in the specific payment order, it is not possible to distinguish confidential from normal payments. This means that the EDS is in principle unsuitable for checking and releasing salary payments by EDS because it cannot be ruled out that unauthorised employees will take a look at the possibly confidential information.

The EBICS society should therefore consider an extension to the XML for the HVT, which will also transmit this important information for the payment type. As long as this does not happen, the EDS can only be used for salary payments to a limited extent.

Author: Michael Schunk

Read more

EBICS: every beginning is hard

It is the nature of things that new customers’ first contact with EBICS is usually the initialisation process. This is somewhat unfortunate, because it means that right at the beginning of their EBICS experience, they are confronted with what is probably the most complicated and least intuitive part. And once new customers have successfully struggled through their own network technology, proxies, firewalls and the TLS, have properly and obediently transferred the data from the BPD sheet into the application – which hopefully guided them as simply and intuitively as possible through sending the two initialisation messages – they will be surprised to find that they are by no means ready to finally use EBICS. Instead, they must first print out, sign and send a multi-page INI letter to their financial institution. And then they wait. They wait until the letter has arrived and a bank employee has entered the 192 hex digits of the hash values of the three EBICS keys into the bank server. Possibly even involving a four-eyes principle process.

Once that is dealt with – and there is usually no clue as to if and when exactly it happens – the new customers can at last use EBICS. Almost. Before that they must download the bank keys and confirm their hash values, which they compare hopefully carefully with those on the BPD sheet.

After this trauma of initial initialisation, the rest is almost a walk in the park. Own keys can be renewed in many applications at the push of a button. New bank keys can now be signed with the old ones and accepted automatically. Things only become really unpleasant if – for whatever reason – a complete reinitialisation becomes necessary.

France, you are (a little) better off

French EBICS customers who read this blog may wonder what I am going on about. Network and TLS may not be any easier to handle in France than elsewhere and the BPD sheet must also be typed out, but at least the actual EBICS key exchange is as simple as one could wish for thanks to CA-based certificates: EBICS users send their keys as certificates, which the financial institution can validate and release directly based on the signature of the issuing certificate authority. The EBICS client can thus download the bank keys as certificates immediately afterwards. And if these certificates were also issued by a CA and the client trusts this CA, then nothing stands in the way of starting an EBICS communication.

This apparent effortlessness is a little deceptive, of course, as the certificates do not just drop from the sky either. The certification process is not necessarily simpler than the EBICS initialisation, because in this case, too, a person and that person's digital identity have to be matched securely. The main advantage is that the process is not regarded as part of EBICS and is therefore not blamed on the protocol. And of course, a certificate can be used for many purposes – the EBICS initialisation, on the other hand, is only ever valid for exactly one EBICS user at exactly one financial institution.

I will only mention in passing the fact that certificates bring with them other problems, such as regular renewal costs, the problem of agreeing on a list of trustworthy CAs as globally as possible, and interesting failure scenarios if there is only one generally recognised provider for the online verification of certificates.

In other words, the process remains a struggle, but we believe that it need not stay that way. In a brainstorming session, we came up with two ideas that we want to present here – even at the risk that they may prove to be entirely lacking in practicality.

Option 1: face to face

Our first idea is based on the assumption that the future EBICS users will sit down with a bank advisor in order to have the advisor activate EBICS for them. While the bank advisor enters the necessary data such as name, address, customer and EBICS user ID into the system, at one point he or she passes the keyboard to the EBICS user, who enters a freely chosen one-time password – and repeats it, as usual, to rule out typos. The EBICS user must remember the password until logging in to the EBICS client and then enter it again when setting up the bank access. With the help of the password, a symmetrical key is generated and used to encrypt the initialisation message – which contains all three EBICS keys. Since the bank server knows the password, it can generate the same symmetric key and communication is protected against interception, manipulation and even man-in-the-middle attacks. Therefore, the server can also return the bank keys directly as part of the response. The initialisation password is no longer required (and must not be reused for later reinitialisations either).

The result: after a single EBICS message, the EBICS user is completely initialised and ready for EBICS. On the bank side, once the setup is complete, the manual steps are eliminated. The customer does not have to send a letter and – most importantly – does not have to wait!

Two possible problems come to mind with this scenario:

1. An attacker who knows both the financial institution and the EBICS user well enough could guess the customer ID and EBICS user ID as well as the password that the customer has come up with and log in before the legitimate user does. The process can, for example, be protected by a PIN, which is generated and given to the EBICS user during setup, as well as by a lock after n failed attempts.
    
2. The errors that the server reports back when someone wildly guesses the key could allow oracle attacks. This problem could also be helped if the EBICS user is completely locked after n failed attempts.

The issues could thus be solved.

Option 2: all digital

Option 1 is still a little bit stuck in the traditional way: the customer gets a piece of paper, the data from it must be typed into the application ... But why? Why not give the customer the data digitally instead? E.g. on a USB drive, on which the bank advisor directly stores the data before handing it over to the customer, who is then free to keep it – naturally with the bank's advertising imprint. The USB drive would then contain a file that includes everything needed for the setup:

• The URL
• The IDs
• A symmetric key, which is used to secure the initial communication in the same way as with option 1

Obviously, there is no need to take into account how much a person can remember or is willing to type; the key can be as long as desired. Attacks by means of guessing the key are no longer an issue. The biggest risk is still that the customer loses the USB drive on the way home. But again, a password protection of the file can help.

Once, however, the EBICS user makes it home safely with the drive, he or she imports the file into the EBICS application. The latter recognises the format and can thus immediately and autonomously set up the complete bank access – as described in option 1.

What if my system has no USB port? Then it may be a smartphone on which I want to register for a signature app, for example. In that case, it may not have much use for USB, but it can do a lot with QR codes. So the data can be provided this way. Or perhaps it is company policy that does not allow the use of USB drives, not even from such a trustworthy source as my financial institution. Then one could of course consider simply sending the file by e-mail. And once the thought has crossed one's mind, one wonders whether it needs a USB stick at all. And the answer is probably no, if (a) the file is cryptographically secured with a sufficiently good password and (b) the password is not included in the same e-mail, but is transmitted in a different, secure way. That should be manageable.

Achieving the goal

The initialisation can be simplified. But for this simplification to be of any use, it is not enough for just one financial institution to implement it or – even more absurdly – just one customer system (provider). Only if such a change becomes part of the EBICS specification can it make life easier for customers and financial institutions. But then, the improvement will be considerable: for the customer, setting up a bank access is no longer a nuisance, and the financial institutions can save themselves the hassle of typing in hash values. There are employees in call centres who in fact do nothing else.

If the initialisation is simplified this much, it is perhaps no longer a problem that it must be carried out individually for each EBICS user. Still, we have given thought to ways of simplification for that aspect, as well – which I will happy to share in a later blog post.


Author: Curd Reinert

Read more

All goes ISO 20022

The title refers to the general migration to ISO 20022 in all payment transactions and the associated reporting. In this context, my colleague René Keller wrote about the plans of TARGET2 and SWIFT to now also implement the ISO 20022 standard, which is already familiar from SEPA, in individual and cross-border payments. The changes described there, especially in interbank payments, now also affect the customer-bank interface.

Just as the Corona pandemic has negative effects in many other places, consequences are also found by way of postponed migration schedules. The changes are coming – just a little later. The time should be used well, as the aspects are not purely IT-related. With the new standard, many processes in payments and associated fields will see fundamental changes and the impact must be considered for the architecture as a whole. This applies for both financial institutions and corporate customers, who will have to deal with a number of changes in the coming releases. The information in the announcements is now available in Appendix 3 of the DFÜ agreement and extends several years into the future – which is completely necessary.

Some make a point of saying that "the forthcoming changes are not that massive; after all, we are familiar with the XML format from SEPA". If the format used in SEPA is "well known", then that is indeed a very good starting point for preparing for the changes. However, there is much more to be considered. On the one hand, SEPA is about to make a release leap. On the other hand, especially in individual and cross-border payments, there is a whole range of special features that do not occur at all in mass payments. Moreover, for regulatory reasons, there will be a switch to structured address information. The challenge lies in the sheer sum of the changes.

camt.053 – version change

With the introduction of SEPA and the Europe-wide uniform format based on ISO 20022, the camt.053 account statement was also introduced alongside the previously common MT940. It was the ideal format for SEPA payments, as data from a uniform data dictionary could now also be transported as account statements via the formats pain (customer-bank) and pacs (interbank). But in addition to bookings in mass payments, there were also individual and cross-border payments. For this reason (and various others), quite a few companies stuck with the old familiar format.

However, the introduction of ISO 20022 in all interbank payments is now taking place on a current ISO release, the one from 2019. SEPA is still using the ISO release from 2009. As with any standard, there are of course various reasons for the further development of the ISO 20022 format, and there will continue to be. New fields will be introduced or code words will be extended. The account statement, which is to pass on all the new information to the end customer without any loss of data, must therefore also comply with the new standard, and so the conversion from camt.053.001.02 to the new release camt.053.001.08 is unavoidable (similarly for camt.052 and camt.054). As corporate customers have been informed at an early stage, sufficient time is now available for often lengthy ERP release cycles. Particularly as it is to be expected that a postponement of the TARGET2 migration to ISO 20022 will also delay the migration here.

MT940 discontinuation

SWIFT will discontinue the MT messages of categories 1, 2 and 9 in interbank communication as of November 2025. At the customer-bank interface (especially with SCORE), this restriction should not apply; in this respect, financial institutions worldwide are not forced to switch off MT101 or even MT940 in their service. However, the German Banking Industry Committee (DK) has decided this is necessary for our "multi-bank standard" – and that is a good thing. Financial institutions may still offer MT940 if they wish, but the advantages of the new standard are already obvious: entire XML structures can be transported from pain via pacs to camt without conversions. It is no big leap to the analogy of containers in logistics. And all corporate customers should be "pushed" towards these advantages.

DTAZV becomes pain.001

With the introduction of pain.001 as a customer order for a SEPA credit transfer, the question was quickly raised: why can't this format also be used for currency payments? The CGI-MP (Common Global Implementation - Market Practice) initiative of corporates, banks and manufacturers soon came together to harmonise the use of this global standard in order to establish a standardised mapping. But the CGI version of pain.001 is based, like the SEPA version, on the ISO release from 2009 – meaning pain.001.001.03. The CGI-MP is working on a new version (ISO release 2019) of the harmonised mapping. The new cross-border payment upload in Annex 3 will also be based on ISO 2019 – meaning pain.001.001.09.

And, as is so often the case, "all goes ISO 20022" also presents a great opportunity. An opportunity for continuous processes on the same data basis which can be handled without conversions. The basis for further digitisation remains standardisation. With "all goes ISO 20022", a continuous standard is available which can also be used for adjacent processes such as "exception & investigation" (queries), notifications, bank fee messages (camt.086 bank service billing) as well as for BAM (bank account management) as eBAM messages. This in turn means that payments (including account statements) are only a small part of the entire ISO universe.


Author: Mario Reichel

Read more

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.  

Status CHECKINBOUNDCHRGS {
    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:

• Using standard software like a customised solution? download expert article by Thomas Riedel and Markus Seeliger, courtesy of IT-Finanzmagazin (German) 
• TRAVIC-Payment Hub for instant payments
• TRAVIC-Payment Hub for individual payments

Read more