By Emmanuel de Rességuier, CEO Fennech Financial Ltd
1/ Innovation in banking: misalignment between offering and needs
I recently met Dan*, a Treasurer of a UK based insurance company and former client, who told me:
“we had our main Euro-zone bank in last week and they pitched me virtual accounts. Honestly, they are completely missing the point”. As I asked why, he said: “Many banks are presenting us so-called innovations, like virtual accounts, yet they don’t understand that implementing such a solution means putting in place another process on top of already too many other processes. We work with more than 30 banks and our base line is not set by the capabilities of the top three, but of the bottom three. We can’t afford to deploy as many different processes as we have banking relationships”.
A fair point from a Treasury practitioner, which demonstrates how little banks sometimes understand the real needs of their clients, and what Banks call “innovations“ are not always straightforward to implement.
This echoed feedback I’ve heard from other experts in conferences, panel discussions or other Association of Corporate Treasurers meetings, who expressed a great deal of scepticism towards virtual accounts, a supposedly miraculous technology. The loudest complaints I have heard from Treasurers in relation to virtual accounts are from those who were sold a solution to work alongside a direct debit collection service. They quickly realised that with the correct referencing in the direct debit messages, there is no additional benefit to using virtual accounts - and the banks charge a lot for that service.
2/ Taxonomy, let’s use the right terminology
I remember that I explained to my team - while I still was working in Banking - that they should be very cautious in the way they were using the terminology “virtual accounts”, as the reality is very different from one bank to the other, from one software provider to the other. Those two words are often misleading for so many people.
Most of the time, the virtual accounts offered by banks are simply virtual IBANs, i.e. numbering extensions of the bank account number, given to payers for easier identification of incoming flows. This has some value in itself, I won’t deny it. It is a robust unique identifier that allows the corporates to sort out transactions credited on their bank account.
But is that really what a virtual account is all about? I do not think so.
Let’s then use different terms for “virtual IBAN” and “Virtual Accounts Management” (VAM).
To be very clear, at Fennech Financial we offer what we call a virtualised (or digital) cash ledger, a robust solution that overcomes the drawbacks of those solutions.
3/ What should it be ?
Ideally, the following functionalities are expected from a serious Virtual Account Management platform:
4/ A multiplicity of different, not harmonised services
Behind a single denomination “Virtual Accounts Management” or VAM, corporates will find very different realities, and different services, sometimes even within the same global bank.
The mistake is to believe, or let people believe, that a virtual account is exactly the same as a true bank account, with the same capabilities but with more flexibility and less constraints. My view is that it simply is not. Let me list a few ideas to prove my point.
So called Virtual Accounts may
· Work only with some currencies. Typically, EURO for European banks, and potentially a few other major currencies.
· Be available only in some locations, even with the largest transaction banks.
· Be linked to some payment systems only. So, these accounts might be reachable via ACH, but not wires, nor instant payments.
· Might not even be able to be individually debited for outgoing payments which may only take place on the master account.
· Only allow incoming transfers. They won’t work for direct debits collection, won’t work for direct debits initiated by your creditors (since they won’t have a mandate for that account), won’t work for cheques or any other local payment types.
· Not have specific user rights or sets of limits.
· Not allow interoperability with other banks, for instance in overlay liquidity management structures, or provide multi-bank reporting.
· Not be linked to EBAM, Swift GPI, TWIST, or to the tax authorities.
· And finally depend on the payors’ willingness to use them. That can be a significant issue when a company asks their existing customers to update the bank account number recorded in their ERP, they rarely do so.
To add to the concerns raised above, what about the hesitations of some Banks to support true “on-behalf of” structures, due to their fear of processing illegal or undue transactions without sufficient supporting documentation (which often arises as a consequence of the implementation of a virtual account structure itself).
5/ And what about bank agnostic offerings from Treasury Management System or other Software providers?
These providers present an advantage vs any bank offering in the sense that they allow a more harmonised approach, often thanks to a unified multi bank linkage. But here again, the reality behind the scenes can be quite different than that which the internet sites and other white papers would suggest.
On a third-party non-banking platform, what is the advantage of either duplicating the virtual IBAN cash allocation already provided by banks, or semi-manually allocating the other transactions? The manual workload then completely offsets the expected benefits.
At one of my previous employers a few years ago, we tried to use one of those supposedly non-bank comprehensive virtual account platforms as the front end of a settlement system we were building. We quickly discovered that this highly regarded platform was in fact an old core banking account maintenance system revisited and implemented outside of a Bank. It required our back-office people 25 minutes on average to open each virtual account before being able to book any transaction. This was so far from being a scalable solution that eventually we were forced to revisit the architecture of the entire service and move away from this platform.
6/ It’s not only a question of system, but of data, processes, automation and scalability
I have also experienced several times within different banks the fact that their virtual IBAN offering was implemented as a new independent system, poorly integrated with the remainder of the core banking and payment systems. As a result, back office people had to manually recapture virtual IBANs or payer IDs in several systems, which meant the solution was not scalable.
All those systems, either sourced from banks or software providers, are most of the time very average in automating reconciling a cash movement to a transaction in an AP or AR ledger, and more importantly very poor in allocating the cash to a counterparty or client. They mostly rely exclusively on one Payer ID and on the information provided on the bank account statement. We all know that the amount of information provided there can be of poor quality (how many CAMT53 - account statement files in XML format - are still fed by legacy reporting systems only able to populate the famous 4 lines of 40 characters from the old SWIFT MT 940 message?). Garbage in, garbage out!
In some industries like insurance, we still see hundreds of people in the back-office, in accounting and settlement teams, manually populating cash allocation information based on contractual documents, or having to source additional information from multiple business applications, paper documents, emails, or even relying on calls to their brokers.
Real efficiency in deploying a true and comprehensive virtual account platform lies in the digitalisation of the underlying contractual documents (contracts, invoices, notes or bordereaux…) as the golden source of data, and then implementing smart, efficient and scalable real-time reconciliation and cash allocation processes that take into consideration multiple criteria instead of only one. Combine this capability with a high performing layer of machine learning and all of the above definitely helps to achieve improved accuracy.
The critical point here is that you not only have to choose a system based on its apparent functionalities, but more importantly you need to re-engineer the whole process which lies behind.
7/ and what about liquidity management?
Several banks and software providers are suggesting that virtual accounts are an elegant solution for liquidity management, replacing notional pooling or zero balanced accounts cash pooling by what is commonly called “Native Liquidity Management”. There is some logic here, as cash is booked on one bank account - the settlement account or master account - and the participants’ positions are reported as isolated on virtual accounts. No need to sweep the cash daily between several bank accounts, it is just a question of keeping track of the loan and borrowing positions, reflect those in the accounting and distribute fairly the benefits.
But what is the point in implementing such a structure if you, as a Treasurer, remain blind and have to do its management manually? Granular cash allocation is not going to give you any reliable forecast. In a best-case scenario, it helps booking the loans and borrowings positions, and may facilitate the usual data crunching (on excel?) for forecasting, assuming that the future can be modelled based on the past, which is debatable, if not dangerous.
Instead, integrating contractual information in the process not only helps in allocating the cash, but allows the computation of realistic forecasts, as the system then knows what has to be paid or collected and when. It is then, and only then, that a Treasurer can truly improve their group wide liquidity management.
8/ Is there an elegant solution?
Yes. And there is probably more than one.
Our solution offers all the functionalities highlighted in the illustration above, under one single process, whatever the Bank.
At Fennech we have developed a unique technology around “Digital Contracts”. Those are similar in nature to Smart Contracts, but they run outside of Blockchain, without any need to tokenise. Our system digitalises contractual documents like complex insurance policies, loan agreements, FX, hedging, sales agreements, rental agreements, invoices or CRM data... into self-executable human and machine-readable objects. It then automatically processes the financial consequences of those contracts, i.e. payments and collections, knowing what has to be paid or collected, to or from whom, when, for what reason, based on which triggers or criteria, irrespective of the payment type, banking provider, or legacy IT systems.
When collecting account statements, the platform reconciles transactions first, including identifying partial or grouped payments, or payments made by someone else on behalf of the debtor. Then, it allocates the cash in real-time on a very robust and scalable digital cash ledger, using a multiplicity of criteria coming from the original contractual documents. Machine learning obviously further helps in improving this cash allocation process. This dynamic digital cash leader is arguably the most flexible and powerful true Virtual Account Management platform as a Service one can find nowadays, and our clients do not need to ask their counterparties to change the account number they pay into.
The accuracy of our system is such that it can dramatically improve the regulatory reporting which regulated financial institutions like Insurers, brokers or payment service providers have to produce and share with the regulator for client monies reporting or capital adequacy reserves for instance.
Our system fully supports and documents automatically “on behalf of” transactions, allowing the deployment of payment and collection factories, escrow services, or In-House Corporate Banks.
It uses contractual information about what should happen in the future to compute realistic forecasting. And obviously it allows significant efficiency gains by automating non-added value back office tasks.
This is not a wish; this is today’s reality!
I really have some problems today when I hear or read the misleading, incomplete or incorrect explanations about virtual accounts, which too often are just limited virtual IBANs.
However, I still love the concept of virtualisation of cash, i.e. true virtual accounts, because they are a major cornerstone to re-engineer Cash and Treasury management in the 21st century.
* names have been changed