PSD2

From an end-user standpoint, PSD2 can be (very simplistically) summarised in the following sentence

Offer functional and security parity between a bank’s channels and its public APIs.

Or

A bank customer must be able to securely do through an API all things she can do through the bank’s other channels.

PSD2 is a “meaty” combination of legal text and technical standards to set out the requirements for secure access by bank customers to their accounts.
More specifically, it is composed of

• The Payment Services Directive 2 which sets out the legal framework and requirements for access to bank customer accounts by Third Party Providers (TPPs).
• The European Banking Authority technical standards for customer authentication and communications (a.k.a. EBA RTS) in PSD2.
• The Electronic Identification Regulation (eIDAS) which sets out the details on the operation of Trust Service Providers (TSPs, more on this below).

PSD2 by its nature (law and technical standards) answers the “why” (legal framework, ownership of data) and the broad “how” (public/private cryptography, identification and security).
The rest of the technical choices and concepts have evolved organically, taking into account industry best practice, while matching the spirit (if not the exact letter) of the law.

The following diagram describes the PSD2 ecosystem, the key elements and their interactions from a high level.
It will auto-scroll on most browsers, as I am making references to it throughout the text below.

Note: The scenario shows interactions in both a local and a cross-European level.
This is a super-set of all possible interactions and contains all concepts and entities. These will apply to the UK and elsewhere, with little change.

Let’s go through the different entities and how they interact.

QTSP

Trust Service Providers (TSPs) are

providing and preserving digital certificates to create and validate electronic signatures and to authenticate their signatories as well as websites in general.

In other words, they play the same role as Certification Authorities in a PKI infrastructure.

Becoming ‘Qualified’ means that they have

status and permission from a supervisory government body to provide qualified digital certificates which can be used to create qualified electronic signatures

The eIDAS legislation wanted to prevent the EU security market from being controlled by foreign entities.
For this reason, it lays out in detail the assessment and practices to be followed by QTSPs across all EU Member States. This will result in interoperability and commercial-grade security across the European trust infrastructure.

The list of each country’s QTSPs are published and regularly updated in a common top-level directory (List of Trusted Lists, LOTL)

The lists are published by each country’s regulator. Each QTSP entry contains their active top-level public key certificates as well as what functionality they are meant for (MA-TLS, e-signatures, timestamping,…). This list is open for inspection and consumption by anyone. More on the LOTL below.

TPP

A Third Party Provider (TPP) is an entity wishing to provide services to a Payment Services User (PSU, i.e. customer).
These services can be

• accessing the customer’s transaction data to generate insights (e.g. “you are spending too much on X”),
• initiating payments (e.g. “automatically invest an amount every month”), etc

Since TPPs are handling sensitive financial data, they are licensed and overseen by their country’s financial regulator (e.g. the Central Bank in Greece, FCA in the UK,…).

To participate in the PSD2 ecosystem and start calling banking APIs, a TPP contacts a QTSP (arrow 1) to issue 2 cryptographic certificates, a QWAC and a QSEAL. More on them below.
The QTSP performs a number of background checks on the TPP before issuing the certificates and charges a price (if the QTSP is a
commercial entity).
These certificates are used as the identifier of the TPP’s Application. A TPP (legal entity) can have many different Applications (i.e. brands) it is operating. ¹ In this case it is a best practice to issue multiple certificate pairs.

OBIE
In the UK, the OpenBanking Implementation Entity (OBIE) has played the role of QTSP so far.
It was established in 2016 to oversee the implementation and roll-out of the standard across the 9 major UK banks. Since OBIE is essentially an independent public entity, it has been offering its services to TPPs for free.

Consent

At the core of PSD2 & OpenBanking is the concept of Consent; the permission of the Customer (PSU) for her account to be accessed by a TPP.

In layman terms, an OpenBanking Consent is the equivalent of a notarized “contract”.
This contract is between the Customer and the TPP. The bank becomes the trusted 3rd party, safeguarding the interests of both Customer and TPP (akin to a notary).

If an OpenBanking “Account Access” Consent was a document, it would read something like

I (Customer) authorize TPP XYZ to access my account 123 and read items A, B and C. This authorization is valid until date DD/MM/YYYY.

