Uninterrupted payments – who doesn't want that?

Some software systems are so critical that the absolutely highest demands on their availability must be met. Admittedly, in the financial sector, the matter is not one of life or death. But the requirements for real-time payments or authorisation processes are constantly increasing and maintenance windows in particular are no longer acceptable. And rightly so: if a maintenance window causes you to get the account statement an hour later or the portal is not accessible for an hour, it may be annoying but not too much of a loss. However, if the bank customer suddenly can no longer pay at the point of sale or cannot authorise a payment in real time, the unavailability becomes extremely relevant.

Therefore, after the authorisation process for card payments, the introduction of instant payments in Europe has made real-time credit transfers an application field for interruption-free systems as well.
Let us first discuss freedom from interruptions. Uninterrupted operation is defined by two different characteristics:

  1. Avoidance of planned unavailability
    The system is permanently operational during normal operation. It has no periodic times of limited functionality such as end of day or reorganisation.
    The system is designed so that even release changes can be carried out during operation without causing downtime.
  2. Reduction of unplanned unavailability
    The system is highly available even in error scenarios. The probability of guaranteed operation is therefore high despite failure of individual components. This probability is calculated or measured as the ratio of production time to runtime, i.e. the time including the downtime, for example 99.99 percent.
    Robustness in overload scenarios is of particular interest here. Although every system has its limits, it does make a difference whether everything collapses beyond the load limit or whether only the additional load cannot be processed as per specifications.

The enthusiasm for the topic usually drops considerably when looking at the costs. It is therefore worthwhile to find architectural solutions and not just shift everything onto the infrastructure. However, even the best software will only work if the system environment is available. I won't to go into more detail on high-availability infrastructure, operating systems, database systems and message brokers – all of which are prerequisites for an uninterrupted overall system. Instead I would like to focus on the software architecture. This can enable the targeted implementation of availability requirements while keeping costs under control.

Since high availability is expensive, the critical processes must first be identified. Therefore we must answer the question which processes must really work all the time and which can be made up for later. In real-time payments, for example, bulk processes are less critical than individual payments.

If large components fall under the critical processes, it should be analysed whether they can be bridged. Can an alternate component replace the critical tasks of a large non-highly available component for the downtime period? In payments, for example, the booking system can be such a large, non-highly available system and the online balance check can be the critical process that must be bridged.

Of course, payments processing as a whole does not work without statuses: unfortunately, money can only be spent once, so the account balance is a relevant status and a banking software must of course be able to accurately reflect this. In our case, this always leads to the use of databases and the need for persistence before and after each relevant status change. It is the design of the database model that determines whether or not we achieve our goal. Highly available processes should work with stable and/or migration-free data structures. This is the only way to avoid the need to shut down critical processes to change the database schema.

The remaining topic is robustness. Science also refers to resilience when describing that disruptions or partial failures of technical systems do not lead to complete failure. In payments, such disruptions can be peaks in the load above agreed limits or surrounding systems that do not respond as quickly as agreed. Downtime of business partner systems and missing acknowledgements of large amounts can also cause failures. In reactive programming, we have found a paradigm that allows for the desired robustness through orientation based on data flows. An overload can thus be encapsulated within affected areas and nothing stands in the way of uninterrupted operation for the remaining data – in our case payments.


Author: Thomas Riedel

The European retail payments strategy – a small reminder of what’s to come

Most of us should have heard it: those interested in payments were not able to miss the European retail payments strategy (RPS) that the EU Commission published on 24/09/2020 and that details the framework conditions for the future orientation of payments in Europe. The paper is worth a read and contains specific recommendations for action and ideas. Of course, a strategy is not yet a law. It is not yet a matter of concrete regulations or implementation dates. However, one can predict which changes will become relevant for payments sooner or later. Specifically, it is about the next 2-4 years.
The retail payments strategy comprises four pillars with 17 measures:

