OFP-019 DraftMedium

TPP account preselection for Data Sharing

A TPP can name the account a payment is made from, but cannot name the accounts it wants for Data Sharing. This proposal lets a TPP pass an encrypted list of account identifiers in the Data Sharing consent from V2.2. The LFI shows only those accounts, preselected and locked, on the authorisation page — the same pattern payments already use for DebtorAccount.

Proposed by

Nebras

Author

Thomas Catchpole

Target

V2.2

Opened

22 Oct 2026

Closes

5 Nov 2026

Decision

Cast your vote

Sign in with the Trust Framework to vote — For, Against, or Abstain — recorded in the open with your reasoning. Your organisation and name come from your directory profile, and each person may vote once. Three questions are attached to this vote — set out in section 05 below. The first asks TPPs where they would use preselection; the second asks LFIs whether they can match every identifier scheme; the third asks both whether the list should be locked.

§ BallotOFP-019Closes 5 Nov 2026 ·

Where do you stand?

Pick a stance to add your name & a comment.

in favour

votes cast

For

Against

Abstain

Voting not yet open

Voting opens 22 Oct 2026

The proposal

01 · Background

Payments can name an account; Data Sharing cannot

A payment consent carries an encrypted PersonalIdentifiableInformation object. When the TPP includes Initiation.DebtorAccount in it, the LFI shows that account as “Account selected for the payment” and the User cannot pick another. When the account does not match, the LFI shows an error and the User returns to the TPP.

A Data Sharing consent has no equivalent. Its only account filters are AccountType and AccountSubType, so a TPP that already knows which accounts it needs — from an earlier consent, or because the User chose them in the TPP’s own interface — can only send the User to the LFI to find and tick them again. If the User ticks the wrong accounts, the TPP finds out only after the consent is authorised.

02 · Recommendation

An encrypted list of accounts in the consent

Take the PII object from payments, keep only the account, call it Accounts, and make it a list.

Proposed — Data Sharing consent at POST /par

"authorization_details": [{
  "type": "urn:openfinanceuae:account-access-consent:v2.2",
  "consent": {
    "ConsentId": "b8f42378-10ce-4d8c-a1b4-91d1a3f6b2e1",
    "Permissions": [ "ReadAccountsDetail", "ReadBalances", "ReadTransactionsDetail" ],
    "ExpirationDateTime": "2027-04-22T00:00:00Z",
    "OpenFinanceBilling": { ... },
    "PersonalIdentifiableInformation": "eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMjU2R0NNIn0..."
  }
}]

# Decrypted PersonalIdentifiableInformation
{
  "Accounts": [
    { "SchemeName": "IBAN",      "Identification": "AE070331234567890123456" },
    { "SchemeName": "MaskedPAN", "Identification": "************1001" },
    { "SchemeName": "IBAN",      "Identification": "AE070331234567890123499" }
  ]
}

Proposed rules

The TPP MAY include PersonalIdentifiableInformation in a Data Sharing consent. It is signed and encrypted to the LFI’s encryption key exactly as for payments, and decrypts to an object holding Accounts: an array of at least one { SchemeName, Identification }.
SchemeName uses the schemes of the accounts endpoint:IBAN, AccountNumber, MaskedPAN, MortgageReference and FinanceReference (AEExternalAccountIdentificationCode). A TPP SHOULD send the identifier exactly as GET /accounts returned it.
The LFI MUST lock the list. It MUST show only the User’s accounts that match an entry in Accounts, preselected, and MUST NOT let the User select any other account. The User may authorise or cancel.
Identifiers that match nothing are dropped. The LFI MUST NOT show or tell the TPP which entries failed to match. If no entry matches, the LFI MUST show that no matching accounts were found, and the User returns to the TPP with nothing shared.
The existing filters still apply. An account that matches an entry but falls outside the consent’s AccountType or AccountSubType is dropped.
Without PersonalIdentifiableInformation, nothing changes. The User selects accounts at the LFI as today.

03 · Customer experience

What the User sees at the LFI

The User holds a current account, a savings account, a credit card and a mortgage. The TPP preselects the current account (by IBAN), the credit card (by masked PAN) and an IBAN the User does not hold. The LFI shows the two matches, locked, with no checkboxes; the third entry is dropped without comment.

Account(s) selected to share information with AlTareq

Current Account

AE07 0331 2345 6789 0123 456

Balance

5,000

Overdraft

1,500

Credit Card | Cashback Card

**** **** **** 1001

Outstanding

2,400

Available

7,600

Review the information you will share

Authorize using AlTareq

Cancel

04 · Technical changes

What changes

One optional property on the Data Sharing consent, and a locked account list at the LFI.

01 · Standards specification — uae-authorization-endpoints-openapi.yaml

Add an optional PersonalIdentifiableInformation (a JWE string) to the consent of the urn:openfinanceuae:account-access-consent:v2.2 authorisation details, and define the decrypted AEBankDataSharingPII schema with a required Accounts array (minItems: 1) of SchemeName and Identification. Targets V2.2.

02 · API Hub

Store the encrypted PersonalIdentifiableInformation with the consent and make it available to the LFI during the authorisation journey, as for payment consents. The Hub does not decrypt it. The accounts the User authorises are recorded on the consent as today.

03 · LFI

Decrypt the PII, match each entry against the User’s accounts, and render the locked list (or the no-matching-accounts state) on the authorisation page.

04 · Documentation

Add a preselection section to the TPP and LFI Data Sharing user journeys, a PII page alongside the payments one, and a V2.2 changelog entry.

05 · Questions

Three questions, asked with the vote

These appear as optional boxes when you confirm your vote.

01 · TPPs

Where would you use account preselection — for example re-connecting a User whose consent has expired, or a lending journey for one known card or mortgage — and which identifier schemes would you send?

This confirms the use cases, and tells us whether every scheme in the list is needed or whether IBAN and MaskedPAN cover most journeys.

02 · LFIs

Can your authorisation journey match each scheme — IBAN, AccountNumber, MaskedPAN, MortgageReference and FinanceReference — against the User’s accounts and lock the list to the matches by V2.2? Is any scheme ambiguous for you, such as a masked PAN shared by two cards?

Preselection only works if every LFI can resolve the identifiers it receives. A scheme that cannot be matched reliably may need to be removed or tightened before the change is adopted.

03 · TPPs and LFIs

Is locking the list right, or should the User be able to add or remove accounts at the LFI? Is it right that identifiers which match nothing are dropped silently?

Locking mirrors DebtorAccount for payments and keeps the result predictable for the TPP. Letting the User change the list gives them more control; the answers decide which way the standard goes.

06 · Pros

What preselection buys

✓Less friction. A User who has already chosen accounts in the TPP’s interface does not have to find and tick them again at the LFI.
✓Fewer wrong selections. The TPP receives the accounts its service needs, rather than whatever the User happened to tick.
✓It reuses what exists. The encrypted PII object, the identifier schemes and the locked-account pattern are already in the standard for payments and the accounts endpoint.
✓It is optional. A TPP that does not send PersonalIdentifiableInformation gets today’s journey, unchanged.

07 · Cons

What it costs

×LFIs must build matching. Each LFI has to decrypt the PII, resolve every identifier scheme against the User’s accounts, and render a locked list.
×Less choice for the User. With the list locked, a User who wants to share a different account must go back to the TPP and start again.
×Silent drops can confuse. If an identifier does not match, the account simply does not appear; the TPP learns which accounts were shared only from GET /accounts afterwards.
×The TPP must already hold the identifiers, which in practice means an earlier consent or the User typing them in.