Decoupled Model D: PSU with a TPP Account

TPP (AISP/PISP/CBPII) passes the PSU’s stored unique identifier to the ASPSP to identify the PSU

User Journey

A decoupled authentication flow where the TPP (AISP/PISP/CBPII) provides the ASPSP a stored PSU identifier, generated by the ASPSP from a previous PSU transaction. This is used by the ASPSP to notify the PSU such that the PSU can authenticate using the ASPSP app on a separate device. This model is ideally suited where the services offered by the TPP involves POS, telephony, or where PSU interaction with the TPP is not possible through a graphical interface (IoT devices), or even when the PSU may not be present within the TPP channel.

Wireframes

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 via the TPP device. The voice commands are an example of how the PSU interacts with the TPP. 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 & CX Considerations

CEG Checklist Reference

PISP IoT device through voice enabled commands asks if they would like to checkout for the requested payment using their stored ASPSP account. After the PSU confirms, the PISP uses the stored PSU identity with the ASPSP to request for payment.

The ASPSP must notify the PSU through the ASPSP app for authentication purposes only without introducing any additional screens. The notification must clearly mention the payment request with the amount and the payee.

1 28

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