Payments before Christmas – Christmas shopping with request to pay?

The Christmas season. Not quite as snow-white, not quite as calm and not quite as peaceful as the stories keep saying – but in its way quite charming. However, this time of year can be a little confusing, especially when the account statements show the pre-Christmas shopping adventures.

Most people will know this: The well-meaning “...but no gift-giving this year!” is even less valid than the shortly thereafter made New Year’s resolutions. And even though it feels like Christmas starts in autumn with the first gingerbread on the shelves, somehow buying the presents is always postponed until the last minute. That is exactly how this year I find myself caught in the shopping madness once more. Parents, sister, grandparents, family of the partner with five siblings – and the next generation is already at the door. Reconciling the various wish lists, shopping lists and plans with my account statements seems to be a job for Sisyphus himself.

My preferred online shops have my direct debit mandate, other digital shops accept only credit card payments, the concert tickets I paid via PayPal and the goods bought analogous and “offline” from the retailers were paid by Girocard.

Recognising all these positions on my much too long account statement reminds me that I still have to order a 3000-piece puzzle for my aunt. Has the tea set for grandma already been paid or will it still be debited? When will my telephone bill be deducted this month? That's usually around this week, isn't it? And what is that “XY shop” again, for what did they get € 90?

Like every year, I have the feeling that the shopping madness is slipping through my fingers and I lose track of things. The time lag between order and payment as well as the many different deadlines leave me with an unpleasant feeling in my stomach – especially in this time of unusual debits from my account something can quickly slip through. What use is it to me that I can reclaim a direct debit if I can no longer identify it? What credit card payment have I really authorised?

It should be easier. It should be better organised. It should be immediate. Next year around this time?
I imagine myself ordering the new radio for my mother and being asked in my banking app at the moment of ordering to release the exact amount for it. The corny Christmas sweaters with the reindeer nose are ordered in two different sizes, tried on. And at the moment of returning the much too large one, my online banking asks me whether I will release the payment for the matching sweater.

There are three packages waiting for me at the Packstation. In order to open the hatch, on request I authorise the payment. The XY shop again wants € 90? Rejected! I didn't order anything there. And my phone bill was apparently higher than usual in December and, therefore, the payment request was not automatically confirmed. I check the call statement and then authorise it manually - that's right, I called my relatives in England.

That is the request to pay. Who knows whether it will make my next Christmas calmer and more peaceful. But getting more control over my payments before they actually happen, and easing my confusion when it comes to my account, that sounds almost as nice as having a white Christmas.

Author: Anuschka Clasen

Read more

XS2A without third-party providers – well, why not?

As part of the PSD2 an interface for third-party service providers (XS2A API) was introduced across Europe. As the initiator, the EU aims to open the access to the customers' bank accounts to third parties and thus wants to promote competition in the market. By the due date on 14/09/2019 the XS2A API was put into operation by the financial institutions in Europe. Since then, market participants have been reorganising, adjusting the XS2A API to the needs of stakeholders and working intensively on services for both consumers and companies.

As a regulatory must-have, the XS2A API is initially a cost factor for financial institutions. However, value-added services have been considered right from the start and have already been specified by the Berlin Group, for example, in order to provide financial institutions with a source of income. But in the current API hype there are no limits to the fantasies about the sources of income.

So we are riding the hype wave for now and imagining the XS2A API as an alternative access channel for companies. And why not? From a technical point of view, the hurdles should be low. A company could identify itself as a third-party service provider by means of an eIDAS certificate. The certificate would only differ in the specific fields for third-party service providers. Similar to EBICS, submitted orders or enquiries can be provided with a signature which the recipient can use to check the integrity of the message. A secure transport channel is guaranteed by the use of TLS.

From a business point of view, you can use the use case "Initiate payment" to execute both individual and collective payments. For the release, consumers are offered the usual authorisation procedures known from online banking (e. g. photoTAN, pushTAN). This would probably be unsuitable for companies. Therefore, the use of corporate seals would be more likely, which has to be specified. The query of account information (balances, transactions, details) is also possible via the XS2A API. In this particular case, where a relationship of trust exists between the company and the financial institution, the consent required for this could be given via a permanently valid consent.

Seen from an average vantage point, the XS2A API would thus be a valid alternative, which is already being considered in various forums. Here, the idea is assigned attributes such as "cheaper, more convenient, real-time capable and more flexible in adjustments". However, the status quo brings us down to earth. The defining specification of the Berlin Group gives the financial institutions a lot of freedom to implement the API. In the effort to reach all financial institutions in Europe via XS2A, this freedom is currently a challenge for all market participants. A state that is not inviting for companies, not yet. However, the foundation for an alternative has been laid.


Author: Christian Wenz

Read more

