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.

FCA Irons Out Brexit Wrinkle For UK Open Banking

'Open banking' enables you to use certain 'account information' and 'payment initiation' service providers (TPPs) to extract your payment data or initiate payments from your payment accounts with banks and other payment service providers (ASPSPs). There are 2 million users in the UK. Open Banking was driven by UK competition law enforcement against banks who were hogging access to payment account data; and by changes to the EU Payment Service Directive as a result of similar concerns across Europe. A key feature of the Open Banking regime is that TPPs' systems must authenticate themselves using a certificate that complies with an EU identity regime (eIDAS), from which Britain excluded UK based TPPs by leaving the EU. The FCA has now come up with the quick fix described below to try to support the continuity of Open Banking after 31 December... 

In July, the European Banking Authority confirmed that eIDAS certificates issued to UK-based TPPs by EU trust providers will be revoked on 31 December, even though UK law would recognise them as valid under its new UK eIDAS Regulation. 

The FCA does not have the ability to delay the revocation of eIDAS certificates; there is no scope within eIDAS to issue UK-only certificates; and there are not yet any UK trust providers qualified to issue eIDAS certificates under the new UK eIDAS Regulation. 

That means TPPs in the UK will no longer be able to access their customer’s payment account data held with their account service payment service providers (ASPSPs) after 31 December without a further change to UK eIDAS requirements, so the FCA has amended them to allow for the use of an alternative form of authentication certificate.

As a result of the recent changes, UK ASPSPs must now accept at least one other electronic form of identification issued by an independent third party, in addition to continuing to accept eIDAS certificates. 

The additional form of identification must:

• be a digital certificate issued by an independent third party upon identification and verification of the payment service provider’s identity;
• include the name of the TPP as well as information on the competent authority the TPP is authorised or registered with, and the corresponding registration number (Firm Reference Number (FRN));
  
• be revoked as soon as the TPP is no longer authorised to conduct TPP activities. 

An ASPSP must: 

• verify the authorisation status of the TPP in a way that would not create any obstacles to TPP access;
• satisfy itself of the suitability of the independent third party issuing the certificate;
• specify publicly which means of identification it accepts to ensure TPPs are aware (e.g. on the Open Banking Implementation Entity (OBIE) transparency calendar or on their website).

To ensure continuity of service and enable TPPs to use the existing 90-day reauthentication cycle, the FCA will allow ASPSPs to accept a certificate obtained from a provider of an API programme that does not meet the amended requirements until 30 June 2021, so long as:

• TPPs have also presented a compliant certificate, as described under the amended requirement, to that non-qualifying API programme;
  
• that API programme verifies the certificate; and 
• continues checking, on behalf of the ASPSP, the status of the TPP’s compliant certificate. 

So, a legacy OBIE certificate may be used during that period, provided that the TPP has presented a valid certificate to the OBIE. 

The FCA has removed the need for the certificate to include the address of the TPP and issuer; the need for revoking the certificate if identity information is unverifiable; and the need for a certificate to be amended (as, technically, a certificate can only be revoked). 

ASPSPs must: 

• assess the need for any changes to their systems and processes and implement any necessary changes by 31 December, and tell TPPs which alternative certificate they will accept as early as possible. 
• continue accepting valid eIDAS certificates. This includes for UK firms until their certificates are revoked, even after 31 December where applicable; as well as for EEA-based firms that benefit from the UK's Temporary Permission Regime to continue providing their services in the UK after Brexit.
  

TPPs whose eIDAS certificate is likely to be revoked must have an alternative certificate(s) as soon as possible ahead of 31 December.

New EBA Guidance On Obstacles And Interfaces: Open Payments Under PSD2

Source: Payments Cards & Mobile

The second Payment Services Directive (PSD2) created the need for a regulatory technical standard (RTS) to govern communications among service providers who offer online payment accounts (ASPSPs) and third party service providers (TPPs) that offer account information services (AIS) or payment initiation services (PIS).  From time to time the European Banking Authority (EBA) issues guidance on the interpretation of the RTS in practice. The latest guidance explains certain "obstacles" that ASPSPs must avoid creating for customers who wish to use the services of TPPs. I've summarised the guidance here to make sure I understand it generally, but please let me know if you need advice in any a specific scenario.

