Learn · Understand · Build

OnBehalfOf — When to Use It and When Not To

CategoryConsentsRead5 minUpdated21 Apr 2026

OnBehalfOf appears in Bank Data Sharing and Insurance Data Sharing PAR schemas to declare that the TPP is acting on behalf of another regulated entity. For Bank Service Initiation (payment) PARs, OnBehalfOf is not used — the payment recipient is represented via creditor fields instead.

ConsentsOnBehalfOfData Sharing

01 When to use

Acting for another regulated entity

Populate OnBehalfOf when the caller (TPP) is requesting authorisation for bank or insurance data sharing only, but is doing so on behalf of another legal or regulated entity:

A TPP provides technology services to an LFI and stages the PAR on behalf of that LFI.
A licensed aggregator or reseller acts as the technical integration layer for another regulated entity.

If the TPP is representing itself (no other regulated entity is involved), OnBehalfOf is not required.

02 The object

Field shape

json

{
  "TradingName": "string",
  "LegalName": "string",
  "IdentifierType": "string",
  "Identifier": "string"
}

Field	Description
`TradingName`	The trading name of the entity being represented.
`LegalName`	The registered legal name of the entity.
`IdentifierType`	Identifier scheme — currently `"Other"` in the published schema.
`Identifier`	The identifier value for the represented entity.

03 Where it applies

Per consent type

Consent type	OnBehalfOf supported?	Notes
Bank Data Sharing	Yes	Declare the legal entity the TPP is acting for within the rich authorisation request.
Insurance Data Sharing	Yes	References a common `AEOnBehalfOf` object — same intent and fields.
Bank Service Initiation (payments)	No	Not used. Merchant identity is carried via the creditor fields in the payment consent.

04 Payments

Use creditor fields instead

For payment consents, the user must be shown who the payment is going to. This information is provided via the creditor fields in the payment consent — not via OnBehalfOf.

Populate the creditor fields so the LFI can display the recipient (merchant/payee) to the user:

Prefer Creditor.Name when it is provided.
If Creditor.Name is not present, fall back to CreditorAccount.Name.en or CreditorAccount.Name.ar as applicable.

This ensures the user sees a meaningful recipient name when authorising the payment.

Warning

Do not attempt to carry merchant identity in an OnBehalfOf object for payment consents — it is not part of the service initiation schema and will be ignored or rejected.

Merchant Name on the authorisation page

If the TPP populates Risk.CreditorIndicators.MerchantDetails.MerchantName in the PII payload, the LFI must reflect this on the authorisation page by displaying the merchant name in the permission header:

With MerchantName

[TPP trading name] needs your permission on-behalf of [MerchantName] to make the payment below:

When MerchantName is not present, the standard wording is shown:

Without MerchantName

[TPP trading name] needs your permission to make the payment below:

This allows TPPs acting as a payment facilitator or aggregator on behalf of a sub-merchant to surface that merchant's identity clearly to the user at the point of authorisation.

05 Examples

Concrete payloads

Bank Data Sharing PAR (with OnBehalfOf)

Use this structure when the TPP is staging the PAR on behalf of another regulated entity:

Bank Data Sharing PARjson

{
  "type": "urn:openfinanceuae:bank-data-sharing-consent:v2.1",
  "consent": {
    "Permissions": ["ReadAccountsBasic", "ReadBalances"],
    "ExpirationDateTime": "2026-02-21T12:00:00+00:00",
    "OnBehalfOf": {
      "TradingName": "Acme Aggregation Ltd",
      "LegalName": "Acme Aggregation Limited",
      "IdentifierType": "Other",
      "Identifier": "AA-TPP-12345"
    }
  }
}

Bank Service Initiation PAR (payment) — creditor fields for merchant identity

Use the creditor fields to identify the payment recipient — not OnBehalfOf:

Bank Service Initiation PARjson

{
  "type": "urn:openfinanceuae:bank-service-initiation-consent:v2.1",
  "consent": {
    "PersonalIdentifiableInformation": {
      "Initiation": {
        "Creditor": {
          "Name": "Example Merchant Ltd"
        },
        "CreditorAccount": {
          "Name": {
            "en": "Example Merchant",
            "ar": "مثال التاجر"
          }
        }
      }
    }
  }
}

Note

In production, PersonalIdentifiableInformation is a JWE encrypted with the LFI's encryption key. The structure above shows the decrypted payload for illustration.

06 Implementation checklist

Practical rules of thumb

If acting on behalf of another regulated entity, include OnBehalfOf in Bank Data Sharing or Insurance Data Sharing PARs.
For payment consents, populate Creditor.Name — or CreditorAccount.Name.en / CreditorAccount.Name.ar if Creditor.Name is not available — so the LFI can display the recipient to the user.
If the TPP is acting as a payment facilitator for a sub-merchant, populate Risk.CreditorIndicators.MerchantDetails.MerchantName in the PII payload so the LFI can display the merchant name on the authorisation page.
Do not use OnBehalfOf in service initiation (payment) PARs.

OnBehalfOf — When to Use It and When Not To

Merchant Name on the authorisation page

Bank Data Sharing PAR (with OnBehalfOf)

Bank Service Initiation PAR (payment) — creditor fields for merchant identity

Read alongside

Consent Identifiers

Payment PII Encryption