OFP-018 DraftHigh impact

Product Application Submission

A User who compares products through a TPP and picks one still has to leave the TPP and re-enter the same details on the LFI’s own channel. This proposal adds, from V2.2, a way for the TPP to submit a User-confirmed application to the chosen LFI through the API Hub and track it to a decision. The LFI keeps full control of KYC, credit assessment and the outcome.

Proposed by

Nebras

Author

Sunil

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. Use the comment box to tell us which parts of the design you would change — in particular the confirmation model, payload encryption and the status model.

§ BallotOFP-018Closes 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

The journey stops at product selection

GET /products lets a TPP compare retail products from every LFI without a User consent. POST /leads lets it refer a User to an LFI with a name, contact details and the product of interest. Neither carries an application. A User who wants to apply now must re-key their personal, employment and income details on the LFI’s website or app, which adds friction and loses applicants.

The closest precedent is Account Opening in Service Initiation, where a TPP forwards an account opening request and User data from a Host LFI to a Candidate LFI and marks fields the User typed or edited. This proposal reuses its Host and Candidate roles and its source marking, and extends the pattern to banking products chosen through a comparison.

Product Application Submission sits between the two existing journeys. If the User wants to be contacted, the TPP uses the Leads API. If the User wants to apply now, the TPP uses this journey. In both cases the LFI takes over for KYC and completion.

02 · Recommendation

One submission API, two ways to fill it

Both models end in the same POST /product-applications call. They differ only in where the application data comes from.

	Model 1 · Direct submission	Model 2 · Hybrid origination
Data source	Entered by the User in the TPP	Retrieved from the User’s existing bank (the Host LFI), completed by the User where gaps remain
Consents	None. The User confirms on a TPP review screen	A standard data sharing consent with the Host LFI, created through PAR. Nothing about it changes
Source marking	Every cluster `UserEntered`	`DataSharing`, `UserAmended` or `UserEntered` per cluster

Scope of the first release

In scope: retail individuals applying for a CurrentAccount, SavingsAccount, personal Finance or CreditCard product that the Candidate LFI publishes in GET /products.
Out of scope: collecting or verifying KYC documents; credit decisioning, pricing and eligibility; commercial arrangements between TPPs and LFIs; mortgages, SME and corporate products, insurance, joint applications and applications on behalf of another person; funding the account or disbursing finance.

User confirmation

There is no consent for the submission. The User’s agreement is shown by confirming the application on a review screen in the TPP. No consent record is created in the API Hub. The only consent in the journey is the Model 2 data sharing consent.
The review screen MUST show, in English and Arabic: the TPP and Candidate LFI, with AlTareq branding; the product; every data item to be sent, with its value; where each item came from; that the purpose is to apply for that product and nothing else; what the LFI may do next; and that the User can withdraw.
The TPP MUST NOT submit data the User has not seen and confirmed, and MUST NOT combine the confirmation with marketing consent or terms for other services.
The TPP MUST keep evidence of what the User saw and confirmed, when, and how the User was authenticated, and MUST provide it to the LFI or Nebras on request.
In Model 2, the data sharing consent is obtained separately, and its stated purpose MUST include preparing an application for the chosen product.

Submission and processing

The TPP builds the form from GET /products. There is no separate requirements endpoint; the LFI MUST publish any product information a TPP needs, such as amount and tenor ranges.
The TPP MUST send only the fields that apply to the product category, and MUST NOT send KYC documents, document images or biometric data.
Every submission carries x-idempotency-key. For a repeat of the same key within 24 hours, the LFI MUST return the original response and MUST NOT create a second application.
The LFI MUST acknowledge synchronously with an ApplicationReferenceId, a timestamp and the status Received. The acknowledgement confirms receipt, not acceptance; assessment never happens in the synchronous call.
The LFI MUST treat these applications like its own digital channels — same priority, terms, pricing and eligibility — MUST use the data only to process the application, MUST apply its normal fraud and risk checks, and MUST NOT silently substitute another product.
The TPP MUST present the status the LFI reports and MUST NOT describe a submitted application as approved, pre-approved or guaranteed.

Personal data

The applicant payload is encrypted (JWE) to a key the Candidate LFI publishes. The API Hub validates the envelope only and forwards the payload unread.
The Emirates ID number, date of birth and contact details MUST NOT appear in URLs, query strings, logs, analytics or error messages at any party. The API Hub logs metadata only.
The TPP MUST delete the application data once it is no longer needed to show status and meet its record-keeping duties.

03 · Lifecycle

Eight statuses, four of them final

Every status is set by the LFI. The TPP reads it through GET and is told of each change by webhook.

Status	Meaning	Final
`Received`	The LFI has accepted the submission for processing. Returned in the acknowledgement.	No
`UnderReview`	The LFI is carrying out KYC, fraud, risk and credit checks.	No
`ActionRequired`	The LFI needs something from the User, described by NextAction.ActionType.	No
`Approved`	The LFI has decided to offer the product. Acceptance or activation may still be pending.	No
`Onboarded`	The account, card or finance has been opened.	Yes
`Rejected`	The LFI has declined the application.	Yes
`Withdrawn`	The User withdrew the application, on the TPP’s request.	Yes
`Expired`	The User did not complete the required action in time.	Yes

