Changes to UK Anti-Money Laundering Regime

The UK's anti-money laundering regulations suffer from an enormously long name, so I will shorten them to the "MLRs" for the purpose of explaining some changes that take effect on 1 September 2022 (except where noted). Perhaps the highlight is that account information service providers (AISPs) will no longer need to comply with the MLRs. This note is a summary for information purposes only, not advice. It does not include changes to the authorities' obligations or offences. If you need advice on any of the changes, please let me know.

• The meaning of a trust or company service provider covers the formation of all forms of business arrangement or "firm", not just companies and other legal persons, including limited partnerships registered in England and Wales or Northern Ireland. TCSPs must conduct customer due diligence when they are providing certain services (outlined in regulation 12(2)(a), (b) or (d) of the MLRs). 

• Cryptoasset transfers will be covered by a new Part 7A from 1 September 2023. The provisions apply to a cryptoasset exchange provider or a custodian wallet provider (referred to as a "cryptoasset business"), whether acting for the transferor ('originator'), the transferee ('beneficiary') or just as an intermediary. Cryptoasset businesses acting for originators of transfers (as well as intermediaries involved in the transfer) must include certain information about the originator and beneficiary of the transfer. Where the information is missing, the cryptoasset business acting for the beneficiary of a transfer (as well as intermediaries involved in the transfer) must request it and consider not making the cryptoasset available (subject to a risk assessment). Similar rules apply in relation to transfers from/to 'unhosted wallets'  (private or self-custody wallets). Cryptoasset businesses must inform the Financial Conduct Authority (“FCA”) of any "repeated" non-compliance. 

• The definition of art market participant in the MLRs will not apply to artists who sell their own works of art over the EUR 10,000 threshold.

• From 1 April 2023, firms covered by the MLRs will have to report to the registrar of companies any material discrepancies between information they hold on the beneficial ownership of a customer and information on the companies register. The registrar has clear powers to deal with such discrepancies. 

• Any change in control of a registered cryptoasset business must now be pre-approved by the FCA (a particularly slow and painful process!), which of course may object and publish a notice of the objection. The FCA and HMRC can now also publish notices of refusals to register applicants. 

• Supervisory authorities can now request suspicious activity reports (SARs) from their members, to assist in meeting their supervisory functions. 

• At long last, account information service providers (or AISPs) will no longer need to comply with the MLRs.

Again, this note is a summary of some changes for information purposes only, not advice. If you need advice on any of the changes, please let me know.

Brexit-proofing... eIDAS Certificates

The European Banking Authority has just reminded firms to get ready for the end of cross-border activity between the EU and UK. Among other things, for Open Banking this means:

“account information service providers (AISPs) and payment initiation service providers (PISPs) registered/authorised in the UK will no longer be entitled to access customers’ payment accounts held at the EU payment service providers and their PSD2 eIDAS certificates under Article 34 of the Commission Delegated Regulation (EU) 2018/389 [the eIDAS Regulation] will be revoked.”

However, as explained by the UK's Information Commissioner, a version of the eIDAS Regulation will take effect in UK law after 1 January 2020 (by virtue of the snappily titled Electronic Identification and Trust Services for Electronic Transactions (Amendment etc.) (EU Exit) Regulations 2019/89). 

This means UK law will continue to recognise EU registered qualified trust service providers, with the intention that UK-based organisations can continue to use EU-based trust services as well as UK-based trust providers. The approved trust providers that appear in the eIDAS trusted list for the UK immediately before the end of the transition period will remain on the list for the new UK scheme after transition ends. But the certificates issued under the UK scheme - or by EU service providers to UK-based firms - will not be recognised in the EU (or EEA).

Of course, it's a practical/commercial issue as to whether EU-based trust service providers will continue issuing certificates to UK firms after Brexit transtion ends…

#PSD2: An Account Information Service Is Not Really A Payment Service

