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

 

Open Finance: The FCA's Call For Input

The FCA has called for suggestions by 17 March 2020 as to how it can support more open access to customers’ financial data. A few thoughts here, with an article to follow in the coming weeks...

The major stumbling blocks, as ever, are genuine customer problems/demand and supplier appetite, which tend to be focused quite narrowly; and who gets access to the data and for what purpose. 

One suspects that the Nirvana of a single consumer 'dashboard for everything' remains a long way off. We’ve seen broad-based initiatives before, like the UK government’s ‘midata’ programme from 2011. Key challenges remain customer identity and authentication on a broad scale, as opposed to channels more closely aligned with specific customer activities. In July 2019 the Government Digital Service and the Department for Digital, Culture, Media & Sport were still calling for evidence of how the Government can support improvements in identity verification and the development (and secure use) of digital identities generally. 

Yet there have been genuine advances around more defined customer activities. The FCA itself cites the second payment services directive and related standards designed to open up the payments market, for instance. These were partly a response to strong demand for new, unregulated services that were already providing access to current account data and enabling the remote initiation of bank transfers. Those competing to provide these services were encountering a distinct lack of co-operation from the current account providers (mainly banks). Specific regulation was forthcoming and has duly helped account information and payment initiation services proliferate and scale. But regulation did not itself catalyse either the demand or the services themselves. 

At any rate, it will be interesting to see whether the FCA receives evidence of other existing but nascent 'open finance' type services whose growth is genuinely stymied by issues that can be resolved by regulation. Whether such use-cases are sufficiently distributed across the range of day-to-day activities in which customers are engaged to constitute generally 'open finance' will be interesting to discover but of secondary importance. 

Of course, the elephant in the room is who will have access to all the data and for what purpose. In this respect, it would be particularly interesting to know when the FCA and PRA will begin to actually audit the use of artificial intelligence by financial services providers, rather than merely survey the industry on a self-disclosure basis. If they're true to form, we'll see a few major train wrecks first...

New To Payments? Try PSD2 Customer Authentication and Communication Standards!

If you are among the new entrants to the regulated payments space you should know that, in a bit to captivate and inspire a generation, the European Banking Authority has published the final 'regulatory technical standards' for payment user authentication and the secure communication of payments data. The standards should take effect in the second half of 2019, but the authorities are keen for regulated payment service providers (PSPs) to adopt them as soon as possible. They are written in legalese, but I've summarised them below in a bid to get them straight in my own head.  Grab a coffee before proceeding!

Strong customer authentication 

PSPs must know they are dealing with their own customer by applying strong customer authentication. This is subject to certain permitted exemptions outlined below. PSPs must also protect the confidentiality and the integrity of each customer's personalised security credentials. Their security measures must be documented, periodically tested, evaluated and audited by auditors with expertise in IT security and payments and operationally independent within or from the PSP.

 

Broadly, authentication must be based on two or more elements of 'knowledge' (password/PIN), 'possession' (card/device) and 'inherence' (fingerprint/iris scan). 

These elements must be subject to measures designed to prevent disclosure (in the case of knowledge) , replication (in the case of possession) and resistance against unauthorized use of device or software (in the case of inherence). 

The breach of one element must not compromise the reliability of the others. Certain measures must also mitigate the risk that a multi-purpose access device has itself been compromised. 

Credentials and Code

Authentication credentials must be masked when displayed and not fully readable as they are being entered; not stored in plaintext; and must be protected from unauthorized disclosure. 

PSPs must document how they encrypt credentials or render them unreadable. 

The creation, processing and routing of credentials must be done in secure environments that accord with industry standards. 

Specific requirements govern the process of associating the user with credentials; delivery; authentication of devices and software; and the renewal, destruction, deactivation and revocation of credentials.

Authentication must result in the generation of an authentication code that is only accepted once by the PSP when the payer uses it to: access the payer’s payment account online, initiate an electronic payment transaction or to carry out any action through 'a remote channel which may imply a risk of payment fraud or other abuse'. 

No information on any of the authentication elements can be derived from the disclosure of the authentication code; nor can it be possible to generate a new authentication code based on the knowledge of any previous code. The code must not be able to be forged. 