The first pillar deals with digital and instant payment procedures. Here, one aspect is of particular importance. If the circulation of instant payments (SCT Inst) is not sufficient across Europe by the end of 2021 (which is the current trend), there will be a legal obligation to provide and accept SCT Inst. However, the EU Commission would like to see an "SCT Inst return option" to give consumers similar rights to a credit card payment (chargeback) when they make a transfer. There will also be a European standard for the use and acceptance of payments by means of QR code, and a digital identity will be promoted. The acceptance of cashless payments is also to be expanded.

The second pillar is about an innovative and competitive payment market. Here, an important aspect that needs to be mentioned is the PSD2. Two years after the last amendments came into force, the hoped-for success is not yet fully visible. Various interpretations form a multitude of obstacles that also exist within individual countries. A review of the current implementation is planned by the end of 2021. The results and experiences are to be incorporated into a proposal for an open banking framework by mid-2022. Whether this will then be called PSD3 or given another name will not be decisive.

The third pillar is about efficient and interoperable payment systems. Here, the focus is on the technical infrastructure that should be available across Europe. Cross-border European payments, including from member states with different national currencies, should be possible in real time.

The fourth pillar comprises efficient international payments. Efficient payments include the traceability of payments that is already being implemented with SWIFT gpi. The use of standardised and modern formats also contributes to this and is already being promoted by the worldwide transition to ISO 20022. Payments to third countries should generally be made faster and more comfortable.

It remains exciting to see which concrete measures will follow. We all know that regulation can never keep up with market developments. When the PSD2 was adopted, for example, hardly anyone had any idea of the diversity that biometrics, voice assistants and paying items (rings, watches, bracelets) would already occupy in everyday life. The legislator can only control the market by means of framework conditions. The retail payments strategy does present some interesting framework conditions, more on its content will follow soon.

The original EU retail payments strategy can be found here:
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52020DC0592

Author: Swaantje Anneke Völkel

The digital euro should be like cash: secure and anonymous

Why do consumers use notes and coins to pay? Cash primarily ensures anonymity and privacy during the payment process. In Germany in particular, cash is of great importance as a means of payment, not least because of these core characteristics. However, the corona virus crisis has led to a shift in payment habits: contactless payments are experiencing a real boom. In its latest publication "Report on a digital euro" the ECB emphasized that although cash is, in Germany, still the most widely used means of payment, there is a clear trend towards more use of digital and innovative forms of payment. This change in payment behaviour can be seen not only in Germany, but across Europe. 

Digitisation needs digital money

The euro area must be prepared for the future and be able to react to short-term changes. The introduction of a “central bank digital currency” (CBDC) could be an important stepping stone to take digitisation and innovation in the European society to a new level. The ECB defines this digital euro as an electronic representation of central bank money that is to be made available to both citizens and businesses. Cash is supplemented by the CBDC as a further means of payment.

The design is still to be specified

The ECB has not yet decided on the design. In addition to considering which models are possible, the ECB has defined its (key) requirements for such a CBDC in the above-mentioned report. In the report, the ECB describes the conditions under which the introduction of a digital euro is necessary and the possible approaches to its design.

Feedback wanted

Broad acceptance of the digital euro is essential. In order to assess how the CBDC should be designed and which use cases are best suited, the ECB has sought public opinion on a digital central bank currency in Europe through an online consultation. Citizens, institutions and experts had the opportunity to submit their views and proposals for solutions. The feedback was enormous and shows the great interest in the topic: more than 8,000 responses were received by the ECB, and the first results have already been published. Accordingly, more than one in three of the participants demand a digital euro that protects the privacy of payment transactions. There is also a strong desire for security and a pan-European reach in a CBDC. It should therefore reflect the core characteristics of cash payments.

Decision by mid-year

Further results of the survey will follow in spring. On their basis and the results from the previous internal investigation phase, the ECB intends to make decisions by 2021 on the start of the digital euro project.

In an online interview on "Reuters Next," ECB President Christine Lagarde said she expects the digital euro to be introduced in the coming years, therefore, the new currency could soon be a reality.

Further information:

European Central Bank: Report on a digital euro, Brussels, October 2020

European Central Bank: ECB digital euro consultation ends with record level of public feedback, 13/01/2021

Author: Anja Kamping

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