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.

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...

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.

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.

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.

Are Influencers Regulated?

We've come along way from sponsorship and advertising deals for sports stars, actors and other celebrities. Now products are marketed by some people whose celebrity and vast wealth comes only from marketing products through posting their own personal 'lifestyle' content in the social media.  Of course, 'traditional' celebrities are also in on the act, and can command even greater sums for their own highly personalised, lifestyle-type endorsements. Yet such personal content is rarely filtered through any type of compliance process, unlike traditional advertising. And the temptation to make a fortune at the touch of a screen often overrides any sense of responsibility on the part of the influencer. As a result, the role of 'influencer' has become one of the most highly regulated in society... and that regulation will only intensify. Please get in touch if you need advice.

It's no surprise that politicians are at pains to see this evolution as wildly positive:

Europeans are spending more time online, meaning that influencers who create content for social media have a greater impact than ever before on the way we perceive and understand the world. In order to ensure that this impact is positive, the EU must provide support to influencers, enabling them to build their media literacy and increase their awareness and appreciation of the rules that govern their actions online. 

- Benjamin Dalle, Flemish Minister for Brussels, Youth, Media and Poverty Reduction

In typical civil law fashion, the EU is calling for positive regulation that will effectively permit the practice of being an influencer and govern how it can be done lawfully.

In common law countries, it's also a case of the law catching up, but the authorities in charge of the marketing rules are less enthusiastic, responding with advertising bans, for example, and now a Financial Conduct Authority prosecution relating to activities between 2018 and 2021 (perhaps more to do with its ban on certain marketing high risk financial derivatives to retail customers). 

The regulators responsible for retail sales (CMA), broadcasting (Ofcom) and advertising (ASA) began jointly targeting 'hidden advertising' in 2020, while the FCA's latest social media guidance is also partly aimed at influencers and other affiliate marketers. 

Yet even the guidelines can be tough to follow, and influencers may well cross the line into other regulated activity, such as the need to register with the FCA for anti-money laundering purposes if you make arrangements with a view to crypto trading, for example.

Please get in touch if you need advice.

European Commission Also Fires Up The Digital Markets Act

Having just opened multiple investigations under the new Digital Services Act, the European Commission has also announced investigations under its new Digital Markets Act (DMA). These investigations would also benefit UK businesses providing services to EU/EEA residents. This post is for information purposes. If you need advice, please let me know.

As previously explained in more detail, the DMA aims to control unfair practices of very large digital platform operators (“gatekeepers”) when providing services that other businesses use to reach their customers online. These gatekeepers effectively act as private rule-makers, and are able to create ‘bottlenecks’ and ‘choke points’ that limit access, unfairly exploit data for their own purposes and/or impose unfair conditions on participants. The DMA operates outside the scope of existing EU competition controls. Member state’s regulators cannot go further than the DMA restrictions, which must be applied consistently throughout the EU. Gatekeepers can be fined up to 20% of worldwide revenue for breaches. The DMA applied from May 2023 and any firm designated as a gatekeeper then has six months to comply with the various requirements. 

Alphabet, Amazon, Apple, ByteDance, Meta and Microsoft were designated as gatekeepers in September 2023, giving them until 7 March 2024 to comply. The European Commission believes they do not. Specifically, the Commission alleges that: 

• the 'steering rules' in Google Play violate Article 5(4) (gatekeepers must allow business users, free of charge, to make offers to and contract with end users acquired either via its core platform service or through other channels, regardless of whether they use the core platform services of the gatekeeper for either purpose);

• the self-preferencing on Google Search violates Article 6(5) (gatekeepers must not treat more favourably (in ranking and related indexing and crawling), services and products offered by the gatekeeper itself in preference to similar services or products of a third party, and must apply transparent, fair and non-discriminatory conditions to such rankings);

• the steering rules in the Apple App Store violate Article 5(4);

• the choice screen for Safari violates Article 6(3) (gatekeepers must allow and technically enable end users to easily un-install any apps on the gatekeeper's operating system (except apps essential for the functioning of that operating system or the device which cannot technically be offered on a standalone basis by third parties). Gatekeepers must also allow and technically enable end users to easily change default settings on the operating system, virtual assistant and web browser of the gatekeeper that direct or steer end users to products or services provided by the gatekeeper); and

• Meta's "pay or consent model" violates Article 5(2) (using personal data gathered by third party businesses from their customer's using the browser, without valid consent under GDPR, in addition to other direct GDPR complaints about that type of model). 

Within the next 12 months, the Commission will inform these gatekeepers of its preliminary findings and proposed orders to fix any issues.

In addition, the Commission:

• is seeking information on Apple's fees for alternative app stores and Amazon's marketplace ranking practices;
• issued document retention orders to Alphabet, Amazon, Apple, Microsoft and Meta to help it monitor their compliance with the DMA; and 
• granted Meta an extension of six months to ensure Facebook Messenger complies with the interoperability requirement in Article 7 (there's a long list of those!).

These investigations would also benefit UK businesses providing services to EU/EEA residents. 

This post is for information purposes. If you need advice, please let me know.