Notifications for incoming SEPA instant payments – an elementary part of the payment process chain

In addition to the short duration of a final real-time credit transfer, the immediate notification of the payment recipient about received payments is a core element of the SCT Inst payment process and the associated further process steps.

What is now well feasible in online transaction processing between consumers or in the merchant-customer relationship poses challenges for the players involved in the EBICS corporate field – as described in Michael Lembcke's blog article "Real-time notifications and EBICS – no more ‘hopeful queries’ for downloads": although transaction notifications have now found their way into Appendix 3 of the DFÜ Agreement, which will be valid as of November 2019, and are specified there as camt.054 messages that can be downloaded using EBICS order type C5N, they must be actively downloaded from the bank by the payment recipient. An active push notification of the payment recipient was so far not planned. In the meantime, however, this functional gap was filled by an extension of the EBICS specification – a notification based on the WebSocket protocol that is sent from the bank server to the customer. Thus transaction information can be downloaded shortly after the corresponding payment has been received. Unsuccessful "hopeful queries" are no longer required.

As a direct notification about the payment receipt also allows for faster and more efficient overall processes in the corporate field, the time has come to take a closer look at this important function.
The starting point of our journey into the instant notification world is the globalisation of society. Almost at any time and place in the world, digital services are available: increasingly in real time – "always on, always instant". In the past, process-related waiting times due to classic payment processes (which could take several days depending on the recipient country) and slow logistical processes during the dispatch of goods were the standard. Now, the progressing digitisation enables more and more continuous process chains without media disruptions and waiting times and ensures rapid growth in the area of new digital offers.

Some of the consecutive steps of the process chain cannot be easily migrated to the instant world, as there are procedural dependencies on the non-digital domain. Other steps, however, are already available 24/7/365 in the present day – and are sometimes even finalised within a few seconds. This includes, among other things, the ordering and the subsequent payment process.

The magic word here is instant payments. Instant payments enable an immediate credit booking of the payment amount to the recipient and thus can also allow for an immediate provision of the service after payment. What works in terms of digital products is more difficult in the mail order trade sector: although it is possible to speed up the overall process through a fast payment receipt at the merchant, direct availability of the ordered goods is difficult to achieve and the customer pays in advance for a short period of time.

A purchase on account would be the least risky option from the customer's point of view. However, it carries increased risks for the merchant/supplier, as they provide services in advance and it cannot be assumed that the outstanding claim will be settled in a timely manner. Advance payment by means of classic payment methods, including cards, only leads to a reversal of the risk position, but not to an optimal risk distribution between the merchant and the buyer. At present, this circumstance can only be dealt with by an intermediary who, as an authority trusted by both the merchant and the buyer, handles the handover of the goods and the payment process at the same time. No payment – no goods; and vice versa. Classic cash on delivery process.

What is the role of the payment recipient notification in this? Without immediate notification of the beneficiary about the received payment, accelerated processes and associated innovative products based on direct payment are unthinkable. Only by means of information for the beneficiary integrated into the payment process or directly connected to it can the underlying transaction be concluded or at least the next step in the process chain be taken – whether through an online process via an API provided by the bank, or by using the EBICS channel combined with a push service.

Up to now, transaction notifications have generally been sent via intraday account information (MT942 transaction report) or in the account statement (MT940) provided with a one-day offset. It is only due to the mandatory immediate response to an instant payment receipt, which is anchored in SCT Inst, that the payment process can be fully completed. This is particularly crucial for the use of instant payments at the POS. Long waiting times until the transaction is completed would prevent customer acceptance. The benchmark for this process is the duration of a card payment.

However, immediate notification is not only relevant at the POS: existing payment methods such as settlement of invoices via instant payments in online banking or the classic cash on delivery at the front door benefit from this. In the first case, the advantage lies in an accelerated overall process for all parties involved, and in the latter it is mainly the substitution of classic payment instruments such as cash or cards.

Notifications will also play a key role in the development of future payment procedures such as Request to Pay. In this context, I would like to refer you to another EBICS blog article dealing with this topic by my colleague Eric Waller: "Request to Pay is changing payments – first use cases".

Author: René Keller

Read more

Formatting errors in EBICS orders – test services can help

EBICS has been specifically designed for secure, high-performance data transfers with files of any size between banks and corporate customers. For payment orders, the content of a file that is uploaded to the EBICS server must match the defined business transaction (order type, FileFormat parameter or BTF) and the respective format specifications. When payments are submitted, collection files with single transactions grouped by ordering party accounts are common practice. The protocol creation (HAC and PTK) for server-side EBICS processes is partly format-specific for payment orders. The authorisation checks and the protocol creation therefore require that the EBICS bank server knows and can read the submitted format at least in the relevant places (for example, ordering party account and amount). In order to read the information, the EBICS bank server performs a format check. The EBICS bank server usually aborts the check as soon as the first formatting error is detected. The order is rejected due to the formatting error and documented in the customer protocol.
Why is the file not fully checked and why are the error details not written into the customer protocol?
There are several reasons for this. First of all, the usual service agreement for e-banking via EBICS includes the upload and fast processing of correct files. Extensive format verification with an error protocol is not included and also not the core task of an EBICS bank server. Furthermore, the bank server capacities are to be used for the immediate processing of format-compliant orders and not for the analysis of incorrect files.

