Implementation example Multibanking

Overview

This page describes the sample use cases for Multibanking and the corresponding access control implementation according to Consent Management.

In Multibanking a customer wants to do multibanking: Example - The customer also wants to view information from his account at FI2 via the portal of FI1.

Assumptions

• The customer is already a customer of both FI1 and FI2 and has a corresponding (secure) login to both.
• Both FIs are already registered with the TCA (Trusted Central Authority), which can also be one of the FIs if they agree upon. This means that both can communicate securely with each other and confirm that both have implemented the necessary APIs (e.g., XS2A) and a corresponding authorization service as described in Consent Management is in place.

Business Flow

1. Customer is logged into FI1 and wants to use multibanking with FI2. Since both FI1 and FI2 are registered with the TCA, the customer can select FI2 from a list in the FI1 portal.
2. The customer gives his consent (defined according to FI1 guidelines) for the connection in the FI1 portal. He then signs in to FI2 via the FAPI flow (FAPI-Flow 2: FI/TPP Initial consent) in order to give his consent there as well (defined according to FI2 guidelines). Afterwards, the FIs are sure that the customer has given the consent. The two accounts are now "linked" to each other.
3. The customer can access information from FI2 on FI1. In the background, the FAPI Flow (FAPI-Flow 3/4: FI/TPP data exchange) is used to securely retrieve the desired information.

FAPI Flows

Adapted flows to CH / Common API situation.

Common flows are:

1. Establish FI/TPP secure communication
2. FI/TPP initial consent
3. FI/TPP data exchange with additional consent
4. FI/TPP data exchange without additional consent
5. FI/FI consent & data exchange: Same flow as for FI/TPP (a second FI takes the role of the TPP). E.g. for Multibanking use cases

1) Establish FI/TPP secure communication

• In addition to the Common APIs, FIs also provide their authorisation endpoint via discovery service.
• For communication between TPP and FI, they must both be classified as trustworthy.
• To avoid that every TPP has to establish a trust with every FI, a Trusted Central Authority takes over the registration of FIs and TPPs and issues certificates/keys. With the registration process, the TCA ensures that only FIs and TPPs that meet all required security guidelines are approved.
• The TCA provides a directory in which all registered FIs and TPPs can be found.
• The TCA ensures that issued certificates/keys can be revoked.
• Communication between TPP and FI are secured by MTLS or HoK (private_key_jwt).

1. A TPP would like to be able to offer its services to customers and FIs. Therefore the TPP registers himself to the TCA. After a check, the TPP is entered in the DB of the TCA and receives the corresponding certificates/keys.
2. The TPP manages the certificates/keys with which it can secure the respective communication channels to the FIs at a later time.
3. An FI wants to provide value to its customers and therefore be accessible to TPP. The FI registers with the TCA for this purpose and receives the corresponding certificates/keys after a check.
4. The FI manages the certificates/keys with which it can later secure the respective communication channels to the TPPs.
5. The TPP or FI shows the customer which FIs or TPPs are registered and can therefore be linked by the customer for additional services.

2) FI/TPP Initial consent

In order for a TPP to maintain relations with FIs on behalf of a customer, the customer's consent is required. With this initial consent, the TPP can query general data of the customer and, if necessary, map different identities with FIs to one identity in the TPP.

1. Strong customer authentication on the portal of a TPP.
2. The customer wants to connect his FI with the TPP and initiates the link.
3. The TPP authenticates itself to the FI (AS) via MTLS or HoK (private_key_jwt) and triggers a pushed authorisation request (PAR).
4. The customer follows the link from the TPP (PAR) and is authenticated by the FI (AS) (front channel).
5. The FI asks the customer if he wants to couple his account to TPP.
6. The customer gives permission to the TPP and the FI provides the customer with an authorisation code (front channel).
7. The customer handles the code to the TPP and the TPP exchange this code at the FI (AS) to tokens (back channel) for later use.
8. The TPP manages the tokens for later data queries to the FI. The linked FI is displayed in the portal.

3) FI/TPP data exchange with additional consent

• To exchange data between a TPP and FI via Common API, the TPP needs so-called access tokens. The access tokens authorise the TPP to use certain services.
• The TPP receives an access token from the FI authorization server. The customer has to give his consent (in case of sensitive actions as payments). This means that the customer must authenticate himself to the FI (AS) and confirm the desired action of the TPP.
• For security reason access token are bound to a TPP/FI communication channel.

1. Strong customer authentication on the portal of a TPP.
2. The customer wants to see general information about his accounts from an FI and requests it in the TPP portal.
3. The TPP authenticates itself to the FI (AS) via MTLS or HoK (private_key_jwt) and triggers a pushed authorisation request (PAR).
4. The customer follows the link from the TPP (PAR) and is authenticated by the FI (AS) (front channel).
5. The FI asks the customer if he wants to allow TPP to query accounts informations.
6. The customer gives permission to the TPP and the FI provides the customer with an authorisation code (front channel).
7. The customer handles the code to the TPP and the TPP exchange this code at the FI (AS) to tokens (back channel).
8. With the received token the TPP accesses the FI (Common API) and queries the data. The channel is also protected by MTLS or HoK (private_key_jwt).
9. The TPP processes the data and presents it to the customer.

RAR is used for fine-grained authorisations. E.g. the customer wants to initiate a payment to the FI of 35.- Fr. via TPP. The customer is then directed to the FI (AS) via RAR (front channel) where he must confirm the payment.

4) FI/TPP data exchange without additional consent

1. Strong customer authentication on the portal of a TPP.
2. The customer wants to see general information about his accounts from an FI and requests it in the TPP portal.
3. The TPP checks whether the user has already linked the desired FI and provides the associated tokens from local DB.
4. The TPP accesses the FI with the tokens and requests the corresponding data.
5. The TPP processes the data and presents it to the customer.