Where the authentication has failed to generate an authentication code, it must not be possible to identify which of the authentication elements was incorrect. 

No more than 5 failed authentication attempts can take place consecutively before the authentication tool is blocked, either temporarily (based on certain factors) or permanently (after a warning). The user has 5 minutes of inactivity after being authenticated before access must time-out. 

Dynamic linking!

The payer must be made aware of both the amount of the proposed payment transaction and of the proposed payee. The authentication code must also be ‘dynamically linked’ (specific to) the amount and the payee. Any change to the amount or the payee must result in the invalidation of the authentication code  that was generated. 

PSPs must ensure the confidentiality, authenticity and integrity of the amount of the transaction and the payee throughout all of the phases of the authentication; as well as the information displayed to the payer including the generation, transmission and use of the authentication code.

Transaction monitoring

PSPs must monitor interaction with their customers to detect unauthorised or fraudulent payment transactions, taking into account elements which are typical of the user when normally using the credentials and, at a minimum, the following risk-based factors: 

• lists of compromised or stolen authentication elements; 
• the amount of each payment transaction; 
• known fraud scenarios in the provision of payment services; 
• signs of malware infection in any sessions of the authentication procedure; and
• where the access device or software is provided by the PSP, a log of the use of the device or software and the abnormal use of the device or software. 

Exemptions from strong customer authentication

The permitted exemptions (subject to transaction monitoring, and quarterly assessments to be shared with the FCA on request) are: 

• checking the balance or the last 90 days of transactions without entering sensitive payment data; 
• a contactless payment of up to €50, a series of up to €150 or 5 consecutive contactless payments; 
• payment at an unattended parking or transport ticket terminal;
• the payee is included in a list of trusted payees (unless adding to or changing the list); 
• recurring payments (after authenticating for the first);
• transfers between the users’ own accounts with the same PSP; 
• a remote electronic payment of up to €30, consecutive payments of up to €100 or 5 consecutive remove electronic payments; 
• commercial payment processes or protocols where the FCA is satisfied they guarantee at least the same level of security as under PSD2; 
• low risk remote electronic payment transactions (based on certain risk factors) where: 

o the fraud rate is below the relevant reference rate; 

o the amount is below a specific threshold; and 

o the PSP’s real time risk analysis hasn’t identified certain specified problems. 

Secure communcations

A PSP's communication sessions must be protected against the capture of authentication data transmitted during authentication, and against manipulation by unauthorised parties based on certain communication standards. These include secure identification of payer’s and payee’s devices; traceability of both the transactions and the interaction with the user and other participants in transactions; and a secure access interface between payer and online payment accounts. 

The access interface must allow for access by the user’s chosen account information service providers (AISPs) and payment initiation service providers (PISPs), although access by AISPs and PISPs can be facilitated via a dedicated interface that meets certain requirements. 

Wakey-wakey!

The End.

Will Regulatory Technical Standards Slow The Pace Of Payments Innovation?

Under the new Payment Services Directive (PSD2), the European Banking Authority (EBA) is tasked with producing 'regulatory technical standards' to be followed by those with certain obligations, including how payment service providers (PSPs) must authenticate customers and communicate with each other. But it seems this process and the standards themselves are acting as a brake on innovation and related investment.

The EBA consulted on its proposed regulatory technical standards for authentication and communication between August and October, with a revised set due in the coming months.

PSD2 requires PSPs to apply "strong customer authentication" where "the payer... accesses its payment account online, initiates an electronic payment transaction or carries out any action through a remote channel which may imply a risk of payment fraud or other abuses."

But two big issues raised by PSD2 are (1) how each type of payment is initiated; and (2) who actually initiates it.

The EBA believes card payments are initiated by the cardholder as payer, but fudges the issue somewhat by requiring the card acquirers (i.e. the PSP of the merchants) to require their merchants to support strong authentication for all payment transactions. The added complication is where a payment transaction is initiated by the payee, but the payer's consent is given "through a remote channel which may imply a risk of payment fraud or other abuses".