But how can a bank offer its corporate customers a service that increases the quality of payment orders in terms of format and content without adding unnecessary load onto the EBICS bank server?
Customers could use test services such as the ISO 20022 test platform for this purpose. As part of the harmonisation of Swiss payments, Swiss banks already offer their customers a test platform for testing incoming and outgoing payment transaction formats.

The test platform mimics the specific production conditions of the bank. It can validate XML-based customer-bank messages and simulate the bank-to-customer interface.

An extension of the ISO 20022 test platform towards payment order checks for specific formatting conventions and content can improve the quality of the file even further. A comprehensive format verification of payment orders carried out in advance enables errors to be identified quickly and easily using a detailed error log.

Files that are invalid with regard to format and content can be detected and corrected in a preliminary check by a test service before they are uploaded to the EBICS server.


Authors: Aline Wendler and Michael Lembcke

Read more

Request to Pay is changing payments – first use cases

The payment request or, in business terms, Request to Pay (R2P), is a new payment instrument that is set to change payments for the long term. In the whitepaper “Request to Pay completes the electronic payment process”, I have already explained the relation between electronic billing, instant payments and the hitherto missing payment instrument Request to Pay.

I will use this blog entry to present the first few of many use cases which can be easily addressed to an existing bank account via Request to Pay:

• Request to Pay in case of an already sent commercial invoice: an easy use case is that the invoice has already been sent in a classic way and a Request to Pay is additionally sent afterwards. This use case primarily focuses on speeding up the settlement of the due invoice by facilitating the invoice data processing for the debtor. The Request to Pay related to the invoice that the debtor has already received is displayed to him in his online or mobile banking application with the recipient data, the payment amount and the remittance information already filled out. The debtor only needs to confirm the data and sign the execution with his credentials.


• Request to Pay combined with a commercial invoice: of course, the previously described use case is also conceivable if both an electronic invoice and the associated Request to Pay are to be presented to the debtor at the same time in his online or mobile banking application. The conventional postal dispatch is thus eliminated and the debtor can view his invoice digitally and pay it in a simple manner. This method also offers the option to digitally store the invoice in a banking archive and to digitally match it with a payment at any time.


• Request to Pay in step-by-step transactions: needless to say, Request for Pay is useful for more than just scenarios with separate locations. It is thus also conceivable to digitise the previous cash on delivery method. The supplier addresses a Request to Pay message to the recipient who then verifies the product delivery and initiates an instant payments order as response to the request. The supplier is informed via a notification that the payment has been received and releases the product.


• Request to Pay in stationary trade: similar to the previously described case, Request to Pay could also be used with instant payments and notifications in stationary trade. In this case, it is not the invoice but the purchase receipt that is transported with the Request to Pay message and can be stored in a digital archive at the account together with the booking. The cashier personnel release the purchase only once the notification has come in.

As demonstrated, payment requests are applicable in many sectors and I therefore believe that the new payment instrument Request to Pay is bound to change payments as we know them on a lasting basis. I will continue to post frequent updates on current developments and additional use cases on this blog.

Author: Eric Waller

Read more

Announcement: Extension of PPI’s EBICS blog – all about payments!

Dear readers,

We are pleased to inform you today about the extension of our EBICS blog.

In the PPI EBICS blog "All about payments" we would like to keep you up-to-date about current payment trends and topics concerning EBICS, SEPA, SWIFT, regulation and digitisation.

From now on the EBICS blog is maintained by two teams of authors in a 2-week rhythm. Our goal: to give you a first-hand account of the views and experiences of our product and consulting experts from customer projects, studies and white papers with regard to current and future requirements of the payments market.

We look forward to your feedback and hope you enjoy reading this blog!

Your team of authors at PPI

Read more

Real-time notifications and EBICS – no more "hopeful queries" for downloads

As I already wrote in my blog post in December 2018, real-time credit transfers (instant payments) in the corporate customer business are making their way into the world of EBICS via the new bulk format. When uploading real-time credit transfers, the EBICS transfer phase is not subject to the strict synchronous time rules of instant payments. The clock starts ticking only after the EBICS bank server processing.

