Customer Data
- Chris Michael
- Alexandros Dimitrakoudis (Deactivated)
1. Description
This bank service request enables TPPs to retrieve a User’s data (with the User’s consent) held with an LFI. The TPP agrees the boundaries of the data sharing consent with the User, the TPP then sends this data sharing consent to the LFI, where it is approved by the User. TPPs are then able to retrieve the status of the data sharing consent and receive data from the User’s account.
This User journey requires an Account Access Consent.
The Bank Data sharing service scope includes domestic payment accounts (i.e. payment accounts offered by LFIs located in UAE) in all available currencies. Please refer to Common Rules and Guidelines | 1. Supported Accounts & Payment Rails for further details on the supported accounts.
Moreover, an LFI may request a data transfer from another LFI on behalf of a User with the User’s consent. In the instance where an LFI is providing a service as a TPP, the LFI will be subjected to the same rules and guidelines as a TPP would be, as specified in the Standard. This is illustrated in Customer Data | 7. LFI as a TPP Example.
1.1 Data Sharing Segments
The scope of the Customer Data Sharing bank service covers the account segments shown below:
Consumers | SME | Corporates |
1.2 Customer Data Sharing - Generic User Story
User Story
As a User (Consumer, Business or Corporate),
I want to provide my consent to a TPP to retrieve data about my account(s),
so that I can access value added services offered by the TPP.
2. User Journey
Users can share data held with an LFI, by providing their data sharing consent to a TPP.
3. Customer Experience
A prototype of this journey showcasing a Personal Finance Use Case can be found here Prototypes for CBUAE docs
3.1 Rules & Guidelines
# | 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 privacy notice, and setting up an account with the TPP, if required. TPPs MUST: 1.1 Provide the User with Terms & Conditions, and Privacy Notice documents, outlining the applicable rights and responsibilities in the context of relevant regulation and legal principles. This may also need to include any onward sharing of personal data, recipients or categories of recipients who receive that data, and the lawful basis for processing the User’s personal data, as per Consent Setup | 2. Consent Codification. 1.2 Obtain the User's agreement to the above before setting them up and be able to request the User’s consent, as per the next step in the process. 1.3 Provide an option for the User to cancel the flow, if preferred. |
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 Confirm the duration of the data access requested or, depending on the use case, allow the User to select how long the TPP can access their data.
2.4 Define the start and end dates for the period needed for historical transaction data, if required for specific use cases and TPP has requested any of the transaction related permissions, as defined in Customer Data | 6.3.1 Data Cluster Definitions.
2.5 Confirm to the User that they can withdraw their consent at any time before the consent expires. 2.6 Provide to the 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/clear the “Is Single Authorization” flag as appropriate (as per Common Rules and Guidelines | 7. Is Single Authorization flag). 2.9 Set the Authorization Expiration DateTime (as per Common Rules and Guidelines | 8. Authorization Expiration Date Time) 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 consent (please refer to Common Rules and Guidelines | 18. Multi User Authorization Flow). 2.10 Obtain the User's explicit consent to access information from the payment account products held at the selected LFI. | ||
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 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/spaces/6af317645dd64444b360d51d5bfb6d46/pages/321226238 | ||
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, as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2draft3/pages/321229345/Customer+Data#6.-Permissions-and-Data-Clusters. |
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/6af317645dd64444b360d51d5bfb6d46/pages/321229790/Common+Rules+and+Guidelines#1.-Supported-Accounts
7.2 Only display the applicable accounts for User selection, when the TPP has specified the Account Type and Account Sub-Type in the consent request object. 7.3 Enable the account selection process as per https://openfinanceuae.atlassian.net/wiki/spaces/6af317645dd64444b360d51d5bfb6d46/pages/321229790/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 NOT request Users to select any account from their eligible account list when the Data Request Consent does not include any account-specific data permissions and instead includes only User data permissions (e.g. in the case of the Parties endpoint). TPPs MUST NOT display any list of eligible accounts in this case, please refer to variation https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2draft3/pages/321229345/Customer+Data#3.2.1-Data-Sharing-for-Contact-and-Party-data-cluster.
7.6 Allow Users to proceed to the Data Sharing Consent authorization without selecting any accounts in the case of Consents solely including non account-specific data permissions. 7.7 Display to the User any accounts that are unavailable to select and share with the TPP and communicate why these accounts 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/6af317645dd64444b360d51d5bfb6d46/pages/321229790/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/6af317645dd64444b360d51d5bfb6d46/pages/321229790/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. | ||
CDCS-9 | Hand-off back to the TPP | |
CDCS-10 | Confirmation to User |
3.2 Journey Variations
3.2.1 Data Sharing for Contact and Party data cluster
3.2.2 Data Sharing for FX & Remittance Services from FX Houses
The below customer journey illustrates the Data Sharing Consent for FX House LFIs.
4. Data Sharing Requests
# | Step | Rules & Guidelines |
|---|---|---|
CDSR-1 | Data Sharing Request | TPPs MUST: 1.1 Only request specific data in the scope of their service (or use case). 1.2 Only submit to OFP data sharing requests for the data clusters and permissions consented by the User, as per the data sharing Consent authorized by the User. |
CDSR-2 | Processing of Data Sharing Requests | OFP MUST: 2.1 Allow TPPs to submit data sharing requests in relation to a data sharing Consent authorized by Users, without any additional MFA or authorization by the Users. 2.2 Check that the received data sharing request relates to a valid data sharing Consent authorized by the User. The Consent MUST be in the ‘Authorized’ state. The OFP MUST reject any data sharing requests related to a data sharing Consent in a different state (e.g. expired) and respond back to the TPP with the appropriate error message/code.
2.3 Reject the data sharing request and provide the necessary error message to the TPP, if any checks on the data sharing request fail against the authorized data sharing Consent.
2.4 Send the data sharing requests to the LFI for the data clusters and permissions consented by the User, as per the data sharing Consent authorized by the User. |
LFIs MUST: 2.5 Allow the OFP to submit the data sharing requests without any additional MFA or authorization from the User. 2.6 Reject the data sharing request received by the OFP, in case there are valid reasons for the data sharing Consent to be suspended, as per https://openfinanceuae.atlassian.net/wiki/spaces/6af317645dd64444b360d51d5bfb6d46/pages/321225013/Consent+Setup#4.-Consent-States or due to any other BAU checks failure. 2.7 Share data requested by the OFP in relation to the authorized data sharing Consent.
| ||
OFP MUST: 2.8 Send an appropriate error response to the TPPs, in case the data sharing request is rejected due to violating any of the LFIs BAU checks. 2.9 Provide the TPP with all the available data for the data clusters and permissions requested in relation to the data sharing Consent authorized by the User. |
5. Consent Updates
# | Step | Rules & Guidelines |
|---|---|---|
CDCU-1 | Consent Update | TPPs SHOULD: 1.1 Enable Users to use the TPP Consent Management Interface (CMI) to amend one or more of the following parameters of a data sharing long-lived consent:
TPPs MUST: 1.2 Require the Users to authenticate with their LFI and authorize the Consent update, if they were allowed to make changes. |
6. Permissions and Data Clusters
In the Bank Data Sharing API design, data elements are logically grouped together into “permissions”. Grouping permissions together and adding another layer of logical grouping and description helps Users' understanding of the data they are being asked to consent to share.
6.1 Permissions
As stated above, data elements are logically grouped together into “permissions”. It is at this level that TPPs request data access. If they request access to a specific permission, they will have access to all the data elements within that permission. This provides a pragmatic approach, allowing TPPs to be selective but at the same time creating a consent process that is at an acceptable level of granularity for Users. Details of the data elements within each permission will be included in the API technical specifications.
6.2 Data Clusters
Grouping permissions together and adding another layer of description aids Users' understanding of the data they are being asked to consent for sharing. This approach also allows consistency of language across TPPs and LFIs to provide additional comfort to Users that they are sharing the data they intended to. If consistent language is used across all member organizations this will drive User familiarity and adoption. These groups of permissions are known as Data Clusters. Data Clusters are not reflected in the API specifications, they are purely a presentational layer on top of permissions to aid User understanding.
6.3 Data Cluster Structure & Language
6.3.1 Data Cluster Definitions
The following table describes how permissions MUST be 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.
Where both Basic and Detail permissions are available for a set of data elements, the Detail permission contains all data elements of the Basic permission plus the additional elements described in the table. For more details about the information in the Data Clusters and permissions, please refer to the Bank Data Sharing API Specifications.
Data Cluster language | Permissions | Permissions Language | Examples of Information available |
|---|---|---|---|
Your Account Details | Accounts Basic (ReadAccountsBasic) | Any other name by which you refer to this account | Currency of the account, Nickname of account assigned by the account owner (e.g. Fahd’s Household account’). Each Account will have a unique and immutable AccountId |
Accounts Detail (ReadAccountsDetail) | Your account name and number | Account Name, account identifier (may include account number, IBAN, mobile number, email address or other unique identifier) (plus all data provided in Accounts Basic) | |
Balances (ReadBalances) | Your account balance | Amount, Currency, Credit/Debit, Type of Balance, Date/Time, Credit Line. | |
Your Regular Payments | Beneficiaries Basic (ReadBeneficiariesBasic) | Payee agreements you have set up | List of Beneficiaries. |
Beneficiaries Detail (ReadBeneficiariesDetail) | Details of Payee agreements you have set up | Details of Beneficiaries account information (Name, account identifier such as IBAN, mobile number, email address or other unique identifier), Beneficiary Type and Account Holding Entity details (plus all data provided in Beneficiaries Basic) | |
Standing Order Basic (ReadStandingOrdersBasic) | Your Standing Orders | SO Info, Frequency, Creditor Reference Info, First/Next/Final Payment info, SO Status | |
Standing Order Detail (ReadStandingOrdersDetail) | Details of your Standing Orders | Details of Creditor Account Information (Name, account identifier such as IBAN, mobile number, email address or other unique identifier) (plus all data provided in SO Basic) | |
Direct Debits (ReadDirectDebits) | Your Direct Debits | Mandate info, Status, Name, Previous payment information, Frequency | |
Scheduled Payments Basic (ReadScheduledPaymentsBasic) | Recurring and future dated payments from your card account | Scheduled dates, currency, amount, reference. Does not include information about the beneficiary. | |
Scheduled Payments Detail (ReadScheduledPaymentsDetail) | Details of recurring and future dated payments from your card account | Scheduled dates, currency, amount, reference. Includes information about the beneficiary. | |
Your Account Transactions | Transactions Credits (ReadTransactionsCredits) | Details of your incoming transactions | Transaction Information on payments made into the User’s account (Reference, Amount, Status, Booking Data Info, Value Date info, Transaction Code). Includes information about the entity that made the payment. |
Transactions Debits (ReadTransactionsDebits) | Details of your outgoing transactions | Same as above, but for debits. | |
Transactions Basic (ReadTransactionsBasic) | Your transactions | Transaction Information on payments for both credits in and debits out of the User’s account (Reference, Amount, Status, Booking Data Info, Value Date info, Transaction Code). Does not include information about the debtor/creditor. | |
Transactions Detail (ReadTransactionsDetail) | Details of your transactions | Transaction Information on payments made both credits in and debits out of the User's account (Reference, Amount, Status, Booking Data Info, Value Date info, Transaction Code, Merchant Category Code). Includes information about the debtor/creditor. | |
FX & Remittance Transactions Basic (ReadFXTransactionsBasic) | Your FX & Remittance transactions | Transaction Information on FX & Remittance payments for both credits in and debits out of the User’s account (including Reference, Amount, Status, Booking Data Info, Value Date info, Transaction Code). Does not include information about the debtor/creditor. | |
FX & Remittance Transactions Detail (ReadFXTransactionsDetail) | Details of your FX & Remittance transactions | Transaction Information on FX & Remittance payments for both credits in and debits out of the User's account (including Reference, Amount, Status, Booking Data Info, Value Date info, Transaction Code, Merchant Category Code). Includes information about the debtor/creditor | |
Your Product Information | Product Information (ReadProduct) | Details of your banking products | Account product information for a specific AccountID |
FX & Remittance Product Information (ReadFXProducts) | Details of your FX & Remittance products | FX & Remittance product information for a specific AccountID. This includes account features & services, such as:
| |
Contact and Party Details | Party User (ReadPartyUser) | High-level information on the successfully authorized user. | The party type, account role, and full Legal Name. |
Party User Identity (ReadPartyUserIdentity) | Full KYC information on the successfully authorized user. | The party type, account role, address, date of birth, Emirates ID. | |
Party (ReadParty) | An array with high-level information on the account owner(s)/holder(s). | The party type, account role, and full Legal Name. |
Note
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.
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.
7. LFI as a TPP Example
The below user journeys illustrates how an LFI could act as a TPP and ingest LFI data. The first flow illustrates a user providing consent for an LFI to access data from the user’s other LFI. The second flow is an example of how an LFI could consolidate transaction history from both LFIs into a single statement. As an extension of this example, the consolidated statement could be used in a credit assessment.
7.1 User provides consent to share data from one LFI to another
7.2 User views consolidated transaction history
@ CBUAE 2025
Open License and Contribution Agreement | Attribution Notice