A dedicated mobile app to capture Strong Customer Authentication for PSD2

Regulations > The Second Payment Services Directive (EU) 2015/2366

A perspective on SCA and how best to meet the PSD2 challenge.

From the PSD2 application date (13th January 2018) new rules on 'payer liability' (articles 73,74) and 'right of recourse' (article 92) will apply. Only if an 'Account Servicing Payment Services Provider' (ASPSP, i.e. bank) requires 'Strong Customer Authentication' (SCA, i.e. personal authorisation) of a payment, is the ASPSP able to transfer the liability onto the payer in the event of fraud. This supercedes any existing contractual agreements between a bank and their customer(s).
Also, PSD2 requires ASPSP's to establish an 'Access-to-account' (XS2A) 'Common Secure Communication' (CSC) API, that would allow 'Third Party Providers' (TPP) to offer payment initiation and/or account information services to the PSU.
The European Retail Payments Board (ERPB) have identified three methods of capturing SCA, in a TPP context:
Embedded: The SCA procedure is managed by a TPP. The Payment Service User (PSU) uses their credentials (e.g smartcard), provided by the ASPSP.
Redirect: the PSU is redirected to the ASPSP’s website for the sole purpose of capturing SCA.
Decoupled: SCA takes place via a dedicated (i.e. single purpose) device and/or app, supplied by the ASPSP.
However, article 32 of the RTS states that an ASPSP must not impose the Redirect option. Nor can the ASPSP require 'additional authorisations and registrations' or 'additional checks on consent'. Therefore if an ASPSP chooses to support Redirect, they must also support Embedded and/or Decoupled as well. The ASPSP must also allow the TPP to manage the process of capturing the PSU's registration and consent request data.
Embedded SCA:
This is probably the only viable option to support the 'Point of Sale' use case, e.g. the purchase of petrol at a petrol station.
However in an internet payments context, the existing procedure (EMV bank card + TAN reader) is not approriate because of the use of a symmetric key. In this case, the TPP effectively is a 'man in the middle' and would potentially be able to determine the value of the symmetric key. This introduces a risk of fraud.
Decoupled SCA:
In this case, the user experience is that the SCA procedure is separated from the TPP app in both space and time. At the point SCA is required, the TPP server transmits a request (e.g. payment instruction) to the ASPSP without SCA. The ASPSP then routes the request data into their Decoupled SCA capture procedure. This could, for example, cause the request data to appear on a user's smartphone for their approval.
Redirection SCA (PC browser):
In this case, a synchnronous SCA procedure is performed. At the point SCA is required, similar to Decoupled the TPP server transmits the request (e.g. payment instruction) to the ASPSP without SCA. The TPP web site then redirects the user to the ASPSP SCA capture web site. Once SCA is captured, the ASPSP SCA web site returns the user back to the TPP web site. If the PSU aborts the procedure at any point, the payment is aborted.
App-to-App Redirection SCA (Smartphone):
In this case, the user experience is of a synchronous SCA capture procedure. They are interacting within a TPP app on their smartphone. At the point SCA is required, similar to Decoupled the TPP server transmits the request (e.g. payment instruction) to the ASPSP without SCA. The TPP app then uses app-to-app communication facilities to launch the ASPSP's dedicated SCA app and pass it control. Once SCA is captured, the SCA app hands control back to the TPP app. In contrast with the browser redirect experience, if the PSU exits the SCA app prior to approval, the SCA request is not necessarily lost. In principle the PSU can return to the SCA app at a later date to complete the procedure (approve or cancel).