Beyond PSD2

Contents

Introduction .................................................................................................................................................. 3

Timeline ....................................................................................................................................................... 4

Understanding the use cases ................................................................................................................... 4

Account Information Service Provider (AISP) .................................................................................... 4

Payment Information Service Provider (PISP) .................................................................................. 4

PSD2, Open Banking, Berlin Group and More ...................................................................................... 5

How to achieve PSD2 compliance .......................................................................................................... 7

TPP on-boarding .................................................................................................................................... 7

User Enrolment and Consent ............................................................................................................... 7

API access .............................................................................................................................................. 7

TPP on-boarding ........................................................................................................................................ 7

Single Sign On (SSO) ............................................................................................................................ 8

Developer on-boarding using API management portal .................................................................... 8

Developer on-boarding using Identity and Access management (IAM) solutions........................ 9

Developer Lifecycle, workflow, and governance ............................................................................. 10

Obtaining client credentials ................................................................................................................. 10

User Enrolment and Consent ................................................................................................................. 11

Browser based TPP ............................................................................................................................. 12

Hybrid Mobile application TPP ........................................................................................................... 14

Native Mobile application TPP ........................................................................................................... 15

SCA ........................................................................................................................................................ 18

Reuse Existing SCA ......................................................................................................................... 18

Introduce New SCA ......................................................................................................................... 18

APIs for SCA ..................................................................................................................................... 18

Dynamic Linking ................................................................................................................................... 19

User Consent ........................................................................................................................................ 19

API Access ................................................................................................................................................ 19

Token – Session model ....................................................................................................................... 20

Transaction and Device data model .................................................................................................. 21

Architecture ............................................................................................................................................... 21

Implementation ......................................................................................................................................... 22

Conclusion ................................................................................................................................................. 25

Appendix .................................................................................................................................................... 25

FAQ ............................................................................................................................................................ 25

Author Pranam Codur, IT Security Specialist, IBM Security

Reviewers Bharat Bhushan, Industry Technical Leader, IBM Banking and FM

Carlo Marcoli, Senior Managing Consultant - API Connect Solutions

Sridhar Muppidi, IBM Fellow, VP & CTO IBM Security

Terminologies

Abbreviations Table

AISP Account Information Service Provider

PISP Payment Initiation Service Provider

TPP Third Party Provider

ASPSP Account Servicing Payment Service Provider

PSD2 Payment Services Directive 2

OBIE Open Banking Implementation Entity

CMA Competition Markets Authority

EBA Euro Banking Association

EU European Union

eIDAS electronic IDentification, Authentication and trust Services

OIDC OpenID Connect

Introduction PSD2 is a regulation that affects banks and financial institutions in the European Union

(EU). The goal behind the PSD2 regulation is to promote competition, make payments

secure, consumer protection and reduce costs of payment services.

From a technology standpoint, banks are required to expose interfaces to third party

providers (TPP). These interfaces can be APIs or might expose screen scrapping

capabilities. The TPP can be an incumbent bank, fintech organization or a merchant

that offers payment services. The TPPs can provide account aggregation and payment

services. The bank’s consumer will have a choice in how they use some of the banking

services. They can continue to use existing apps and card-based payment mechanisms

or, they can interact with the TPP to adopt and use these services. The latter approach

will disintermediate the bank.

If PSD2 is a regulation for banks in the EU, then Open Banking is a regulation that

affects bank in the United Kingdom. Many countries have started creating similar

regulations [see appendix].

This document will discuss the technology components required to build a PSD2

compliant solution and capture ideas being explored by banks which is outside the

scope of PSD2. The solution and technology components explained in this document

are compatible with other regulations. The reader is expected to have a technology

background.

Timeline

Understanding the use cases Let us understand the two main use cases in PSD2 with examples.

Account Information Service Provider (AISP) use case - A multi-bank user gives

consent to a TPP to access their bank accounts. The TPP – in an AISP role in this

instance, launches an application that displays the account balances and transactions

from all the bank accounts owned by the user.

Payment Information Service Provider (PISP) use case - A user is at the checkout

screen of an eCommerce website. The user gets a choice to make the payment using

PayPal, debit or credit card and “Direct from Account”. The user chooses the “Direct

