Search This Blog

Sunday 29 September 2024

The FCA Wonders Out Loud Whether UK E-money Is Really Redeemable at Par...

The 'decoupling drama' surrounding USDT stablecoins appears to be echoing in the UK e-money world amid news from the UK Financial Conduct Authority that it doesn't know whether UK e-money firms fully safeguard the cash corresponding to their customers' e-money balances. This bombshell comes with a commitment to change the safeguarding rules in ways that could bring further problems, casting serious doubt on whether UK authorities' really have a grip on the payments sector.

This post is for information purposes only. If you would like legal advice, please let me know.

Context

The FCA's consultation on proposed changes to the 'safeguarding' rules for non-bank payment service providers makes you wonder who's been responsible for supervising the 24 year old sector. The regulatory regime has been under the FCA's direct supervision since it took over from the beleaguered Financial Services Authority in 2013. The sector comprises over 1,200 firms and processed £1.9 trillion in payment transactions in 2023. Electronic money (basically prepaid stored value that's used for making e-payments to others) represents about £1 trillion of these volumes, issued by 250 firms. Some e-money balances, such as those relating to prepaid card programmes, are significant and held for long periods. 

E-money is supposed to be issued on receipt of funds, and to be 'redeemable' on demand, at 'par value'. So, if you pay £1 to the issuer, it should immediately credit your online payment account in its systems with £1 and that balance should continue to be 'worth' 1 GBP when you transfer, spend or withdraw it. You have the regulatory right to withdraw - or 'redeem' - your e-money balance on demand. 

But e-money balances (like other non-bank payment flows) are not subject to the deposit guarantee under the Financial Services Compensation Scheme that backs bank deposits (up to a limit of £85,000 for all your deposits with the one bank). Instead, the right to redeem your e-money at par is underpinned by a regulatory obligation on the issuer to safeguard the corresponding amount of cash in GBP in a designated bank account, separate from its own funds (or with insurance), so that the funds are available to pay out immediately on demand.

Other types of non-bank payment service provider (payment institutions) must also safeguard customer funds, but they're only supposed to hold funds for as long as it takes to execute/process the related payment order, rather than allow their customers to hold an ongoing balance, so the time during which the funds are 'at risk' of the PSP going bust or dissipating the funds should be shorter than for e-money balances.

What's the immediate problem (opportunity)?

The FCA admits in its consultation paper that it does not know whether firms are failing to fully safeguard funds corresponding to the payment transactions they process or the e-money they issue. Worse, it reveals that in the 5 insolvencies of e-money institutions from 2018-2023 only 20% of funds were available and it took over 2 years on average time for an administrator to distribute the first round of customers' balances...

This seems to echo what happened when the value of  Tether's USDT 'stablecoins' - which aim to trade at parity with the USD - de-pegged from the USD. The scenario presented traders with an arbitrage opportunity: some borrowed amounts in a rival stablecoin and bought USDT at a discounted rate, betting that if USDT returned to its 1:1 peg, they could sell their USDT at parity and repay their loans at a profit.

In principle, there may be little difference between a right to redeem an 'e-money' balance in an online account and a 'fiat-backed stablecoin'. Indeed, the EU regulates fiat-backed stablecoins in the same way that it regulates e-money, while the FCA suggests they should be regulated differently, as recently discussed on LinkedIn.

Could there be an 'arbitrage opportunity' between balances issued by different e-money issuers, based on the extent of their safeguarding and availability of the balances?

Why Doesn't the FCA Make Firms Reveal How Much is Safeguarded At All Times?

Alarmingly, the FCA says the problem arises from firms not understanding how to safeguard, as well as "challenges in supervision and enforcement": 

33. In some firm failures there has been evidence of safeguarding failings which put client funds at risk and resulted in shortfalls. The current light-touch regime around [FCA!] reporting requirements means that supervisors have insufficient information to identify firms that fall short of our expectations. This then prevents the FCA from being able to prioritise resources, be that support or enforcement, on firms that pose the greatest risk to clients prior to insolvency. 

34. In particular, we are concerned about 2 areas. First, regulatory returns do not contain sufficient detail to assess whether firms are meeting their safeguarding obligations. Second, the safeguarding audits provided for in the Approach Document do not have to submitted to the FCA, further limiting our oversight