When the Customer uses the TPP’s Application (arrow 2) to access her account, the TPP makes a call to the bank’s API (arrow 3).
If the Consent does not already exist, its capture flow is the first thing which takes place. More on this in the next section.

The Consent is stored in the bank’s systems.
Every time the TPP makes a call on behalf of the Customer, it references the Consent as “proof”. The bank provides a mechanism for the Customer to revoke the Consent at any time prior to expiration. This “breaks the contract” and prevents the TPP from any further calls on behalf of the the Customer.

ASPSP

In PSD2-speak a bank has the ceremonial title Account Servicing Payment Services Provider (ASPSP).
The reason they did not go for the term “bank” is that PSD2 covers not just banks but a wider range of deposit-holding organisations, like building societies in the UK.

The ASPSPs are responsible for implementing and enforcing the 3 key OpenBanking features: APIs, Security and Consent Capture.

1. APIs

Specification

To satisfy PSD2’s mandate, all European ASPSPs are required to publish dedicated APIs ². This needs to happen by the date of the law coming into effect. However that requirement does not say what the APIs should actually look like (i.e. endpoints, data,…).

In UK the API specification and roll-out has been centrally co-ordinated by the OBIE.
By signing up to the UK’s OpenBanking scheme, all participating banks are required to

• provide a uniform set of APIs according to the given specifications, and
• (most importantly) follow a uniform API version lifecycle and operational standards

This allows for a consistent and smooth integrator experience as all UK bank API implementations are practically identical.
Minor/optional differences are documented and the whole of the UK ecosystem is advancing from version to version in “lock-step”.

This is in contrast to the rest of the ASPSPs in Europe, where each bank is free to implement its own API specification.
Unlike the prescriptive OBIE mandate, the PSD2 technical specifications are very permissive. This results in a sea of nuances and differences from bank to bank.

Needless to say that these differences make it prohibitive for any small-to-medium TPP to create and maintain connections to more than one bank. This gives rise to API aggregators like Yapily and TrueLayer.
Their value proposition is that they provide a uniform, common API on top of all the different bank implementations. This approach, by necessity, does not expose every little bank-specific detail offered by each API. It is however the only way to hide the underlying “mess” and allow the TPP team to focus on delivering features.

Registration

A TPP Application needs to be registered with an ASPSP before they can start calling the APIs.

There are two ways of achieving this and ASPSPs pick one or the other.

• Manual registration (example)
  In this case, the TPP fills in a form in the ASPSP’s API portal, uploading their QSEAL certificate.
• Automatic registration (example)
  This approach follows the OpenID Connect Dynamic Client Registration specification. The TPP creates a signed software statement assertion, containing both the TPP’s information as well as the QSEAL.

Behind the scenes both approaches achieve the same thing: creating a client entry for the TPP’s Application in the authorisation server’s database, with the QSEAL as client credentials.

Alternative channels

It is worth noting that PSD2 explicitly mandates that ASPSPs make a dedicated TPP channel, not discriminating in terms of performance and availability compared to their other channels (mobile, eBanking,…).

In practice this means that the new APIs need to have

• the same uptime as the bank’s mobile/eBanking channels,
• the same performance/throughput, and
• (as a stop-gap) no unplanned downtime of more than 30 consecutive seconds.

The onus is on the ASPSPs to continuously prove that they meet this criteria.
If they do not, then they will need to provide a “fallback mechanism”. This fallback can be anything, from a
separate API stack to modifying their existing customer-facing interface for programmatic access by TPPs. ³

The creation of a new API with a complex new security profile is not a small undertaking, especially for small and medium banks.
This has led to a growing marketplace of providers for PSD2 API compliance solutions. These are “bolt-on” platforms exposing OpenBanking-compatible APIs to the outside world. Under the hood they can be configured to connect to existing legacy bank systems.

2. Security

The OpenBanking API security is built on top of the Financial API and Open ID Connect specifications.
In both cases it has opted for the highest security options, namely

• MA-TLS for communication, and
• JWT signatures for API client identification.

These are made possible by using a pair of…

QSEAL and QWAC

These acronyms come from the eIDAS regulation.

• QWAC
  Qualified Website Authentication Certificates (QWACs) are intended for ‘Internet Entity Identity’ authentication and encryption. They are meant to be used at the Transport Layer. In OpenBanking they are used in MA-TLS communication between the TPP and the bank.