from Account” payment mechanism. The user is redirected to a TPP – in a PISP role.

PISP gets the user’s consent to initiate the payment with the user’s bank. The user’s

bank confirms the initiation of payment to the PISP and notifies the user. The merchant

receives the payment and delivers the services.

There are other use cases which are not covered in this document as the concepts

explained using the two main use cases hold valid for the other use cases.

The document explains the consent mechanisms and user flow in detail in the sections

below.

PSD2, Open Banking, Berlin Group and More There are many documents and working groups on PSD2 regulation. The PSD2 RTS

are a set of guidelines published by the EBA defining how the market participants are

expected to implement PSD2. In other words, The PSD2 RTS is a guide that captures

the requirements at a high level and does not capture technical details such as

protocols to be used and implementation details. PSD2 is a policy document. The UK

Open Banking Implementation Entity (OBIE) and other working groups capture the

requirements at a low level and explicitly mentions the protocols and technology

requirements (See Appendix). Berlin Group, a pan-European payments interoperability

standards group, has created documentation that captures technical details. Most

organisations tend to follow the practices captured by these two groups. These two

groups are defined in the context of the EBA RTSs. However, there are many other

organisations that are creating standards and implementation guides in this domain.

In Table 1, a high-level comparison between OBIE and Berlin Group is captured. This

document will focus on all the details shown in the table below.

Table 1

How to achieve PSD2 compliance There are three steps to realize the PSD2 use cases.

TPP on-boarding

The TPP uses the APIs exposed by the bank and provides AISP or PISP services to the

bank’s consumer. To use the APIs, the TPP needs an eIDAS certificate. However,

some ASPSPs recommend TPPs to obtain credentials from the bank. In this document

we will focus on the latter pattern.

User Enrolment and Consent The TPP application is developed and used by the bank’s consumer. The consumer is

asked to authenticate at the bank and authorise the TPP transaction. The bank’s

consumer gives consent to the TPP to use data that belongs to him/her.

At a later point, the consumer can withdraw the consent. The implication is that the bank

needs to support consent management

API access Once the bank’s consumer provides consent, the TPP can make transactions on behalf

of the user. The TPP provides AISP or PISP services to the consumer by calling the

bank’s APIs

Strong Customer Authentication (SCA) and Fraud Protection are needed at every step.

The following sections will explain each of the steps in detail.

There are other features that need to be developed for a complete PSD2 solution. The

table below shows the features that are mandatory and optional.

Features Required

Developer portal Yes

APIs – future dated payments Yes

TPP Onboarding Yes

Initiate payments Yes

XS2A services Yes

Value-add services No

Platform/ Ecosystem No

SCA exemptions No

TPP on-boarding As mentioned earlier, we discuss the approach where the TPP needs credentials from

the bank to access the bank’s APIs. The TPP developer authenticates and proves the

validity of the TPP before obtaining credentials from the bank’s developer portal. To fulfil

this requirement, the TPP needs to register with a central directory that is known to all

banks and the bank needs a developer portal that can connect to this central directory

to confirm the validity of the TPP. Using a developer portal can be an obstacle to

adoption. Dynamic registration of TPPs using eIDAS certificate to validate the TPP is a

model that is being recommended by the community. However, the banks are still

exploring using a developer portal for API governance, enforcing security and API

usage analytics.

PSD2 and Open Banking directories such as PRETA and Open Banking Directory have

their own onboarding process for the TPP. This topic is outside the scope of this

document.

There are many different approaches to manage the TPP developer authentication and

authorization to the bank’s developer portal.

Single Sign On (SSO) The TPP developer could sign in at the central directory to access the bank’s API portal.

In OBIE, the Open Banking Directory acts as an OpenID Connect (OIDC) Provider and

the bank’s API portal acts as the OpenID Connect Relying party. Figure 1 shows a high-

level view of the integration.

Figure 1

In this model, the TPP developer registers and authenticates at the central directory.

The central directory also issues a Software Statement Assertion (SSA) to the TPP.

SSA is a JSON Web Token (JWT) containing metadata about the TPP.

OIDC flow is used to sign in the TPP developer to the bank’s developer portal. The ID