ASPSPs must allow TPPs to connect to their systems through either a "dedicated interface" or the same interface that its customers use for authentication and communication. The challenge is that the dedicated interface must not create "obstacles" to the TPP's provision of payment initiation and account information services. The EBA is particularly concerned about scenarios where the customer has to be redirected from the TPP's system to the ASPSP's system in order to be authenticated. TPPs have argued that such redirection is an obstacle to the customer experience in accessing their payment accounts, where that is the only method of authenticating the customer. 

The RTS itself notes some obstacles, but the EBA guidance now provides other examples in terms of:

• the types of authentication procedures that ASPSPs’ interfaces are required to support;
• whether mandatory redirection at the point-of-sale is an obstacle;
• whether multiple Strong Customer Authentications (SCA) can be required;
• whether the 90-days re-authentication requirement can be relaxed;
• the extent to which manual account input/selection is an obstacle;
• whether additional checks on customer consent can be required; and
• what additional registrations might be permissible.

Authentication procedures that ASPSPs’ interfaces must support

If the interfaces provided by ASPSPs do not support all the authentication procedures made available by the ASPSP to its customers, this would be a breach of the RTS and an "obstacle". So, if customers use biometrics or a mobile authentication app to access their account directly with the ASPSP,  then they must also be able to do so when using their payment account via a TPP.  That interface should not create unnecessary friction or add unnecessary steps in the customer journey compared to the direct customer interface. 

Payments at point-of-sale

It has been argued that mandatory redirection to the ASPSP's system when the customer uses a payment initiation service (PIS) offered by a payment initiation service provider (PISP) to initiate a payment at the point-of-sale is an obstacle because redirection only works in a web-browser or mobile apps-based environment. For payment initiation services to work at point-of-sale, PISPs argue that ASPSPs should be required to enable 'decoupled' or 'embedded' authentication flows, even if they don't offer that to their customers when paying directly.

The EBA says that while PSD2 does not oblige ASPSPs to enable PIS-initiated payments using authentication procedures that the ASPSP does not yet offer to its customers directly, if an ASPSP were to offer to its customers the ability to perform instant payments at the point of sale directly, then the ASPSP should also allow its customers to initiate instant payments using a PISPs’ services at the point of sale, within the same amount limits.

Requiring multiple strong customer authentications (SCA)

The authentication of the customer with the ASPSP as part of the TPP user experience using a redirection or decoupled approach would be an "obstacle" if it creates unnecessary friction or add unnecessary steps, compared to the authentication procedure offered by the ASPSP to its customers when accessing their payment accounts or initiating a payment directly.

Similarly, when a customer is using a PISP to initiate a payment, it would be an obstance if one SCA were required to access the account data, and a separate SCA for initiating the payment, unless required by the ASPSP as part of "duly justified security arguments" in a particular case (e.g. suspicion of fraud for a particular transaction) and the ASPSP could substantiate that upon request by the local regulator.

The fact that the ASPSP may require a separate SCA for ‘log-in’ (or to access payment account data more generally) when the customer directly initiates a payment with the ASPSP, is not a sufficient ground to justify applying two SCAs in the PIS scenario.

However, in some PIS journeys customers do not specify which payment account is to be debited in the payment initiation request, and only do that when transferred to the ASPSP’s domain/system. In such cases, it would not be considerd an obstacle for the ASPSP to require one SCA to access the list of payment accounts in its system, and a second SCA to authenticate the payment.

Two SCAs may also be necessary for a combined use of an account information service and a payment initiation service (unless an exemption applies): one to access the payment account data and another to initiate the payment.

90-day re-authentication for Account Information Services (AIS)

The RTS provides an exemption from the requirement to apply SCA for each access to the ASPSPs system where the AIS accesses only a limited set of data (account balance and/or 90 days of payment transactions) and its customers must re-authenticate at least every 90 days. This is to balance ease of use with increased security. The EBA "advises" local regulators to encourage all ASPSPs to use this exemption. 

ASPSPs may also choose to delegate or outsource SCA to TPPs to conduct SCA on the ASPSP’s behalf,  but are not obliged to do so (outsourcing guidelines would apply).

Account input or selection

Interfaces that require customers to manually input their IBAN into the ASPSP’s system in order to be able to use a TPP’s services are an "obstacle".

To avoid this, either: 