• QSEAL
  Qualified Electronic Seal Certificates (QSEALs) are to be used at the Application Layer. They are used to “stamp” communication in order to prove origin, authenticity and integrity. In OpenBanking they are used for JWT signatures.

QWACs and QSEALs are issued by QTSPs, signed by the QTSPs Certification Authority certificate. The QWAC/QSEAL contains specific fields allowing the bank to identify the TPP legal entity.
In the digital domain, the presence of valid certificates is legal proof that

• the call to the bank’s APIs comes from a TPP
• …who is properly regulated (its regulator id being in the certificate), and
• …which has undergone checks by the QTSP.

As a consequence, for any ASPSP receiving an API call with an expired/revoked TPP certificate it is a signal that “the TPP has lost its license or is otherwise unfit for financial transactions”.

Which makes it critical that the banks perform…

Certificate validation

During the MA-TLS handshake of a PSD2 API call (arrow 3), the bank receives the TPP’s QWAC.
It then needs to answer 3 questions:

• Is this a syntactically correct TPP eIDAS certificate, i.e. according to the spec?
• Is this certificate issued by a trusted QTSP, i.e. has the TPP been properly vetted?
• Is this certificate still valid and not revoked, i.e. is the TPP still authorized to make PSD2 calls?

Syntax check
The certificate’s field values must correspond to the prescribed ETSI standard.

QTSP check
The European Commission publishes a machine-readable top-level “List of Trusted Lists” (LOTL).
This is an ETSI TS 119 612 XML document, acting as an index to the list of trusted QTSPs, published by each member state. For example, in the excerpt below, you can see the URL location of the Austrian list of QTSPs.

1
2
3
4
5
6
7
...
<OtherTSLPointer>
  <ServiceDigitalIdentities>...</ServiceDigitalIdentities>
  <TSLLocation>https://www.signatur.rtr.at/currenttl.xml</TSLLocation>
  <AdditionalInformation>...</AdditionalInformation>
</OtherTSLPointer>
...

Downloading the Austrian list we have, among others

• the update schedule of the list itself (ListIssueDateTime, NextUpdate)
• the different QTSPs (TrustServiceProvider), each one having…
• their CA X509 certificates and subject names,
• what types of eIDAS certificates this CA can issue (e.g. CA/QC means QWAC/QSEAL),
• if this CA is currently active (e.g. this one is granted, i.e. active), and
• when the current status started (in this case, when it was activated and started issuing eIDAS certificates)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
...
<SchemeOperatorName>
  <Name xml:lang="en">Rundfunk und Telekom Regulierungs-GmbH</Name>
  <Name xml:lang="de">Rundfunk und Telekom Regulierungs-GmbH</Name>
</SchemeOperatorName>
...
<ListIssueDateTime>2020-01-09T01:00:00Z</ListIssueDateTime>
<NextUpdate>
  <dateTime>2020-07-09T00:00:00Z</dateTime>
</NextUpdate>
...
<TrustServiceProviderList>
<TrustServiceProvider>
<TSPInformation>
<TSPName>
  <Name xml:lang="en">
  A-Trust Gesellschaft für Sicherheitssysteme im elektronischen Datenverkehr GmbH
  </Name>
</TSPName>
...
</TSPInformation>
<TSPServices>
<TSPService>
<ServiceInformation>
<ServiceTypeIdentifier>http://uri.etsi.org/TrstSvc/Svctype/CA/QC</ServiceTypeIdentifier>
<ServiceDigitalIdentity>
<DigitalId>
  <X509Certificate>
  MIIE0TCCA7mgAwIBAgICApMwDQYJKoZIhvcNAQEFBQAwgc8xCzAJBgNVBAYTAkFUMYGLMIG...==
  </X509Certificate>
</DigitalId>
<DigitalId>
  <X509SubjectName>
  CN=TrustSign-Sig-01, OU=TrustSign-Sig-01, O=A-Trust Ges. für Sicherheitssysteme im elektr. Datenverkehr GmbH, C=AT
  </X509SubjectName>
