| Expand | ||||
|---|---|---|---|---|
| ||||
|
...
# | Step | Rules & Guidelines |
|---|---|---|
CDCS-1 | Initiate User Set-up (Conditional) | Depending on the use case, the User may have to be onboarded with the TPP by agreeing to any relevant terms and conditions (e.g. regarding sharing and storage of personal data) and setting up an account with them if required. TPPs MUST: 1.1 Provide the User with a Terms & Conditions, and Privacy Notice outlining applicable rights and responsibilities in the context of relevant regulation and legal principles. This may need to include any onward sharing of personal data, recipients or categories of recipients who receive that data, and the lawful basis for processing personal data as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52527334/Consent+Setup#2.-Codification-of-the-User-Data-Agreement 1.2 Obtain the User's agreement to the above before setting them up and be able to request User consent as per the next step in the process 1.3 Provide an option to cancel the flow |
CDCS-2 | Data Sharing Consent | Basic Consent Parameters TPPs MUST: 2.1 Request only data required to perform their service (or use case). 2.2 Use the data language standards to describe the data clusters and data permissions in user-facing interactions so that the User clearly understands the data that will be requested from their LFI to provide the service requested
2.3 Depending on the use case confirm the duration of the data access or allow the user to select how long the TPP can access their data.
2.4 Depending on the use case confirm the starting date from which the data is required. The maximum duration of historical data that can be requested by the TPP and which MUST be sent by the LFI for a Data sharing Request is as defined under Max historical data for Data Sharing Request. 2.5 When a ‘long-lived’ consent confirm to the User that they can withdraw their consent at any time before the consent expires 2.6 Provide to User, the OFP and the LFI their trading/brand name clearly and the name of any other parties they are supporting (if applicable). 2.7 Allow the User to identify and select the LFIs for the Consent
|
Additional Consent Parameters TPPs MUST: 2.8 Set the Accepted Authorization Type (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5standardsv1rc1/pages/109415230121375612/Common+Rules+and+Guidelines#7.-Accepted-Authorization-Type). 2.8 Set the Authorization Time Window (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5standardsv1rc1/pages/109415230121375612/Common+Rules+and+Guidelines#8.-Authorization-Time-Window) if there are specific timing requirements that must be met for the Consent authorization. This is also relevant to cases where multiple authorizers are required to authorize the payment consent. 2.10 Obtain the Users' explicit consent to access information from payment account products held at LFIs as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52527334/Consent+Setup#2.1--Data-Sharing-Consent. | ||
CDCS-3 | Consent Staging | |
CDCS-4 | Hand-off to LFI | TPP MUST: 4.1 Notify the User that they will be transferred to the selected LFI to undertake their authentication and consent Authorization as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5standardsv1rc1/pages/109415230121375612/Common+Rules+and+Guidelines#11.-Hand-off-to-LFI |
CDCS-5 | Authentication | LFI Authentication Only LFI MUST: 5.1 Enable Users to perform authentication with their LFI, as per the following sections: 5.2 Re-direct Users back to the TPPs, with information that the Consent has not been authorized, if User authentication has failed or User opt to cancel the authentication/authorization process. |
Centralized Authentication and Authorization (Federated) Only 5.3 As per https://openfinanceuae.atlassian.net/wiki/x/HoBBAw | ||
CDCS-6 | Disclosure Consent | LFIs MUST: 6.1 Enable Users to authenticate using Multi-Factor Authentication (MFA) in order to review and authorize the data sharing single-use or long-lived Consent. 6.2 Retrieve from the OFP the data sharing Consent details staged by the TPP using the unique Consent Identifier. 6.3 Display details of data that will be shared and for how long 6.4 Use the data language standards to describe data clusters and permissions in user-facing interactions so that the same information is displayed to the User |
CDCS-7 | Select Accounts | LFI MUST: 7.1 Display list of eligible accounts for data sharing to the User as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5standardsv1rc1/pages/109415230121375612/Common+Rules+and+Guidelines#1.-Supported-Accounts
7.2 Only display the applicable accounts to the User for selection when the TPP has specified the AccountType and AccountSubType in the consent request object. 7.3 Enable the account selection process as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5standardsv1rc1/pages/109415230121375612/Common+Rules+and+Guidelines#12.-Payment-Account-Selection-at-LFI 7.4 Allow the User to select which of their accounts to share data from if the consent includes account-specific data permissions, and if there are multiple accounts available 7.5 When the consent does not include any account-specific data permissions (e.g. Customer data permissions only granted) the LFI MAY omit this step as no account data will be requested. 7.6 Allow the customer to proceed to the consent authorization step without selecting at least one account when the consent includes non account-specific data permissions. 7.7 Display to the User any accounts that are unavailable to select and share with a TPP and communicate why these cannot be selected. 7.8 Check the authorization status of the selected payment account is in accordance with the TPPs' Accepted Authorization Type as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5standardsv1rc1/pages/109415230121375612/Common+Rules+and+Guidelines#13.-Check-Accepted-Authorization-Type. |
CDCS-8 | Confirmation/ Authorization | LFIs MUST: 8.1 Present to Users all the details in relation to data sharing Consent. 8.2 NOT allow Users to change any of the Consent parameters (e.g. permissions) staged by the TPP. 8.3 Request Users to authorize the data sharing Consent. 8.4 Enable Users to cancel the data sharing Consent request from within the authorization journey 8.5 Re-direct Users back to the TPPs, with information that the Consent has not been authorized, if Users opt to cancel the Consent authorization process before final authorization. 8.6 Check the Authorization Time window is valid as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5standardsv1rc1/pages/109415230121375612/Common+Rules+and+Guidelines#20.-Check-Authorization-Time-Window. 8.7 Change the state of the data sharing Consent from Awaiting Authorization to Authorized, when all Authorizers (one or more) have authorized the data sharing Consent. 8.8 Update the data sharing Consent details stored in the OFP with all the information included in the data sharing Consent authorized by the User. |
OFP MUST: 8.9 Confirm back to the LFIs that the data sharing Consent details have been updated successfully. | ||
Multi-Authorization Journey Only | ||
CDCS-9 | Hand-off back to the TPP | |
CDCS-10 | Confirmation to User |
...
6.3 Data Cluster Structure & Language
6.3.1 Data Cluster Definitions
The following table describes how permissions MUSTbe grouped into Data Clusters and the language that MUST be used to describe the data at each of these clusters. Both TPPs and LFIs MUST describe the data being shared at a Data Cluster level and allow Users to “drill-down” to see the detail at the Permission level using the permission language set-out in the table below.
...
With respect to the Data Clusters and Permissions language, LFIs SHOULD consider whether the language that is displayed to Users is appropriate when the information being accessed relates to more than one party. For example, “Your data” may need to be adapted to just “data” to indicate to Users that the account information being displayed may not be solely specific to them. For example, in cases of joint accounts, when the account information of both parties is requested.
6.3.2 Data Cluster Requirements
The spreadsheet below provides the requirements for applying the permissions provided by a given Data Cluster to the response payload from each functional area of the Bank Data Sharing API.
| View file | ||
|---|---|---|
|
6.4 Relevance of Data Clusters
...
by Product Type
TPPs MUST ensure they have business rules that manage the relationship between Data Clusters to product types and omit access to Data Clusters that are irrelevant to a specific product type, as well as their service offering. If a TPPs requests a Data Cluster of data that is irrelevant to the product type associated to the payment account, for example the Scheduled Transfers Data Cluster is requested for a Savings Account product type, the LFIs MAY provide that Data Cluster as empty.
...