token generated during the OIDC flow contains TPP information. The information is

used to sign in the developer at the bank’s developer portal. Additionally, the bank’s

developer portal could call an API on the central directory to verify the SSA.

The alternate approach being discussed in PSD2 work group is that ASPSPs and TPPs

will use eIDAS qualified website certificates for mutual authentication. The eIDAS

certificate might contain details like that captured in the SSA.

Developer on-boarding using API management portal In this model, the TPP developer registers and authenticates at the API portal hosted by

the bank. Many vendors provide API management tools that also support developer on-

boarding. Figure 2 shows a high-level view of the integration.

Figure 2

The developer authenticates at the developer portal and in some cases provides an

SSA issued by the central directory. The developer portal has built in access control

policies to allow or deny access. As mentioned in the previous model, the bank’s

developer portal could call an API on the central directory to verify the SSA.

In many cases, the TPP developer may not have SSA issued by the central directory. In

such cases, additional information from the developer might be required.

Developer on-boarding using Identity and Access management (IAM) solutions This is a model outside the scope of PSD2. However, we notice many banks exploring

and implementing this pattern. In this model, the TPP developer registers and

authenticates at the API portal hosted by the bank. But the API portal is protected by an

IAM solution. This model is needed is most cases as API management vendors do not

support complex authentication and authorization requirements such as Social Login,

Strong Authentication, Risk Based Access, etc. Many API management vendors

support SSO via standards such as OIDC and SAML. These technologies are used to

integrate the developer portal with the IAM solution.

Figure 3

The developer authenticates at the IAM solution that protects the developer portal. As

mentioned in the previous models, the bank’s developer portal could call an API on the

central directory to verify the SSA.

This is a recommended model as it captures complex requirements but follows industry

standards. The solution can be hosted in the cloud, on-premise or a hybrid approach

can be taken based on the use cases. Parts of the solution are also available as SaaS.

Developer Lifecycle, workflow, and governance TPP developer might belong to an organization that has its own hierarchy. The

developer’s role might decide the access rights and subscriptions to APIs. The

developer’s manager or the bank’s administrator might want to approve, deny, and

govern the developer’s identity. The bank’s API publisher might want to recertify access

to APIs. There are many other use cases that need to be fulfilled. Remember, these use

cases are outside the scope of PSD2. However, many banks are exploring and

implementing these requirements.

Most API management vendors provide capabilities around basic subscription and

workflows. The recommended approach is to use a vendor who provides an ability to

extend this capability and integrate with an IAM solution (Figure 4)

Figure 4

Obtaining client credentials The TPP developer will authenticate to the developer portal and obtain credentials.

These are also known as client credentials as the TPP is the client that accesses the

bank’s APIs. The client credentials allow the TPP to trigger delegated authorization

protocol flows such as OAuth and OpenID Connect (OIDC). As discussed earlier, if

APIs can be accessed using eIDAS certificates then this pattern is not required.

However, we see that banks prefer an approach where TPPs obtain client credentials.

The TPP developer is requested to enter details about the TPP such as TPP name,

redirect URI, etc. This data can be validated with the central directory.

The client credentials should be accessible by the API management solution and the

IAM solution. We recommend that the architecture be such that the two solutions are

loosely coupled. The advantages of such an architecture is listed below.

• API management and Security are handled by components specifically

developed for such requirements.

• Flexibility to replace each solution

• Extension and addition of components that fulfil fraud protection and strong

customer authentication

Figure 5 shows the model where the credentials are synchronised between the two

components.

Figure 5

A component such as the synchronize service might be needed because the bank’s

developer portal and the IAM solution are generally on different network zones.

However, many API management vendors allow plugins that help synchronize data to a

database or by calling out to a service. In such cases, the synchronize service is not

required.

At the end of this step, the TPP has client credentials that can be used in the TPP

application to call bank APIs and trigger user flows.

User Enrolment and Consent The TPP developer releases the TPP application. TPP could be a mobile based

application or a browser-based application. The technology requirements differ based

on the type of application. Each subtopic will cover user consent, fraud protection and

strong customer authentication (SCA)

Browser based TPP In this model, the bank’s consumer, herby called user interchangeably, launches the