</DigitalId>
</ServiceDigitalIdentity>
<ServiceStatus>
http://uri.etsi.org/TrstSvc/TrustedList/Svcstatus/granted
</ServiceStatus>
<StatusStartingTime>2017-10-04T22:00:00Z</StatusStartingTime>
...

Validation check
The company A-Trust, the QTSP in the above XML fragment, is a trusted one; all European ASPSPs must accept eIDAS certificates issued by it. This means being able to perform an MA-TLS handshake and accept the TPP client certificate.
For this to happen securely, the bank needs to add the above X509Certificate value to the whitelist of its network device handling TLS (usually the external load balancer).

Considering that the LOTL contains entries for 10s if not 100s of QTSPs from around Europe and is updated almost daily, the bank needs to

• download and parse it at least once a day (example parser),
• update their network device(s) with the whitelisted QTSP CA certificates, and
• (most importantly) upon receiving a QWAC, reach out to the issuing QTSP’s Certificate Revocation List or OCSP endpoint to verify that the QWAC is still valid (arrow 4).

All of this is NOT a trivial task to configure, operate AND keep performant.

The same concern extends to validating TPP JWT signatures with QSEALs.
In the UK ecosystem, the OBIE is providing a central JWKS endpoint listing the TPP public keys for signature validation (example entry). However this is a convenience and not a standard approach across the EU.
In the general case of PSD2, the bank has no central reference for the public key of QSEALs, hence it requires the TPP to upload them to the API portal in advance.

3. Customer consent

As mentioned previously, the first thing that happens when a TPP calls a bank, is capturing the Customer’s Consent to share her data with the TPP.
The OpenBanking technical specification solves this by implementing a Hybrid Flow based on OpenID Connect. In this implementation, the intentId is the unique Consent identifier.

Visualizing the flow from a customer’s point-of-view (e.g. to initiate a payment) will make things clearer.

Source: OpenBanking - Customer Experience Guidelines

• The TPP’s application has gathered all information from the Customer (bank details etc) and displays a confirmation screen with the payment that will be initiated (red dot 1, 2)
• It then redirects the Customer to the bank’s OpenBanking endpoints to capture the Consent (blue 3).
  Behind the scenes, the TPP’s application has already initiated the Hybrid Flow, by making API calls. These calls inform the bank that “Please create a Consent for a payment of £31.94. A Customer is coming your way to confirm it”.
• The bank displays its standard login screen to the Customer (red 4).
  This is where the bank gets to know who the TPP’s customer really is. In this example it also captures the explicit Customer’s Consent for the transaction (red 6).
• Once the Customer identifies herself and clicks Continue/Confirm, the Bank sends the Customer back to the TPP (blue 7).
  Behind the scenes, the bank confirms to the TPP that the Consent has been authorized by the Customer. The payment can be initiated at the TPP’s discretion.
  From that point on, the TPP’s application continues with its normal UX (red 9).

The Customer Experience Guidelines of OpenBanking has a wealth of mockups and guidelines, describing happy and unhappy paths for various Consent capture scenarios (web, mobile, token-based identification,…).

Regulators and passporting

The last case of PSD2 validation is a regulatory one. It is also the most interesting and peculiar.
Within the EU, any financial institution is licensed by its home country’s regulator to operate within that country. The EU’s legal framework also allows it to provide services to any other EU country, as long as the regulator has given it explicit permission for those countries. This explicit permission is called passporting. ⁴

EU banks, upon receiving an API call from a TPP licensed in another country ⁵, must check if this TPP is passported for the bank’s country of operations (arrow 5).

This is where it gets interesting. There is no machine-readable standard for reporting this information.
Regulators are free to provide this information as they wish, resulting in a mish-mash. Here are some examples from Austria, Hungary, Latvia and Greece.
There is an EBA register of TPPs which also exists in machine-readable form, but this is a convenience only; it has no guarantee of accuracy or legal standing.
The only real way for a bank to be covered for regulatory risk ⁶ is to either write custom screen-scraping code for all the regulator websites or have people checking their websites every day.

This information gap has given rise to an interesting business model: “regulatory service” API providers, like Preta and Konsentus.
Behind the scenes this type of providers do exactly that: they either have custom screen-scraping code or simply mechanical turk operations, fronted by an easy-to-use API. They provide the operational and indemnity guarantees that information is timely and accurate.