35. Furthermore, the lack of clarity and precision in current provisions leads to difficulties in enforcement as firms may be able to contest findings. This can undermine the credibility of enforcement as a deterrence.

Begging the question: in such circumstances, should the market continue to believe that UK issued/FCA-regulated e-money is really on par with GBP? 

New Rules...

The UK authorities' proposed remedy is to bring in more detailed rules, in two phases: supplementary rules under the current regulations "to reduce the incidence and extent of pre-insolvency shortfalls" (why so late?) and moving the e-money/payment services safeguarding regime under the FCA's wider 'client asset rules' (CASS) regime "to improve the speed and cost of distributing funds post-insolvency" - suggesting that the last attempt to improve the insolvency regime for non-bank payment service providers failed.

The interim rules will only echo current requirements, however, with only monthly reporting on the amount of e-money issued and corresponding cash safeguarded. Will the market be told? Even stablecoin issuers publish the amount of backing assets they hold (to prevent a 'run' on their stablecoins and a crash in the value). Maybe e-money issuers should start doing that, too? 

Among the eventual CASS rules will be an obligation to hold safeguarded funds under a statutory trust in favour of their e-money holders. This reflects the FCA's frustration at having already lost the argument in the case of Ipagoo in the Court of Appeal, which held that there is no statutory trust in favour of e-money holders under the E-money Regulations. The FCA is also pressing for a statutory trust over the cash which 'backs' fiat-backed stablecoins (while the EU has not). 

The statutory trust idea, in particular, raises a number of issues. 

The first issue is whether an e-money holder could have property rights in two distinct assets: the e-money balance (or the right to redeem it at par) and the beneficial interest in the pool of cash held by the issuer in the statutory trust (equating to the par value of e-money held)? If so, does the e-money holder simply have double the value of their e-money balance and/or could the value of these interests diverge?

Secondly, if the e-money itself gives the holder rights in the underlying cash in the statutory trust, why isn't e-money an investment instrument of some kind (the very thing that stablecoin issuers have structured their offerings to avoid, for fear of creating a regulated 'security')? Could it be traded on an exchange (or 'multi-lateral trading facility'), for instance? 

Thirdly, the requirement for the corresponding cash to be held in trust is no guarantee that an adequate amount will be held, or that the issuer won't somehow subvert the trust by, for example, failing to deduct 'own funds' (such as amounts owed in fees). What would such a failure mean for the value of the e-money balance itself (or the right to redeem it at par)?

There are likely other issues, such as those arising where an e-money holder has somehow granted an interest to a third party in either the e-money balance or the beneficial interest in the statutory trust. Currently, only the e-money issuer may have an interest in corresponding cash that is safeguarded. 

None of this is to suggest that there aren't answers in each case. The point is that the new concept of a statutory trust over the cash corresponding to e-money balances raises fresh uncertainty where the situation already appears grave under simpler rules; and without really solving the fundamental problems of potentially safeguarding too little and slow distribution on insolvency. 

More transparency and closer supervision would seem to be preferable.

Conclusion

The potential for new safeguarding rules is an almighty distraction from the critical uncertainty surrounding the integrity of the non-bank payment sector today.  

To ensure market confidence, e-money and payment firms may need to resort to publishing their safeguarding position on a daily basis, regardless of the FCA's requirements.

And new FCA rules will prove futile if the level of supervision remains the same.

This post is for information purposes only. If you would like legal advice, please let me know.


Monday 23 September 2024

A New Role In Ireland!

I'm pleased to say that I've been welcomed into a new consulting role in Dublin with Crowley Millar, a boutique in the financial district that prides itself  on 'pragmatic expert advice' - apt for someone whose other blog is Pragmatist! 

Huge thanks to Hugh Millar and the other partners for agreeing to take me on, and to Bryan Sweeney who led the charge on the very kind recommendation of a mutual client.

So it wasn't the beach that's kept me from these pages. In fact, it's been such a frantic summer I've had to restrict myself to posting on LinkedIn and occasionally Mastodon while absorbed by an almighty due diligence exercise and various other things. Fortunately, the change in UK government meant a pause on the consultation front.

At any rate, I've resurfaced, both here and in Dublin, so stay tuned...


Saturday 20 July 2024

