The goal of the Payment Service Directive (PSD) 2 regulation has been set to improve competition and participation in the payment industry especially also for non-banks. This regulation is was set to be finally implemented by banks and vendors on September 14th 2019.
Due to problems with testing time and/or other issues, this deadline has been delayed by multiple national banking institutions. In Germany, banks need to use the time until December 2020 to verify and/or improve their “XS2A” interface to enable vendors and other actors.
However, there have been other issues with PSD2 on a technological standpoint. One element is the technical implementations which complies with the requirements set out by the PSD2 regulation. In an attempt to standardise the input and output elements of such an interface, the Berlin Group initiative defined the structure and elements of an interface which allows a Trusted Payment Provider (TPP) to interact with a Account Servicing Payment Service Provider (ASPSP) to request a payment initiation or allow restricted access to account information. These requests require the authorisation by an authenticated payment service user (PSU). This authorisation requires a strong customer authentication (SCA) to ensure that requests for information or payment are not authorised by an unauthorised user.
In our conversations with partners and customers alike we find again and again though that the technical basics about necessary interactions between the PSU, TPP and ASPSP to implement a given SCA method are unclear or misunderstood.
This article aims to provide the fundamental basics of the different methods defined by the Berlin Group and enable anyone from developer to manager to gain an understanding of how the Berlin Group defines the flow of those SCA methods.
PSU, TPP and ASPSP: The actors in PSD2 flows
The understanding of why and how any given SCA method is implemented requires a basic understanding of the actors involved in any flow. The starting point is usually the payment service user (PSU). This actor simply represents the customer of e.g. a web shop or any other given instance which requires an interaction with a given bank account of the customer. The interesting point of the PSU as an actor in these scenarios is the fact that its interaction with the bank can occur in various ways which are described later.
The second actor is the trusted payment provider (TPP). The TPP is the already described instance which interacts with the application programming interface (API) of the bank which manages the account of the PSU. The TPP identifies itself to the bank by presenting a QWAC certificate that is issued by a qualified signing certificate authority (QTSP). This requires for an implementation of the banking interface to maintain an up-to-date list of the different QTSPs to be able to verify that the presented certificate is valid and has not been revoked or expired. Moreover, each national authority keeps a record of what a TPP is or is not allowed to do in a certain country. This level of authorisation is also needed and needs to be checked on a daily basis.
The third actor is the bank. Within the PSD2 context, a bank is called an Account Servicing Payment Service Provider (ASPSP). The bank offers an API which allows the interaction with the bank which is called XS2A interface in the Berlin Group specification to request two types of services. The first type is called a consent which describes the access a TPP gains to specified account information of a given PSU. The second type involves the initiation of a payment which describes the parameters of a money transfer between TPP and PSU.
No matter which type of request is issued the general flow starts with the specified request from the TPP towards the API of the ASPSP. The next step of the flow involves the authorisation of this request by the PSU which is done by following a selected or enforced SCA method.
SCA methods defined by the Berlin Group specifications
Now that we established a basic understanding of the PSD2 technical context as well as ist actors it is time to look at the important step of ensuring that a specific request of a TPP is only granted if the authorised user has agreed to this request. This obviously holds certain risks for the ASPSP. It cannot allow any adversary to misuse its public API which basically allows the requesting entity to request the transfer of money or sensible information. From a security perspective, the basic attack vectors are:
– Identity fraud: Impersonation of a valid customer by a malicious actor
– Unauthorised money transfer and any following (legal) consequences
– Information theft: This is especially important in the light of the General Data Protection Regulation (GDPR) and consequences in case of a data leak
This brings us to the basic question how the ASPSP can ensure that the request of a given TPP is valid, that the PSU agrees with this request and that the PSU is actually the customer which identity it provides. The Berlin Group specification defined four possible methods in the context of PSD2:
In the following, this article will provide an overview over the flows of the different SCA methods. The focus points of this overview are the initial answer to the TPP request, the follow-up steps for the interaction and the finishing steps after a successful authorisation or rejection.
The redirect method allows the bank to use its own web user interface (UI) to manage the user authentication and request authorisation. The redirect URL is a weblink which redirects the web browser of the PSU to a given web address. The use of the redirect SCA method requires a redirect URL of the TPP’s web application which has to be sent with the initial request. This web address is used later to redirect the flow from the ASPSPs web UI back to the TPPs web application. The ASPSP processes the request and responds with a requestID and a distinct redirectURL which is used to redirect the browser of the PSU to the web UI of the ASPSP. In the next step, the PSU is authenticated and accepts or rejects the request of the TPP. The TPP stays idle in the meantime. Once the authorization has been completed, the ASPSP will redirect the browser of the PSU back to the TPP using the requestURL send in the initial request. At this point, the flow of the process returns to the TPP which now makes another call to the API of the ASPSP. The TPP might e.g. decide to check the status of the request again (e.g. in case of a payment initiation to check whether the payment execution has been initialised) or try to directly access the requested resource and show a graphical response to the PSU depending on the response by the ASPSP.
If the decoupled approach is the chosen SCA method, a dedicated application (e.g. a smartphone application) is required. In this scenario, the TPP sends the initial request. In this case, there is no need to add a redirect URL since the authentication and authorisation process is totally decoupled from the flow of the TPP (hence the name). The response of the ASPSP contains necessary information about the request, including the ID of the request resource. This can be used by the TPP to request information about the request. The web application of the TPP may show some sort of a progress screen at this point while the TPP is waiting for the authorisation of its request. Once the response to the initial request has been sent to the TPP, the ASPSP will trigger a notification to the dedicated application. This can be e.g. the default banking application which has incorporated the process for multi-factor authentication and the authorisation of a given request. The PSU interacts with this application to authenticate itself and authorise or reject the request. This will change the status of the request (as it is changed in any other SCA method as well). The status value can be requested by the TPP which might implement a logic based on the returned value. For example, if the status of the authorisation has been set to “finalised” this triggers the continuation of the process flow inside the web application of the TPP which then shows a success screen to the PSU.
The integrated OAuth2 method uses the well-known flow of the OAuth2.0 process flow to provide an access token to the TPP which allows the TPP to access information and/or services limited to the scope of the token. If you are not familiar with the OAuth2.0 flows you may find a helpful resource here . The basic flow is very similar to the redirect method described above. The difference between the two methods lies within the way access is granted to the TPP. A quick note: The APIIDA AG does not support this method at the moment since the specification by the Berlin Group require a dynamic OAuth scope which stands in contrast to the original OAuth2.0 specifications.
The embedded method is the most complex SCA method since it incorporates the TPP within the process of the PSU authentication and the authorisation. This brings up a couple of issues e.g. how to provide security and privacy to the authentication factors of a given PSU for the ASPSP without disclosing them to the TPP and also how to ensure the integrity of the data displayed to the PSU for a given request (e.g. which account information are accessed) or the integrity of the parameters (e.g. to accept or reject a request).
Deciding which SCA methods to use
As described in the last section, the SCA methods define the way a given PSU is authenticated and authorisation of a given TPP request is executed. The decision which SCA methods are offered lies with the ASPSP which is providing the XS2A interface. As shown in the examples and description in the last section, the decision of which SCA methods to support comes down to the investment necessary to adopt existing solutions and/or infrastructure to the new process, the trust relationship between TPP and ASPSP and last but not least customer experience. While the later might play a secondary role from the perspective from the traditional banking perspective it is a way to distinguish oneself from the competition and increase the customer base by allowing different methods e.g. based on the request type, the customer preference or the TPP (e.g. origin (EU, Non-EU), type (bank, vendor, others) or criticality of the request).
The same goes for TPPs which need to support the process logic to support multiple SCA methods and therefore offer their customers flexible but secure ways to interact with their bank.
If you are interested in learning more about the technical implications of PSD2 processes, feel free to contact us at APIIDA AG for further information. We also provide an up-to-date implementation of an XS2A interface (based on the Broadcom Layer7 API Gateway) for ASPSPs compliant to the Berlin Group specifications and offer an SCA solution based on APIIDA Intelligent SSO.