What's a vIBAN?
You will likely have seen your own unique IBAN - the string of letters and numbers that relates to your current account (the most common type of payment account). IBANs are used in about 80 countries, including the UK and EU, and each IBAN has some letters to denote the country where the bank account is based. They are usually used for international or 'cross border' payments, instead of the 'account number and sort code' for domestic payments.
Tracking incoming payments is not really a consumer problem, but some businesses need to receive many payments from many different customers into one current account (to pay for, say, purchases or deposits). Usually, the business gives each customer a unique reference number to include in each payment order, along with the bank account number, so the company knows who paid. The trouble is that many customers don't include their unique reference number when making the payment from their bank, so the business receiving the payment has to spend time figuring out ('reconciling') who made the payment while the funds sit in 'suspense'. That means extra cost and delay in processing transactions, and that's usually a problem for both the business and the customer concerned.
Where a business has a really big corporate customer, it might make sense to a separate bank account (and related IBAN) just for that customer. But that would usually prove very costly for lots of consumers or smaller business customers.
Enter the vIBAN!
Instead of the additional reference number with the IBAN, the business gives each customer one unique account number to make the payment to. That a unique number looks like an other IBAN but is really just a unique number that the issuer uses to receive and move the funds to the business's actual IBAN and bank account. It's literally a virtual IBAN.
In many cases, the vIBAN may be issued/controlled by an intermediate payment service provider which holds a database matching each vIBAN with a customer number given to it by the business. When the money comes into the relevant IBAN account for that business, the intermediary electronically reports who made the payments in a way that the business can then match with its actual customer database.
The business could also make payments to customers using the same process, but in reverse.
Each vIBAN can also be limited to a particular type of transaction, like 'top-ups' to an e-money account or prepaid card.
One confusing aspect of the EBA report is that it refers to the actual bank account associated with the IBAN as the 'master account' which implies that each vIBAN is itself an account when that is not the case. There is only one actual bank account involved in an IBAN/vIBAN arrangement. If there has to be a reference to a 'master' at all, then it would be more helpful if the IBAN itself were referred to as the 'master IBAN' to differentiate it from the vIBANs associated with it (there is also the concept of a 'secondary IBAN' that refers to the actual bank account).
Do vIBANs have other uses and benefits?
vIBANs have other benefits besides solving the main payment-tracking problem.
Sometimes, for example, local banks or businesses in one country will refuse to make payments to an IBAN that has a different country code (so-called 'IBAN discrimination'). So a supplier based outside that country will arrange for local vIBANs to be presented to its local customers, so they or their bank won't refuse to pay. IBAN discrimination is banned in the EU and UK under the Single Euro Payments Area (SEPA Regulation), but the rule is not always enforced in practice.
The same set up that defeats IBAN discrimination is also used to establish a more cost-effective global payment network. That's because the ability to receive and make payments locally in many different countries usually requires a network of different local payment service providers, but they can all be controlled by one corporate team. That team can manage payments for external customers or internal payments among the companies in the same corporate group, and can also keep balances in different currencies to minimise foreign exchange exposures and conversion costs.
What are the risks/concerns relating to vIBANs?
Possibly the easiest concern to understand is that people making payments (and their payment service providers) are nervous about not being able to tell the difference between an IBAN and a vIBAN. Only the recipient/payee and the PSP(s) issuing the vIBANs know the difference and there may not be any direct customer relationship between the PSP that issued the vIBAN and the end-user. As described above, the initial 'payee' may in fact be an intermediary PSP and not the PSP of the actual intended end-payee. That could interfere with the need to verify the actual payee (and efforts to stop 'Authorised Push Payment' fraud). Similarly, the use of vIBANs may impede the transparency requirements around payer and payee under Funds Transfer and SEPA/ISO standards.
At the regulatory/technical level, some regulators (indeed vIBAN issuers!) don't understand that vIBANs as really just reference numbers. Sometimes vIBANs are also confused with a 'secondary IBAN' which, like the original or 'primary IBAN' also identifies an actual bank account. Some regulators also seem to believe (or there is contractual/operational confusion which suggests) that a vIBAN necessarily implies or creates a distinct, extra payment account (rather than just the data showing which end-user made/received a payment). Unfortunately, that analysis would also mean there is a direct customer relationship between vIBAN issuer and the end-user, which would trigger a lot of related contractual and compliance requirements and confusion over customer's rights (including deposit guarantee schemes), regulatory supervision and complaints.
However, even if the vIBAN were to be considered an 'identifier' of the actual bank account under the associated IBAN, where the end-user is not the named holder of that bank account then the account could not be deemed that end-user's payment account. The EBA is concerned that this may mean an end-user somehow lacks a payment account and the related regulatory protection that brings. But, of course, the vIBAN itself is just a reference number that the end-user quotes when initiating a payment order - and a payment order could only be initiated in relation to a source payment account from which the relevant funds are to be drawn to fund the payment transaction.
Some regulators agree that vIBAN issuance is not itself a regulated banking/payment service activity, so cannot provide the basis for an institution to open a branch in another member state (host state) under passporting arrangements. Other regulators allow vIBAN to constitute an activity enabling passporting or requiring local authorisation/agency. This means that institutions need to check the regulators view on both sides of each border they wish to 'cross' by issuing vIBANs.
The EBA has also found that some regulators have effectively banned cross-border issuance of vIBANs, by requiring that there must be no divergence between the country code of the vIBAN and the country code of the IBAN of the actual payment account. While those regulators point to ISO technical standards for their view, the EBA has explained that the European Commission does not share that interpretation, nor is it consistent with the SEPA Regulation.
There's also some risk that a PSP issuing vIBANs might be facilitating the operation of an unauthorised payment service business, depending on the nature of the business being operated by the immediate customer and services offered to end-users (i.e. is that customer offering one of the specified 'payment services' as a regular occupation or business activity).
There is also the potential for failures in fraud reporting where a payment is made to a vIBAN in one country, but actually means the payment has been routed to a payment account with an IBAN in another country.
Are separate vIBAN controls needed?
Some regulators' concerns about vIBANs might be addressed if those same regulators were to tackle IBAN discrimination in their jurisdictions - so that vIBANs aren't needed as a 'band aid' or 'sticking-plaster' for that problem.
For anti-money laundering purposes, it's especially important for the issuing PSP to understand the payee's business, the scenario in which the vIBANs are being used, and the type of end-users able to use the vIBANs and the rationale for the payments being received (or made). This becomes more critical where the end-users are based in another jurisdiction.
In turn, the payment services regulator in the country where the vIBAN arrangement is deployed needs to know that: vIBANs are being issued; the issuing PSP has the right risk assessment, customer due diligence and transaction monitoring controls in place (including where another PSP or business is actually allocating the vIBANs to the end users); and that suspicious transactions involving vIBANs can be detected, reported to the correct country authority and readily traced. Again, this becomes more important where the end-users to whom vIBANs are issued are based in another ('host') jurisdiction to the ('home') jurisdiction where the IBAN and bank account are based.
Some PSPs have already lost their licences over failure to comply with existing controls in the vIBAN context, but the EU's new AML Regulations will explicitly require the 'account service' PSP that offers the underlying payment account to which the IBAN relates to be able to obtain customer due diligence information on end users to whom the associated vIBANs are issued 'without delay' and in any case within five working days - even where vIBANs are issued by another PSP.
In addition, the next anti-money laundering directive (AMLD6) will require all national bank account registers to hold information on vIBANs and their users.
The EBA has also included an Annex listing the factors that may increase or reduce the risk of money laundering or terrorist financing.
Please let me know if I can help you navigate any issues you have regarding vIBANs under existing regulation, or under the proposed controls relating to them.
No comments:
Post a Comment