Corporates generally wish to reduce the number of bank accounts they run, and to have greater central control over the activity across them. This means integrating the cash balances on accounts used for day-to-day payments into one Treasury position, which is all the easier to achieve when the number of bank accounts is minimised. Running a Virtual Account system is one of the ways of perfecting this.
This is because, where files of payments, direct debits and enquiries are brought together into a service centre for insertion into the banking system, and where statements, advices and enquiry responses are retrieved through some kind of "finance portal", the question arises as to whether individual subsidiaries need to have their own bank accounts. The service centre can of course be permitted to operate bank accounts held in the subsidiaries' names under a Power of Attorney or similar legal authorisation, and subsidiaries need to be able to place bank account details on their invoices, but do these details have to relate to an account that a bank has rolling up into its general ledger?
Where SEPA payments are used, it is in theory an option for the service centre to have the account, and process payments as follows:
- For direct debits originated, to populate the details of the respective subsidiary in the field "Ultimate Creditor"
- For outgoing payments by SEPA credit transfer, to populate the details of the respective subsidiary in the field "Ultimate Debtor"
- For incoming payments by SEPA credit transfer, to ask the debtor to send the money to the account of the service centre but to be sure to quote the details of the respective subsidiary in the field "Ultimate Creditor"
This last point is where things can start to go wrong, as the subsidiary will have to quote complex bank details on its invoice, details it cannot be sure that the debtor will transpose into their payment order to their bank, including where the debtor bank eBanking system does not have that facility built in. This could lead to many payments landing on the service centre's account that are hard to apply and reconcile.
This is where the concept of Virtual Accounts comes in, that the service centre holds a "real" account with a bank, and the subsidiary can have a sub-account of that "real" account, but with its own unique bank details. In the basic version those bank details are identifiable to the same bank as the one with the "real" account. The routing tables of payment clearing systems will pick up that part of the bank details which indicate the Account Servicing Institution and route the payment there, without checking that the full details are valid (i.e. that the destination account really exists). It is then up to respective destination to either credit the payment or return it, depending upon the status of the destination account.
In other words, where IBAN is being used, the routing tables only view that part of the IBAN that is about routing, and not the piece about the account number. Under the basic implementation of "virtual" accounts, the "real" account and all the "virtual" accounts will have the same routing stem and be identifiable to the same bank.
The subsidiaries then need only put their own "virtual" bank details on their invoice: there is no need to trouble with the bank details of the service centre or with any mention of Ultimate Debtor or Ultimate Creditor.
This basic implementation of Virtual Accounts would have all the accounts identifiable to the same bank in the same country. In that case which entities should the bank carry out AML/CFT due diligence on? Just the service centre or all the subsidiaries as well? Surely the answer is in what impression is held out to the trading counterparties, namely that the bank details infer that the bank quoted is acting as an Account Servicing Institution for that precise company, and had carried out fill AML/CFT due diligence on it.
The second variant on the implementation of Virtual Accounts is where, for example in the SEPA Area, accounts that could operationally all be held centrally at one bank in the SEPA Area but are instead decentralised amongst the branches and subsidiaries of the same bank. This would be to ensure that trading counterparties were always paying:
- To an endpoint within their own country
- In local currency
- From a resident entity to a resident entity of that country
In these circumstances – and regardless of the measures put in place to eliminate the distinction between national and cross-border payments – neither cross-border fees nor central bank reporting apply.
In this configuration the bank details issued to each subsidiary would be composed according to the conventions for the subsidiary's country of incorporation: for SEPA payments the IBANs would conform to the country standard of payer and receiver, and would be national payments. Despite all the accounts being with the same banking group, the IBANs would clearly correlate to the respective branches and subsidiaries of the bank. The single "real" account of the service centre would reside somewhere in the bank's network.
Under this configuration it would clearly be irrelevant for the branches and subsidiaries to have an AML/CFT file on the service centre, as they have no relationship at all with them. The options are that they either have no AML/CFT file at all, or that they have one on the subsidiary that they have allowed to be associated to them by the issuance of an IBAN identifiable to them. The risks to the bank of not doing this are obvious: should the customer defraud its trading counterparties and authorities become involved pursuing recovery of funds, the bank would not like to reveal it had no AML/CFT file on the subsidiary. If there was a file held on that subsidiary but maintained at a different location of the same bank, that might be something, but an AML/CFT file done only on the owner of the "real" account and held in a different country would surely not be acceptable.
Even more troubling is the third configuration, established where the bank holding the "real" account has no local branch or subsidiary presence in the country of the subsidiary. The set-up has the same intentions as the second one: to enable the trading counterparties to avoid making cross-border payments. In this set-up the subsidiary is issued with an IBAN according to the conventions of its country of incorporation, and identifiable to a local bank there, not to any branch or subsidiary of the bank where the "real" account exists.
In this case the local bank would surely find itself in serious trouble if circumstances similar to these ones above occurred, and it transpired that the local bank had no AML/CFT file either on the subsidiary or the owner of the "real" account, and that there was no file on the subsidiary anywhere. Interbank indemnities in this field are no substitute for carrying out the AML/CFT work yourself, and especially when a bank issues bank details that infer to other parties that the bank is acting as Account Servicing Institution for the subsidiary.
Thus the naming of Virtual Accounts should not be held to infer that AML/CFT controls can be bypassed or reduced for any legal entity that is issued with its own unique bank details. Even where it is the same bank that issues the bank details for the subsidiaries and for the "real" account owner, this should be the rule. Still more is the case when (i) the virtual accounts are identifiable to the branches and subsidiaries of the same bank but in a variety of countries and (ii) the virtual accounts are identifiable to other banks.
Unfortunately it is precisely in these distributed account models that the responsibility for AML/CFT matters can become blurred, and parties can start to imagine that the responsibility falls on others, even where their bank has issued bank details that unequivocally identify them as an Account Servicing Institution.
You need to sign in or register before you can add a contribution.