Transition rules

A final status never changes.
Only ActionRequired returns an application to review. The LFI MAY move an application from Approved to ActionRequired, for example for offer acceptance, and products with no separate approval step MAY move from UnderReview straight to Onboarded.
ActionRequired carries an action type: Documents, IdentityVerification, ESignature, WetSignature, BranchVisit, OfferAcceptance or Other. Where the User must continue in the LFI’s channel, the LFI MUST provide a single-use, time-limited HandOffUrl on a domain registered with the API Hub, which the TPP opens in the system browser. The TPP MUST NOT collect or relay KYC documents.
An application left in ActionRequired past its expiry MUST move to Expired with reason ActionNotCompleted.
On Rejected the LFI MAY return a reason code — NotEligible, UnableToVerify, DuplicateApplication, ProductUnavailable or Other — and MUST NOT return free text or personal data. Explaining the decision remains the LFI’s job, in its own channel.
The TPP MUST let the User withdraw an application that is not in a final status, and the LFI MUST set it to Withdrawn. Withdrawal does not oblige the LFI to delete records it must keep by law.
Each status change MUST generate one webhook event, in order, and MUST be visible through GET before the event is sent.

04 · Technical changes

What changes

Three TPP-facing endpoints, a webhook event, and API Hub support. Names and fields below are proposals and will be replaced by OpenAPI definitions once the design is agreed. They follow the casing of the existing Products and Leads APIs.

01 · Standards specification — Product Application endpoints

POST /product-applications submits an application and returns 201 with the acknowledgement. GET /product-applications/{ApplicationReferenceId} returns Status, StatusUpdateDateTime and, where relevant, StatusReasonCode and NextAction. POST /product-applications/{ApplicationReferenceId}/withdrawal withdraws a non-final application.

As with POST /leads, the call is authorised by the TPP’s own access token, not a User-authorised one: the User does not authenticate at the Candidate LFI and no consent is recorded. Every call carries x-fapi-interaction-id; the submission also carries x-idempotency-key. Targets V2.2.

02 · Ozone Connect

Matching operations on the Candidate LFI’s Ozone Connect endpoints for submission, status and withdrawal. The API Hub forwards the envelope and the encrypted applicant payload, enriched with TPP information. Errors follow the LFI error model and are mapped to the TPP standard by the API Hub.

03 · API Hub

Validate the TPP’s token and the envelope on every submission, rejecting one that is not valid for the calling TPP, the Candidate LFI or the ProductId. Add an endpoint for LFIs to publish status changes. Register each LFI’s hand-off domains and encryption keys, expose which LFIs support the journey so a TPP does not offer “apply” where it cannot be accepted, and apply rate limits.

04 · Webhooks — uae-webhook-template-openapi.yaml

Add the event product-application.status-changed, carrying only ApplicationReferenceId, Status and StatusUpdateDateTime. It carries no personal data; the TPP calls GET for details. Delivery is at least once, with retry for 24 hours.

05 · Products API

No change to GET /products is proposed, but an LFI MUST publish there any product information a TPP needs to complete the application. Gaps found during drafting would be added to the product schema.

Request envelope

Readable and validated by the API Hub.

Field	Type	Required	Notes
`ProductId`	string	Mandatory	From GET /products
`ProductCategory`	AEProductCategoryCodes	Mandatory	CurrentAccount, SavingsAccount, Finance or CreditCard
`DataClusters`	array of enum	Mandatory	The clusters in the applicant payload
`Provenance`	array	Mandatory	One entry per cluster: Cluster, Source and, for DataSharing, HostLfiCode, DataSharingConsentId and RetrievedDateTime
`TppApplicationReference`	string	Optional	The TPP’s own reference for the journey
`Channel`	enum	Optional	MobileApp or Web
`ApplicantPayload`	string (JWE)	Mandatory	The applicant data below, encrypted to the Candidate LFI

Applicant payload

Encrypted to the Candidate LFI. The API Hub does not read it.

Group	Field	Required	Notes
Applicant core	`FullNameEnglish`	Mandatory	As on the Emirates ID
Applicant core	`FullNameArabic`	Optional
Applicant core	`EmiratesIdNumber`	Mandatory	Declared by the User; format-checked only
Applicant core	`DateOfBirth`	Mandatory
Applicant core	`Nationality`	Mandatory	ISO 3166-1 alpha-2
Contact	`MobileNumber`	Mandatory	E.164
Contact	`Email`	Mandatory
Contact	`PreferredLanguage`	Optional	en or ar
Employment and financial	`EmploymentStatus`	Conditional	Mandatory for Finance and CreditCard
Employment and financial	`EmployerName`	Conditional
Employment and financial	`MonthlySalary`	Conditional	Amount and currency
Employment and financial	`LengthOfServiceMonths`	Conditional
Employment and financial	`SalaryTransferBank`	Optional	Name and, where known, the LFI code
Employment and financial	`ExistingMonthlyLiabilities`	Optional	Amount and currency
Product request	`RequestedAmount`	Conditional	Finance amount or card limit
Product request	`TenorMonths`	Conditional	Finance only
Product request	`ProductSpecificAnswers`	Optional	Key–value answers to inputs the product publishes in GET /products
Declaration	`UserConfirmedAccuracy`	Mandatory	true, with ConfirmedDateTime from the review screen