If DAOs Are Really Autonomous, They Could Be Regulated As AI Systems Under the EU's AI Act...

Two recent publications - that of the EU's Artificial Intelligence Act and the UK Law Commission's 'scoping paper' on whether and to what extent Decentralised Autonomous Organisations should be granted legal status - got me thinking about this, because both AI systems and DAOs will tend to be global or 'borderless' in nature. It seems to me that the EU may have granted certain DAOs a form of legal status already - as AI systems - while focusing responsibility and liability on only some of the roles involved... If so, we can add this to other examples of sector-specific regulation in areas where DAOs might be established to operate, which could also have significant implications for the DAO and its participants. Please let me know if you require legal advice in these areas.

Defining AI systems and DAOs

‘AI system’ means [with limited exceptions] a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments;

The Law Commission uses the terms "DAO" very broadly to describe:

a new type of online organisation using rules set out in computer code. A DAO will generally bring together a community of (human) participants with a shared goal – whether profit-making, social or charitable. The term DAO does not necessarily connote any particular type of organisational structure and therefore cannot on its own imply any particular legal treatment.
As to what is meant by "autonomous" the Law Commission found that:

In the context of a DAO, “autonomous” has no single authoritative meaning. Some suggest that “autonomous” refers to the fact that the DAO has (a degree) of automaticity; that is, it relies in part on software code which is capable of running automatically according to pre-specified functions. Others suggest that “autonomous” is a broader, descriptive term used to encapsulate the idea that DAOs are capable of operating in a censorship-resistant manner without undue external interference or internal (or centralised) control. In this paper we allow for both meanings.

To merge the two concepts: a DAO's governance or decision-making could be automated 'with varying levels of autonomy' using codified 'smart contracts' that operate automatically in certain circumstances, to infer from the inputs received how to generate recommendations or decisions that influence the DAO or some other virtual or physical environment. 

Whom would this affect?

The AI Act applies to any person who supplies an AI system (or GPAI model) on the EU (read EEA) market (wherever they may be located) and anyone located outside the EU who provides or deploys an AI system outside the EU, if the output of the AI system is to be used in the EU. 

The AI Act encompasses a range of roles or actors who might - or should - have responsibility/liability in connection with the risks posed by an AI system, each of whom qualifies as an "operator":

‘provider’ means a natural or legal person, public authority, agency or other body that develops an AI system or a general-purpose AI model or that has an AI system or a general-purpose AI model developed and places it on the market or puts the AI system into service under its own name or trademark, whether for payment or free of charge;

‘deployer’ means a natural or legal person, public authority, agency or other body using an AI system under its authority except where the AI system is used in the course of a personal non-professional activity; 

‘authorised representative’ means a natural or legal person located or established in the [EEA] who has received and accepted a written mandate from a provider of an AI system or a general-purpose AI model to, respectively, perform and carry out on its behalf the obligations and procedures established by this Regulation; 

'importer’ means a natural or legal person located or established in the [EEA] that places on the market an AI system that bears the name or trademark of a natural or legal person established in a third country; 

‘distributor’ means a natural or legal person in the supply chain, other than the provider or the importer, that makes an AI system available on the [EEA] market; 

When we think about who might be involved or 'participate' in a DAOs, the Law Commission has grouped them as follows (though the roles may not be mutually exclusive):

  1. Software developers 
  2. Token holders of the tokens that enable governance or other types of participation 
  3. Investors/shareholders (where DAOs use recognised legal entities such as limited companies). 
  4. Operators/contributors in connection with the DAO's tokens (miners/validators), software, management etc. 
  5. Customers/clients, where the DAO offers an external service.
However, it is clear that these roles don't readily 'map' to the AI Act's concepts of responsibility for managing risks associated with the establishment, deployment and ongoing operation of DAOs.

This is not unusual when it comes to sector-specific regulation, which tends to focus on certain activities that some legal person or other must be conducting in the course of developing/establishing, deploying, operating and winding-down/up (although perhaps a lot of this type of regulation tends to be more limited in its territorial application).

Conclusion

Of course it's important to think of DAOs in terms of being an 'organisation' of some kind with legal implications for the participants depending on the actual type (Chapters 3 to 5 of the Law Commission's paper). 