TPP and selects the bank where he/she has an account. The TPP triggers an OIDC

flow which redirects the browser to the bank’s login page. While this document explains

the OIDC flow remember that this protocol is not mandatory. The user authenticates at

the bank and gives consent to the TPP. Based on the risk the user might be requested

to complete strong authentication. In the end, the TPP receives an access token. This

access token can be used by the TPP to make transactions on behalf of the user.

Figure 6 shows the user interaction with the TPP. The user experience might differ, but

the core requirement is captured in the use case flow mentioned in Figure 6.

Figure 6

Let us revisit the use case in detail. The TPP triggers an OIDC flow. Note that PSD2

and some groups do not specifically mention OIDC. In some cases, OAuth is

suggested. However, the both OIDC and OAuth are delegated authorization protocols

and many banks use it to fulfil their PSD2 requirements.

The use of OIDC protocol is recommended due to the reasons mentioned below.

• Access and Identity tokens can be created

• Signed and encrypted requests can be handled

• Industry wide adoption

• Recommended by groups working with OBIE and FAPI

The OIDC request can contain data that is validated by the bank. In some cases, the

bank validates the data with the central directory. The Open Banking specifications

require the bank to use MTLS to validate the TPP. But, many banks have their own

interpretation of the specifications and tend to validate the TPP in different ways.

The user is requested to authenticate at the bank. Most banks want to keep the user

experience the same and do not show a new user interface. In such cases, there needs

to be an integration between the bank’s login component and the IAM solution that

provides the support for OIDC. Many vendors support such integrations.

After the user authenticates at the bank, a risk engine calculates the risk. The term risk

engine is used to capture different requirements. The risk engine needs to support the

following.

• PSD2 specification requirements that categorize payments above a certain value

as risk

• PSD2 requirements around adaptive and risk-based access

• Malware and Fraud detection

The enforcement of the policy can be triggered at different points. The IAM solution, the

gateway which might be placed in front of the IAM solution or the service implementing

the API can be enforcement points. The implementation team needs to evaluate the

pros and cons of using a specific enforcement point.

The risk engine uses a policy to identify the requirements. A dynamic policy based on

OIDC request data or a predefined policy can trigger strong customer authentication

(SCA). A dynamic policy that identifies malware and fraud is needed. In a browser flow,

JavaScript snippets can be inserted in the bank’s login and consent page. The data

collected by the snippets can be used to identify risk. Omni channel data such as ATM

data, user fraud rates, transaction risk analysis data, etc can be used to identify the risk

associated with the transaction. Many vendors provide a cloud-based fraud/risk

protection solution backed by research teams. Figure 7 shows the pattern explained

above.

Figure 7

Based on the risk SCA is triggered. This could be an in-band SCA where the existing

security tokens already available to the user can be used or an out-of-band notification

based SCA can be used. Since the user is authenticated at the bank the existing

security tokens can be used. Most banks opt for this approach as it is cost effective and

on-boarding a new out-of-band notification based SCA might be expensive. However,

later in the document, we will discuss the need for a new SCA.

Hybrid Mobile application TPP In this model, the bank’s user, launches the TPP mobile application and selects the

bank where he/she has an account. The TPP triggers an OIDC flow which launches and

redirects a browser to the bank’s login page. The user authenticates at the bank and

gives consent to the TPP. Based on the risk the user might be requested to complete

strong authentication. In the end, the TPP receives an access token. This access token

can be used by the TPP to make transactions on behalf of the user.

The browser that gets launched can be a web view or the mobile’s native browser. The

redirect URI configured for OIDC will point to the mobile application’s native URL. Apple

and Google recommend using native SDKs and not relying extensively on hybrid flows.

The user experience too is different when a hybrid application is used. The redirection

sometimes launches pop-ups which leads to poor user experience.

After the user authenticates at the bank, a risk engine calculates the risk. The same

model as explained in Figure 7 can be used. However, the data collected by snippets

from the native browser or a web view is minimal and risk identification is comparatively

less effective. Despite the limitations, many customers still prefer hybrid applications

because it is easier to develop.

Native Mobile application TPP In this model, the bank’s user, launches the TPP mobile application and selects the