Errors added by this journey

HTTP	Code	When	Returned by
400	`InvalidRequest`	The envelope or the applicant payload fails schema validation	API Hub or LFI
404	`ProductNotFound`	The ProductId is unknown to the LFI	LFI
404	`ApplicationNotFound`	The reference is unknown, or belongs to another TPP	LFI
409	`IdempotencyConflict`	The key was used before with a different payload	LFI
409	`DuplicateApplication`	An equivalent open application already exists	LFI
409	`ApplicationInFinalStatus`	Withdrawal requested for an application in a final status	LFI
422	`ProductNotAvailable`	The product is no longer offered	LFI
422	`RequirementsNotMet`	A mandatory field is missing, or a value is outside the range in the product data	LFI

Error messages MUST NOT echo applicant data.

Examples

Model 2 submission · applicant payload shown encrypted

POST /product-applications
x-fapi-interaction-id: 93bac548-d2de-4546-b106-880a5018460d
x-idempotency-key: 6f1d2c0e-8b3a-4f7e-9c21-5a4b7d9e0f13

{
  "Data": {
    "ProductId": "PL-STD-001",
    "ProductCategory": "Finance",
    "DataClusters": ["ApplicantCore", "Contact", "EmploymentFinancial", "ProductRequest"],
    "Provenance": [
      {
        "Cluster": "ApplicantCore",
        "Source": "DataSharing",
        "HostLfiCode": "HOSTLFI01",
        "DataSharingConsentId": "dsc-91d4a7e2-33b0-4c8a-8f6e-5d1c0e7b2a44",
        "RetrievedDateTime": "2026-11-03T09:41:12Z"
      },
      { "Cluster": "Contact", "Source": "UserAmended" },
      { "Cluster": "EmploymentFinancial", "Source": "UserEntered" },
      { "Cluster": "ProductRequest", "Source": "UserEntered" }
    ],
    "TppApplicationReference": "app-20261103-5521",
    "Channel": "MobileApp",
    "ApplicantPayload": "<JWE compact serialisation>"
  }
}

GET status · further action required

{
  "Data": {
    "ApplicationReferenceId": "APP-7K2M9Q4X",
    "ProductId": "PL-STD-001",
    "Status": "ActionRequired",
    "StatusUpdateDateTime": "2026-11-03T11:02:10Z",
    "NextAction": {
      "ActionType": "IdentityVerification",
      "ExpirationDateTime": "2026-11-10T11:02:10Z",
      "HandOffUrl": "https://onboarding.example-lfi.ae/continue/3f9a1c"
    }
  }
}

05 · Pros

What the journey buys

✓The User applies once. Details entered or shared in the TPP reach the LFI’s onboarding engine as a structured application, instead of being re-keyed on the LFI’s website or app.
✓One integration for every LFI. A TPP submits the same payload through one API Hub endpoint, rather than building a bespoke integration per bank.
✓The LFI keeps the decision. KYC, fraud and risk checks, credit assessment and onboarding stay with the LFI, and the TPP may not present a submitted application as approved.
✓It builds on what exists. Product selection uses GET /products, Model 2 uses unchanged Data Sharing consents, status reuses the Webhooks service, and the Leads API stays the fallback for LFIs that are not ready.
✓Personal data stays out of the API Hub. The applicant payload is encrypted to the Candidate LFI, so the Hub, its logs and its operators never hold it.
✓The LFI knows where the data came from. Each cluster is marked as entered by the User, shared from a Host LFI, or amended by the User, so the LFI can weigh it accordingly.

06 · Cons

What it costs

×It is a new build for every participating LFI. Submission, status and withdrawal must be wired into the origination engine through Ozone Connect, with idempotency, a status feed and secure hand-off links.
×It needs new API Hub capability: an endpoint for LFIs to publish status events, a new webhook event, a capability flag, and registration of hand-off domains and encryption keys.
×There is no consent record for the submission. The User’s agreement rests on the TPP’s review screen and the evidence the TPP keeps, and the legal basis for sending the data needs review before issue.
×An encrypted payload cannot be validated by the API Hub. Schema errors in the applicant data surface at the LFI, and key publication and rotation have to be built.
×Shared data is attested, not proven. In Model 2 the Candidate LFI cannot confirm the TPP did not alter data retrieved from the Host LFI; source marking is the TPP’s declaration.
×The channel can be abused. Fraudulent or repeat applications are controlled by TPP authentication, API Hub rate limits and the LFI’s own checks, not by the protocol.