Make the transaction narrative a required field
Add TransactionInformation — the transaction narrative — to the required list on every transaction the data-sharing API returns. The narrative is what powers categorisation, affordability, and underwriting; without it the dataset is close to meaningless. This codifies what Nebras already enforces for CASA, and asks the ecosystem whether it is achievable for every product.
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.
The narrative is the value — and it is optional
A transaction returned from GET /accounts/{AccountId}/transactions carries the structured essentials — an amount, a date, a credit/debit indicator, a type. What tells a TPP what the transaction was actually for is the narrative: the free-text TransactionInformation field. It is the single most important input to the use cases Open Finance exists to enable — categorisation, affordability assessment, and underwriting. Strip it out and a statement collapses into a column of amounts a TPP cannot reason about.
Yet in the specification the field is defined but not required. In the TPP Standards spec, TransactionInformation is a string of 1–500 characters described as “the transaction narrative, which is unstructured text”, but it does not appear in the AETransaction required list. The picture is the same on the LFI side: the Ozone Connect transactionInformation field is optional on CbuaeTransaction too. An LFI can therefore return a schema-valid transactions response with no narrative at all.
In practice Nebras has not accepted that. Where an LFI’s CASA transaction data has arrived without narratives, it has been treated as a functional-certification failure and a remediation plan has been required before sign-off — because a dataset without the narrative is not a functioning dataset. This proposal asks that we stop enforcing that case by case and write it into the standard.
The complication is scope. The remediation practice grew up around CASA — current and savings accounts, where a narrative is dependable. But the transactions endpoint is a single shared schema used for every product: credit cards, personal finance, mortgages, and SME / corporate accounts all report through it. We have not scrutinised the narrative for those products the way we have for CASA. Making the field technically required turns it on for all of them at once — so the honest question this proposal puts to the ecosystem is whether every LFI can actually supply it, for every product.
Require it on the transaction object
Add TransactionInformation to the required list of the transaction object, on both sides of the Hub: AETransaction in the TPP Standards spec and transactionInformation on CbuaeTransaction in the Ozone Connect spec. The field already exists and is already sized — this is a one-line addition to a required array, not a new field or a shape change. Field bounds (1–500 characters) do not move.
Because the LFI is the producer of this data, the obligation binds the LFI. It is asserted primarily at functional certification — exactly where Nebras already asserts it for CASA — so that a narrative-less transactions response fails sign-off before production rather than being remediated ad hoc afterwards. Writing it into the schema makes the rule published and testable instead of discretionary.
The proposal deliberately recommends the uniform change — required across every product — because that is what a schema-level requirement means, and because a consistent narrative across LFIs is what makes the data comparable. But it does not assume every product can meet it. Whether that is achievable for credit cards, personal finance, mortgages, and SME accounts is the central open question below, and the answer may move us toward a product-scoped rule enforced at certification rather than in the schema. We would rather surface that trade-off than legislate through it.
What changes in the spec
A single field added to the transaction object’s required list on each side — field definition and bounds unchanged.
Add TransactionInformation to AETransaction.required in uae-account-information-openapi.yaml. The field’s own definition (string, minLength 1, maxLength 500) is untouched.
Add transactionInformation to CbuaeTransaction.required in uae-ozone-connect-bank-data-sharing-openapi.yaml, so the obligation binds the LFI as the data producer and the two sides stay in step.
The Ozone Connect transactionInformation currently declares no length bounds. Add minLength 1 / maxLength 500 so both sides agree on what a valid narrative is — otherwise a field that is “required” could still be an empty string.
Primarily at functional certification, against the LFI’s pre-production environment — the same gate at which Nebras already requires CASA narratives. Formalising it in the schema turns today’s case-by-case remediation into a standing conformance rule.
This is a response field, so strict runtime rejection is blunt: a single narrative missing from an LFI response would otherwise fail schema validation for a whole page of transactions. Certification is therefore the primary control; any runtime handling at the API Hub should be decided deliberately rather than defaulting to a hard reject.
# GET /accounts/{AccountId}/transactions · AETransaction — today
required:
- TransactionId
- CreditDebitIndicator
- Status
- BookingDateTime
- Amount
- TransactionDateTime
- TransactionType
- SubTransactionType
# TransactionInformation is DEFINED but not required:
properties:
TransactionInformation:
description: The transaction narrative — unstructured text.
type: string
minLength: 1
maxLength: 500# GET /accounts/{AccountId}/transactions · AETransaction — proposed
required:
- TransactionId
- CreditDebitIndicator
- Status
- BookingDateTime
- Amount
- TransactionDateTime
- TransactionType
- SubTransactionType
- TransactionInformation # ← added; field bounds unchanged (1–500)CARREFOUR HYPERMARKET, DUBAI MALLDebit — merchant and locationSALARY — ACME TRADING LLCCredit — payer identifiedATM Withdrawal — ADCB, Sheikh Zayed RdCash — channel and siteEtisalat postpaid billBill payment — biller namedIB Transfer to A. Khan — rentTransfer — counterparty and reason
(field omitted)Fails: the field is now required and absent-Passes schema, defeats intent — placeholder paddingN/APasses schema, defeats intent — no narrativeTransactionPasses schema, defeats intent — generic fillerTXNPasses schema, defeats intent — carries nothing
Only the first row on the right is caught by the schema (the field is now required and absent). The rest pass a presence check yet carry no narrative — which is precisely what the quality question below is about.
What requiring the narrative buys
- ✓The dataset gains its meaning. The narrative is what turns a row of amounts and dates into something a TPP can act on — categorisation, affordability assessment, and underwriting all read from it. Without it the payload is close to inert.
- ✓Codifies a rule Nebras already enforces. Where CASA transaction data has arrived without narratives, Nebras has required remediation plans before functional sign-off. Making the field required turns that case-by-case remediation into a published, testable conformance rule.
- ✓One consistent expectation across every LFI — the narrative can no longer be silently dropped by some institutions and populated by others, which is what makes cross-LFI data comparable.
- ✓A missing narrative is caught at functional certification, before production, rather than surfacing as a data-quality gap once TPPs are live.
- ✓Minimal, additive spec change: the field already exists and is already sized (1–500 characters). This only adds it to the transaction object’s required list — no new fields, no shape changes.
What it costs
- ×The rule was shaped by CASA. Current and savings accounts reliably carry a narrative; credit cards, personal finance, mortgages, and SME / corporate accounts may source it differently — or, for some product cores, not populate it at all.
- ×An LFI whose core does not emit a narrative for a given product line would need a core or mapping change to comply — a real remediation cost, not just a schema toggle.
- ×A hard presence check guarantees the field is there, not that it is useful. It invites placeholder padding (“-”, “N/A”, “Transaction”) that passes validation while defeating the intent.
- ×The transaction object is a single shared schema — required is all-or-nothing across products. It cannot, as written, say “required for CASA, optional for mortgages”.
- ×Because this is a response field, strict runtime rejection is blunt: one transaction missing a narrative could fail validation for an entire page of results. Primary enforcement therefore sits at certification, not at every live call.
What we’re asking the ecosystem
The recommendation is uniform on purpose — but whether it is achievable everywhere is genuinely open. Settle this and it folds into the change.
- Q1Cross-product achievability — this is the central question. The narrative is dependable for CASA, but the transactions endpoint is shared across credit cards, personal finance, mortgages, and SME / corporate accounts. For each of those, can your core reliably supply a meaningful narrative for every transaction? Where it cannot today, what would remediation involve, and how long would it take? Making the field required binds every product at once — we need to know where that is not achievable before we commit.