There is a view, however, that card payments are among those that are in fact initiated by the payee (the merchant), who is not in fact the 'payee' of the cardholder at all but is paid by the card acquirer to which the merchant submits its transactions. The cardholder just pays the card issuer. This is all bound up in fundamental problems with the definitions of "payment transaction", "payer" and "payee" in both the PSD and PSD2; and the fact that card acquiring works through a series of back-to-back contracts that do not involve any direct contract between the buyer and the seller at all concerning payment processing. Indeed, a challenge for the UK's implementation plans is that there is a Court of Appeal decision which supports this view. 

In these respects, PSD2 appears to set up a 'legal fiction', which (despite taking a somewhat purposive approach in the 'fudge' explained above) the EBA appears to insist on in language at the end of its consultation paper: "all the requirements under consultation apply irrespective of the underlying obligations and organisational arrangements between" the various types of PSP, payers and payees. In other words, we have a weird situation where the law and related standards are to be applied regardless of how payment systems and processes really work.

Not only can this lead to situations where, for example, some banks insist that the PSD does not cover card acquiring, but it can also cause over-compliance to avoid doubt and other restraints on innovation.

While distinctions concerning how payments are inititiated and by whom might seem to matter less in the context of security measures to be adopted by PSPs - since everyone is interested in reducing financial crime - it is absolutely critical in the context of software and services that contribute in any way to payments being "initiated" and whether the suppliers or users of such software and services must be authorised as "payment initiation service providers" or perhaps even as the issuers of payment instruments. 

It will be very interesting to see how the Treasury proposes to address these problems in transposing PSD2 itself, although it's more likely the FCA will be left to explain how to comply, assuming the Treasury declines to take a purposive approach to EU law and simply copies the language of PSD2 into UK law (a process known as 'gold-plating').

There are numerous other glitches in the technical standards that have been identified by respondents, too numerous to mention here, but which it is hoped will be reconsidered in the next version - not that such standards should ever be considered as 'final' or set for all time. Indeed, an overarching problem seems to be that in the EBA's attempts to drag our legacy payments infrastructure into the 21st century, insufficient attention has been given to existing and potential alternative security technology - even in cases where incumbents are seeking to leapfrog the limitations of legacy systems.

Meanwhile, a year has slipped by since PSD2 was approved and the standards themselves are only due to take effect in October 2018 'at the very earliest', by which time they are likely to be thoroughly out of step with commercially available technology. 

While old systems may need to be accommodated to some degree, surely the pace of payments innovation should not be tied to the slowest animals in the herd?

Guest Post at Open Identity Exchange - A Pragmatic Approach To Distributed Ledgers

The post appears here.

Thanks to OIX for the opportunity to support the initiative.

Of #Smart Contracts, Blockchains And Other Distributed Ledgers

Seems I caught Smart Contract Fever at last week's meeting of the Bitcoin & Blockchain Leadership Forum. So rather than continuing to fire random emails at colleagues, I've tried to calm myself down with a post on the topic.

For context it's important to understand that 'smart contracts' rely on the use of a cryptographic technology or protocol which generates a 'ledger' that is accessible to any computer using the same protocol. One type of 'distributed ledger' is known as a 'blockchain', since every transaction which is accepted is then 'hashed' (shortened into a string of letters and numbers) and included with other transactions into a single 'block', which is itself hashed and added to a series or chain of such blocks. The leading distributed ledger is 'Bitcoin', the blockchain-based virtual currency. But virtual currencies (commodities?) are just one use-case for a distributed ledger - indeed the Bitcoin blockchain is being used for all sorts of non-currency applications, as explained in the very informative book, Cryptocurrency: How Bitcoin and Digital Money are Challenging the Global Economic Order. As Jay Cassano also explains, another example is Ripple, which is designed to be interoperable with other ledgers to support the wider payments ecosystem; while Ethereum is even more broadly ambitious in its attempt to use smart contracts as the basis for all kinds of ledger-based applications.