There are good reasons why an "account information service" (AIS) became a regulated "payment service" under the not-so-new Payment Services Directive (PSD2). Chief among them was retail banks' decades-long refusal to allow retailers and other unregulated service providers access to the data in their antiquated systems at all, let alone seamlessly via 21st century "application programming interfaces" (APIs) that are now commonplace. Resolving those concerns sparked formal registration and other complex regulatory and technical requirements on service providers wishing to enable the sharing of payment data (AISPs), including a lot of unfortunately necessary detail in the Directive about customer authentication and information security. Yet years after PSD2 was set in stone confusion still reigns over exactly what an AIS actually is or is not, both as defined in local payments regulation implementing PSD2 and how such services work commercially - especially because an AIS rarely stands alone...

The FCA is doing its best to clarify the regulatory scope of an AIS, including confusion about who might be the AISP, when a firm would require formal registration as an agent and how to benefit from the exclusion for 'technical service providers' (see Q25A of its Perimeter Guidance on payment services). But those issues are merely the tip of the iceberg.

The major problem is that an AIS is primarily a data service (and one which involves personal data at that). This means an AIS attracts the need for several sets of regulatory consents and specific information to be included in customer contracts, as well as the typical series of contractual licences to receive and use the data itself. 

The challenge to getting all this right is that it's rare for payments regulatory specialists to know very much about data licences, or for lawyers who specialise in data licensing to know anything about PSD2. It still feels strange to me to have spent a career on both sides of that divide - veering from financial information service licensing at Reuters, to e-commerce specialist at DLA, to payments specialist at Earthport, to P2P lending at Zopa (which involved licensing of user-generated content and market data) and back to payments at Amazon and WorldPay. And even though I've also continued to advise private clients on all types of services since 2005, there's still very much a sense of 'switching hats' when working through the various issues. 

So what are they?

Regulatory requirements for an AIS

From a regulatory standpoint the multiple sets of rights needed to supply an AIS include:  