But what about the opposite direction for instant payments business transactions in EBICS? After all, a credit notification, if not possible in real time, should still be sent to the payment recipient as soon as possible. In the standard role relationship between customer and bank, the EBICS client always downloads the information from the bank server. An active provision by the bank via EBICS is not intended. Especially the business community has urged the banks and the German Banking Industry Committee (Deutsche Kreditwirtschaft) to find a pragmatic solution for a push option. The ultimate goal was to develop a solution that could be implemented without the need to change the EBICS protocol and the role concept.

The result was the idea to create a new web socket-based standard interface that informs EBICS clients when new information is available for download. This also includes information about a newly available credit notification. This new push channel is thus not used to transfer any sensitive data. The download of the relevant sensitive data is still carried out via the secure EBICS channel.

In the meantime, the Deutsche Kreditwirtschaft has described this new interface in the "Spezifikation Echtzeitbenachrichtigungen" (specification for real-time notifications) and published version 1.0 on July 18, 2019 on the German EBICS website (www.ebics.de).

Now the interface must be implemented in the EBICS clients and EBICS servers in a standard-compliant and timely manner. This development opens up new possibilities for optimising corporate customer business, even independently of instant payments. For example, the frequent and ongoing "hopeful queries" by automated EBICS clients (as performed in case of account statement downloads) can be eliminated for all download processes. This means that both EBICS client users and bank server operators can expect a load reduction. That's good news, isn't it?


Author: Michael Lembcke

Read more

Is the EBICS protocol exempt from strong authentication (SCA) in line with PSD2?

We have been asked this question repeatedly by French and European financial institutions and it has not always been easy to give a sufficiently formal answer.

Recently, the Banque de France wrote an official reply in which it added the EBICS protocol to the list of procedures and protocols exempt from strong authentication under Article 17 of the delegated regulation (UE) 2018/389. The regulation states that: "For legal entities initiating electronic payment transactions through dedicated payment processes or protocols that are available only to payers who are not consumers, payment service providers may waive the requirement of strong customer authentication where the competent authorities consider that such processes or protocols provide at least a level of security comparable to that provided for in the directive (EU) 2015/2366."

The full text can be found on the following page: https://www.banque-france.fr/stabilite-financiere/securite-des-moyens-de-paiement-scripturaux/2eme-directive-sur-les-services-de-paiement
However, this does not mean that EBICS does not support strong authentication - far from it! The certainty that the EBICS protocol guarantees at least comparable levels of security to those provided for in the directive has long been established. With this in mind, I would like to invite you to read or re-read the article EBICS and PSD2 – How do they work together? published on this blog a few months ago.

Author: Marc Dutech

Read more

Verifying the hash value of the bank keys in the EBICS initialisation request

EBICS transactions are divided into different phases: initialisation, data transfer and acknowledgement (the latter only for download transactions).

The scope of the initialisation includes, among other things, checks of the following aspects:

- Order type

- Authentication signature

- Hash values of the bank keys

- User-related authorisations

Only once the initialisation is successfully completed does the transaction continue with the transfer phase, during which the actual order data is sent. The hash values of the bank keys are checked during initialisation to ensure that the client uses the current bank keys. If the check is not successful, the server sends the return code EBICS_BANK_PUBKEY_UPDATE_REQUIRED. For the client, this indicates that the most recent bank keys should be downloaded by means of the order type HPB.

Before the EBICS 3.0 harmonisation, the bank keys could be used directly or within certificates. As per EBICS specification, up to EBICS 3.0 the hash values of the public bank keys must be specified in the transaction initialisation – irrespective of whether it is certificates or keys that are exchanged with the bank.

As of EBICS 3.0, certificates are mandatory for key management. In this context it was decided that both for uploads and for downloads, the hash values of the certificates will have to be specified in EBICS initialisation requests in the future.

Usually the manufacturers of EBICS bank servers enable their customers to have a gradual transition by allowing them to specify both the bank keys and the certificates in DER format. This means that customers do not have to perform a download via the order type HPB after the migration to EBICS 3.0. Both keys and certificates can be specified either in a specification compliant hex layout or in an alternative Base64 layout. A mixture of both layouts in one request is usually not intended.

By the way: with EBICS 3.0, the key management has been unified not only for bank keys, but also for user keys. It is thus now mandatory to initialise users with certificates not only in France (CFONB), but in all countries. Usually EBICS bank servers allow for a gradual transition in this aspect, as well. User keys with a minimum length of 2.048 bits can also be used for EBICS 3.0. For key updates (order types HCA, HCS and PUB) new certificates can usually be signed with the keys of older EBICS versions.
CA-based certificates are still only used in France. From the bank server perspective, however, nothing should stand in the way of introducing them in other countries.


Author: Hendrik Chlosta

Read more

gpi and EBICS – how do they work together?