Generally speaking, the process of forming a 'smart contract' would be started by each party publishing a coded bid/offer or offer/acceptance to the same ledger or 'blockchain', using the same cryptographic protocol. These would be like two (or more) mini-apps specifying the terms on which the parties were seeking to agree. When matched, these apps would form a single application encoding the terms of the concluded contract, and this would also be recorded in the distributed ledger accessible to all computers running the same protocol. Further records could be 'published' in the ledger each time a party performed or failed to perform a contractual obligation. So the ledger would act as its own trust mechanism to verify the existence and performance of the contract. Various applications running off the ledger would be interacting with the contract and related performance data, including payment applications, authentication processes and messaging clients of the various people and machines involved as 'customers' or 'suppliers' in the related business processes. In the event of a dispute, a pre-agreed dispute resolution process could be triggered, including enforcement action via a third party's systems that could rely on the performance data posted to the ledger as 'evidence' on which to initiate a specific remedy. 

Some commentators have suggested this will kill-off various types of intermediaries, lawyers and courts etc. But I think the better view is that existing roles and processes in the affected contractual scenarios will adapt to the new contractual methodology. Some roles might be replaced by the ledger itself, or become fully automated, but it's likely that the people or entities occupying today's roles would be somehow part of that evolution (if they aren't too sleepy). The need for a lot of human-readable messages would also disappear, signalling the demise of applications like email, SMS and maybe even the humble Internet browser. Most data could flow among machines, and they could alert humans in ways that don't involve buttons and keyboards.

So what are the benefits?

Well, it might take significant investment to set up such a process, but it should produce great savings in time, cost, record-keeping and so on throughout the lifetime of a contract. And, hey, no more price comparison sites or banner ads! Crypto-tech distributed ledgers would enable you to access and use a 'semantic web' of linked-data, open data, midata, wearables, smart meters, robots, drones and driverless cars - the Internet of Things - to control your day-to-day existence.

The downside?

This also might also play into the hands of the Big Data crowd (if they find a way to snoop on your encrypted contracts), or even the machines themselves. So it's critical that we figure out the right control mechanisms to 'keep humans at the heart of technology - the topic of the SCL's Tech Law Futures Conference in June, for example.

Meanwhile, I'm reviewing my first smart contract, which is proving rather like being involved in the negotiation of a software development agreement - which it is, of course. I'll post on that in due course, confidentiality permitting...

Of #Blockchains And #MultiFactorAuthentication

Okay, so yesterday I was trying to use the car rental scenario to understand the concept of blockchains and distributed ledger technology and ended with the point that all sorts of computer applications could run "on" the blockchain. Some could act as gateways between/among blockchains, and some could link applications on blockchains with the applications running on the Internet - like social media, email - or applications on mobile networks, including SMS. 

So, in the example, the contractual program running on the blockchain that doubles as my car rental contract could also initiate a text message telling me where and when to pick up my rental car. 

I also mentioned that my own request to rent a car could provide the details for where the car rental company's program could go to verify my driver's licence. I didn't mean for identification purposes, but to work out if I'm licensed to drive a vehicle.

On the identity front, I mentioned that both me and the car rental company would be acting pseudonymously. That's important because blockchain transactions are accessible by anyone with a device running the relevant technology. So mine and the rental car company's respective bits of code would have to offer a way for us to authenticate each other. And this is where the public nature of blockchains really come into their own.

Back in 2011, we had a big discussion on identity at the CSFI from which my 'takeaways' were that (1) identity is dynamic, not static - we are better defined by the data generated by everything we do, rather than a birth date or fingerprints. So (2) verifying our identity could be based on a unique snapshot of our behavioural data, which could then be discarded, rather than a passport etc.  which could be copied and used by fraudsters.

The challenge with multi-factor authentication in the Internet world is possibly that the data is subject to alteration (though on a mass scale it could be hard to alter every item of data about a person's behaviour).

But blockchains are infinitely harder to alter, since (I'm told) all the computers running the technology check each block when it is completed and that can't be undone, unless you control most of the computers at any one time (like a villain in a Bond movie).

So our identities could be verified by reference to a series of our blockchain transactions. For privacy and security reasons, each blockchain transaction should be coded so as not to give away much information about the transaction itself. That ought to be easy, since the code only needs to be understood by the computers who process each transaction at that time. At any rate, each transaction could somehow be combined into a unique identity token that would continually evolve to remain unique.

Hey presto, reliable multi-factor authentication!

Do I have any of this right?