bank where he/she has an account. The TPP triggers an OIDC flow which launches a

view that requests the user to login with their bank’s user credentials. The user

authenticates at the bank and gives consent to the TPP. The consent view will be like

the login view. Notice that there is no browser in this flow. Based on the risk the user

might be requested to complete strong authentication. In the end, the TPP receives an

access token. This access token can be used by the TPP to make transactions on

behalf of the user.

The EBA suggests that the user gives consent only to the TPP and there is no consent

required on the bank. However, most banks have not yet implemented this pattern.

Another emerging pattern is around client and server-side components for TPP. The

TPP client does not directly obtain the access token. The server-side component of the

TPP obtains the access token and the TPP client calls the APIs via the server-side

component. However, this will be additional burden on the TPP.

For a complete native experience, the following must be fulfilled.

• The bank should expose authentication APIs

• The user experience while authenticating at the bank should be evaluated by the

application development team. A new bank login user interface can take users by

surprise.

• The TPP must ensure the user credentials are securely sent to the bank’s

authentication API

• The risk engine will rely on data sent by the native TPP application

After the user authenticates at the bank, a risk engine calculates the risk. There are two

models which can be used to send data to the risk engine. In Figure 8, the TPP

application uses an SDK to send data to the risk engine. The data is used to calculate a

risk score and trigger SCA which can be completed by the user using the Bank’s native

application.

Figure 8

In Figure 9, the TPP application uses an SDK to send data to the risk engine. The data

is used to calculate a risk score and trigger SCA which can be completed by the user

using the TPP.

Figure 9

There are limitations in both models as mentioned below.

• Many vendors offer SDKs that help integration with risk engines. However, TPP

developers might be reluctant to use risk detection SDKs specified by the bank’s

vendor because the TPP developer might end up using multiple SDKs based on

each bank’s preferred vendor.

• If the SCA is handled by the TPP then the bank must expose the authentication

APIs and the challenges explained in the previous section need to be discussed.

• If the SCA is handled by the Bank’s native application, then an integrated

solution needs be developed where the risk data is sent by the TPP but a SCA

notification sent to the user via Bank’s native application. Once the SCA is

approved then the TPP flow resumes.

SCA The core requirement in PSD2 is SCA. The Berlin Group specification explains in detail

the different SCA options. However, it does not explain whether a bank needs to use

existing SCA mechanisms or introduce new SCA mechanisms.

An existing SCA mechanism can be used when there is a user session at the bank.

When there is no user session at the bank, using existing SCA mechanism can be

complex. Let us understand the patterns with use cases.

Reuse Existing SCA

The user launches an application that triggers PSD2 use case flows mentioned earlier.

Since, the user is always requested to authenticate and give consent at the bank, there

is a valid user session. The user might be able to use a hardware token or enter an

SMS sent to the user to complete the SCA. Many banks use such SCA mechanisms

and this would work if the user interacts with the bank during the PSD2 flow.

Introduce New SCA

A typical use case is when a payment is made at a kiosk. At a kiosk, the user might not

be able to use a hardware token or enter an SMS sent to the user. An out of band

authentication via notification might be needed.

Another example is recurring payment use case. The payment might be scheduled

monthly without requiring user to be logged into the bank. If a risk is identified during a

recurring payment, the bank might want to trigger SCA. An out of band authentication

via notification might be needed. Most specification do not discuss this use case, but

banks consider this to be a valid requirement.

The recommended approach is to use existing SCA mechanisms for the common use

case but start implementing out of band authentication mechanisms. Many banks are in

the process of implementing new SCA mechanisms as a part of their digital

transformation strategy.

APIs for SCA

Some banks are exposing APIs for user authentication and SCA. The TPPs will call the

APIs and the bank’s user interface is not used. There are some points to keep in mind

while using such an approach as listed below.

• User experience will be different when an API is used compared to a browser

redirect to a familiar user interface

• Security implications of letting TPPs call APIs

• Triggering existing SCA methods without user sessions might not be feasible. In

a later section, this document discusses an approach to support such

requirement.

Dynamic Linking Dynamic linking is closely linked to SCA. The requirement is to link authentication

tokens to the payment amount and payee of the transaction. This helps maintain the