Isn't gpi purely a SWIFT topic? At first glance it might be. The abbreviation originates from SWIFT and means "Global Payments Innovation". The gpi initiative was launched at the end of 2015 and was already broadly supported by many global financial institutions.

gpi is based on the unique end-to-end transaction reference (abbr. UETR), which accompanies a payment throughout the sometimes long correspondence bank chain. The reference may be a monstrosity of 36 characters in a format defined by a universal algorithm (xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx), but that monstrosity ensures an end-to-end uniqueness without an "issuing authority". Though initially, the UETR was only used in a CUG (closed user group) for (corporate) customer payments in MT103 messages, by now all payments in the FIN network have such a reference – a reference that remains unchanged throughout the entire payment process chain.

The second substantial part of gpi is the so-called Tracker. The Tracker is a central database for all gpi payments and is hosted at SWIFT. It provides the participating banks with comprehensive information on the status of payments in the correspondent bank chain, on fees and on currency conversion rates. While the FIN transport reads this information directly from the transported messages, non-FIN banks can also actively inform the Tracker. Currently under discussion is the so-called confirmation – a notification on the credit arriving in the beneficiary's account at the end of the payment process chain. As of 2020, all FIN banks shall be obligated to use the confirmation.

But why all this effort? gpi tackles the two core challenges in correspondent banking – transparency and speed. The extensive use of the UETR has yielded statistical data: on average, 40 percent of the gpi credit transfers are booked on the account of the end beneficiary within five minutes, 50 percent within 30 minutes, 75 percent within six hours, and almost all of them within 24 hours. Such a statement was simply impossible to make before gpi. On the contrary, all treasurers have experienced cases of payments arriving too late or not at all, with high, inexplicable fees, and with unclear or missing purpose information.

In addition to technical details such the UETR and Tracker, gpi provides a rulebook that stipulates the preferably same-day forwarding of a payment with complete remittance information and specification of deducted fees and currency conversion details. As there is no global transparency guideline, these stipulations have to be enforced on the basis of multi-lateral contracts. And that is a good thing – it's about time.

The (corporate) customer shall receive better service in cross-border payments. Aside from speed and transparency, another aspect is the acknowledgement. Acknowledgements, or receipts, have so far been used in cash transactions only. In electronic payments, the motto was mostly "shoot and forget". If no complaints come in, the money must have reached its destination. Recent years have seen a remarkable development in the SEPA, and with instant payments according to the SCTinst scheme, electronic payments now have acknowledgements, too. With SWIFT gpi, such an acknowledgement can also be generated, even if it (still) requires a complete FIN chain in the settlement process. However, there is a long way left to go: so far, the broad, bank-internal implementations have been in the focus. The connection of customer systems for access to the information or even for forwarding of statuses and fee information to the customer system is still in its early stages. But alone the possibility to check on a payment's status via a central database in case of doubts shows considerable progress in the vast correspondent bank network.

Is this potential only applicable to FIN? Not at all. Current developments, e.g. the migration of real-time gross settlement systems (RTGS) such as TARGET2, EURO1 or CHAPS from MT to XML messages according to the ISO 20022 standard, are going in this direction. The (newer) ISO message formats contain dedicated fields for the UETR, meaning that the reference is transferred outside the FIN network, as well. Just recently, SWIFT made an announcement: "SWIFT trials instant cross-border gpi payments through TIPS"[1].

For the connection of gpi return messages to customer systems such as TMS or ERP, PSR messages (payment status reports, i.e. pain.002) are more efficient than manual processes. These self-services alone are already a significant step towards more transparency. By the way, the standards for these return messages, i.e. fields (tags) and codes, were made multi-bank compatible in the harmonisation initiative CGI-MP. PPI is now also actively partaking in this initiative.

Furthermore, the customers shall be enabled to initiate their reference in the payment as UETR – in the pain.001.001.03 within special fields according to the CGI-MP, or even in more current ISO versions within dedicated fields.

This customer-bank or bank-customer interface is where both customer payments and PSR return messages are often also transferred via EBICS. Which means that gpi and EBICS do not contradict each other, but are rather complementary concepts – as is often the case in payments.

Author: Dr. Mario Reichel

[1] Source: https://www.swift.com/news-events/press-releases/swift-trials-instant-cross-border-gpi-payments-through-tipshttps://www.swift.com/news-events/press-releases/swift-trials-instant-cross-border-gpi-payments-through-tips

Read more

EBICS tests with customers in a productive bank server?