However, it's also critical to consider the potential impact of sector-specific regulation that governs the activities of developing/establishing, deploying, operating and winding-down/up certain types of services or products. This type of regulation tends to be more limited in its territorial application, so requires a country-by-country (or even state-by-state analysis in countries like the US or India or regional trade arrangements, like the EU). Significant examples of this type of regulation that may have very grave implications for the liability and responsibilities of DAO participants include anti-money laundering requirements, financial regulation and tax (Chapter 6 of the Law Commission's paper), and we can add the AI Act as a more recent example. 

Please let me know if you require legal advice in these areas.


Monday 15 July 2024

Of APP Fraud, Safeguarding And "Asset Pools"

The awesome scale of 'authorised push payment' fraud is causing sleepless nights throughout the banking and payments industry, and much uncertainty as to where liability sits. There is a seemingly endless array of scenarios in which APP fraud can occur. Examples include impersonation, investment, romance, purchase, invoice and mandate, CEO fraud and advance fees. It's conceivable that liability could vary according to whether or not the payer is a consumer (or to be treated as one), as well as the type of institutions and payment services involved. I've set out below a quick summary of the current state of play for information purposes only, including various cases before the courts. Let me know if you need legal advice on any aspect, including possibly lobbying the new government to grasp some of the nettles via some form of regulatory action, to spare everyone a lot of time and expense...

Regulatory developments

I covered the Payment Systems Regulator's proposals in this area last June, and these have been brought in with effect from 7 October 2024. 

The CRM Code only covered 60% of APP fraud within its voluntary scope, so mandatory reimbursement requirements were always on the cards. 

The new reimbursement requirement applies to consumers, micro-enterprises and small charities which are all treated as ‘consumers’ under the Payment Services Regulations 2017 (PSRs), as with the CRM Code. In other words, it only covers payments made using Faster Payments where the victim is deceived into allowing or authorising a payment from their account with a PSP to another account outside the victim's control at another PSP.  

Firms must reimburse all in-scope customers who fall victim to APP fraud (with some exceptions), sharing the cost of reimbursing victims 50:50 between sending and receiving PSP, with extra protections for vulnerable customers. 

As the operator of Faster Payments, Pay.UK is responsible for monitoring all directed PSPs’ compliance with the FPS reimbursement rules and will operate a reimbursement claim management system (RCMS) that all members (direct participants) in Faster Payments must use from 1 May 2025, with various reporting standards mandated by the Payment Systems Regulator, with some limited to the larger participants. Affected PSPs must also explain this to their customers, including in service terms and conditions, so let's know if I can help there in particular.

As mentioned in March, the previous government proposed an amendment to Regulation 86 of the Payment Services Regulations to extend the time limit on processing a payment order where it has been authorised by the payer but their PSP reasonably suspects APP fraud.

Liability aside from the regulatory solution

Breach of Duties

As clarified by the Supreme Court in Philipp v Barclays: 

  • banks have a duty to execute a valid (clear, lawful) payment order promptly
  • a bank cannot execute a payment outside its mandate, so cannot debit the relevant amount from the customer's account in that case, and if it were to do so, then the customer has a debt claim against the bank.
  • banks also have a duty of care to customers to interpret, ascertain and act in accordance with their customers' instructions, which only arises where the validity or content of the customer's instruction is unclear or leaves the bank with a choice about how to carry out the instruction. The duty won't apply in the case of a valid payment order that is clear and leaves no room for interpretation or choice about what is required to execute it (i.e. the bank must simply execute, according to the first duty above). 
  • Where the general duty of care arises, and the payment instruction was given by an agent of the customer, and a bank has reasonable grounds to believe that the payment instruction given by the agent is an attempt to defraud the customer, the Quincecare duty requires the bank to refrain from executing the payment pending its inquiries to verify that the instruction has actually been authorised by the principal/customer. A similar duty applies where the bank is on notice that the customer lacks mental capacity to handle their finances or bank accounts.
  • the bank may also have a duty to take reasonable steps to recover funds that its customer claims to have paid away by mistake or as a result of fraud.

