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.

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.

#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: Are Merchant Checkouts "Payment Instruments"?

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 whether online merchants' checkout process/pages could be "payment instruments", so that merchants who host their own process might be engaging in the regulated activity of "issuing payment instruments" (and possibly even offering a "payment initiation service"). There is now precious little time for retailers to consider the issue,  decide whether their activities are caught and, if so, whether to outsource the hosting of the checkout process to a duly authorised firm or its agent, restructure the checkout process or the entity/ies that operates it, or become authorised or the agent of an authorised firm.

Everyone is familiar with the e-commerce 'checkout' page or process, with its list of ways to pay for the items selected or in the 'shopping basket'. Sometimes these are hosted by a regulated payment service provider, an exempt 'technical service provider' or 'gateway', and sometimes by the merchant itself (in which case the merchant has to comply with certain security requirements in relation to card transaction data, for example). 

Whether technical service providers who are currently exempt will remain so under PSD2 is already an open issue, since to remain so they cannot also provide either a payment initiation service or an account information service, even though they still would not be handling the funds to be transferred.

The big question is whether merchants themselves fall into the regulated scope, especially as they ultimately receive funds, so might not qualify as technical service providers.

First, a few (of the many) relevant definitions:

“issuing of payment instruments” means a payment service by a payment service provider contracting to provide a payer with a payment instrument to initiate and process the payer’s payment transactions;

“payment instrument” means any— (a) personalised device; or (b) personalised set of procedures agreed between the payment service user and the payment service provider, used by the payment service user in order to initiate a payment order;

“co-badged”, in relation to a payment instrument, refers to an instrument on which is included two or more payment brands, or two or more payment applications of the same payment brand;

Note that the references to 'payment service' and 'payment service provider' are redundant or circular - essentially, they mean anyone who is, or should be, authorised to provide a regulated payment service. The reference to 'co-badging' is important as certain information could have to be provided under the Merchant Interchange Fee Regulations.

I think the primary questions are as follows, but the answers would vary considerably according to the payment method and other facts and circumstances:

• which payment transaction is involved in the relevant scenario, and who is the relevant 'payer'?

• is the checkout process/page a "personalised device"; or "personalised set of procedures agreed between" the customer and the merchant?

• if so, is the checkout process/page "used by the payment service user" (again, see here)?

• if so, is the payment service user using the checkout process/page "in order to initiate a payment order"... as explained previously...or 'payment transactions'?

• finally, how much processing would a merchant have to do to fall within the meaning of "initiate and process the payer's payment transactions": so, when does that processing begin and end; what steps/participants are involved; what is the nature of the processing (e.g. does it send transaction data to a payment gateway, acquirer or other type of payment service provider?); is the merchant acting as principal, agent or payee?

Hopefully, the Treasury and FCA will explain their interpretation soon!

#PSD2: What Is A Payment Initiation Service?

The Treasury is currently consulting on regulations to implement the new Payment Services Directive (PSD2). There is little commentary in the consultation paper and many old questions remain unanswered, with the regulations to go live on 13 January 2018.  Government policy is to simply gold plate 'copy out' EU directives, which creates a rod for the UK's own back leaves the FCA to say how it will interpret the new rules in a consultation paper it proposes to issue in Q2.  But some new services will be regulated, and time is getting very tight for firms who offer them to figure out whether to outsource the operation of the service to a duly authorised firm or its agent, or become authorised or the agent of an authorised firm. In this post, I'll briefly explore the new regulated service of "payment initiation" and why it takes a very careful analysis of the facts to figure out who is offering that service in any given payment scenario.