• explicit consent from the customer for the supply of the AIS itself (under payments regulation) - note that that 'customer' does not include a third party with whom the customer wants to share the data; and
• under data protection regulation, explicit consent (or some other legitimate basis) for the collection, processing, sharing etc of the data itself, to the extent required to deliver it to a third party - as well as for the processing etc of that data by the third party (which may be tackled via the third party's own privacy policy and data consents).

In addition, payment services regulation specifies certain information that must be included in either an ongoing or single use service contract with the customer.

Meeting these requirements is complicated by the fact that the customer is also likely to be using the AISP's platform to be receiving and sharing data from other types of personal account that are not regulated. So the payment-specific regulatory requirements have to be met within a context where unregulated data services are also being provided.

Commercial requirements

From a commercial standpoint, there are numerous copyright licensing issues to consider regardless of whether the data being shared comes from a payment account or some type of unregulated account. Indeed, the data being contributed and shared could come from the customer herself (user-generated information or 'UGC'). In effect, even the information coming from the user's accounts with third parties is effectively user-generated, particularly in terms of whether the service provider takes responsibility for its accuracy and so on.

These licensing issues must also be considered in terms of what licences are required 'upstream' from the customer, the service provider and any sources of data, as well as downstream licenses - and usage restrictions - from the standpoint of the service provider, the customer and third parties receiving the data. These licences are likely to be reflected in an array of different contracts, including customer terms and commercial agreements. Appropriate disclaimers, exclusions and limits on liability must also be considered.

This is where the sanity of specifically regulating payment account information services becomes questionable, as some of the typical commercial requirements may conflict with the liability and information requirements relating to an AIS, in which case it would need to be 'carved-out'.

Conclusion

These are not the only issues related to the supply of account information services or other data services, but they do illustrate the complex challenges arising from the fact that AISPs had to be subjected to regulation for banks to cooperate with them, and yet an AIS involves the supply of data in a way that other regulated payment activity does not, often in combination with other data services.

#PSD2: What Is An Account Information Service?

The Treasury is consulting on its proposed regulations to implement the new Payment Services Directive (PSD2) in the UK.  The consultation ends on 16 March 2017 and the regulations must take effect on 13 January 2018. The FCA will consult on the guidance related to its supervisory role in Q2 2017. Time is tight and there are still plenty of unanswered questions, which I've been covering in a series of posts. In this one, I'm exploring the issues related to the new "account information service", which is being interpreted very broadly indeed by the FCA.  Firms providing such services will need to register with the FCA, rather than become fully authorised (unless they provide other payment services); and they are spared from compliance with a number of provisions that apply to other types of payment service provider. But now is the time for assessing whether a service qualifies, and whether to restructure or become registered.

The Treasury has, naturally, copied the definition from the directive:

‘account information service’ means an online service to provide consolidated information on one or more payment accounts held by the payment service user with either another payment service provider or with more than one payment service provider (article 4(16)) - [my emphasis] - but has added:

"and includes such a service whether information is provided—

(a) in its original form or after processing;

(b) only to the payment service user or to the payment service user and to another person in accordance with the payment service user’s instructions" [which do not appear in PSD2]

This reflects the government's broad definition of the directive (para 6.27 of the consultation paper) - consistent with the UK needlessly creating a rod for its own back and particularly ironic in the light of Brexit. The account information service provider (AISP) should be granted access by the account service provider to the same data on the payment account as the user of that account (para 6.25). A firm will be considered an AISP even if it only "uses" some and not all of that account information to provide "an information service" (para 6.28).

Services that the government believes are AISs include (but are not limited to):

• dashboard services that show aggregated information across a number of payment accounts; 
• price comparison and product identification services;
• income and expenditure analysis, including affordability and credit rating or credit worthiness assessments; and 
• expenditure analysis that alerts users to consequences of particular actions, such as breaching their overdraft limit.

The services could be either standardised or bespoke, so might include accountancy or legal services, for example (para 6.30).

Some key points to consider:

• does it matter to whom the account information service is provided? The additional wording seems to suggest that the 'payment service user' must be at least one recipient of the information, but does that mean the payment service user of the payment account or the person using the account information service?  This would seem to cover every firm that prepares and files tax or VAT returns, for example, since these are usually provided to both the client and HMRC.

• the service has to be "online", but what if some of it is not?

• little seems to turn on the word "consolidated", since the Treasury says a firm only needs to use some of the information from the payment account to be offering an AIS, and it could be from only one payment account. For instance, what if a service provides a simple 'yes' or 'no' to a balance inquiry or request to say whether adequate funds are available in an account, and that 'information' or conclusion/knowledge is not drawn from the payment account itself, but merely based on comparing the balance with the amount in the customer's inquiry or proposed transaction?

• the payment account that the information relates to must be 'held by the payment service user' with one or more PSPs, so presumably this would not include an online data account or electronic statement that shows the amount of funds held for and on behalf of a client in a trust account or other form of safeguarded or segregated account which is in the name of, say, a law firm or crowdfunding platform operator (albeit designated and acknowledged as holding 'client money' or 'customer funds');

• it seems impossible for the relevant data to provided in its 'original form', since data has to be processed in some way to be 'provided' online, but this could cover providers of personal data stores or cloud services that simply hold a copy of your bank data for later access;

• what is meant by 'after processing':

1. it may not be clear that a firm is providing information 'on a payment account', as opposed to the same information from another type of account;

2. does this mean each data processor in a series of processors is providing an AIS to its customer(s) - which brings us back to whether it matters who the customer is - or does interim processing 'break the chain' so that the next processor can say that the information was not 'on a payment account' but came from some other service provider's database (whether or not it was an AIS), such as a credit reference agency?

3. what about accounting/tax software providers providers who calculate your income and expenditure by reference to payment account information but may not necessarily display or 'provide' the underlying data - although presumably the figures for bank account interest income (if any) in a tax return might qualify?

Sorry, more questions than answers at this stage!

Update on 21 April 2017:

The FCA has indicated in Question 25A of its proposed draft changes to the Perimeter Guidance that:

"Account information service providers include businesses that provide users with an electronic “dashboard” where they can view information from various payment accounts in a single place, businesses that use account data to provide users with personalised comparison services, and businesses that, on a user’s instruction, provide information from the user’s various payment accounts to both the user and third party service providers such as financial advisors or credit reference agencies." [my emphasis added]