As of EBICS 2.4, in France it is possible to not use the business transactions with 3-character order types that are customary in Germany and other countries, but to instead exchange FileFormat parameters of up to 40 characters. These must each be introduced with the FUL or FDL order types. Here, it is possible to specify a so-called test flag. Using this flag, during the productive operation, an EBICS customer can make a test submission and signal this to the financial institution, for example when sending a file. Provided that there is a bilateral agreement on the use of the test flag, the financial institution may accept the order, classify it as a test case and separate it prior to the actual processing. The use of a test flag in the running operation is not uncontroversial to the financial institutions. Presently, the German financial institutions mainly reject such an option.

With the current EBICS version 3.0 and the unified use of BTFs instead of order types and FileFormat parameters the existing test flag is omitted in the EBICS specification. In addition, with the EBICS CR EB-17-01 Element Group Parameter a stricter check of the use of not bilaterally agreed upon specifications in the generic parameters of the BTF has been introduced. Specifications that are not permitted are now rejected with the EBICS return code 09-0-0-06: EBICS_UNSUPPORTED_REQUEST_FOR_ORDER_INSTANCE.

To assist with the introduction of EBICS 3.0 in France, the French CFONB has created their own migration guidelines (EBICS 3.0 Aide à la migration BTF & Table de correspondance File Format/BTF). Since in France the test flag has been used by financial institutions in the past and there will continue to be a need for such an option in the future, for the BTF migration the CFONB has defined the use of the test mode for BTF and added it as an optional feature in the guidelines. Therefore, in the case of bilateral agreements between the financial institution and the customer even for BTF the parameter TEST can be used in test cases. If the specification of the parameters differs, a rejection occurs with the return code mentioned above. EBICS bank servers and EBICS clients can optionally offer this functionality.

Independent from this, for EBICS there is also the alternative to use business transactions (BTFs) that have been especially agreed upon bilaterally for the test submissions.

In the end, however, it must be noted that when using the test option in the production environment there is always a risk that the test data may negatively affect the production or even unexpectedly be introduced into the production data.

The more secure option then remains to have an own EBICS bank server installation for EBICS tests with customers. And why not?


Author: Michael Lembcke

Read more

Standardisation and automation in external asset manager relations thanks to EBICS

External asset managers (EAMs) offer their wealthy private customers or institutional customers such as pension funds and insurance companies a multitude of services (for example, tax and real estate consulting as well as trading and investment transactions). The customer accounts are usually held at one or more custodian banks. Interactions with the financial institutions are often neither standardised nor automated. Communication by mail, telephone, e-mail and sometimes even fax dominates everyday business.

Few big asset managers have a SWIFT connection and are using it for treasury and foreign currency transactions (message category 3), securities transactions (message category 5), precious metal transactions (message category 6) or cash management transactions (message category 9). Some have implemented proprietary system-to-system connections, for example via FTP, to exchange financial messages. In Switzerland we are currently observing a trend towards EBICS as an alternative connection type for these use cases.

During the PPI Petit Déjeuner in April 2019 in Lausanne, a representative of Credit Suisse presented the offer "Private swift Network (PsN)". It deals with the extension of the EBICS service scope in the sense that about 20 new EBICS order types (reports for download) based on the EAM use cases mentioned above are available. Thanks to their cooperation with leading software manufacturers of portfolio management systems (such as Allocare or Expersoft), Credit Suisse achieves a significantly higher level of standardisation and automation when interacting with their partners. In concrete terms, the SWIFT messages of the above message categories can now also be transferred via EBICS.

As the EBICS protocol is flexible with regard to the content transferred, Credit Suisse additionally offers other formats like CSV or XML for reporting on the transactions and assets, including the master data of the respective customer depositories. All players stand to profit from the new offer: asset managers can connect more financial institutions via EBICS at low cost and automate their processes, software manufacturers can effectively extend their functional scope, and financial institutions can boost their appeal for EAMs. Viewed across all parties and processes, the error rate decreases and the implementation speed increases through elimination of manual operations.

Swiss financial institutions that are currently implementing projects in this area are already planning the next steps of the EBICS offer extension. In addition to the reporting functions (EBICS download), the order functions (EBICS upload) shall also be offered in the future. Especially orders in the trading business (SWIFT message category 5) are well-suited for uploads via EBICS. Particularly stock exchange orders (like SWIFT MT502) shall be transmitted from the asset manager to the financial institution. In the same way as the known payment order interfaces, the stock exchange interfaces are connected on bank side. The use of an EDS is also conceivable in this context.

In conclusion:

The first financial institutions in Switzerland are extending their EBICS offer beyond the use cases of payments. The Credit Suisse offer for medium and larger asset managers paves the way for EBICS in the EAM customer market and will likely prompt others to follow suit. Software manufacturers of portfolio management systems are slowly but surely learning to understand the EBICS protocol and extending their connectivity options with this connection type. When it comes to formats and standards that may be transferred via EBICS in the future, there are no limits to the possibilities. It is safe to say that for a certain customer segment, EBICS presents a viable alternative to the communication via SWIFT even in domains outside of payments.