These findings are generally consistent with the Payment Services Regulations 2017 (PSRs), although (as the Supreme Court also explained), the PSRs did not provide for reimbursement of authorised payments, so did not assist victims of APP fraud, partly because they deem such payments to be correctly executed. However, the PSRs do oblige payment service providers to "make reasonable efforts to recover the funds involved", for which PSPs can charge any contractually agreed fee; and Regulation 90 has been amended to enable liability to be imposed “where the payment order is executed subsequent to fraud or dishonesty” under the Payment Systems Regulator's arrangements explained above - but this does not provide a direct right of action for customers.

It's has since been accepted (e.g. in Larsson v Revolut) that the above duties which apply to banks in a payment scenario, also applies to other types of regulated PSPs (e-money institutions and payment institutions). 

In Larsson, the claim was against the receiving PSP with which the payer also happened to have an account, although that wasn't the account from which payment was taken. However, the court held there were no duties owed by the PSP of the payee ('receiving PSP') to the payer, but did preserve the (slim) possibility of arguing 'dishonest assistance in a breach of trust' such that a constructive trust may have arisen over the proceeds of the payment transaction. 

CPP v NatWest further considered the concept of a 'retrieval duty'. That claim was held to be time-barred in the case of the PSP of the payer; but not in the case of the PSP of the payee, which might owe the duty where: 

  • it assumed a responsibility to protect the payer from the fraud; 
  • it has done something which prevents another from protecting the payer from that danger; 
  • it has a special level of control over that source of danger; or 
  • its status creates an obligation to protect the payer from that danger. 

I could see claimants arguing that the presence of voluntary and mandatory APP fraud schemes lend weight to some of these factors, while PSPs arguing that those schemes should be disregarded as they only operate strictly within their own scope.

Unjust enrichment

Terna v Revolut involves a claim by the payer that the receiving PSP was 'unjustly enriched' when the payer instructed its own bank/PSP to pay funds to a third party account in the mistaken belief that it was paying a genuine invoice from an energy supplier. The payment went via a correspondent (intermediary) bank via a series of SWIFT inter-bank messages; and the funds disappeared from the third party account within hours of being credited by the payee's PSP (an e-money institution). 

For this type of claim to succeed, the payee's PSP must have benefited at the claimant's expense in a way that was 'unjust' and without any defence

When the payee's PSP received funds in its account with a correspondent bank, it issued e-money to the payee, so claimed that it had not benefited. Some first instance decisions are consistent with that, but established banking law holds that this is not a valid argument; and the court was not convinced that the position may be different with an e-money institution that must issue e-money on receipt of funds and safeguard the funds (which a bank does not have to do) because one safeguarding option involved investing the cash (not to mention insurance as another option). Instead, the court held, these facts might operate as a defence, but that could only be decided on a full trial.

On whether the PSP was unjustly enriched 'at the claimant's expense' the court held that SWIFT and CHAPS payments should be treated the same way; and these were potential instances of 'indirect benefit' rather than 'direct benefit'. Here, the court considered that an 'indirect benefit' is to be treated the same as a direct benefit, where there is agency or a 'set of co-ordinated transactions' and that both applied (contrary to an earlier High Court case of Tecnimont). The likely questions at trial, therefore, are whether the enrichment was 'unjust' and/or a defence applied. 

Fortunately, permission to appeal has been granted, so there's an opportunity to settle the difference of opinion between High Court judges. It's probably too much to ask, but in that event it would be helpful if the Court of Appeal were to add some guidance as to how it would treat claims of unjust enrichment in situations where other forms of payment services (and systems) are implicated. For example,  'money remittance' is defined in the PSRs to mean: 

"the transmission of money (or any representation of monetary value), without any payment accounts being created in the name of the payer or the payee, where— 

(a) funds are received from a payer for the sole purpose of transferring a corresponding amount to a payee or to another payment service provider acting on behalf of the payee; or 

(b) funds are received on behalf of, and made available to, the payee.


Liability where funds are frozen or accounts suspended for regulatory reasons

Kopp v HSBC is another interim judgment, which involves a situation where the payer's bank suspended the payer's account following an anti-money laundering review that the payer argued had been carried out, preventing the payer making certain payments for which it then incurred liability to the payees under an indemnity, including ongoing interest. On an interim summary judgment application, the court held there was a triable issue as to whether the bank's liability clause ('buried' in the service terms) might fail to satisfy the reasonableness requirement under the Unfair Contract Terms Act (which also protect small businesses). That meant the court also refrained from deciding whether the clause in question excluded these heads of liability on the basis that they were not “direct loss of profit” or “other direct losses” or were expressly excluded as being “indirect or consequential loss (including lost business, data, profits or losses resulting from third party claims) even if it was foreseeable”.

