Do you understand what a virtual account / vIBAN really is?
I thought it might be useful to go back to basics a little bit and talk about real accounts, virtual accounts, how the linkage is created, etc. There are some conceptual and practical differences that are helpful to know. As I have said in other articles, none of the descriptions should be construed as advice, and there are also some personal opinions here that may not reflect the official views of Freemarket.
Freemarket’s use of virtual accounts
As we have discussed in our safeguarding article, funds deposited with a Payments Institution (PI) such as Freemarket are held in safeguarding accounts. These accounts are in the name of the PI or E-Money Issuer (EMI), but funds are held in-trust for the beneficial use of their underlying clients. The safeguarding process defined in payment services regulations means that the clients are the beneficial owners of the funds they have deposited even if their name is not on the real bank account.
In some contexts, virtual accounts are called ‘wallets’ but this tends to be a retail term and doesn’t reflect the range of functionality a corporate would use. Virtual Accounts are used by PIs and EMIs to create a record of ownership of the funds on an account that the client and the PI / EMI can both agree. They create a virtual representation of the debits, credits and resulting balances to enable the company and their client to keep track of the funds in the safeguarding account which are attributable to that client. They can also be used to create (virtual) Inter-Account Transfers where a client can move funds between virtual accounts – these are moves between virtual ledger positions and do not result in money actually moving onto or off the real account.
Virtual IBANs are virtual accounts where the reference number mimics the format of a real bank account reference number.
To understand where and how your money is held and accounted-for by a payment institution, it is important to start with a common understanding of what real bank accounts are. This becomes the benchmark for comparison as the bank is the traditional alternative.
Real bank accounts
When you pay funds into a UK high-street clearing bank (e.g. Barclays, HSBC, Lloyds, NatWest, Santander), your money is held as ‘client money’ and on deposit. The account may be called a current or demand deposit accounts. You are effectively lending money to the bank, and in due course, they should pay it back. Counter-intuitively, i.e. even though cash-at-bank is classified as an asset by any other type of business, banks classify their customers’ deposits as liabilities. This reflects the fact that they see this as the money they have borrowed and they ‘owe’ it back to their lenders (depositors). Current accounts are ‘on-demand’ so the depositor can withdraw funds (i.e. demand their loan to the bank is repaid) straight away.
The treasury department at the clearing bank pools all of the deposit money it has collected (borrowed from clients) and uses it to make further profits. The bank allocates some funds to lending (e.g. mortgages, cards, unsecured loans, etc.), some to investments (e.g. buying government bonds) and keeps some physical notes and coins in the cashiers’ tills. It *may* also hold some money on deposit at the central bank (in the UK, the Bank of England).
As a depositor, this does NOT mean you have vicariously lent money to mortgage-holders, invested in government bonds or have an account at the Bank of England, and nor does it mean the Bank of England identifies you as a depositor. There is no connection at all between the money you have deposited and any of transactions the bank uses it for. Money is ‘fungible’ i.e. 2 deposits of the same amount would be indistinguishable from each other, like two £10 notes both in your pocket at the same time.
The sort code and account number structure of UK bank account reference numbers is used for a couple of different purposes.
- Routing of payments. The sort code is 6 digits starting with the bank’s own number (e.g. “20” is Barclays). The rest of the code is split usually by accounts platform and/or customer segment and/or branch (in Barclays’ case, the ‘head office’ branch sort code is 20-00-00).
- Segregation & Accounting. If the sort code is the city, district and street name, the account number is like the door number to the house which owns the money
The banks do have a general requirement to keep their own funds separate from client funds (no co-mingling), but client funds are routinely mingled *with each other*. The bank’s own treasury department aggregates client money and then ‘lends’ the moneys to various of bank business units. This is the basis of fractional reserve banking.
Freemarket’s accounts with its banks
Freemarket holds real bank accounts with each of its banks, just like any other PI or EMI. Some of these accounts are for the specific and sole use of themselves (operational accounts used to pay salaries and bills), whereas it has other specific accounts for the storage of money for client transactions (safeguarded funds).
Just as high street clearing banks to mingle client funds (but do not co-mingle those with their own equity capital), safeguarding accounts also mingle funds across clients (but do not co-mingle with their own money in operational accounts). As with banks, client deposits may be mingled but not co-mingled with their own funds. So far, so same.
Clients sometimes ask us whether their funds are held in separate bank accounts which are solely for their own use. Given what we have described above, the answer to this question is, therefore ‘no’. Holding separate accounts for each client is not operationally possible for any PI or EMI and the banks would not support it. We have to explain to clients that their funds are perfectly safe but mingled together with the funds we hold for other clients.
Virtual Accounts
The numbering system used in naming a virtual account is an artificial address that helps the PI or EMI to track who the beneficial owners are of the funds flowing in and out of the real safeguarding account.
You can find virtual accounts as reference numbers on utility bills, tax bills etc. In this day-and-age, the reference number is very likely to be a virtual account number.
- The bill-issuer creates a negative balance on the virtual account and the billing system sends out the bill
- When you pay the bill the balance goes back to zero
- Once the due date is passed, the bill issuer just needs to find the non-zero balances and send chasers. Everything that is zero is considered to be reconciled.
This is one of the most obvious corporate use cases of virtual accounts and also makes them very easy to understand. The virtual account can make accounts-receivable into a semi-automated or fully-automated task.
It is very important to remember that Virtual Accounts are not real bank accounts. This may seem trite, but it is often forgotten. Even where virtual account numbers include a sort code and account number (a virtual IBAN, see below), this does not make them bank accounts. We do not talk about Virtual Account monthly ‘statements’, but rather we create user-defined reports which can be daily, weekly, monthly or of any other frequency. They can be made to look and feel like a bank statement, but this is a thin facade.
Virtual IBANs
Virtual accounts can take many forms including unique reference numbers. However, one particular form of Virtual Account has started to dominate use cases – the Virtual IBAN.
An IBAN is an International Bank Account Number. It is constructed in different ways around the world, but in the UK it is derived from the country code, the account-holding Bank’s identifier (called a BIC) and the 14-digit sort and account number.
The reason a virtual IBAN (“vIBAN”) is so useful is that it creates both an address and a reference number. If a bill is issued and you are told to pay to a virtual IBAN which is unique to you as the payer, there is no need for a reference number. The key to this functionality is that the bank providing the real account must be able to map the non-real virtual IBAN to the real account’s IBAN, and vice versa.
Unique sort codes
The sort codes used to create a virtual account reference number can be registered by the PI or EMI itself or can come from a ‘stock’ of sort codes operated by the underlying bank which also provides the real account. The use of separate sort codes is no more than a cosmetic affectation, like a car with a personalised registration (number plate). A unique sort code does not change how the funds are stored or how safe the money is, any more than a personalised registration changes the performance of a car.
Multi-currency vIBANs
There is also widespread talk of multi-currency vIBANs where a user only needs one virtual account number for all the currencies it operates. Real multi-currency bank accounts are starting to emerge from some banks, but in most cases the mapping of the virtual to the real accounts uses the currency as well. In the background the funds still flow to a real single-currency bank account.
The other interesting thing about these multi-currency vIBANs is that uptake by corporates has been relatively slow so they have remained mostly a ‘retail’ product. This may be because the corporate maintains real ledgers in different currencies in their ERP system, so they prefer to be presented with the information in a virtual account on a currency by currency basis. This is, of course, not universally true of corporates and the situation could evolve further over time.
Differences between virtual and real accounts
It is reasonable to deduce that the account numbers used by banks (sort code and account number) are very similar indeed to virtual accounts. In both cases, they create an ‘address’ for funds to be recorded as debits, credits and balances and they create a routing when money is being moved.
However, real accounts must be issued and operated by credit institutions (which are usually regulated banks). Real accounts have a number of defining characteristics not matched by virtual accounts. The key differences where virtual accounts overlay safeguarding accounts include:
1. There is no need to ‘map’ a real account to another account.
a. The real account details are complete in all respects.
b. A virtual account must always ‘map’ to a real account.
2. The funds held in a real bank account are being ‘lent’ to the bank.
a. The bank can then use those funds to generate a profit (subject to Basel III regulations).
b. A PI or EMI must store the safeguarding funds it holds in a Credit Institution ‘in trust’ for the beneficial use of the PSU and must not use the money for any other purpose.
3. Funds held in a safeguarding account are not protected by depositor protection such as the UK’s Financial Services Compensation Scheme
a. Funds held on a safeguard account connected to a virtual account reference number are not protected either.
b. Note that FSCS is only available to retail and micro-enterprise depositors, so this may not be relevant to all potential users of a PI. For example, it is unlikely create any difference or disadvantage to corporates.
4. In a bank deposit the PSU faces the credit risk of the bank but when funds are held in a PI / EMI the PSU does not face the credit risk of the PI / EMI. Safeguarding means that they are protected from the API / EMI’s liquidation and so faces the credit risk of the bank providing the safeguarding accounts.
5. The real account in a credit institution can pay interest, whereas a PI / EMI is specifically not allowed to pay interest.
a. In a low interest rate environment credit balances are not earning interest anyway, so this is unlikely to be a disadvantage.
b. In an API, the deposit should be accompanied by a payment instruction so the opportunity time ‘lost’ for interest to be earned should be minimal.
Note that virtual accounts may also be used to overlay operational accounts or ‘client money’ which is regulated in a different way in the UK. The last two differences described above may not always be true, but importantly they are always true for UK PIs and EMIs.
A corporate client will need to understand how these differences manifest as business issues when they are deciding whether to use a Bank or PI to facilitate their cash management, payments and FX. For corporates I would argue that there is practically no disadvantage to using a PI with virtual accounts rather than using a bank with a real bank account as:
- The mapping is taken care of by the PI and their bank;
- Liquidity is immediately available in either case;
- The corporate is not eligible for FSCS or other forms of depositor protection; and
- Interest which might have been earned on a bank current account is likely to be close to zero.
The advantages of virtual accounts are numerous, including the cost to operate, speed to open and close, use in reconciliations, ability to centralise receivables and payables in a large corporate, etc.
Why banks are looking at providing Virtual Accounts to corporates
The key question is: if banks can provide real bank accounts, why would they bother offering virtual accounts?
2 main reasons:
Reason 1.
Banks can no longer profitably offer notional pooling. In fact, since the advent of Basel III, notional pooling now makes a loss.
For those of you without a corporate treasury background, traditional notional pooling allowed companies to group their accounts at the same bank and have the bank treat them as one single account. The companies could run positive and negative balances on the accounts and the bank would aggregate these for the purposes of paying / charging interest.
Basel III forces the banks to carry capital for both deposits (to prevent a cash call liquidity ‘run’) and debt (as a buffer against losses). Historically these could be netted as well. However, under Basel III capital for deposits and loans may not offset (unless there are guarantees which most corporates will not provide) so the bank must hold risk free instruments for both. By allowing corporates to offset banks do not make a profit on either the deposit or the lending but still have the cost of setting capital aside for both.
The alternative is to offer a virtual account overlay above fewer real accounts. Positions can then be netted on a virtual basis – the capital is solely measured at the real account level. This provides the illusion of separation of funds when in fact (as far as the regulators and accountants are concerned) there is just one single aggregated balance.
Reason 2.
Banks are looking to offer value-added services to corporates. The advantages of virtual accounts are the same irrespective of whether they are offered by a bank or non-bank and include:
a. Speed, cost, efficiency, overhead of opening, maintaining and closing real bank accounts. Overheads include the constant need for the corporate treasury team to supply KYC information to open accounts.
b. Logical account structure to consolidate and centralise payables & receivables
c. Reduced consumption of working capital
d. Virtual accounts package-up neatly with other solutions. For example they could allow banks to build new or extend the use of existing functionality including in the worlds of FX and payments, term-lending, working capital, trade finance, invoice finance, supply chain finance, etc.
In my view, the banks are a long way behind in adoption and roll-out of virtual accounts solutions. For some time to come they will try to ration the offering to:
- client money for regulated entities e.g. solicitors, insolvency practitioners, property managers, etc.
- safeguarding for regulated PIs / EMIs
For own-funds solutions (i.e. where the corporate is trying to structure their accounts logically) banks will only be interested in offering virtual accounts to large corporate clients.
Key takeaways
Virtual accounts
- create a record of how much of a PI’s or EMI’s funds are for the beneficial use of a client;
- are not real accounts but create the illusion of a real account by replicating their addressability
- are very useful because they are cheap and fast to open, close and operate; and
- can be used by corporates as well as PIs / EMIs for to manage payables / reconcile receivables
vIBANs
- are structured as a real IBAN;
- create a combined ‘address’, routing and reference number;
- must be mapped to the real IBAN account to create the routing of funds; and
- can have unique sort codes, but this is a cosmetic feature and accounts without unique sort codes do not have any disadvantages in functionality or security
Banks
- Will focus on mitigating the unprofitability of notional pooling
- Will fail to understand, let alone exploit, the power of virtual accounts
- Will fail to offer virtual accounts to SMEs in the right format and functionality