integrity of the transaction. Any change by a malicious entity during the transaction can

be identified and the token can be invalidated.

We have seen banks follow some of the methods given below to fulfil this requirement.

• Transaction Signing during SCA using public key cryptography. During the step

where the user authorizes the TPP, the transaction is linked to the access token

• Linking the token to the payment transaction. In this method, the access token is

linked to the payment transaction in a data store

• Encoded tokens. In this method, the encoded access token has information

about the transaction. This however is the least recommended method as it

poses security threat. Some customers use public key cryptography to overcome

the security problem. However, this add burden on the TPP to decode the token.

Most IAM solution vendors expose interfaces to develop the methods explained

above. Vendors claim out of the box solution. However, the exposed interfaces are

needed to build a complete solution.

User Consent During the PSD2 use case flow, the user gives consent to the TPP. Many vendors

provide consent management capabilities in their IAM solution. However, many banks

are exploring developing or integrating consent management systems external to the

IAM solution. The consent management system might help with GDPR requirements.

Given below are some consent management system requirements that can be fulfilled

by an IAM solution vendor or must be developed by the bank.

• Users should be able to revoke consent to the TPP

• Users can temporarily enable or disable access to their data

• (Optional) Users can enable or disable access to specific data

API Access The access token obtained by the TPP is used to make API calls and provide AISP and

PISP services to the user. The technical specifications for PSD2 and Open Banking do

not explain the need for SCA during the API access in detail. However, many banks

want to protect users from fraud when the TPPs access APIs.

The API service can integrate with the bank’s existing fraud and risk engine to detect

threat during API access and trigger SCA if needed. Let’s understand the different

models that can be used for API access with fraud protection and SCA.

Token – Session model This model is shown in Figure 10. During API access, the access token obtained by the

TPP can be exchanged to obtain a user session. The user session and page friction can

be used to identify user behaviour pattern and malware threats using snippets as

mentioned earlier. The data collected by the snippets can be used to identify risk. Omni

channel data such as ATM data, user fraud rates, transaction risk analysis data, etc can

be used to identify the risk associated with the API call. Based on the risk, SCA can be

triggered. Since the access token is used to create a user session the existing SCA

mechanisms can be used. There are implications associated with this model as listed

below.

• The model creates a user session. The user session can be used to make

malicious transactions

• Converting an access token to a user session does not align with the OIDC

principles of delegated authorization

• The model works only for browser based TPPs

Despite the challenges banks are exploring this model as some banks require user

sessions to serve API requests.

Figure 10

Transaction and Device data model This model is shown in Figure 11. During API access, the transaction data and device

data is passed to the risk engine. This data is used to calculate risk and trigger SCA.

The TPP may not send device data but the transaction data along with protocol headers

might help identify some of the device attributes. Integrating with a backend system can

help identify omni channel threat. This is a recommended model.

Figure 11

Architecture An overview of the PSD2 reference architecture for an ASPSP is shown in Figure

12. Let us understand the architecture components and players.

At the boundaries: TPP, the consumer using the TPP, the TPP registry and the

certificate authority issuing the eIDAS certificates.

In the middle: The services exposed by the bank for PSD2 use cases.

In grey: The back-end systems managing accounts and payments including the

integration and messaging layer.

In green: The security component for PSD2.

In dark blue: Gateways to enforce API access policies, a developer portal to enable

TPP developers to subscribe to APIs, API management and analytics to control the API

lifecycle, monetisation elements, etc.

The components mentioned here are not mandatory, but they become essential when

the ASPSP wants to achieve goals beyond compliance requirements. These

components also get added based on the maturity of the API strategy.

In light blue: The TPP registry holding a copy of the data stored in the European

Registry. The account request and payment initiation services support the interactions

between the TPP, the ASPSP and its consumer. The Sandbox enables the TPP to test

those interactions using mock data.

Figure 12

Implementation A leading financial services group in Europe built their PSD2 solution as shown in

Figure 13

Figure 13

In the solution described above, the API calls are routed via a reverse proxy. The

access manger solution helps maintain session, transform security tokens, and use

delegated authorization protocols. This model helped the customer to release their first

