PSD2 – Powered By Pixie Dust

I was recently on a panel at NextGen Banking Nordics, discussing PSD2 (of course) where I was pretty critical of the draft Regulatory Technical Standards (RTS) on Secure Customer Authentication.

After the discussion, a venture capitalist approached me in a fluster and asked me to clarify why authentication via mobile phone may not comply with the RTS.  He had two fintech clients relying on this, both of whom claim to be PSD2 compliant.

Examining the draft

I explained as follows.

The relevant section of the draft RTS is Article 6 which says:

2. Where any of the elements of SCA is used through a multi-function device [it] shall provide measures to mitigate the risk of the multi-purpose device being compromised.
3… the mitigating measures shall include, but not be limited to:
a)  the implementation of separate trusted execution environments inside the multipurpose device.
I had mentioned on the panel that the wording of the RTS is very ambiguous – if one of my business analysts wrote requirements like that, I’d make him/her re-write them! This is a prime example of the problem.

Clarifying the ambiguities

In this particular case, there are two ambiguities. First, how should we parse the phrase “shall include, but not be limited to…”? One possibility: “Shall include” means the following items MUST be included, “but not be limited to” means other items MAY be included – in which case, a trusted execution environment is mandatory. Or does it mean “the following items are examples of what is permissible, but there may be others (unspecified)?” In which case the standard allows a trusted execution environment, but offers no guidance on what else is permissible.

Second, what are “trusted execution environments” anyway? The phrase Trusted Execution Environment (capitalised) generally refers to the GlobalPlatform specification. Is that what the RTS means? If not, what DOES it mean? Who decides whether a particular phone, or operating system, or app, is a trusted execution environment?

The answer is that there is no official body proposed to check compliance against the RTS. Article 7 allows PSPs to self-certify using internal or external auditors, according to the PSP’s own audit framework. When the inevitable security breaches occur, lawyers will be the only ones to benefit as parties fight out their varying interpretations of the standards.

Putting your trust in pixie dust

This is a single example, but the draft RTS is riddled with similar vagueness and ambiguity. That is the heart of our critique of the RTS. With its loose language and failure to define terms, it is not a standard against which things can be evaluated. That leaves it open for any vendor to declare their product or service “PSD2 compliant”, and buyers have no way to validate that claim.

You should treat such claims like a car bumper sticker that says “Powered by Pixie Dust”.