EBICS as a SaaS – EBICS in the cloud

Whether for financial institutions, corporate customers, payment service providers or Internet service providers: EBICS is used in all these areas in Europe today. Why is that? On one hand, EBICS is geared towards the mass payments that are common in corporate banking, and on the other hand, EBICS is established as an e-banking standard in Europe. 

 

I need EBICS connectivity – do I have to operate EBICS myself? 

 All the EBICS market participants have one thing in common: their core business is usually not primarily in the operation and handling of the EBICS communication, but, for example, in the supply and sale of banking products, payment services and in the Internet business. The communication needs to work, and you want to rely on a standard, so that you do not have to build and maintain your own connection solutions with each partner.  

In order to be able to concentrate fully on the core business, it might be interesting to think about the "software as a service" concept for all services related to EBICS. There are different approaches for the EBICS services to be operated in the cloud. Service users may be able to save a lot of money and thus benefit from greater flexibility because an EBICS solution can be introduced faster and can be expanded or reduced more easily.   

Financial institutions with a smaller number of potential EBICS customers in particular shy away from the high initial costs of installing and operating an EBICS bank server themselves. Is this effort and its cost worthwhile for the initial few, perhaps 50 – 100 corporate customers?

EBICS in the cloud

So why operate the service yourself? Why not hire a service provider who has been involved in the EBICS business from the very beginning and thus has mastered all its facets?
Buying a complete EBICS bank server as a service at low cost, that would be it. The best way to do this is to use a web-based corporate customer portal, so that customers can enjoy the new service quickly and without much effort. Both financial institutions and corporate customers can then use these services.

EBICS is not a service that is only about gaining a decisive advantage in competition with other financial institutions. Offering EBICS and the corresponding payment services is one of the "must-haves" of a financial institution. So why not share the initial cost with others and use a more cost-effective service in the cloud?

EBICS in the cloud: perhaps a worthwhile course of action. Right?

Author: Michael Lembcke

Request to Pay – easy thanks to EBICS

Appealing to consumers, and an important addition to point-of-sale (POS) purchases from a business customer's perspective – such are the current reviews for Request to Pay (RTP). The new initiative for a uniform payment request (EPC014-20) in the European area has been defined by the European Payments Council (EPC) in June 2020.

With an RTP solution, customers can now pay for their purchases directly at their customer advisor without having to go to the cash register. The shopping experience will change significantly as a result. In online trading, RTP is a better payment option for the supplier than direct debit; after all, the latter may be revoked. With the credit transfer resulting from the RTP, additional fees, such as those for credit cards, PayPal and similar solutions, are eliminated. This also applies to the additional infrastructure costs of the processors.

Another advantage is that RTP can be used to transport all the information that the following credit transfer must contain from the payment recipient's perspective. The goal is to ensure a payment accounting that is as fully automated as possible. This is achieved by obliging each of the parties involved to forward the data once received to the next instance for further processing. However, in order for private consumers to be able to use this new idea across the board, appropriate mobile applications must first be created for debtors. This will undoubtedly happen – even though quite some time will likely pass until then.

At present, the EPC initiative is still unclear on how the promoted universal accessibility of the debtor can be implemented in a uniform manner. In this case, the basic concept that the RTP recipient can be addressed in any arbitrary way impedes rapid implementation. As is so often the case, the EPC is encouraging the new service providers to take the initiative here. But many questions remain unresolved. The specification leaves questions open and relies on solutions from future suppliers which do not yet exist.

This is precisely where financial institutions have the opportunity to take active action – now! The EBA has already made a proposal that is simple and fully functional for Europe and is implementing it in infrastructure solutions. The concept is simple and based on the SEPA clearing of the European Union. In the EBA's RTP network, the debtors are unambiguously identified with their IBAN. The EBA's payments clearing system can now be used to identify and reach each financial institution of the payer. This gives European financial institutions control over mass payments and provides them with a Europe-wide alternative to the many mobile but incompatible national payment procedures on offer, in particular PayPal.

If the payer's financial institution receives an RTP, it will notify the payer about the payment request via existing online banking channels. Ideally, this is done directly via the financial institution's associated app on a mobile device. The debtor can then pay for the product immediately. However, this still requires updates to the customer systems of companies and payers.

Just like in the B2C business, RTP can also be used in the B2B business. Especially since the introduction is much easier and faster than in the consumer business. With the EBICS protocol, a huge number of companies are already using a channel that can be easily extended for RTP. In many cases, a simple configuration adjustment in the form of new order types is enough. Thus, companies can now send a payment request to another company by submitting an RTP (pain.013) order. The latter also receives the payment request via EBICS. The target address is simply the IBAN, and the rest of the process is performed electronically across Europe – via the existing EBA networks as a central clearing platform. This means that, in principle, every company and every account holder in the SEPA area can be reached. 

The associated status return messages signal the invoice issuer in a short time whether the debtor rejects or accepts the sent RTP. In the latter case, the goods can be shipped. The payment does not always have to be initiated immediately; payments at a later date are also supported by the RTP specification. In the RTP process, two different ISO XML formats (pain.013.001.07, pain.014.001.07) are used. If necessary, a recall can also be implemented. Everything can be easily transported via EBICS.

For a convenient use of RTP, the EBICS customer systems and corporate customer portals can now implement the appropriate creation and upload functions and display the status return messages in their interfaces. If there is no response from the RTP recipient, the status can be actively requested at any time. Or a recall of the RTP can be initiated (pain.056).

As existing SEPA credit transfers or instant payments can be used in the process, payments and incoming messages for accounts within the span of seconds become possible. The advantage of an RTP over a direct debit is obvious: no complex mandates need to be created or stored. In addition, payments made in this way cannot be recalled per se. For the retailer, RTP thus reduces the risk of a direct debit revocation, which otherwise exists for a few weeks.

Now is the perfect time for companies to create the right conditions for RTP. In doing so, they will be ready when consumers can use the new payment format at any time and in any place in a mobile manner.

PPI will implement the conditions for a Europe-wide success of RTP in the TRAVIC products in 2021. TRAVIC-Port will enable the creation and upload of RTP, TRAVIC-Corporate will authorise the submitter and validate the RTP order, and TRAVIC-Payment Hub with TRAVIC-Interbank will support the transfer to the EBA network. Through RTP, financial institutions can at least partially regain their formerly central role in payments, which they have lost to alternative methods such as PayPal and others.

Author: Michael Schunk

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)

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

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?

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 

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