The decision to regulate "payment initiation services" is said to have resulted from the popularity of services that enable you to pay for online purchases by making a bank transfer (see recital 27 and the Commission's FAQs 18, 21).

But "payment initiation service" seems to have been defined in article 3 to cover any payment method:

“a service to initiate a payment order at the request of the payment service user with respect to a payment account held at another payment service provider .”

Note also, that a "payment instrument" is defined as "a personalised device(s) and/or set of procedures agreed between the payment service user and the payment service provider and used in order to initiate a payment order.

The UK government also says it reads the definition of "payment initiation service" broadly and that users will have the right to use payment initiation services in connection with all online payment accounts, including current accounts, credit card accounts, savings and e-money accounts (paras 6.22, 6.23 and 6.27).  That makes sense, as to exclude providers of payment initiation services for some payment methods and not others would be discriminatory, and shield the excluded firms from competition (see PSD2 recitals 29, 32 and 68).

There is no definition of “initiate a payment order” in PSD2 and different payment methods comprise different processes, actors and events - and sometimes several payment transactions are involved, as in the case of card payments (see PSD2 recital 68).

The European Banking Authority has issued regulatory technical standard for security of online payments that also identifies "payment integrators" as firms who "provide the payee (i.e. the e -merchant) with a standardised interface to payment initiation services provided by PSPs". In other words, even within the payment initiation process, there are technical service providers who support the process but are not responsible for the "payment initiation service" that initiates the relevant payment order.

So when considering who is providing a payment initiation service, one needs to consider: which type of payment method or instrument is being used; which of potentially several payment orders is involved; which payment account each order relates to; which payment service user is making the request to initiate the relevant payment order; which element of which service actually initiates that payment order; and who provides that service.

Yet there are divergent views on who initiates card payments, for example, since there are actually multiple transactions involved...

PSD2 concedes (at recital 68) there are (at least) three steps to a credit card payment - authorisation, an initial transaction where the issuer pays the acquirer (which can be a complex netting process involving a scheme operator), and a later one between cardholder's bank and the issuer (to pay the card bill). There's a third, of course, where the acquirer pays the merchant - and the fact this is not mentioned in the recital underscores why it is silly to refer to the cardholder as the 'payer' and merchant as his intended 'payee', since the cardholder intends to pay the card issuer, rather than the merchant. 

Recital 68 sidesteps the critical issue by stating that the "use of a card or card-based instrument... triggers" the whole payment flow, as does the provision that addresses the scenario where the card issuer is separate from operator of the related payment account:

"the payer has initiated the card-based payment transaction for the amount in question using a card based payment instrument issued by the payment service provider" (Article 65(2)(b))

"Payer" means either "a natural or legal person who holds a payment account and allows a payment order from that payment account, or, where there is no payment account, a natural or legal person who gives a payment order.

"Allowing" a payment order is not necessarily the same as "initiating" what has been 'allowed'.  And it's important to consider which payment instrument is being used and who really 'uses' it.

So it's easy to see why, in the context of a credit card payment, there is disagreement as to whether the cardholder is initiating one or more payment order(s) when offering to pay by card and/or entering her PIN in the relevant card terminal; or the merchant initiates a payment order when it accepts the transaction at the terminal and/or sends the transaction to the acquirer; or whether the acquirer initiates the first payment order when it accepts the transaction from the merchant and/or submits the transaction to the card issuer via the card scheme systems. 

Only when you determine the answer to this question can you then identify the payment method or instrument involved; the relevant payment order; the payment account to which the order relates; the payment service user who is making the request to initiate the order; which element of which service actually initiates that payment order; and who provides that service. 

Clearly, it's important for the authorities to provide greater clarity here; and it looks like the EU and the Treasury has left it to the FCA to do so...

Update on 21 April 2017:

In its consultation, the FCA proposes to add the following Question 25B to its Perimeter Guidance:

"Q25B. When might we be providing a payment initiation service?

The service of payment initiation is defined in regulation 2 as “a service to initiate a payment order at the request of the payment service user with respect to a payment account held at another payment service provider”.

This includes businesses that contract with online merchants to enable customers to purchase goods or services through their online banking facilities, instead of using a payment instrument or other payment method. However, it is not limited to arrangements where the service provider has a pre-existing relationship with the merchant. Any business offering payment initiation services as a regular occupation or business activity will require this permission unless exempt under Schedule 1 Part 2.

In our view, the provider of a service that transmits a payer’s card details, along with a payment order, to the payer’s payment service provider, but does not come into possession of personalised security credentials, is not carrying out a payment initiation service."