Carsten Miehling

Read more

You are a bank customer and you are using EBICS: Will your EBICS monitoring still work with EBICS 3.0?

Since EBICS 2.5, EBICS clients cannot only use the purely text-based customer protocol but also an XML-based customer protocol for monitoring EBICS processes and results. The XML-based customer protocol is particularly suitable for automated evaluations. For downloading the protocol from the EBICS server, the EBICS client can use the order type PTK for the text-based protocol and the order type HAC for the XML-based protocol. With EBICS 3.0, the text-based protocol is no longer part of the specification. Moreover, changes of the HAC protocol have to be considered during automated result evaluation. Due to the required overall version interoperability, these changes partly affect EBICS clients of previous EBICS versions too, if an EBICS bank server supports EBICS 3.0.

Hence, software manufacturers and EBICS users must be prepared for changes of EBICS clients that already provide functions for the automated customer protocol evaluation. First, a change from PTK to HAC should be performed for automated evaluations in EBICS clients. Furthermore, users of the HAC protocol must be aware that with EBICS 3.0 the final HAC protocol is displayed differently.

Up to now, the HAC end flag with the identifiers ORDER_HAC_FINAL_POS and ORDER_HAC_FINAL_NEG has provided information on whether the submission was positive or negative. With EBICS 3.0, only the HAC end flag ORDER_HAC_FINAL is still available which informs on the submission’s result in conjunction with the last reasons code only. The final code DS04, for example, stands for the order’s rejection whereas code DS05 proves that the order was successfully submitted and forwarded to the bank system. Further reason codes have to be considered.

To make sure that your EBICS monitoring will still provide the correct results, I recommend to rely on the HAC customer protocol and to focus on the evaluation of the reason codes. This way, you can easily keep track of the EBICS communication with your financial institution.

Michael Lembcke

Read more

Migration to EBICS 3.0 in France

EBICS 3.0 entered into force in France on 27 November last year. A good two months have passed since then and we think this is a good time to assess the progress of the migration to the new version.

The aim of this new version is to harmonise EBICS and thus ensure the following: 

• a uniform EBICS version in all countries in which EBICS is used
• uniform identification of BTF (Business Transaction Formats)
• a uniform X.509 format for filing the key

The date of entry into force only applies to French financial institutions and is not mandatory for corporate customers. The latter can decide for themselves when they would like to migrate.

The big French financial institutions have been working on the migration projects for several months and most of them are now able to offer their customers the EBICS 3.0 channel. The others are in the final testing phase and will soon be opening the EBICS 3.0 channel.

The smaller financial institutions have not reached this stage yet. Only a few have started their migration projects and much suggests that they will only be able to offer the EBICS 3.0 channel in a few months' time, possibly even in 2020.

However, these differences in time implementation should not pose a hindrance to corporate customers keen to migrate to EBICS 3.0 in the near future. For in a transition phase of some length, even financial institutions that have already migrated to EBICS 3.0 will continue to support the 2.4.2 version that has been in force since EBICS was introduced in France (version 2.5 is currently used in Germany). This transition phase will give corporate customers time to update their client software.

Due, however, to a lack of interest in the new version, particularly on the part of corporate customers, the transition phase could drag on. To prevent this from happening, the financial institutions can offer their corporate customers additional services that will become possible with the extensions of the new version. These include simpler setup of transfers and the electronic distributed signature. The latter allows corporate customers to sign orders asynchronously after file transfer (in version 2.4.2, the electronic signature had to be sent together with the order file), thereby offering them greater mobility.

The impact of this will be particularly felt when the X.509 certificates are completely virtual and the mobile signature can really be used. Experts are working on this subject and efficient solutions can therefore be expected in a few months...

Marc Dutech 

Read more

How EBICS can be improved (Part 10) - EBICS downloads based on date and time specifications

In payments, it is becoming increasingly important for bank customers to be kept up to date on intraday payment movements, especially since the introduction of new procedures such as instant payments. This development also poses new challenges for the EBICS standard in the corporate customer business. EBICS customers usually have to actively retrieve information on payment movements from the bank server. The so-called historical download with date specification is the suitable method, especially for corporate customers using several EBICS clients. As, however, the historical download through EBICS is only specified to the day, in practice large volumes of data are downloaded several times intraday. Moreover, business timestamps for EBICS depend on the provision format and are therefore at best specified to the day and at worst simply not available on the bank server. The downloading clients then have the task of automatically filtering the redundantly downloaded data. Such behaviour currently places significant additional burdens on all systems involved, both on the part of the customers as well as the banks.

This situation could be remedied by extending the EBICS specification by defining specified time-controlled downloads.

