#

Step

Rules & Guidelines

ICS-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 perhttps://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final/pages/210796838/Consent+Setup#2.-Consent-Codification

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

ICS-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.2.1 Display to the User the data clusters that will be collected and the purpose the data will be used for when the data permissions cannot be set by the User due to the service being 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.3.1 When a ‘single-use’ account access consent is required, confirm to the User that their accounts will only be accessed for the duration required to fulfill the single use case.

  • 2.3.1.1. Confirm to the User what will happen to their data once the service has been provided

• 2.3.2 When a ‘long-lived’ consent is required for the service to be provided, allow the User to agree to the access duration

  • 2.3.2.1 Confirm to the User that when the consent reaches the end of the sharing duration period, the consent will expire and will not be renewed.

  • 2.3.2.2 When the consent expires confirm to the User what will happen to their data and the service being provided.

• 2.3.3 When an account access consent is ‘long-lived’ with no expiry date defined, confirm to the User the requirements for re-authorizing their access consent after 'n' days

2.4 Define the start and end dates for the period needed for historical data, if required for a specific use case. The end date of the period of historical data that can be requested by TPPs and which MUST be returned by LFIs for a Data sharing Request is as per the End Date of historical data for Data Sharing Request https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850897/Limits+and+Constants#A.-Limits.

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 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

• 2.7.1 Provide a way for the User to search for their LFI

Additional Consent Parameters

TPPs MUST:

2.5 Set the Accepted Authorization Type (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final/pages/210800446/Common+Rules+and+Guidelines#7.-Accepted-Authorization-Type).

2.6 Set the Authorization Time Window (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final/pages/210800446/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.7 Obtain the Users' explicit consent to access information from insurance products held at LFIs (as perhttps://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final/pages/210796838/Consent+Setup#2.1--Data-Sharing-Consent).

ICS-3

Consent Staging

As perhttps://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final/pages/210800446/Common+Rules+and+Guidelines#10.-Consent-Staging

ICS-4

Hand-off to LFI

TPPs MUST:

4.1 Notify the User that they will be transferred to the selected LFI to undertake their authentication and consent authorization (as perhttps://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final/pages/210800446/Common+Rules+and+Guidelines#11.-Hand-off-to-LFI)
Example wording to use: ‘We will securely transfer to YOUR LFI to authenticate and authorize the data sharing request“.

• 4.1.1 Where an LFI is using the CAAP application, TPPs MUST notify the user that they will be transferred to the CAAP to undertake consent authentication and authorization with their LFI.

ICS-5

Authentication

LFIs MUST:

5.1 Enable Users to perform authentication with their LFIs, as per the following sections:

• https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final/pages/210797382/Authentication+and+Authorization#2.-Redirection

• https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final/pages/210797382/Authentication+and+Authorization#3.-Decoupled-Redirection

5.2 Re-direct Users back to the TPPs, with information that the Consent has not been authorized, if User Authentication has failed or Users opted to cancel the authentication/authorization process.

ICS-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 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 the duration of how long it will be shared for

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

ICS-7

Confirmation/ Authorization

LFIs MUST:

7.1 Present to Users all the details in relation to data sharing Consent.

7.2 NOT allow Users to change any of the Consent parameters (e.g. permissions) staged by the TPP.

7.3 Request Users to authorize the data sharing Consent.

7.4 Enable Users to cancel the data sharing Consent request from within the authorization journey.

7.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.

• 7.5.1 The LFI must also notify the OFP that the consent has not been authorized and change the consent state from Awaiting Authorization to Rejected.

7.6 Check the Authorization Time window is valid as perhttps://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final/pages/210800446/Common+Rules+and+Guidelines#20.-Check-Authorization-Time-Window

7.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.

7.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:

7.9 Confirm back to the LFIs that the data sharing Consent details have been updated successfully.

ICS-8

Hand-off back to the TPP

As perhttps://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final/pages/210800446/Common+Rules+and+Guidelines#14.-Hand-off-back-to-the-TPP

ICS-9

Confirmation to User

As perhttps://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final/pages/210800446/Common+Rules+and+Guidelines#16.-Confirmation-to-User

ISR-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.

ISR-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.3.1 Only allow data sharing requests from TPPs for the data clusters and permissions consented by the User as per the data sharing Consent authorized by the User.

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 the case there are valid reasons for the data sharing Consent to be suspended as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final/pages/210796838/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 the 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.

Any other name by which you refer to these policies

Provide policy identifiers to facilitate retrieval of other policy details. No other policy data is provided unless explicitly requested.

(ReadMotorInsuranceCustomerBasic)

Your basic information

Provides basic customer information, including full name and short name.

Your detailed information

Provides full customer details, including address, employment information, and emergency contact details.

Bank Account Information

(ReadMotorInsuranceCustomerPaymentDetails)

Your bank account details

Provides customer bank account information.

(ReadMotorInsuranceProduct)

Your policy and vehicle information

Provides all policy data including policy number and vehicle information.

Your premiums and claims

Provides premium and claim information.

Motor Insurance

Your add-ons

Add-ons to a motor insurance policy such as additional coverage.

Health Insurance

Your dependents

Provides relevant information on dependents included in a health insurance policy.