• the TPP can seek its customer's consent to retrieve the list of all her accounts with the ASPSP via the ASPSP's interface and display it to the customer in the TPP's system, so she can select the account and the TPP can then request access or initiate a payment using the account details; or

• if the ASPSP has implemented a redirection or decoupled approach and the TPP does not extract and then transmit the account details to the ASPSP with its customers' request,  the customer could select the relevant account(s) on the ASPSPs’ domain during the ASPSP's authentication procedure, in a way that is no more complicated than selecting the account(s) directly with the ASPSP (e.g. via a drop-down list of accounts, or prepopulated account details if only one).

In an "embedded" scenario, however, where the customer's credentials are exchanged between the TPP and the ASPSP and the customer does not interact with the ASPSP to authenticate, a PISP may need to obtain the details of the account from the customer in advance (if it does not also have an AIS license and/or consent from the customer to access the list of accounts). That's because a PISP is not entitled to access the list of all the customer’s payment accounts, as this information goes beyond the scope of data that PISPs have the right to access. So not providing the list of all payment accounts to a PISP is not an "obstacle".

However, even where the customer only selects the account on the ASPSP’s domain, the ASPSP should provide to the PISP the number of the account that was selected and from which the payment was initiated, if this information is also made available to the customer when the payment is initiated directly. Once the account number is provided to the PISP, the ASPSP should not request the customer to re-select that account when using the PISP again, because that would be an "obstacle".

Additional checks on consent

It is the regulatory obligation and the responsibility of each TPP to ensure that it has obtained the customer's explicit consent to the use of its service. The ASPSP must not make its own check for whether the customer gave that consent to the TPP, and it would be an "obstacle" for the ASPSP to require the customer to give that prior consent. 

Similarly, the ASPSPs contract with its customers “should not contain any provisions that would make it more difficult, in any way, to use the payment services of other payment service providers...”. This extends to access by individual authorised users on corporate accounts.

Additional registrations

Requiring a TPP to go through additional registration processes with the ASPSP to access the ASPSP’s interface would be an obstacle, unless (a) technically required to enable a secure communication (e.g. pre-registration to use the ASPSP’s mobile banking app or a dedicated/decoupled app), (b) processed in a timely manner, and (c) does not create unnecessary friction in the customer journey. 

