Decoupled Model C: TPP Generated Identifier

PSU provides a TPP (AISP/PISP/CBPII) generated unique identifier to the ASPSP to identify the request from the TPP

User Journey

A decoupled authentication flow where the PSU provides a dynamic identifier generated with their ASPSP to the TPP (AISP/PISP/CBPII), which is then used by the ASPSP to identify the PSU through the ASPSP app to authenticate and action the TPP request. This model is best suited to a TPP app that can “capture” the code from the ASPSP app (e.g. by scanning a QR code). Alternatively, the PSU can be prompted to type in an identifier in the TPP App. This may be a long series of characters and may result in a sub-optimal customer experience.

Wireframes

To demonstrate Model C based decoupled we have used one variation of PIS journey (Single Domestic Payments – a/c selection @ PISP) as an example, where the ASPSP receives all the details of the payment order via the code generated by the PISP.

This flow applies to other variations of PIS journeys covered in detail under section Payment Initiation Services (PIS). AISP journeys covered under section Account Information Services (AIS) and CBPII journeys covered under section Card Based Payment Instrument Issuers (CBPIIs).

CEG Checklist Requirements 1

For this step, please refer Section 4.1.1, step 1 & step 2.

CX Considerations 2

PISPs must present PSUs with the authentication options supported by the ASPSP which in turn can be supported by the PISP device/channel (e.g. A PISP kiosk that can only support authentication by ASPSP mobile app).

CX Considerations 3

If PISPs and ASPSPs support Model C then PISPs must display an identifier generated from the ASPSP to the PSU (e.g. QR code) and information on how the identifier should be used within the ASPSP app (e.g scan QR code with the ASPSP app).

CX Considerations 4

PSUs should be able to easily use the identifier presented by the PISP application (e.g. scan the code from the Kiosk in this instance) without much friction (e.g of manually entering an alphanumeric code).

CEG Checklist Requirements 5

After the PSU the scans identifier from the PISP within the ASPSP app, then the ASPSP must display the payment request and clearly mention the amount and the payee and payment account.

CEG Checklist Requirements 6

ASPSPs performs SCA. The ASPSP app based authentication must have no more than the number of steps that the PSU would experience when directly accessing the ASPSP mobile app (biometric, passcode, credentials).

CX Considerations 7

ASPSPs must make the PSU aware that they have been logged off from the ASPSP app and notify them to check back on the originating PISP app.

CEG Checklist Requirements 8

The PISP must confirm successful confirmation of payment initiation.

We have illustrated an example where the dynamic identifier is a QR code and scannable by the ASPSP app. The code generated is however not limited to QR code and the options supported are chosen by the ASPSP. The general guidance is that the use of the code within the ASPSP app should not introduce friction in the journey.

CEG Checklist Requirements & CX Considerations

CEG Checklist Reference

For this step, please refer Section Single Domestic Payments – a/c selection @ PISP), step 1 & step 2.
PISPs must present PSUs with  the authentication options supported by the ASPSP which in turn can be supported by the PISP device/channel (e.g. A PISP kiosk that can only support authentication by ASPSP mobile app).
If PISPs and ASPSPs support Model C then PISPs must display an identifier generated from the ASPSP to the PSU (e.g. QR code) and information on how the identifier should be used within the ASPSP app (e.g scan QR code with the ASPSP app).
PSUs should be able to easily use the identifier presented by the PISP application (e.g. scan the code from the Kiosk in this instance) without much friction (e.g of manually entering an alphanumeric code).
After  the PSU the scans identifier from the PISP within the ASPSP app, then the ASPSP must display the payment request and clearly mention the amount and the payee and payment account.
28
ASPSPs performs  SCA. The ASPSP app based authentication must have no more than the number of steps that the PSU would experience when directly accessing the ASPSP mobile app (biometric, passcode, credentials).
1
ASPSPs must make the PSU aware that they have been logged off from the ASPSP app and notify them to check back on the originating PISP app.
The PISP must confirm successful confirmation of payment initiation.
26

Click for Related API specifications

What the research says

Click for Customer Research 
Previous
v3.1.8
Next