version of the PSD2 solution. However, the recommended approach is shown in Figure

14.

Figure 14

In this model, the API Gateway is not inline with the access management solution. The

end user interacts with the access manger reverse proxy. Once the access token is

available to the TPP, the TPP calls APIs behind the API gateway. The risk engine is

used to detect threat during all interactions.

Figure 15 shows the entire PSD2 user interaction flow in detail.

Figure 15

Let us understand the steps in detail. The assumption here is that the APIs are available

for the TPP.

1. User launches a TPP application. To consume the AISP and PISP service, the

user needs to onboard a bank. The TPP application requests the user to select a

bank

2. The user selects the bank to be onboarded. Next, the TPP redirects the user to

the bank. The bank processes the request

3. The bank requests the user to authenticate, complete SCA based on risk policy

and provide consent to the TPP. Please see the FAQ section to understand

consent process.

4. The user gives consent and completes SCA

5. The bank issues an access token to the TPP

6. The TPP can start using the access token to call the bank’s APIs.

7. The user consumes the TPP service. The TPP calls an API with the access

token

8. The gateway checks with the access manager whether the access token is valid

or not.

9. The access manager notifies the gateway about the validity of the access token.

10. The gateway allows access to the API

11. The API’s response is sent back to the TPP

In step 8 the risk service could identify a risk which triggers SCA. The topics covered

earlier capture the different ways to trigger SCA.

Conclusion PSD2 solutions require API management, access management solutions with strong

customer authentication capability and risk-based services to detect threat. However,

PSD2 is more than just meeting compliance requirements. It provides an opportunity to

offer consumers faster, safer and more convenient services.

Appendix 1. Other OpenBanking Initiatives across the world:

a. Hong Kong - https://www.hkma.gov.hk/eng/key-information/press-

releases/2018/20180718-5.shtml

b. France - https://www.stet.eu/en/psd2/

c. Australia - https://treasury.gov.au/consultation/c2018-t247313

d. New Zealand - https://www.paymentsnz.co.nz/about-us/payments-

direction/api-framework/

2. Relevant Hyperlinks –

a. OBIE - https://www.openbanking.org.uk/about-us

b. PSD2 Regulation - https://ec.europa.eu/info/law/payment-services-psd-2-

directive-eu-2015-2366_en

c. Reference architecture -

https://developer.ibm.com/apiconnect/2018/08/21/psd2_architecture/

FAQ As an international bank in the UK (Mizuho, Bank of China, etc) do I need to

comply?

Yes. A bank operating in Europe needs to comply with the regulatory requirements.

Can I follow a single implementation standard across all EU Countries I operate in?

No. Implementation standards recommend security protocols, payload structure,

user interaction experiences, etc and might differ from each other. We recommend

you look at the regulatory compliance requirements and then choose an

implementation standard.

What is the MVP that will get me compliant to PSD2?

We feel that the following three capabilities makes a bank compliant to PSD2:

1 TPP Enrolment

2 User enrolment and consent

3 API access

What are the penalties for non-compliance?

As of now the answer is No. But the regulatory standards will be updated in

November 2018. The penalties for non-compliance might be discussed in the

updated document.

What is the impact of GDPR on PSD2?

Data is stored and used during the PSD2 scenarios. There is data exchange

between the TPP and the ASPSP. Data is also stored in the form of user consent.

We recommend making GDPR assessments while designing and implementing the

PSD2 solution.

What is the difference between OB and PSD2?

PSD2 is a legislation and OB is an implementation guide. The PSD2 documentation

does not discuss technical details whereas OB explains the technical details. We

recommend using OB as it is the most comprehensive implementation guide

available as of today.

What are other countries doing about OB and PSD2?

Countries all around the world are discussing and releasing standards which are like

OB and PSD2. The Appendix above captures some such standards.

Who must follow which standards?

Open Banking’s adoption is mandatory for the nine largest providers of current

accounts in the UK also known as the CMA9. Other Financial Institutions can

choose other standards.

Is user consent provided at the TPP or the bank?

The latest RTS and OB working group suggest that the consent is provided at the

TPP and the bank should use it as an implicit consent. However, many banks today

have not implemented that approach. Most banks today implement a consent

mechanism.