Optional or freely agreed registrations between ASPSP and TPP are permitted (they just can't be imposed by the ASPSP).

It would also be an "obstacle" to require registration steps or processes with the ASPSP in order for the TPP to have access to the ASPSP’s production API, other than the identification of the TPP via an eIDAS certificate.

What Is A "Payment Service"?

I'm often approached by senior managers in businesses who've been asked this question - usually by their credit card acquirer, a financial regulator or a potential customer doing its due diligence. There's often no simple answer, but I've explained the main issues below. Please get in touch if you would like to discuss any of them.

Which types of businesses need to think about this?

This question tends to arises where your business:

• receives cash from one set of customers and makes payments to other customers. Examples range from e-commerce marketplaces, to law firms, to fully regulated payment service providers (including banks, e-money institutions and payment institutions);

• issues vouchers or other forms of value that can be exchanged for goods or services, either from the same business or some other participating retailers or suppliers;

• enables customers to send transaction data to their card acquirer, initiate a payment from their bank account or share bank statements or other financial information with third parties.

Depending on the circumstances any of these activities could mean that you are either:

• offering an "e-money" service and/or a "payment service", in which case you would and need some form of regulatory authorisation or registration; or

• your activities might be outside the scope of regulation, or in scope but specifically excluded from some or all of the authorisation or registration requirements.

How are payment services regulated?

Activities involving e-money and payments are mainly regulated throughout the EEA under national regulations that implement the second Electronic Money Directive (EMD) and the second EU Payment Services Directive (PSD).

These two directives are 'maximum harmonisation' directives, which means each EEA member state is supposed to apply them the same way (subject to a few permitted options). However, the interpretation by one country’s regulator that a service is either out of scope of the EMD and PSD, or in scope but expressly excluded, cannot be ‘passported’ to other EEA countries. So it is prudent to check the interpretation with local counsel in each significant EEA market in which you intend to operate.

If your activities are in scope, and not excluded, then you would need to be authorised as an E-money Institution (EMI) or payment institution (PI), or registered as small EMI or PI or as the agent of an EMI or PI. If you offer 'account information services' then you only need a registration; and some types of exclusion also require you to register with the local regulator.

A fully authorised firm may “passport” its services into other EEA countries (or rely on its principal’s passports if it is a registered agent).  Because of Brexit, however, UK-based institutions would need to set up an entity based in one of the remaining EU27 countries, or an EEA member state, from which to passport services around the EEA; and EEA-based firms can either register for a temporary permission (by 30 January 2020) or set up a UK subsidiary and apply for the relevant authorisation or registration locally.

What is a payment service?

Unless you enable the collection and withdrawal of physical cash, the “payment services” you are most likely to be concerned with involve:

• the 'execution' (processing etc) of payment transactions involving card-based payments, bank/credit transfers, direct debits, either with or without credit;

• money remittance: where funds are received from a payer, without any payment accounts being created in the name of the payer or the payee, for the sole purpose of transferring a corresponding amount to a payee or to another payment service provider acting on behalf of the payee, and/or where such funds are received on behalf of and made available to the payee;

• issuing payment instruments: contracting to provide a payer with a payment instrument to initiate and process the payer’s payment transactions (a payment instrument is any personalised device(s) and/or set of procedures agreed between the user and the service provider that is used to initiate a payment order);

• aquiring payment transactions: contracting with a payee to accept and process payment transactions, which results in a transfer of funds to the payee (e.g. debit/credit card acquiring or 'merchant acquiring');

• payment initiation services: a service to initiate a payment order at the request of the user with respect to a payment account held at another payment service provider; or

• account information services: an online service to provide consolidated information on one or more payment accounts held by the user with on or more other payment service provider(s).

There are many related definitions, but the central one to understand is that a "payment transaction" means "an act initiated by the payer or payee, or on behalf of the payer, of placing, transferring or withdrawing funds [i.e. money, including "e-money"], irrespective of any underlying obligations between the payer and payee." This definition can involve some degree of legal fiction, such as when applied to card acquiring, which actually involves multiple payment transactions.

What is e-money?

The term “electronic money” or "e-money" means monetary value that is:

• electronically stored; 
• represented by a claim on the electronic money issuer, 
• issued on receipt of funds, 
• for the purpose of making “payment transactions”; 
• accepted by a person other than the electronic money issuer; and 
• not a “limited network” service.

"Limited networks" are services based on specific payment instruments that can be used only in a limited way and meet any one or more of the following conditions:

• allow the holder to acquire goods or services only in the issuer's premises;

• are issued by a professional issuer and allow the holder to acquire goods or services only within a limited network of service providers which have direct commercial agreements with the issuer;

• may be used only to acquire a very limited range of goods or services; or

• are valid only in a single EEA State, are provided at the request of an undertaking or a public sector entity, and are regulated by a national or regional public authority for specific social or tax purposes to acquire specific goods or services from suppliers which have a commercial agreement with the issuer.

The exclusion for limited networks also applies to payment services generally. This can include loyalty schemes, fuel card schemes and so on. Some regulators may consider gift cards as falling within this exclusion, while others may not see them as within scope of the PSD at all.

Is the service offered by way of business?

This is where a lot of uncertainty can arise because, in some countries (like the UK), the regulator is only concerned about payments activity that is operated or offered as a business separately or distinctly from any other activity. In other countries, however, this may not be a factor that the regulator considers to be very important, if at all.

So it's worth considering that if you are receiving money and paying it out or holding it on a customer's behalf only as a small part of a much wider service - like, say, a law firm - then it is possible that the local regulator might not consider your payments-related activity to be a "payment service" in its own right (but of course other laws and/or professional rules may apply to those scenarios anyway).

It is also worth exploring any opportunities to re-position or integrate the payments activity so that it is not offered by way of business in its own right.

Even if your activity is in scope, could an exclusion apply?

Some activities that initially meet the test of being a "payment service" might actually benefit from a specific exclusion under the EMD or PSD.  There is quite a long list of possible exclusions. Some reflect day-to-day activies, like paying another person directly, paying by paper cheque etc., or physically transporting cash. Others are quite specialised and/or involve a lot of explanation and the possibility for regulators to interpret them differently, as with the scope of the EMD or PSD.  Exclusions that are likely to involve considerable legal analysis are:

• the commercial agent's exclusion: covers payment transactions from the payer to the payee through a commercial agent authorised via an agreement to negotiate or conclude the sale or purchase of goods or services on behalf of only the payer or only the payee;

• the technical service providers exclusion: covers services which support the provision of payment services, without the service provider entering into possession of the funds to be transferred - like 'payment gateway' services or anti-fraud services, for example. These services include processing and storage of data, trust and privacy protection services, data and entity authentication, information technology (IT) and communication network provision, provision and maintenance of terminals and devices used for payment services, but exclude payment initiation services and account information services;

• the limited network exclusion, which I've already mentioned above in relation to e-money.

Conclusion:
Again, there is often no simple answer as to whether your activities constitute a regulated e-money or payment service, but I've explained the main issues above. Please get in touch if you would like to discuss any of them.

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

Payment Services #.0: When Payments Finally Become Less Visible

Today marks the dawn of new payments regulation under the second Payment Services Directive (PSD2). Yawn, you say. But, unusually for a technology-based industry, the experience for customers should outstrip the hype. Is this Payment Services 2.0? 3.0? 4.0?  Who cares? After all, "paying" for something or "checking your balance" should not be an activity all on its own. It should be just a small part of something else you're in the middle of doing. In other words, it's what you won't see that should make all the difference...

You might not deal with your bank anymore when paying or checking statements

New “payment initiation services” will mean you can use a separate service provider to make payments from your bank account or other payment accounts, without logging-in to your payment account provider's systems.

New “account information services” will combine the information from all your payment accounts and display it to you in one place. You could also permit that information to be sent to others (e.g. a lender, a comparison website or professional adviser). 

Not only will such services cut the amount of time you spend logging-in to different providers. They'll also make it easier for you to gather your financial information, understand and control your financial affairs and make payments from a range of accounts. 

You won't see retailers charging you for the privilege of paying them

From now on, nobody can add a charge based purely on how you pay them. So all their profit will be in the price of the goods or services you buy, not the extras. 

The UK has typically gone further than other EU countries to apply this to every type of consumer payment method. So, any contract term requiring such a 'surcharge' will not be enforceable. In fact, there will be an implied requirement to refund the excess. Or you could initiate a chargeback via your debit/credit card issuer, or make a claim against your credit card issuer under section 75 of the Consumer Credit Act. 

In addition, any extra charge for using a commercial payment method must be limited to the supplier's cost of accepting that type of payment. Again, no room for extra margin here.

You won't realise that big loyalty schemes are now policed by the FCA

Retail loyalty schemes, such as gift cards, fuel cards and other ‘limited network’ programmes, will need to be registered with the Financial Conduct Authority if the value of their transactions meets or exceeds €1 million (or the GBP equivalent) in any 12 month period.

The intention is to safeguard customer funds that are paid into wider schemes, as with any other e-money or payment service.

The FCA must then decide if the scheme really is a ‘limited network’ that's entitled to an exclusion from e-money and payments regulation. 

If not, then the retailer may have already committed an offence by offering the scheme in the first place.

The retailer also commits an offence if it fails to notify the FCA within 28 days after reaching the €1 million threshold. So retailers should check the status of their loyalty programmes well before then!

You will see less delay in handling your complaints 

The time for processing customer complaints has been cut from 8 weeks to 15 business days. This increases the pressure on payment service providers to operate much more efficiently, so they have fewer complaints and find it easier and less costly to solve any problems you do have. 

You won't see the increased security

You won't see all the standards-setting and development work that's going on behind the scenes to make all of this happen in a far more secure way than payment services have worked before.

The new regulations bring mandatory technical standards for better ways to make sure customers are who they claim to be, and for the different types of payment service providers to work together where you need them to do so.

So, finally, "payments" will become less visible... if you know what I mean.

Fake News, Screen-scraping and the European Banking Federation #PSD2

The old row between new financial service providers and the European Banking Federation has blown up again. At issue is whether the providers of new regulated "account information" services that rely on access to your payment account data should be able to copy it from your online account ('screen-scraping') or only get it through a different type of interface (API) directly provided and controlled by the bank.

Rather typically, the EBF has produced a video that purports to explain 'screen-scraping' (which could be done in a single slide) but actually misleads by suggesting that the motives of the new service providers who want to do it are unlawful. 

Of course, the method of accessing the account information really has nothing to do with the motives of this new type of regulated service provider.

Instead, the EBF's tactics merely reflects the major banks' age-old resistance to anyone else using "their" payment data to provide you with services that are more useful than the very limited data and features available in your bank account. In fact, that resistance led retailers to launch 'loyalty' programmes and behavioural targeting of advertising as far less efficient ways of figuring what you like to spend your money on.

But the data in your payment account is your data, and you should be able to combine it with your other data - or have trusted third parties do that for you - if you wish. 

That's why - refreshingly - the authorities insisted that PSD2 should specifically regulate the new 'account information service providers'; and, crucially, requires banks to make your payment account available to them, precisely so that you can - if you wish to - rely on their services to make sense of your financial affairs or know how much money you have available while shopping etc., without having to log-in to your bank account(s). 

PSD2 also obliges your payment account information service provider to comply with security and data protection requirements when accessing and handling your payment data, regardless of how they get access to that information. 

So, the latest dust-up is is really just an (old) technological argument about whether a service provider should use your log-in credentials to copy the information from the screen that you see, or only access the data through an interface provided (possibly badly) by the bank. It has nothing to do with the possible motives of the service provider in using the data - and they have to behave lawfully anyway.

The fact that the EBF has resorted to fake news and moral panic tells me that any real 'arguments' against screen-scraping are very weak indeed...

#PSD2: The FCA Clarifies The "Business Test"

In deciding whether or not a firm's activities are caught by the new Payment Services Directive (PSD2) as implemented in the UK by new Payment Services Regulations, one needs to first consider whether the activities are conducted by way of business. This is a question of fact and degree that can be difficult to answer. In the consultation on its approach to supervising the new regulations, the Financial Conduct Authority has helpfully done a lot more than it has in other areas to clarify when it considers that a payment activity will constitute 'a regular occupation or business' in itself, as opposed to being merely part of another type of business.

FCA's current guidance on the Payment Services Regulations 2009 states (at PERG 15.2, Q.9):

“…Simply because you provide payment services as part of your business does not mean that you require authorisation or registration. You have to be providing payment services, themselves, as a regular occupation or business to fall within the scope of the regulations. Accordingly, we would not generally expect solicitors or broker dealers, for example, to be providing payment services for the purpose of the regulations merely through operating their client accounts in connection with their main professional activities.”

The FCA has revised Question 9 as part of its proposed draft changes to the Perimeter Guidance to read as follows:

"Q9. If we provide payment services to our clients, will we always require authorisation or registration under the regulations?

Not necessarily; you will only be providing payment services, for the purpose of the regulations, when you carry on one or more of the activities in PERG 15 Annex 2:

• as a regular occupation or business activity; and

• these are not excluded or exempt activities.

Simply because you provide payment services as part of your business does not mean that you require authorisation or registration. You have to be providing payment services, themselves, as a regular occupation or business to fall within the scope of the regulations (see definition of "payment services" in regulation 2(1)). In our view this means that the services must be provided as a regular occupation or business activity in their own right and not merely as ancillary to another business activity. Accordingly, we would not generally expect the following to be providing payment services as a regular occupation or business activity:

• solicitors or broker dealers, merely through operating their client accounts in connection with their main professional activities;

• letting agents, handling tenants’ deposits or rent payments in connection with the letting of a property by them;

• debt management companies, receiving funds from and making repayments for a customer as part of a debt management plan being administered for that customer; and

• operators of loan or investment based crowd funding platforms transferring funds between participants as part of that activity.

The fact that a service is provided as part of a package with other services does not, however, necessarily make it ancillary to those services – the question is whether that service is, on the facts, itself carried on as a regular occupation or business activity."

Simlarly, in Question 38, the FCA proposes to state:

"Q38. We are an investment firm providing investment services to our clients - are payment transactions relating to these services caught by the regulations?

Generally, no. Where payment transactions only arise in connection with your the main activity of providing investment services, in our view it is unlikely that you will be providing payment services by way of business. In those limited cases where you are, the PSRs 2017 do not apply to securities assets servicing, including dividends, income or other distributions and redemption or sale (see PERG 15 Annex 3, paragraph (i))."

In relation to e-commerce marketplaces, the FCA proposes to add the following question to its Perimeter Guidance:

"Q33A. We are an e-commerce platform that collects payments from buyers of goods and services and then remits the funds to the merchants who sell goods and services through us – do the regulations apply to us?

The platform should consider whether they fall within the exclusion at PERG 15 Annex 3, paragraph (b). The PSRs 2017 do not apply to payment transactions from the payer to the payee through a commercial agent authorised via an agreement to negotiate or conclude the sale or purchase of goods or services on behalf of either the payer or the payee but not both the payer and the payee.

Recital 11 of PSD2 makes clear that some e-commerce platforms are intended to be within the scope of regulation. An example of where a platform will be acting for both the payer and the payee would be where the platform allows a payer to transfer funds into an account that it controls or manages, but this does not constitute settlement of the payer’s debt to the payee, and then the platform transfers corresponding amounts to the payee, pursuant to an agreement with the payee.

The platform should also consider whether they are offering payment services as a regular occupation or business activity (see Q9). Depending on your business model, the payment service may be ancillary to another business activity, or may be a business activity in its own right. Where the payment service is carried on as a regular occupation or business activity, and none of the exclusions apply, the platform will need to be authorised or registered."

The FCA also proposes to add Question 34A relating to "online fundraising platforms":

"Q34A. We are an online fundraising platform which collects donations in the form of electronic payments and transmits funds electronically to the causes and charities that have an agreement with us - do any of the exclusions apply to us?

Persons collecting cash on behalf of a charity and then transferring the cash to the charity electronically do not fall within the exclusion in PERG 15 Annex 3, paragraph (d), unless they themselves are carrying this out non-professionally and as part of a not-for-profit or charitable activity. For example, a group of volunteers that organises regular fundraising events to collect money for charities would fall within this exclusion. On the other hand, an online fundraising platform that derives an income stream from charging charities a percentage of the money raised for them is unlikely to fall within this exclusion.

Nor will an online fundraising platform accepting donations and then transmitting them to the intended recipient be able to take advantage of the exclusion in paragraph (b), as they are not a commercial agent authorised via an agreement to negotiate or conclude the sale or purchase of goods or services on behalf of either the payer or the payee but not both the payer and the payee.

Online fundraising platforms should also consider the guidance in Q33A."

There may be some confusion over whether a platform is an "online fundraising platform" covered by Questions 33A and 34A, as opposed to a 'donation/reward based crowdfunding platform' which I would suggest should be treated consistently with loan/investment based crowdfunding platforms under Question 9 above.

Consultations On Supervision Of New Payment Services Regs Under #PSD2

The FCA is consulting on its approach to supervising the new regulations that will implement PSD2. It's a huge job, and delays to the release of the draft regulations has left little time to prepare for the regulations to take effect from 13 January 2018. Responses to the FCA consultation are due by 8 June 2017, and can be provided online. 

The consultation is explained in the first 60 pages of the main policy document, and the detailed changes to the FCA Handbook is in the Annexes (another 217 pages worth!), including important updates to the 'perimeter guidance' on activities that are in scope, out of scope or excluded (Annex K from page 223 of the PDF version).

The FCA has also helpfully published a mark-up showing changes to its Approach Document that explains how it regulates the current PSD. The regulations are still in draft, so the FCA's guidance may also change if the regulations do; and there are certain 'regulatory technical standards' being developed that could also produce changes over time.

Meanwhile, the Payment Services Regulator has also issued its guidance on how the draft regulations impact its supervision of payment systems.

Unfortunately, the UK's view of PSD2 may not be consistent with other member states, and further divergence could occur after Brexit. The main consequences of this are explained in my answer to Question 1 of the Treasury consultation.

I will likely publish my general observations on the FCA's proposed changes in the coming weeks, where possible. 

In the meantime, my general response to the Treasury consultation on the draft Payment Services Regulations is here; and I've also previously posted on the following general issues under PSD2:

• Loyalty schemes with volumes over €1m (or GBP equivalent) must register with FCA, which must decide if they are a ‘limited network’; 
• Are Merchant Checkouts ‘Payment Instruments’? – may impact how checkout processes are structured/hosted and who by; 
• What is a ‘Payment Initiation Service’? – could affect merchants and various ‘technical service providers’ who support payment processes but don’t handle funds; 
• What is an ‘Account Information Service’? – new issue for accountants, personal data aggregators, cloud storage providers etc. who handle payment account data; 
• Are ‘bill payment services’ in or out of scope of new UK payments regs? 
• Post-Brexit outlook for passporting – if you need to get authorised to offer services across EU/UK, where do you do it? 

#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]