Fintech Payments Security

PSD2 pixie dust

PSD2 pixie dust. Main image: artshock,
Written by Tom Hay

According to Tom Hay, the wording of the Regulatory Technical Standards leaves it open for anyone to call themselves PSD2 compliant.

I was recently on a panel at NextGen Banking Nordics, discussing PSD2 (of course). I was pretty critical of draft Regulatory Technical Standards (RTS) on Secure Customer Authentication, on which the consultation has just closed. 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, as he has two fintech clients relying on this, both of whom claim to be PSD2-compliant. 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.

Checking compliance

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 them rewrite them! This is a prime example of the problem. 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.

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’s 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”.

READ NEXT: The UK Open Banking API framework – more questions than answers?

Main image: artshock,

About the author

Tom Hay

Tom Hay is head of payments at Icon Solutions, and an IT architect specialising in large-scale, real-time payment systems. He has deep experience with financial institutions moving to next-generation payment systems. He draws on two decades of payments experience as head of architecture with one of Europe's largest clearing houses, and as CTO of a successful VC-backed company selling real-time payments products to international markets.

Leave a Comment