eBAM – building block for digitisation

A crisis can also be a catalyst for progress. The current corona crisis is probably different from many others before because it forces us into the digital realm – from home schooling to the home office, the pressure is on to re-evaluate many activities regarding many aspects. Gaps are becoming apparent that were not perceived as such in an analogue world without contact limitations and other restrictions. Application processes, authorisations and releases are part of this.

And when we talk about cash management solutions here on the blog, I think the topic of bank account management is also part of it. This does not only include the exchange of messages at the customer-bank interface, but also the management of bank and account master data and their signature authorisations (not only the digital ones) as well as all related documents, the processes in the entire account life cycle and the tiresome balance confirmation. This is where all the requirements in the KYC area as well as authorisations and digital identities come into play.

These topics could have long since been moved to the digital world as part of eBAM – the electronic bank account management. Standardisation is needed here and it starts with the correct spelling. EBAM or eBAM or e-BAM?

The time has come – many building blocks are available. Some manufacturers in the area of cash management or treasury offer modules especially for the administration of data on the corporate customer side. Success stories can already be reported for the first purely digital account opening processes. There have also been encouraging developments regarding KYC and digital identities. Even the messages at the customer-bank interface in XML according to the ISO 20022 standard are in principle available. The further development of the standard is also being discussed by a working group of the CGI-MP (common global implementation – market practice) – a global initiative of corporate customers, financial institutions and manufacturers for the harmonisation of the use of ISO 20022 at the customer-bank interface. The standards are the basis for digitalisation. They create security for manufacturers and users.

In Germany, with the appendix 3 of the DFÜ agreement there has been a long-standing multi-banking tradition – i.e. one standard that reaches many financial institutions. For this, by now, optional topics can also be integrated such as the bank service billing (BSB). Not everyone needs to support the topic – but if they do, they need to comply with the standard. And I would like to plead for such an option on the subject of eBAM. For EBICS it is easy to transport the XML messages in the message group camt (account management) – the (harmonised) standards must be agreed upon. The simple use case of a signature authorisations overview shows a first step in this direction with EBICS using the order type HKD, but – see above – this is still only the start.

Of course, the customer-bank communication part of eBAM does not have to be realised via EBICS, SWIFT as a transport route is also possible. Even APIs open up many possibilities. Independent of the channel the basis should be a standardisation of the content (XML in harmony with json) and the basic processes. And for content in the XML format according to ISO 20022, a further chapter should be added to the appendix 3 of the DFÜ agreement.

On this basis, the above-mentioned manufacturers can then expand their products for "multi-banking" and financial institutions can offer new services to many customers with similar systems – enabling them to fit very well into the digital world with these services.

Author: Dr. Mario Reichel