Deadline For SCA On E-commerce Transactions Slips Again

Once upon a time, the second Payment Services Directive required mandated the introduction of 'strong customer authentication' (SCA) - also known as 'two factor authentication' or 'multi-factor authentication' - for remote and electronic payment transactions from 14 September 2019. But fear that consumers will abandon online transactions, lack of industry preparation and then the pandemic have seen this rather battered can being kicked steadily further down the road. The UK's Financial Conduct Authority has now declared the latest 'deadline' to be 14 March 2022.

This time it might be serious.

UK Changes To Strong Customer Authentication and Payments Guidance

The FCA is consulting on some noteworthy changes to certain technical aspects of payments regulation and related guidance. Responses to the questions relating to contactless payments should be answered by 24 February 2021, and on the other aspects of the consultation by 30 April 2021. If you need assistance on any of these issues, please let me know.

Specifically, the FCA is changing the regulatory technical standards applicable to strong customer authentication (SCA) to: 

• create a new SCA exemption in Article 10A so that a customer's payment account provider (ASPSP) does not need to require the customer to reauthenticate every 90 days when accessing account information through an account information service provider (AISP or TPP);
• limit the scope of the existing Article 10 exemption to when the customer accesses their information directly;
• add a requirement where a TPP continues to accesses account information where the customer does not actively request, the TPP will need to reconfirm the customer’s explicit consent every 90 days and disconnect access/stop collecting data if a customer fails to re‑confirm their consent.
  
• require certain ASPSPs to allow access by TPPs to payment accounts via 'dedicated interfaces' rather than modifed customer interfaces for personal and SME ‘current accounts’ ("payment accounts" under the Payment Account Regulations) and credit card accounts held by consumers or SMEs.
• require that the technical specifications and testing facility only be made available to TPPs from the launch of new products and services, rather than 6 months in advance and that the requirement for a fallback interface should only take effect six months after launch.
• allow ASPSPs to rely on exemptions from setting up a fallback interface granted by home state competent authorities;
  
• amend the threshold at which SCA must be applied to a single payment from £45 to £100-£120 and the threshold value for cumulative contactless payments from £130 to £200.

In addition, the FCA will amend its guidance in the "Approach Document" on how it supervises SCA to be consistent with the above changes and with existing EBA and European Commission guidance as follows:

• SCA would need to be reapplied where the final amount of a payment is higher than the original amount authorised, so long as the final payment is reasonably within the amount the customer agreed to when authorising the payment and not higher by more than 20% and the customer has agreed to the possibility before authorising the original amount. 
• the payee’s PSP (e.g. merchant acquirer) should be liable where it triggers an SCA exemption and the transaction is carried out without applying SCA, so (other than where the
  payer has acted fraudulently) the payer’s PSP would refund the customer and be entitled to reimbursement by the payee’s PSP.
• for the purpose of what can be used to satisfy two of the three SCA authentication factors (knowledge (something only the user knows), possession (something only the user possesses) and inherence (something the user is)): a device could only be used as evidence of 'possession' where there is a reliable means to that the device is actually in the customer's possession; static card data cannot satisfy either the 'knowledge' or 'possession' factor; behavioural biometrics may satisfy the 'inherence' factor (as they ‘relate to physical properties of body parts, physiological characteristics and behavioural processes created by the body.
  and any combination of these) but not other individual properties, such as spending patterns.
• the fraud rate calculation used to anyalyse whether transaction risk is low enough to justify the exemption from SCA should only include unauthorised or fraudulent remote electronic transactions for which the PSP was liable, and no other types of transactions (unlike the calculation for payments fraud reporting under REP017).
• the corporate exemption is applicable to cards or payment instruments that are ‘only
  available to payers who are not consumers’, i.e. only available to corporate customers.
• the authentication elements the customer uses to access their payment account online (including via a mobile) may be reused if they then initiate a payment within the same online session), so a customer could authenticate the payment only one extra element where the firm relies on the account log-in password, for example (as long as the dynamic linking element is linked to the SCA element used when the payment is initiated).
• merchant-initiated transactions: transactions initiated by the payee only, without any involvement from the payer, are not in scope of SCA. While card‑based payments generally imply an action by the payer and are considered as 'transactions initiated by the payer, through the payee',
  where a payer has given a mandate to the payee/merchant for a transaction, or series of
  transactions, made using a card or other payment instrument then the payments
  initiated pursuant to this mandate are outside of the scope of SCA  That includes payments made under continuous payment authorities such as a subscription for a streaming service, but SCA is required to set up the mandate.