Failure to safeguard customer funds

The extension of bank duties and potential APP fraud liability to all types of regulated PSPs (accepted in Larsson) sadly raises the prospect of the insolvency or a voluntary winding up of smaller e-money or payment institutions. 

This is relatively rare, since PSPs are required to have a certain amount of minimum capital (both by regulation and, where applicable, card scheme rules) and to manage their working capital to remain a going concern, unless and until they are fully 'wound-down'. 

However, sudden, unexpected losses could conceivably arise, particularly where there is poor record-keeping or other problems, such as dissipation of assets or perhaps a sudden, significant 'spike' in APP fraud for which it is at least probable that the PSP might be liable (a matter for directors to consider in the exercise of their duties). 

One consequence of APP fraud in this context would likely be that funds which ought to have been, or should have remained, safeguarded were not. The question would then arise whether the affected customer has a priority claim in the "asset pool" of the failed PSP. 

I recently explained the position in more detail in the context of the administration of UAB Payrnet in Lithuania. In the UK, an “insolvency event” (including a ‘voluntary winding up’) of the PSP triggers the creation of an “asset pool” of ‘relevant funds’ to be distributed by an administrator according to a specific hierarchy. The claims of e-money holders are to be paid in priority to all other creditors, with no rights of set-off or security applicable until the e-money holders have been paid. If funds should have been safeguarded according to the regulations but were not, national laws come into play within the overall intention behind the E-money Directive to achieve ‘maximum harmonisation’ of the e-money regime. 

In the case of Ipagoo a failed UK e-money institution, the UK Court of Appeal decided that the EMD did not require the UK to impose a statutory trust over the “asset pool” under UK e-money regulations (EMRs), so they don't impose or create a trust. Instead, the court held that the EMD requires all funds received by EMIs from e-money holders to be safeguarded, not merely those that had actually been safeguarded appropriately. Therefore, the “asset pool” must include both relevant funds that have been safeguarded in a compliant way as well as a sum equal to relevant funds that ought to have been, but had not been, safeguarded in accordance with EMRs, along with the “costs of distributing the asset pool” (including the costs of ‘reconstituting’ the asset pool in circumstances where relevant funds have not been safeguarded, as administrative costs associated with the asset pool itself).

Therefore, it might be claimed (possibly via a retrieval duty or unjust enrichment argument) that funds wrongly paid out should have remained safeguarded, though there is perhaps a question whether the payer qualifies as an 'e-money holder' or other 'user' for whom the institution holds relevant funds within the asset pool.

Conclusion

While the various court proceedings are proving somewhat helpful in revealing and resolving some of the uncertainty relating to where liability for APP fraud might sit, this is clearly a very slow and costly process. It would have been preferable for the Treasury, FCA and Payment Systems Regulator to have worked together more proactively to address the issue. With the change in government already heralding more attention being given to detailed issues, it is to be hoped that these are included.

Let me know if you need legal advice on any aspect, including possibly lobbying the new government to grasp some of the nettles via some form of regulatory action, to spare everyone a lot of time and expense...


Sunday 14 July 2024

Potential Support for Decentralised Autonomous Organisations (DAOs) Under English Law?

Source: Yield App

Following an earlier consultation that I covered for the SCL, the Law Commission has identified issues and potential reform/innovation to aid the new UK Government in considering whether to support Decentralised Autonomous Organisations (DAOs), under English law.  

The Commission does not think we need a DAO-specific legal entity, but suggests that "a limited liability not-for-profit association with flexible governance options" could be useful, subject to certain issues relating to anti-money laundering, financial services regulation and taxation.

The Commission's paper explains:

  • the philosophy and technology behind DAOs;
  • their possible legal characterisation, including how liability might be attributed to a DAO or its participants;
  • legal entities that might be used as part of a "hybrid" DAO’s structure
  • whether England and Wales is an attractive jurisdiction for DAOs, bearing in mind areas of local regulation that may affect them;
  • further work that might be useful, if DAOs are considered worthwhile, to ensure that they can be regulated;
  • whether current law can accommodate the use of blockchain/DLT for governance purposes.