In this case, the EBICS server would support an additional variant of the historical download. Unlike the previous standardised historical EBICS download, the time would now also be taken into account for the start and end times. Moreover, the stated times and dates should always refer to the time and date of provision. This would enable the EBICS server to deliver all data records that had been provided within the specified time period. For more flexible handling, it should also be permissible when making download requests to specify in each case only one of both times and dates. Otherwise, the download would behave in the same way as the previous standard download in the acknowledgement phase.

I think specifying such a uniform solution for all EBICS users in the EBICS standard could refine the download process for EBICS, reduce the burden on servers and significantly improve the process, especially given the growing need to be kept up to date. This would make the proprietary solutions already used in EBICS products superfluous.


Michael Lembcke

Read more

EBICS and the API discussions – a status update from Switzerland

Since SIX Interbank Clearing (SIC) became an official member of the EBICS SCRL as a representative of the Swiss financial market in spring 2015, a lot has happened with regard to corporate communication interfaces for banks. Considering the growing commotion in the area of electronic interfaces, the time seems right for this blog to take a closer look at the current situation.


Naturally, such an exploration must also broach the subject of APIs (application programming interfaces) – an acronym that is being proclaimed as the great salvation of digitalisation strategy in some bank management circles. Do APIs, particularly those for account information and payment order services, have the potential to render long-serving file transfer protocols like EBICS obsolete? This question especially arises when taking into account that start-up and fintech companies tend to prefer these streamlined APIs to the rather complex implementation process of EBICS.


To find an answer with regard to Switzerland, the reader less familiar with the Swiss financial market needs up-to-date background information. First of all, we should keep in mind that Switzerland is not a member of the EU and as such is in no way bound by the PSD2 (second payment services directive). This means that financial institutions are not obligated to offer APIs, which eliminates one major driving force. Unlike FinTS in Germany, there is also no standardised online banking interface in Switzerland. Nonetheless, the good news coming from the European Union has been heard in Switzerland, as well.


Before diving deeper into the hot topic of API initiatives, let us once again acknowledge how widely the use of EBICS has spread. In the past five years, following the example of the German implementation, the EBICS protocol has made its way into all larger institutions as a standard service offer for electronic data exchange with corporate customers. The ability of the protocol to transfer very large volumes and, more recently, the use of the EDS (electronic distributed signature) are highly appreciated by medium-sized and large corporate customers. All notable Swiss software providers with electronic banking solutions have made EBICS part of their product offer.


So far, so good, one might think. As mentioned before, the API discussion in Switzerland is in equally full swing. There are currently two initiatives worth noting, which we will briefly discuss in a moment. To be clear upfront, the author does not consider these initiatives a replacement for EBICS, but rather an additional option in the range of bank interfaces that is suited for a specific customer segment (usually smaller corporate customers that use cloud solutions for bilateral data exchange with financial institutions).


A highly promising initiative appears to be "Corporate API" by SIX and the Swiss financial institutions. The name refers not only to a freely accessible standard, but also to a suitable platform for that standard. Both are being developed by SIX in collaboration with representatives of financial institutions and software providers. The platform enables easy participation in a newly unfolding ecosystem that is set to provide services far beyond the PSD2 scope (AIS, PIS).


The formats offered by "Corporate API" are JSON and ISO 20022 XML. The JSON variant will be extremely easy and fast to implement and is intended for software providers who do not require the complexity of ISO 20022 messages. The ISO 20022 XML variant supports the entire spectrum of possibilities known from the CH payments migration. The end of 2018 will already see the first tests with piloting financial institutions and providers.


Another current project is called "Common API". The "Common API" by SFTI (Swiss Fintech Innovations) is based more heavily on the PSD2 and the implementation of the Berlin Group. In contrast to the "Corporate API", the specification of the SFTI defines the API in more general terms and leaves the selection of the target group to the service provider. According to information by SFTI, the big banking application providers are involved in the development of this standard. SIX has accompanied the development process of the SFTI specification from the beginning and will carry forward the results of the SFTI working group in the future. It is hence entirely possible that the two standards will turn out to be at least partly compatible.


The situation for software developers in Switzerland is not exactly simple, with EBICS as an established productive protocol on the one hand and new initiatives waiting in the wings on the other. Depending on the customer segment and the business model, solution providers are faced with the question which implementation they should offer – or whether perhaps it should be more than one. What's more, some financial institutions have by now released proprietary interfaces (such as the Hypothekarbank Lenzburg, which presents itself as a highly innovative fintech bank). If the application area is extended to Europe, already well-known initiatives like "Berlin Group", "STET" or "Open Banking" are added to the mix. As to be expected, the Swiss financial market has not adopted any of the existing standards, the "Swiss finish" remaining rather popular in these parts.


Carsten Miehling

 

Read more