LFI · Insurance · Data Sharing · UX

Insurance Data Sharing — User Experience 2 min read

When a customer is redirected to you to authorize an Open Finance consent for Insurance Data Sharing, you must present an Authorization Page that clearly explains what they are authorizing. The page must collect the customer’s explicit and informed consent, and it must accurately reflect each insurance type and permission set requested.

Policies must be presented grouped by status — Active policies are selectable by default; policies in an end state (Expired, Lapsed, Cancelled, Surrendered, Converted, DeathClaim, RiderClaim) appear in a collapsible Inactive Policies group so the customer can see what is in scope but not select policies that can’t be shared. Statuses follow the AEInsurancePolicyStatusCodes enum defined in the Insurance OpenAPI spec.

The wireframe below is interactive: edit the consent body and the simulated policies, and watch the LFI screen filter to the insurance types the TPP requested and bucket them by status.

01 Interactive Demo

Edit the consent and policies, then watch the LFI screen respond

TPPConsent page

LFIAuthorisation page

Something went wrong

We couldn’t find any policies that match the insurance type(s) requested, so unfortunately we’re unable to share any information with [TPP Trading Name].

By pressing Close you will be returned to [TPP Trading Name]. No data will be shared.

Customise the consentBody below and watch the wireframes above update live. The LFI screen only shows policies whose InsuranceType appears in Data.Permissions, and groups them by status.

Configure the mock insurance policies the authenticated user holds at their LFI. Flipping a policy's Status moves it between the Active and Inactive groups on the wireframe.

Insurance type

Status

Policy number

Premium (AED)

Start

End

Insurance type

Status

Policy number

Premium (AED)

Start

End

Insurance type

Status

Policy number

Premium (AED)

Start

End

Insurance type

Status

Policy number

Premium (AED)

Start

End

Insurance type

Status

Policy number

Premium (AED)

Start

End

Insurance type

Status

Policy number

Premium (AED)

Start

End

Insurance type

Status

Policy number

Premium (AED)

Start

End

Insurance type

Status

Policy number

Premium (AED)

Start

End

Insurance type

Status

Policy number

Premium (AED)

Start

End

Insurance type

Status

Policy number

Premium (AED)

Start

End

02 Field-Driven UI

How API request fields change what the user sees

Permissions and Data Access

For Insurance Data Sharing, the Permissions field is an array of { InsuranceType, Permissions[] } objects — permissions are scoped to a specific insurance type, so a TPP can request different data clusters per type in a single consent.

Permission code	What the user sees on both the Consent and Authorisation pages
`ReadInsurancePolicies`	Policy details — Your policy number, type, status, start and end dates, sums insured, and coverage.
`ReadCustomerBasic`	Basic customer details — Your name, contact details, and the people named on the policy.
`ReadCustomerDetail`	Detailed customer details — Your name, date of birth, Emirates ID, nationality, address, contact details, and people named on the policy.
`ReadInsuranceProduct`	Product information — The insurance product underwriting your policy — cover type, features, add-ons, terms, and exclusions.
`ReadInsurancePremium`	Premium details — Provides the details of the premium paid or being paid, along with confirmation of future renewal premiums when applicable. In some cases, your insurer may protect this information by sending it in a locked format and issue you a code (via SMS or email). You'll need to enter this code within our service so that we can show you premium details.
`ReadCustomerPaymentDetails`	Payment details — The bank account or card used to pay your premium, plus payment frequency.
`ReadCustomerClaims`	Claim details — Claims raised on your policy — status, dates, amounts, and the events that triggered them.

Insurance Type Filtering

Each entry in Permissions nominates an InsuranceType. The LFI Authorisation Page only shows policies whose type appears in the consent — this acts as the equivalent of Banking’s AccountSubType filter.

`Permissions[].InsuranceType`	LFI Authorisation Page Behaviour
One or more types	Only policies whose `InsuranceType` matches one of the requested values are shown for selection. If the user holds no policies of any requested type, the LFI returns the no-matching-policies error and the authorisation flow cannot proceed.
None / empty	Invalid — `Permissions` must contain at least one entry and each entry must declare an `InsuranceType`. The consent is rejected before authorisation begins.

Tip

Only request the insurance types your service genuinely needs. Listing extra types forces the user to scan irrelevant policies and is flagged during CX certification.

Policy Status Grouping

Policies are grouped on the Authorisation Page by their Status field (AEInsurancePolicyStatusCodes). Currently active statuses are presented first and selectable by default; end-state statuses are bucketed into a collapsible Inactive Policies group so the user can see what is in scope but cannot select policies whose data can’t be shared.

Status group	Statuses included	Behaviour
Active	`New`, `Renewed`, `InForce`, `PaidUp`	Shown first, with a green tick header. Selectable by default.
Inactive	`Expired`, `Lapsed`, `Cancelled`, `Surrendered`, `Converted`, `DeathClaim`, `RiderClaim`	Collapsed by default behind an amber clock header. The policy’s end-state status is shown below the insurance type so the user understands why the policy is not selectable.

On Behalf Of

When a TPP acts on behalf of another entity (e.g. an aggregator operating under a different trading name), OnBehalfOf.TradingName identifies the entity to the user on both the Consent and Authorisation pages.

`OnBehalfOf.TradingName`	Consent / Authorisation Page Behaviour
Provided	The trading name is displayed in the page copy so the user clearly understands which entity they are sharing data with.
Not provided	The TPP’s registered name is displayed in place of the trading name.

Tip

Always populate OnBehalfOf.TradingName so users see a recognisable name rather than a blank or placeholder.