From 13 January 2018, banks, electronic money issuers and other payment service providers (together, PSPs) will be required to “appl[y] strong customer authentication“.

Now that we have both the second Payment Services Directive (PSD2) and the European Banking Authority’s draft Regulatory Technical Standards (RTS), we can begin to see what this might mean, and what it might involve.

I know. This doesn’t exactly ring with clarity or certainty, does it? Here’s why.

The What:

“Strong customer authentication” means “an authentication based on the use of two or more elements categorised as knowledge (something only the user knows [for example, a password]), possession (something only the user possesses [for example, a particular cell phone and number]) and inherence (something the user is [or has, for example, a finger print or iris pattern]) that are independent, [so] the breach of one does not compromise the others, and is designed in such a way as to protect the confidentiality of the authentication data“.

For these purposes:

1. “authentication” means “a procedure which allows the [PSP] to verify [(a)] the identity of a payment service user [(PSU); or (b)] the validity of the use of a specific payment instrument [and/or] the user’s personalised security credentials“; and
2. “personalised security credentials” means “personalised features provided by the [PSP] to a [PSU] for the purposes of authentication“.

(See articles 4(29) to (31) of PSD2.)

The When:

A PSP must apply “strong customer authentication” every time a payer:

1. (directly or through an account information service provider (AISP)), (a) accesses its payment account online; (b) initiates an electronic payment transaction; or (c) carries out an action through a remote channel that “may imply” a risk of payment fraud or abuse;
2. (directly or through payment initiation service provider (PISP)), initiates an electronic remote payment transaction. This “strong customer authentication” must also include elements dynamically linking the particular transaction to a specific amount and payee.

However:

1. paragraph 1 (above) won’t usually apply if “the payer accesses exclusively the information of its payment account online, or the consolidated information on other payment accounts held, without disclsoure of sensitive payment data“. And it won’t apply if the payer makes a contactless payment at a point of sale, provided that (a) the individual amount is no more than €50; and (b) the aggregate value of previous contactless payments without “strong customer authentication” is no more than €150; and
2. paragraph 2 (above) won’t usually apply if the payer initiates an online credit transfer, if the payee is on a list of trusted beneficiaries, which the payer has already created with its account servicing PSP. Nor will it apply if (for example) a payer transfers money from one of its accounts at an account servicing PSP to another account at the same PSP.

For these purposes:

1. a “payment transaction” is “an act, initiated by the payer or on his behalf or by the payee, of placing, transferring or withdrawing funds, irrespective of any underlying obligations between the payer and the payer“; and
2. a “remote payment transaction” is “a payment transaction initiated via internet or through a device that can be used for distance communication“;

… which makes the undefined terms “electronic payment transaction“, “electronic remote payment transaction” and “remote channel” seem rather odd, until you remember the policymakers’ underlying aims – to be (a) proportionate (“strong customer authentication“ probably isn’t necessary for paper based transactions); and (b) technology neutral (so that payments and security technology can develop freely, without being unnecessarily constrained by the law).

(See articles 4(5) and (6), 74(2) and 97 of PSD2; and article 8 of the RTS.)

The How: (What?)

When a PSP applies “strong customer authentication“, it must use a procedure that (a) allows it “to verify [(a)] the identity of a [PSU; or (b)] the validity of the use of a specific payment instrument [and/or] the user’s personalised security credentials“; and (b):

1. “result[s] in the generation of [a single use] authentication code” (SUAC) every time the payer accesses its payment account online, initiates an electronic transaction, or carries out an action through a remote channel “which may imply a risk” of fraud or other abuse;
2. includes a “time out” mechanism;
3. includes a mechanism that will stop a person (a) working out which element of the “strong customer authentication” was wrong, if the procedure is followed correctly but that doesn’t generate an SUAC; or (b) accessing the relevant payment account after a maximum number of failed attempts;
4. protects communication sessions against (a) the capture of data transmitted during the authentication procedure; and (b) data manipulation by others; and
5. prevents, detects and blocks fraudulent payments before the PSP’s final authorisation.

If a payer is initiating an electronic remote payment transaction, the procedure must also ensure that the payer “is made aware at all times” of, and the SUAC must be specific to, the transaction amount and the payee. So, if the amount or payee changes, the SUAC must change too.

It must also be impossible to forge the SUAC; take one SUAC to generate another; or to use an SUAC to uncover any knowledge, possession or inherence information.

(Although it isn’t absolutely clear, it appears that the account servicing PSP of the payer must ensure that), the elements of “strong customer authentication” that are categorised as:

1. knowledge, are subject to mitigation measures to stop them being disclosed to unauthorised 3rd-parties;
2. possession, have security features “ensuring resistance against“ copying; forgery; cloning; and use by, and disclosure to, unauthorised parties;
3. inherence, have security features (a) “ensuring resistance against“ sensitive information being disclosed to unathorised parties; and (b) a sufficiently low likelihood of an unauthorised party being authenticated as the legitimate PSU. The “use of elements categorized as inherence shall [also] be subject to measures ensuring that the devices and the software provided to the payer guarantee resistance against unauthorised use of the elements through access to the devices and software“.

(For “The How:“, see articles 4(29) to (31), and 97, of PSD2; and the rather circular and ambiguously drafted article 1 of the RTS. See also articles 2 to 7 of the RTS.)

Comments:

The European Banking Authority (EBA) has deliberately taken a principles based approach to the RTS, so that it doesn’t inadvertently stifle payments and security innovation. It has also tried to be proportionate and technology neutral, so that PSPs can still innovate without having to think about frequent legal-framework change; and PSUs can still take advantage of new payment methods and technologies, without having to give security an especially high priority when they choose one payment method over another. These are laudable aims, but the drafting of the RTS shows just how difficult it can be to meet them, and still make the legal position clear.

It’s often difficult, with principles based regulation, to work out exactly what you need to do to meet your legal obligations … and the RTS have been drafted in a way that makes it especially difficult in this case. Start with the proverbial blank piece of paper, and it could take weeks. Start with modern best practice in mind – for example, (a) passwords that meet minimum and maximum length and character criteria; and (b) app-based SUAC generators that are (in both cases) consistent with modern best practice – and there’s not as much to do … even if there’s still a great deal.

Unfortunately, these problems are exacerbated by the circular and frequently ambiguous drafting that’s been used in PSD2 and the RTS. Some member state regulators will try to fill these gaps – most won’t. So, unless the EBA sorts its drafting out before it finalizes the RTS, many PSPs will need a lawyer in the room when they design or change their “strong customer authentication” procedures. Like many things, it’s impossible to tell whether that’s really what the EBA had in mind, or not. Either way, it seems to have met this particular goal, even if it hasn’t met the others.

[View source.]