• in order to monitor the contactless exemption thresholds, firms use a counter that is either host‑based, on a device (which won't count offline transactions); or chip‑based, on the physical card, (which will count both online and offline transactions), but in either case firms should consider the risk of unauthorised or non‑compliant contactless transactions being made and monitor the effects of the option in practice.
  
• clarify that ASPSPs must share with payment information service providers (PISPs): the name of the account holder (if the name is shown to the customer in their online account); and the account number and the sort code (if these are shown to the customer after they make a payment). 
• reflect the fact that ASPSPs must accept at least one other electronic means of identification issued by an independent party, in addition to eIDAS certificates (Article 34 of the SCA‑RT). 
  

The FCA will also amend its guidance in the "Approach Document" on how it more generally supervises the regulation of e-money and payment services to: 

• make the temporary Covid19 guidance on safeguarding permanent and to extend guidance on risks and controls relating to the insurance method of safeguarding to the guarantee method of safeguarding;
  
• include guidance on the Treasury's proposed special administration regime for e-money and payment institutions;
  
• reflect the extension of the FCA’s Principles for Businesses to the provision of payment services and issuing of e‑money by certain PSPs and e‑money issuers;
  
• reflect the application of certain communication rules and guidance in the Banking Conduct of Business Sourcebook (BCOBS) to communications with payment service and e‑money customers and the communication and marketing of currency transfer services;
• clarify the FCA's expectations on notifications under the electronic communications exclusion (ECE) and limited network exclusion (LNE) including more detail on the types of information expected as part of a firm’s notification and the types of firms that may be able to benefit from the LNE;
• update certain reporting requirements;
• reflect changes following EU withdrawal and the end of the transition period, and the application of our rules and guidance to firms in one of the temporary permission schemes designed to replace passporting as the basis for EEA-based EMIs, PIs and RAISPs to continue operating in the UK for 3 years after the end of the transition period. 

If you need assistance on any of these issues, please let me know.

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.

The End Of Unilateral Change In Contracts For Payment Services? No! [Updated]

This is the final post about some awkward PSD2 issues that were recently referred to the European Court of Justice. The initial post sets out the facts and the four issues referred to the ECJ. The second post addresses the Avocate General's opinion that the contactless feature of a credit or debit card is a separate payment instrument in its own right. The third examines the AG's view that making contactless payments with a debit or credit payment card means the cardholder is using the card "anonymously". The fourth explores whether a card issuer can agree with the cardholder that it is not technically feasible to block the card or prevent further use of the payment instrument if it is lost, stolen etc., even when it is possible to block it.

This post examines the view of the AG (and the Austrian court) that a payment service provider can only rely on the regulation allowing automatic changes to its contracts for "non-essential changes", citing German court rulings that such acceptance "cannot extend to substantial contractual changes."

 

[Update, Spoiler alert 17.11.20: the ECJ did not agree (see end of this post).

Why is this important?

This is a huge issue for the payments industry, because it is very expensive in time and resources to re-issue contracts to large numbers of customers, many of whom will simply not bother to open and/or reply without significant prompting. Enabling changes to be made on notice, with a right to terminate if the changes aren't accepted, means that customers can choose to ignore the correspondence yet continue to receive the payment services. Preventing it means services will cease unless customers open, read and say they accept.

These practicalities are recognised in the recitals to PSD2:

(57) In practice, framework contracts and the payment transactions covered by them are far more common and economically significant than single payment transactions. If there is a payment account or a specific payment instrument, a framework contract is required.

(60) The way in which the required information is to be given by the payment service provider to the payment service user should take into account the needs of the latter as well as practical technical aspects and cost-efficiency depending on the situation with regard to the agreement in the respective payment service contract.

(63) In order to ensure a high level of consumer protection, Member States should, in the interests of the consumer, be able to maintain or introduce restrictions or prohibitions on unilateral changes in the conditions of a framework contract, for instance if there is no justified reason for such a change.

This last recital is important, because national contract laws do generally offer consumers protection from the abuse of unilateral change arrangements, as discussed below. The point here is whether PSD2 allows such arrangements to be agreed for all changes to payment services contracts, or just "non-essential changes." 

What does PSD2 allow?

The relevant provisions of PSD2 are as follows:

‘framework contract’ means a payment service contract which governs the future execution of individual and successive payment transactions and which may contain the obligation and conditions for setting up a payment account;

Article 51 Prior general information

1. Member States shall require that, in good time before the payment service user is bound by any framework contract or offer, the payment service provider provide the payment service user on paper or on another durable medium with the information and conditions specified in Article 52...

2. If the framework contract has been concluded at the request of the payment service user using a means of distance communication which does not enable the payment service provider to comply with paragraph 1, the payment service provider shall fulfil its obligations under that paragraph immediately after conclusion of the framework contract.

3. The obligations under paragraph 1 may also be discharged by providing a copy of the draft framework contract including the information and conditions specified in Article 52.

Article 52 Information and conditions

Member States shall ensure that the following information and conditions are provided to the payment service user:...6. on changes to, and termination of, the framework contract:

(a) if agreed, information that the payment service user will be deemed to have accepted changes in the conditions in accordance with Article 54, unless the payment service user notifies the payment service provider before the date of their proposed date of entry into force that they are not accepted;... 

(c) the right of the payment service user to terminate the framework contract and any agreements relating to termination in accordance with Article 54(1) ...

Article 54 Changes in conditions of the framework contract

1. Any changes in the framework contract or in the information and conditions specified in Article 52 shall be proposed by the payment service provider in the same way as provided for in Article 51(1) and no later than 2 months before their proposed date of application. The payment service user can either accept or reject the changes before the date of their proposed date of entry into force.

Where applicable in accordance with point (6)(a) of Article 52, the payment service provider shall inform the payment service user that it is to be deemed to have accepted those changes if it does not notify the payment service provider before the proposed date of their entry into force that they are not accepted. The payment service provider shall also inform the payment service user that, in the event that the payment service user rejects those changes, the payment service user has the right to terminate the framework contract free of charge and with effect at any time until the date when the changes would have applied.

2. Changes in the interest or exchange rates may be applied immediately and without notice, provided that such a right is agreed upon in the framework contract and that the changes in the interest or exchange rates are based on the reference interest or exchange rates agreed on in accordance with point (3)(b) and (c) of Article 52...

The first point to note is that it is mandatory to enable payment service provicers and customers to agree a unilateral change process: "Member States shall ensure... if agreed... in accordance with Article 54... Any changes...specified in Article 52 shall be proposed...".

Secondly, there is no distinction made for the type of changes to the framework contract that can be covered by the unilateral change process, except to say that changes in interest or exchange rates based on agreed reference may be applied immediately and without notice, if that is also agreed.

Consumer Protection

This is not to say that consumers are not protected against the abuse of a unilateral change arrangement - it's just that those protections are not stated in PSD2 as conditions attaching to its use. 

The need for the unilateral change arrangement to be "agreed" provides the necessary hook for local law "restrictions or prohibitions" of the kind contemplated by recital 63, namely "in the interests of the consumer... for instance if there is no justified reason for such a change." 

But I would submit such restrictions or prohibitions cannot distinguish between types of change, even if, for example, they require a "justified reason" for every type of change.

Under English law, for example, independently of the unilateral change arrangements in the Payment Services Regulations 2017, the parties to a contract can agree that one party has the right to unilaterally vary it, but some constraints apply to how that right is exercised. For instance:

• any clause in a business-to-business contract that is subject to the Unfair Contract Terms Act 1977 (UCTA) which allows a party to perform in a way that is substantially different to what was reasonably expected will be void unless it passes the test of reasonableness; 
• various terms giving traders the unilateral right to change the terms of a contract, the characteristics of the products supplied or the price payable under the contract are grey-listed in the Consumer Rights Act 2015 under suspicion of being unfair, with an exception for financial services contracts (particularly those for an indefinite duration) that reflects the type of mechanism specified in PSD2 (paragraphs 21-23 of Schedule 2); 
• the courts may imply a term that such a right must not be exercised capriciously, arbitrarily or for an improper purpose (Nash v Paragon Finance), except in the case of a decision whether to exercise an absolute contract right (The Product Star (2)).

In Ireland, the unilateral change arrangement in PSD2 is included in the European Union (Payment Services) Regulations 2018. In addition, the European Communities (Unfair Terms in Consumer Contracts) Regulations, 1995 allows terms under which a seller or supplier reserves the right to alter unilaterally the conditions of a contract of indeterminate duration, provided that he is required to inform the consumer with reasonable notice and that the consumer is free to dissolve the contract.

In the case at hand, my view is that the unilateral change clause is not of itself unfair or unreasonable etc., but the clauses that wrongly claim the bank is unable to prove a payment was authorised or is technically unable to block contactless use might be impeached (whether under UCTA, or on grounds of mistake etc as explained in previous posts). 

What is a non-essential change?

At any rate, even if the relevant provisions in PSD2 were to support the restriction of unilateral change arrangements to "non-essential changes" (which they do not, as explained above) that would beg the question what a "non-essential change" might be and, if it is non-essential, why the service provider would bother with the change at all. 

The risk of uncertainty on this point is that service providers will err on the side of caution, thereby increasing cost and inconvenience to consumers with the risk that their payment services will cease for lack of agreement to contract changes that consumers view as mundane, possibly without them having any ready alternative.

Indeed, an essential change (to comply with a change in the law, improved security etc) might be very much in the consumer's interest, particularly where necessary to efficiently ensure the continued use of the service, while minimising the associated cost and inefficiency (as per recital 60). It would seem harsh and disproportionate to deprive them of that benefit for merely failing to read their correspondence and signify acceptance that could otherwise have been rightly taken for granted (with the right to terminate if not).

Post Script 17.11.20

Great news! The ECJ has held that the unilateral change mechanism in PSD2 (Directive 2015/2366) can be used for both consumer/micro-enterprise customers and larger corporate customers (subject to the corporate opt-out) and there is no limit to the type of contractual changes that can be made using the unilateral change mechanism under PSD2. However, where the customer is a consumer the changes themselves can be assessed for unfairness under the Unfair Terms in Consumer Contracts Directive 1993 (Directive 93/13):

Consequently, the answer to the first question is that Article 52(6)(a) of Directive 2015/2366, read in conjunction with Article 54(1) thereof, must be interpreted to the effect that it governs the information and conditions to be provided by a payment service provider wishing to agree, with a user of its services, on tacit consent with regard to changes, in accordance with the detailed rules laid down in those provisions, of the framework contract that they have concluded, but does not lay down restrictions regarding the status of the user or the type of contractual terms that may be the subject of such tacit consent, without prejudice, however, where the user is a consumer, to a possible review of the unfairness of those terms in the light of the provisions of Directive 93/13.

Can A Bank Make You Agree That Your Card Cannot Be Blocked When It Actually Can Be Blocked?

This is the fifty seventh fourth post in a series about some awkward issues under PSD2 that were recently referred to the European Court of Justice. The initial post sets out the facts and the four issues referred to the ECJ. The second post addresses the Avocate General's opinion that the contactless feature of a credit or debit card is a separate payment instrument in its own right. The third examines the AG's view that making contactless payments with a debit or credit payment card means the cardholder is using the card "anonymously". In this post, I explore whether a card issuer can agree with the cardholder that it is not technically feasible to block the card or prevent further use of the payment instrument if it is lost, stolen etc., even when it is possible to block it. Again, the two prior judgments in the Austrian courts effectively found that the bank cannot validly get customers to agree to something that is factually wrong. In this instance the AG appears to agree (and that it is possible to block contactless use).

 

[Update, spoiler alert 17.11.20: the ECJ agreed with the AG. See end of this post]

This issue is important because payment service providers could escape certain liability if contactless functionality is treated separately as a "payment instrument which, according to the framework contract, solely concerns individual payment transactions not exceeding EUR 30... if the payment instrument does not allow its blocking or prevention of its further use."

In this case, the bank stated in its card terms (the "framework contract") that "it is technically impossible for the debit card to be blocked when used for low-value transactions" and, if lost etc. "it shall still be open to use for low value payments not requiring a PIN up to a value of EUR 75, even after a block has been placed on the card [for higher value transactions]..."  so "payments may not exceed EUR 25 per individual transaction and the debit card cannot be blocked for low-value payments made without entering a PIN..."

On this point, the AG noted that even the bank admitted at trial that it can could block a multifunctional payment card; and evidence was accepted that "almost all Austrian banks" provide in their terms that "after a blocking notification, the card's [contactless] functionality is required to be and is... blocked." This would be a reference to the card number being blacklisted (on a MATCH list), or placed in a hotlist or blocklist for a specific merchant, as well as the industry and regulatory contactless security protocols explained in the second post on this case. This in turn implies that blocking the contactless functionality is done within the scope of blocking the card itself and this prevents further use. Accordingly, the bank's terms in this case are simply wrong in stating that "it is technically impossible" to block the contactless payments, and the requirements for the exclusion are not satisfied.

Of course, under English law, these facts would also raise issues under the law of mistake, which can affect the formation, existence and enforceability of the contract.

In my view, the AG's acceptance of the facts and reasoning on this point also runs contrary to the notion that the contactless functionality could be a separate payment instrument in its own right, since the blocking procedures for the card encompass the contactless functionality. 

In addition, even if the contactless functionality were construed as a payment instrument in is own right, as the AG suggests, the bank would still fail because, according to the bank's framework contract, the payment instrument does not "solely concern individual payment transactions not exceeding EUR 30." The contract is clear that the cards can be used for higher value payments requiring the entry of a PIN, and the clauses relevant to low-value transactions use language such as "when the debit card is used to make low-value payments without entering a PIN" and "any risk of misuse of the payment card for low-value payments not requiring a PIN" and "the debit card cannot be blocked for low value payments made without entering a PIN." 

Indeed, it would also be true to say that the contactless use of the card can be blocked by virtue of the cardholder being unable to enter the PIN when challenged.

Note, too, that the legal requirement for the liability exclusion to apply is that the payment instrument does not allow its blocking or prevention of its further use. Therefore it does not matter that one or more unauthorised payment transactions might go through before the card is reported missing or a thief fails to enter the PIN when challenged. 

In the final post, I will address the Advocate General's view that the unilateral change mechanism for amending payment services 'framework' contracts cannot be applied to "the essential elements" of the contract, such as those used to add contactless functionality to a payment card (i.e. another payment instrument). This would introduce huge practical challenges - and costs - for all payment service providers seeking to update their contracts to introduce new products and features, as well as aggravation for their customers.

Post Script 17.11.20

The ECJ has agreed with the AG:

"...a payment service provider wishing to exercise the option provided for in Article 63(1)(a) of Directive 2015/2366 may not, in order to relieve itself from its own obligations, simply state, in the framework contract relating to the payment instrument concerned, that it is unable to block that instrument or to prevent its further use. That service provider must establish, with the burden of proof being on that provider in the event of a dispute, that that instrument in no way allows, on account of technical reasons, its blocking or prevention of its further use. If the court hearing those proceedings considers that it would have been physically possible to carry out such blocking or to prevent such use, having regard to the objective state of available technical knowledge, but that the provider did not make use of that knowledge, Article 63(1)(a) may not be applied to the benefit of that provider."

This is inconsistent with the findings on anonymity, however, where the ECJ was prepared to simply accept as fact that the issuer of NFC functionality is unable to establish who used the card in that mode (when that does not seem to be the case and/or technology may evolve to put that beyond doubt).

If an issuer could prove that the instrument does not allow blocking or prevention of further use, then it could agree with the user in the customer contract to disapply: 

• the requirement of the user to inform the provider without delay of the loss, theft, misappropriation or any unauthorised use of the payment instrument concerned;
• the need for the provider to make available to the user means to make that notification free of charge or to request unblocking of that instrument; and
• the provision which relieves the payer from the financial consequences of any use of the lost, stolen or misappropriated instrument that takes place after that notification (except where he or she has acted fraudulently). 

 

Are [Low Value] Contactless Card Payments "Anonymous"? Yes! [Updated]

This is the third post in a series about some awkward issues under PSD2 that were recently referred to the European Court of Justice. The initial post sets out the four issues referred and the facts. The second post addresses the Avocate General's opinion that the contactless feature of a credit or debit card is a separate payment instrument in its own right. Here, I comment on the AG's view that making contactless payments with a debit or credit payment card means the cardholder is using the card "anonymously". Again, this is contrary to two previous judgments in the Austrian courts. 

 

[Update, spoiler alert 17.11.20: the ECJ agreed with the AG! See end of this post]

This matters, because PSD2 would apply differently to contactless payments if they were carried out using a separate payment instrument, rather than as just another card payment. In addition, payment service providers could escape certain liability for anonymous transactions (which the bank in this case sought to do) and contactless payments would (strangely) not be subject to the obligation of strong customer authentication in the relevant PSD2 regulatory technical standard. Specifically, the bank could escape the liability if contactless functionality is treated separately as a "payment instrument which, according to the framework contract, solely concerns individual payment transactions not exceeding EUR 30... if the payment instrument is used anonymously or [the bank] is not in a position for other reasons which are intrinsic to the payment instrument to prove that a payment transaction was authorised.

In this case, the bank stated in its card terms (the "framework contract") that it "shall not have to prove" and it "is unable to prove" that low value transactions were authorised and not defective.

The Austrian regional appeal court held that the contactless functionality on a multifunctional payment card just creates a separate processing category, like mail-order telephone order (MOTO), but for low-value purchases; and the contactless functionality is personalised by virtue of being protected by the need for a PIN to be entered from time to time. 

The Advocate General considers that contactless payments using the contactless functionality on a debit or credit card are "depersonalised" and "anonymous" because the communication between the contactless functionality and the terminal "is sufficient to validate the transaction, irrespective of who is in possession of the card at the time, and dispenses with the need for the cardholder to enter his PIN or provide a handwritten signature." 

There are numerous problems with this view.  

The AG cites analysis from the European Central Bank and the Euro Retail Payments Board. But I do not read anything in either report on the development of contactless acceptance, and the ability to have separate contact and contactless devices/procedures to support the conclusion either that where the same card can operate in both modes they are separate, or that the contactless mode is depersonalised or anonymous. 

A payment card might be used by a third party (with or without authorisation) in either contact mode or contactless mode. Payment cards were notorious for high rates of fraud long before the introduction of contactless functionality. That in itself explains the industry's decision to introduce the Chip-and-PIN security measure over a decade before the statutory requirement for strong customer authentication in the relevant PSD2 regulatory technical standard. Indeed the report from the Euro Retail Payments Board referred to by the AG explains that adoption rates were still quite low even by 2015, and the ability for Chip-and-PIN cards to be used contactlessly was a key driver to improve adoption rates of Chip-and-PIN cards by making it quicker and more convenient to use them for lower value transactions, subject to the industry requirement to enter the PIN from time to time as a guard against unauthorised use. The contactless functionality merely creates the potential for choices to be made about whether and when the user must enter the PIN related to the card. The fraudster takes the risk of being detected if he does not have the PIN.

It is therefore odd to say that contactless functionality added to a card to improve its utility is somehow independent of the card, and that the requirement to be able, if and when challenged, to enter the Personal Identification Number set by the cardholder (who must keep it secret) somehow renders the contactless use of the card "depersonalised" and "anonymous". Card issuers must also carry out "customer due diligence" on their cardholders, including identify verification and transaction monitoring.

The entry of the PIN and the lack of a report by the cardholder that the card has been stolen should also make it probable that the cardholder made the contactless transactions since the previous entry of the PIN. This means that the requirement to enter the PIN from time to time is also an important factor in determining the validity of contactless transactions, not to mention the customer identity verification and monitoring obligations that sit behind the issuance of the card/account and PIN. 

The AG also relied on the fact that the bank in this case delivered the cards with the contactless functionality automatically enabled so that cardholders might be unaware the functionality existed. Ironically, I would regard this as confirmation that the contactless functionality does not constitute a distinct payment instrument (let alone an anonymous one), and that this is a good basis for saying the bank could not then pretend that the feature was at all distinct. It is clear that, for practical purposes, the bank saw the contactless functionality as an inherent property of the card itself, not distinct.

Furthermore, it is a legal requirement under the regulatory technical standard that requires strong customer authentication (SCA) for cards used for remote or electronic payment transactions that the security credentials for the card (which do not vary for contact or contactless use) must be applied, unless the issuer of the payment instrument/account to which the security credentials relate applies any of the following exemptions:

Low-value transactions: up to €30 per transaction (limit of five separate transactions or €100);

Recurring transactions: e.g. subscriptions for the same amount and payee (SCA applied to the first transaction);

Whitelisted: payers can add payees to a whitelist of trusted beneficiaries with the issuer, but payees can't request this;

Corporate payment processes: dedicated process for non-consumers, approved by the regulator (member states may exclude micro-enterprises as consumers);

Contactless: up to €50 (limit of five separate transactions or €150 without an SCA check);

Unattended terminals: only for paying transport fares or parking fees;

Low-risk of fraud: as determined by the issuer, depending on its average fraud levels for the relevant acquirer (not by merchant/channel), with different limit for cards and credit transfers.

Importantly, the European Banking Authority has said that the limit of five transactions needs to be calculated not on the basis of all transactions where the exemption could have been applied, but on the basis of transactions where the particular exemption was applied. This reflects the fact that certain scenarios may trigger the application of more than one exemption. So the use of the card to pay £2.50 at an unattended parking machine should not count towards your five contactless or low-value transactions.

Therefore, the regulatory SCA requirement introduces a significant regulatory challenge to the 'anonymous' use of a card's contactless functionality. It merely dictates that an issuer may allow the use of the card without the security credentials in seven scenarios, the contactless scenario being merely one.

 

It would make no sense to consider the SCA requirements in the context of the contactless feature on its own, and it is worth noting that the Advocate General does not contend that the use of a payment card in each of the other scenarios benefiting from an exemption from SCA also constitutes a separate "payment instrument" in its own right.

It would also be wrong, however, to conclude (as the Advocate General has) that contactless payments would not themselves "not subject to the obligation of strong customer authentication". The regulatory SCA standard requires that the customer's contactless use must be challenged by the requirement to provide her security credentials, either every fifth time she uses it or when a total transaction value of €150 is reached. This will result in the attempted contactless use being prevented, and an invitation to insert the card in the relevant terminal into which the credentials can be entered.

My next post will address the Advocate General's view on the third issue raised in proceedings - in effect that it is not technically feasible for an issuer to block the contactless use of a payment card or prevent further use of the payment instrument if it is lost, stolen, misappropriated or used without authorisation. 

Post Script 17.11.20

The ECJ has agreed with the AG:

"...the use of the NFC functionality for the purpose of making low-value payments constitutes ‘anonymous’ use, within the meaning of Article 63(1)(b) of [PSD2], even where the card equipped with that functionality is associated with the bank account of a particular customer. In such a situation, the payment service provider is objectively unable to identify the person who paid using that functionality and thus unable to verify, or even prove, that the transaction was duly authorised by the account holder... 

...a contactless low-value payment using the NFC functionality of a personalised multifunctional bank card constitutes ‘anonymous’ use of the payment instrument in question, within the meaning of that derogation provision. 

Yet this is not only inconsistent the facts, in my view, but also with the ECJ's own finding in relation to the question of whether the instrument allows blocking or prevention of further use in Article 63(1)(a), where the ECJ held the bank bears the onus of proof in order to rely on the derogation. While in that respect the bank was not allowed to merely assert in the contract that it is impossible to block the payment instrument concerned or to prevent its continued use, where, in the light of the objective state of available technical knowledge, that impossibility cannot be established; here the ECJ has done that job for the bank!

Where this leaves the use of SCA in relation to NFC payment transactions is unclear, but banks and other payment servicer providers who issue NFC functionality may agree with customers that:

• the provider need not prove the authentication and execution of payment transactions;
• the service provider is not liable for unauthorised payment transactions; and
• the payer loses the cap of EUR 50 on losses resulting from such transactions, after notification to the provider of the loss, theft or misappropriation of the payment instrument.

Is The Contactless Payment Function In a Payment Card a Separate Payment Instrument? Yes! [Updated]

This is the second in a series of posts about a case referred to the European Court of Justice that raises some awkward issues under PSD2. The initial post sets out the four issues on which the Advocate General has expressed his opinion, and the facts in the case. This post addresses the AG's opinion on the first question, namely that the contactless feature of a credit or debit card is a separate payment instrument in its own right, contrary to two previous judgments in the Austrian courts.

This matters, because PSD2 would apply differently to contactless payments if they were carried out using a separate payment instrument, rather than as just another card payment.

[Update, Spoiler alert 17.11.20: the ECJ has agreed with the AG! See end of this post] 

 

Let me know if I can help you with any of these issues.

What is a payment instrument?

A "payment instrument" is defined in PSD2 as:

"any personalised device and/or set of procedures agreed between the payment service users and the payment service provider and used in order to initiate a payment order".

The Advocate General cites extensive debate on whether or not the word "personalised" applies to both "device" and "set of procedures", since EU countries are split in how they have transposed the definition in their national laws implementing PSD2. One group of member states (France, Spain etc) did not apply "personalised" to "set of procedures". The Germans applied "personalised" expressly to both "device" and "set of procedures" and the rest (the Netherlands, UK etc) copied the definition as set out in the directive, leaving the issue open. In any event, the Advocate General has said that "it must be agreed that the definition... allows for personalised and depersonalised or anonymous varieties" of payment instruments, citing the ECJ's judgment in the T-Mobile Austria case that payment instruments may be either:

• personalised, which is to say that they allow the payment service provider to verify that the payment order was initiated by a user authorised to do so; or
• anonymous or non-personalised, in which case the payment service providers are not required to prove that the transaction in question was authenticated.

My own view is that T-Mobile Austria is correct (though it's important not to get too caught up in the difference between "anonymous" and "non-personalised"). Indeed, this interpretation allows for 'virtual cards' where no physical plastic is created yet they are still personalised, while the French/Spanish interpetation could mean virtual cards are not payment instruments in those countries!

But in my view this distinction should be irrelevant in the present case, since the contactless use of an NFC-enabled payment card is neither "anonymous" nor "non-personalised", as I'll explain in my next post on the second issue being referred to the ECJ. However, the Advocate General clearly relies quite heavily on the scope for non-personalised payment instruments in his view that the contactless feature is a payment instrument in its own right.

Is NFC functionality of a payment card a separate payment instrument? 

It seems unnecessary to get into all of the technical detail of how near-field communication (NFC) or the other technology enables the use of a payment card to be used 'contactlessly' by waving it near a terminal to initiate the relevant payment transactions, rather than swiping the card or inserting it into the terminal and entering a personal identification number (PIN). The AG's opinion refers to technological "formats based mainly on ISO 14443", but it should be noted that the industry actually develops NFC solutions to the EMV specification that began with contact-based Chip and PIN (under ISO/IEC 7816 for contact cards) and contactless functionality [note, you must agree EMVCo's terms to access the spec]. I think that's an important sign-post to the many stakeholders and systems potentially impacted by the case in point.

The first Austrian court held that the contactless feature was not to be viewed as a distinct low-value payment instrument, because the same card could be used to make other payments. The regional appeal court held that the contactless functionality just creates a separate processing category, like mail-order telephone order (MOTO), but for low-value purchases; and it is personalised by virtue of being protected by the need for a PIN to be entered from time to time.

However, the Advocate General has said that a 'multifunctional' payment card features two different payment instruments:

• a personalised device which requires the use of one or two security elements (strong authentication) and is reserved for payments from a certain value; 
• a set of procedures for making low-value payments without using those security elements, via NFC functionality.

In reality the NFC feature cannot be used independently of the card it resides upon - the user has to wave the card near an NFC-enabled terminal. In addition, the NFC feature is technically configured under the industry (non-regulatory) standards so that the security credentials (PIN) must be entered from time to time. Therefore, the highlighted language shows the card and the NFC feature must constitute the same payment instrument, with the NFC feature merely creating the potential for choices to be made about whether and when the user must enter the security credentials related to the card.

Furthermore, it is a legal requirement under the regulatory technical standard that requires strong customer authentication (SCA) that the security credentials must be applied, unless the issuer of the payment instrument/account to which the security credentials relate applies any of the following exemptions:

Low-value transactions: up to €30 per transaction (limit of five separate transactions or €100);

Recurring transactions: e.g. subscriptions for the same amount and payee (SCA applied to the first transaction);

Whitelisted: payers can add payees to a whitelist of trusted beneficiaries with the issuer, but payees can't request this;

Corporate payment processes: dedicated process for non-consumers, approved by the regulator (member states may exclude micro-enterprises as consumers);

Contactless: up to €50 (limit of five separate transactions or €150 without an SCA check);

Unattended terminals: only for paying transport fares or parking fees;

Low-risk of fraud: as determined by the issuer, depending on its average fraud levels for the relevant acquirer (not by merchant/channel), with different limit for cards and credit transfers.

Importantly, the European Banking Authority has said that the limit of five transactions needs to be calculated not on the basis of all transactions where the exemption could have been applied, but on the basis of transactions where the particular exemption was applied. This reflects the fact that certain scenarios may trigger the application of more than one exemption. So the use of the card to pay £2.50 at an unattended parking machine should not count towards your five contactless or low-value transactions.

Therefore, the regulatory SCA requirement cannot be seen as determinative of what amounts to a payment instrument. It merely dictates that an issuer may allow the use of the card without those credentials in seven scenarios, the contactless scenario being one.

It is worth noting that the Advocate General does not contend that the use of a payment card in each of the other scenarios benefiting from an exemption from SCA also constitutes a "payment instrument" in its own right.

In any case, there is only one set of credentials issued per card (it's hard enough for consumers to remember one PIN etc per card, let alone multiple PINs for different uses of the card!). Neither the industry EMV standard nor the regulatory SCA standard dictates distinct security credentials for different uses of the card.

It is also wrong, therefore, to conclude (as the Advocate General has) that contactless payments are themselves "not subject to the obligation of strong cusotmer authentication". The regulatory SCA standard requires that the customer must be challenged to provide her security credentials either every fifth time she uses it or when a total transaction value of €150 is reached. This will result in the attempted contactless use being prevented, and an invitation to insert the card in the relevant terminal into which the credentials can be entered.

The Advocate General also believes that making the contactless feature a distinct payment instrument is also justified by the need for users of NFC-enabled cards to receive "enhanced protection" and to promote fair and transparent competition between the issuers of such cards. However, PSD2 already addresses these points insofar as any payment service provider who fails to apply SCA (unless the issuer has applied an exemption) will be liable for any resulting unauthorised transaction, and could face enforcement action (now delayed to 14 September 2021))

The Portuguese and Czech governments also made submissions in the latest appeal to the effect that the contactless feature of a payment card is not a distinct payment instrument ("any personalised device and/or set of procedures agreed between the payment service users and the payment service provider and used in order to initiate a payment order"). The Portuguese pointed out that not even cards themselves are mentioned in the definiton of payment instrument, yet are specifically mentioned elsewhere in PSD2 as ways of initiating payment transactions. The Czechs said the contactless functionality is merely one of the ways the card can be used.

I would go further by focusing on the fact that contactless use of a payment card does not alter the effect of using the card to "initate a payment order". Recital 68 of PSD2 explains:

The use of a card or card-based payment instrument for making a payment often triggers the generation of a message confirming availability of funds and two resulting payment transactions. The first transaction takes place between the issuer and the merchant’s account servicing payment service provider, while the second, usually a direct debit, takes place between the payer’s account servicing payment service provider and the issuer. Both transactions should be treated in the same way as any other equivalent transactions.

It is clear from the balance of the Recital 68 that if the same payment transactions flow from the use of the card with or without the security credentials, then they are to be treated the same (subject to the 'liability shift' and potential enforcement action related to any failure to use the credentials where the issuer requires). Indeed, this is also consistent with the need for 'technological neutrality', which the Advocate General has ironically said somehow requires the separate treatment of the contactless feature. The fact that a debit card and credit card can also reside on the same multi-functional card does not alter the fact that the card itself is still the single payment instrument in each use-case, with the one set of security credentials.

Nothing turns on the use of both the terms "card" and "card-based payment instrument". These are used interchangeably in the recitals to PSD2. In the main text of PSD2, the term "card-based" is generally used to refer to any payment instrument/transaction involving a payment card. The only exception is that the expression "execution of payment transactions through a payment card or a similar device" is included among the activities that constitute the "Execution of a payment transaction" which is are two types of regulated "payment service" (depending on whether credit is also involved).  So, if the Adocate General were correct in holding that the contactless element of a payment card constitutes a separate payment instrument distinct from the card, then it would follow that executing the related payment transactions is not a regulated activity because they are not executed "through a payment card"...

In the next post, I will address the Advocate General's view that making low-value contactless payments with a multifunctional card means the cardholder is using the card "anonymously" (which would mean contactless payments are not subject to the obligation of strong customer authentication in the relevant PSD2 regulatory technical standard mentioned above.

Post script 17.11.20:

 

The ECJ has agreed with the AG:

"...the NFC functionality of a personalised multifunctional bank card, by means of which low-value payments are debited from the associated bank account, constitutes a ‘payment instrument’, as defined in that provision."

 

Again, this suggests that the ensuing payment transaction is not "through a payment card or similar device" and NFC payment transactions are not 'card-based'. This calls into question how the execution of NFC payment transactions is regulated.

Red Alert: European Court Is Told That The Contactless Feature of a Payment Card is a Separate Payment Instrument!

Fans of the adage "A hard case makes bad law" will wince as the regulatory and contractual treatment for contactless credit cards and debit cards is at risk owing to the misadventures of a single Austrian bank. I would hope that the industry is alive to the problem and is finding a way to improve the bank's arguments and save the day. Let me know if I can help!

Briefly stated, a series of questions has been referred by the Austrian Supreme Court to the European Court of Justice and, alarmingly, the Advocate General has given his opinion to the effect that:

1. The contactless feature of a credit or debit card is a separate payment instrument in its own right.
2. Making low-value contactless payments with a multi-functional card means the cardholder is using the card "anonymously" (and this means contactless payments are not subject to the obligation of strong customer authentication in the relevant PSD2 regulatory technical standard).
3. The issuer of the contactless feature can only use the low-value exclusions from liability for unauthorised transactions in PSD2 if the issuer can show that it is not technically feasible to block the card or prevent further use of the payment instrument if it is lost, stolen, misappropriated or used without authorisation.
4. The unilateral change mechanism for amending payment services 'framework' contracts cannot be applied to "the essential elements" of the contract, such as those used to add contactless functionality to a payment card (i.e. another payment instrument).

I have briefly set out the facts of the case below, and will post my thoughts on each of these issues in turn over the coming days, but in summary I do not see how the first two points could be right, for reasons I will explain.

The third issue is a question of fact. In this particluarly case the issuer appears to have created a problem for itself by inserting factually inaccurate provisions in its card terms, so that "according to the framework contract" it was not technically feasible to block contactless use, even though it really is possible to decline the transactions on a stolen card.

The fourth is a really awkward twist in the tale, since it introduces huge practical challenges - and costs - for all payment service providers seeking to update their contracts to introduce new products and features, as well as aggravation for their customers.

The Facts

When it began issuing cards with NFC/contactless functionality, the bank in this case decided to also amend its payment card terms to avoid liability for unauthorised payments when the cards were used in contactless mode (i.e. using 'near-field communication' or NFC functionality).

The bank's new terms said the bank (a) did not "have to prove" that a contactless payment was authorised; (b) it was unable to do so; and (c) that it was "technically impossible" for the card to be blocked when used for low-value transactions, even if blocked for other types of transactions. On this basis the bank concluded that it was not liable for any unauthorised low-value contactless payments.

Like all payment service providers, to introduce these changes to its terms the bank relied on the 'unilateral change' mechanism under PSD2, so that customers would be deemed to have accepted the changes unless they notified the bank within two months that changes were not accepted, and terminated the contract.

Whether the bank could do this depended on whether the use of the contactless feature was itself a "payment instrument" independent of the use of the card in, say, Chip-and-PIN mode, mail-order/telephone order (MOTO) or indeed online. 

Two Austrian courts held that the contactless mode is not a payment instrument in its own right, so the bank can't escape liability in this way. So far, so good, because many card issuers would otherwise need to review their terms to figure out if they had properly addressed the contactless as a distinct payment instrument - and maybe many would be tempted to pull the same stunt.

However, both the Austrian consumer body who brought the original proceedings (the VKI) and the bank then appealed to the Austrian Supreme Court, which in turn referred to the European Court of Justice the issues of whether the contactless payment feature could be considered a payment instrument in its own right, and whether the bank could use the 'unilateral change' mechanism to introduce the exclusion of liability for contactless payments. The case actually goes back to before the implementation of PSD2, but the provisions under the PSD and PSD2 are essentially the same, so the ECJ's ruling will determine the position under PSD2 as well.

The preliminary step in ECJ proceedings is the filing of an Opinion of the Advocate General, with whom the court very often agrees.

FCA Delays SCA... Again

The UK's Financial Conduct Authority has again delayed its deadline for enforcing the implementation of 'strong customer authentication' in e-commerce transactions, until 14 September 2021. 

The FCA had already turned a blind eye to the threshold for applying SCA to contactless card transactions, in light of the role that contactless cards play in social distancing.

The FCA still expects firms to follow the industry implementation plan agreed with UK Finance, though that can now be extended to the new deadline.

FCA Turns Blind Eye To SCA For Contactless Card Payments

The introduction of 'strong customer authentication' (SCA) - also known as 'two factor authentication' or 'multi-factor authentication' for remote and electronic payment transactions has had a checkered history. Payment service providers should have been challenging customers to provide extra authentication details from 14 September 2019. But lack of industry preparation led the FCA (in line with the European Banking Authority and other EU national regulators) to state that it will not enforce the requirement until 14 March 2021, so long as PSPs are following an agreed industry plan to introduce the checks. In light of the COVID19 crisis, the FCA has now added:

"...we are very unlikely to take enforcement action if a firm does not apply strong customer authentication when the cumulative amount of transaction values has exceeded EUR 150 or five contactless transactions in a row. But this is only as long as the firm sufficiently mitigates the risk of unauthorised transactions and fraud, by having the necessary fraud monitoring tools and systems in place and taking swift action where appropriate."

Further time may also be allowed for introducing SCA for e-commerce payments generally, beyond 14 March 2021.

Meanwhile, the date for applying regulatory standards to secure communications amongst PSPs was also deferred from 19 September 2019 to 14 March 2020, yet some PSPs have not complied. The FCA is also letting them off the hook, where they are "facing further delays due to coronavirus:

"...we will consider on a case-by-case basis the appropriate further measures. In doing so, we will in particular consider:

• firms’ security around authentication to access their online banking and when making payments;

• their controls and processes to reduce fraud;

• whether that impact is likely to be exacerbated given the current circumstances."

 

UK Delays Anti-fraud Measures For Banking And Payments

It seems payments legislators wrote checks the industry couldn't cash... The UK's Financial Conduct Authority has announced a delayed ‘migration plan’ for phasing in compliance with the Strong Customer Authentication requirements by March 2020 for internet banking and March 2021 for e-commerce transactions, instead of 14 September 2019. The FCA made a separate announcement for consumers.

Update: The FCA has also written to the CEOs of payment service providers it supervises, commending the plan from the trade body, UK Finance for meeting the deferred timeline. This will see SCA phased-in from Feb 2020 for merchants who are ready, with support from the card schemes in driving the adoption of the 3D Secure protocol (3DS 2.1/2) from March/September 2020.

This follows the guidance issued in June by the European Banking Authority that EU national regulators could agree specific migration plans (although I'm not sure the EBA expected industry-wide delays!).

The FCA says that it will not take enforcement action against payment service providers if they do not meet the relevant requirements for SCA from 14 September 2019 in areas covered by the agreed plan, where there is evidence that they have taken the necessary steps to comply with the plan. 

At the end of the 18-month period, the FCA expects all firms to have made the necessary changes and undertaken the required testing to apply SCA. 

It will be interesting to see how much progress is really made in the next 6 to 18 months...

EBA Gives Some Leeway On SCA

There has been increasing concern that the e-commerce world won't be ready for the introduction of "strong customer authentication" (or two-factor authentication) for electronic and remote payments on 14 September 2019. The checks apply to electronic and remote payments, which include payments online, as well via mobile devices, kiosks or other machines. It is feared many aren't aware of the new checks or the potential that checks will lead to failed or abandoned transactions, causing a hit to retailers' and payment service providers' revenues. The European Banking Authority now says local financial regulators may provide limited additional time to payment service providers to introduce compliant processes “on an exceptional basis and in order to avoid unintended negative consequences for some payment service users" on that date. 

Specifically, the PSPs must have agreed a migration plan with their regulator and execute it "in an expedited manner." The regulator should monitor the execution of the plans "to ensure swift compliance..." 

The opinion also contains tables listing the types of features that will (or, in marginal cases, will not) constitute compliant elements for the purpose of SCA (two of either "inherence", "possession" or "knowledge" - i.e. what the customer is, what the customer possesses, or what the customer knows).

There is also guidance on how to satisfy the additional requirements for "dynamic linking" (to ensure the SCA elements link the transaction to an amount and the specified payee when initiating the transaction) and that the SCA elements be independent of each other.

The EBA issued an earlier opinion and a Q&A on how all this applies, but it remains to be seen how many retailers are aware of the new requirements at all, let alone the potential impact on customer experience and 'conversion' (customers dropping out at the payment step when asked to complete one or more additional authentication steps).

Whether payments are affected depends on whether PSD2 applies - some may be out of scope based on currency or location, while others may be within the scope of PSD2 but excluded. There is then a question whether the transaction is interpreted to be one caught by the SCA requirement. Is it remote or electronic and initiated by the payer (rather than being a 'merchant initiated transaction')? Even transactions that are in scope may not be caught if the issuer (not the merchant or acquirer) of the payment instrument/account applies any of the potential exemptions:

Low-value transactions: up to €30 per transaction (limit of five separate transactions or €100);

Recurring transactions: e.g. subscriptions for the same amount and payee (SCA applied to the first transaction);

Whitelisted: payers can add payees to a whitelist of trusted beneficiaries with the issuer, but payees can't request this;

Corporate payment processes: dedicated process for non-consumers, approved by the regulator (member states may exclude micro-enterprises as consumers);

Contactless: up to €50 (limit of five separate transactions or €150 without an SCA check);

Unattended terminals: only for paying transport fares or parking fees;

Low-risk of fraud: as determined by the issuer, depending on its average fraud levels for the relevant acquirer (not by merchant/channel), with different limit for cards and credit transfers.

The FCA will apply the SCA standards in the UK even if Brexit occurs.