Personally, under current law it seems likely to me that anyone attempting to set up a DAO in or from the UK is potentially running the risk of incurring unlimited personal liability under UK regulation and English law. In other words, they would be taking on the significant burden of resisting claims by third parties to the effect that they could be personally liable for the relevant activities and obligations, whether from a general liability standpoint or in relation to certain regulatory breaches that might occur, in the process of establishing and operating the DAO.

If you require legal advice on DAOs under UK/English law, please let me know.


Wednesday 29 May 2024

Virtual IBANs (vIBANS) Explained

The European Banking Authority has put together a helpful overview of the six main ways that virtual International Bank Account Numbers (vIBANs) are being issued and used throughout Europe (and the UK). The EBA clarification is welcome, as there is confusion as to whether a vIBAN represents/creates a corresponding payment account, or just operates as a unique reference number to track payments. Not only does this confusion fail to fix underlying problems, such as IBAN discrimination, but it can also trigger many other compliance and commercial challenges. There is also concern as to whether vIBAN schemes are adequately supervised and transparent, including from a financial crime standpoint... 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.

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.


Friday 24 May 2024

Understanding Card Scheme Fees: Payment Systems Regulator Report

The Payment Systems Regulator has issued a consultation paper/interim report burrowing further into the apparent lack of competition between the two major card schemes and potential harm to customers, particularly on the acquiring side. The PSR identified in a previous report that the card acquiring market wasn't working for UK merchants whose turnover is less than £50m, with one problem being the inability to compare pricing. This report reveals that fees charged by the two main card scheme operators have increased 30% in real terms over 5 years, with no link to improvement in service quality. The report looks at how the scheme operators deal with both their card issuing and acquiring members, but tends to focus on problems that acquirers have in understanding fees imposed on them, since they represent about 75% of the operators' net scheme/processing fee revenue. The specific problems and the proposed remedies are outlined below. There’s an opportunity to respond to the consultation by 31 July. Please let me know if I can help you understand the potential commercial or regulatory impact in your case.

In particular, the report sets out a number of areas where the quality of service is leading to poor outcomes for acquirers and merchants, including a lack of transparency in billing information for mandatory and optional fees, and as to the triggers of (potentially avoidable) 'behavioural fees' (intended to deter certain practices or incentivise the adoption of specific technical solutions):

(a) acquirers often experience difficulties accessing, assessing and acting on information they receive from Mastercard and Visa – which requires time to query, and some even employ consultants or pay for additional reporting or other services from the schemes themselves to understand pricing and fees charged;

(b) as a result, many acquirers aren't able to adopt a very sophisticated assessment of the impact of scheme/processing fees - and even where they can pass fees on contractually they may decline to do so or ‘misbill’ (either under/over bill) merchants;

(c) A large majority of acquirers described issues relating to the transparency of information on mandatory and optional fees - in fact acquirers reporting such issues accounted for over 90% of the total acquiring market;

(d) Poor outcomes for acquirers include:

  • Acquirers have difficulty understanding behavioural fees, which may also be distorting the behaviour and responses of acquirers and merchants, and limit the point of the behavioural fees;
  • Acquirers also find it difficult to understand mandatory and optional scheme and processing fees and how they apply, including whether certain services (and therefore the fees) are optional or mandatory;
  • Acquirers have problems accessing and clarifying information with the scheme operators, in a timely fashion or sometimes at all.

(e) remedies include requiring Mastercard and Visa to:

  • Develop and publish a pricing methodology to explain how the prices of these services relate to costs, together with obligations to document decisions;
  • Demonstrate that a service is ‘optional’, i.e. that viable alternatives to supply by the two card schemes exist;
  • Provide acquirers and merchants with more accurate and relevant information about behavioural fees, so they can be avoided or at least their cost can be correctly allocated;
  • Consult more widely before introducing new services or making changes to prices.
  • Provide bespoke materials to help specific businesses understand the scheme services being supplied;
  • Improve the quality and timeliness of information provided to acquirers, including billing information.

Please let me know if I can help you understand the potential commercial or regulatory impact in your case.