PSU provides an ASPSP generated unique identifier to the TPP (AISP/PISP/CBPII) which is then passed back to ASPSP to identify the PSU

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 a Model B based decoupled journey, we have used one variation of the PIS journey (Single Domestic Payments – a/c selection @ PISP) as an example, where the ASPSP receives all the details of the payment order from 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

Not shown in the diagram but as in 1 & 2 in Model A.

CEG Checklist Requirements 2

Not shown in the diagram but as in 1 & 2 in Model A.

CX Considerations 3

If PISPs and ASPSPs support Model B then the PISP should provide the PSU information on how the identifier can be generated with their ASPSP and make the PSU aware about how this identifier will be used.

CEG Checklist Requirements 4

PSUs use the ASPSP app to generate the unique identifier.

CX Considerations 5

PSUs should be able to easily provide the identifier to the PISP application (e.g. scan the code into the Kiosk in this instance).

CEG Checklist Requirements 6

After the PSU provides the ASPSP app generated identifier to the PISP, then the ASPSP must display the payment request within the same session of the ASPSP app and clearly mention the amount and the payee.

CEG Checklist Requirements 7

ASPSPs must apply SCA which should 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 8

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 9

The PISP must confirm successful confirmation of payment initiation.

We have illustrated an example where the dynamic identifier is a QR code and is scannable by the TPP. The code generated by the ASPSP is however not limited to QR code.

The general guidance is that the code generation with the ASPSP should not introduce friction in the journey.

Requirements and Considerations

CEG Checklist Requirements & CX Considerations

Not shown in the diagram but as in 1 & 2 in Model A.

22

Not shown in the diagram but as in 1 & 2 in Model A.

22

If PISPs and ASPSPs support Model B then the PISP should provide the PSU information on how the identifier can be generated with their ASPSP and make the PSU aware about how this identifier will be used.

PSUs use the ASPSP app to generate the unique identifier.

6

PSUs should be able to easily provide the identifier to the PISP application (e.g. scan the code into the Kiosk in this instance).

After the PSU provides the ASPSP app generated identifier to the PISP, then the ASPSP must display the payment request within the same session of the ASPSP app and clearly mention the amount and the payee.

28

ASPSPs must apply SCA which should 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

What the research says:

“Research shows that consumers are familiar with decoupled authentication when making a payment or setting up a new payment. This means that, if PIS journey designs follow similar patterns, consumers will be comfortable with them. Many welcome the additional level of security decoupled authentication provides.”

Click for Customer Research