Define an allowed character set for Debtor and Creditor References
Keep the payment references free-text, but constrain them to a single agreed character set — uniform across the ecosystem — so every LFI knows exactly which characters it must accept and store.
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 references that didn’t fit
Every payment instruction carries two free-form notes — a Debtor Reference and a Creditor Reference — that travel with the payment to support reconciliation and to give the customer something recognisable against the transaction. In v1.2 and v2.0 these were not free text at all: they were defined by a tightly prescribed regular expression (AEStructuredDebtorReference / AEStructuredCreditorReference) that required a fixed machine prefix — the TPP’s Trust Framework ID, the account BIC, and, for merchant payments, a merchant identifier — with the human-readable text appended at the end, up to a combined 120 characters.
That shape did not meet the needs of TPPs. The part a customer actually reads — the free-text reference — sat behind roughly 50–60 characters of identifiers. LFI core banking systems carry a narrower reference field than 120 characters and truncate from the right, so the machine prefix survived intact while the meaningful free text was clipped or lost entirely. The rigid pattern also rejected legitimate references outright, leaving TPPs no room to pass the information their use case required.
In version 2.1 we relaxed the schema: the Debtor and Creditor References became a plain free-text string (minLength 1, maxLength 35, no enforced pattern), so the text the customer relies on comes first and is no longer squeezed behind a fixed prefix. Alongside that, we moved the structuring guidance out of the schema and into a business rule — CRG-5.3 — that TPPs SHOULD follow where a payments use case does not dictate otherwise, putting the free-text reference first and the bank / merchant / TPP names after it, within the 35-character budget. Structure became a recommended convention, not a validation gate.
Since that change, LFIs have asked that the references not be left completely open to any character. Relaxing the structural pattern was right — but with no validation at all, an LFI cannot know in advance which characters it will be handed, and each institution is left to guess what its own systems can accept and store. The ask is for a defined set of permitted characters: not as prescriptive as the old structured pattern, but a single, uniform character-set validation applied consistently across the entire Open Finance ecosystem, so that every LFI knows exactly what it must accept and every TPP knows exactly what it may send.
Constrain the characters, not the structure
Keep the references free-text and 35 characters long, but reintroduce a single pattern that validates the characters, not the structure. The pattern defines an allowed character set — nothing about where the bank name or TPP name must sit. That ordering stays a recommendation in the TPP standards (linked below), not a validation rule.
We propose a set in two groups: a conservative Latin baseline — the ISO 20022 / SWIFT “x” set (Latin letters, digits, space, and / - ? : ( ) . , ’ +) that LFI cores, the SWIFT-heritage UAEFTS rail, and ISO 20022 AANI all store reliably — plus the Arabic block (U+0600–U+06FF), so a customer can write a genuinely Arabic reference, names included. As one regular expression, with length still capped at 35:
^[A-Za-z0-9 /?:().,'+\\u0600-\\u06FF-]+$
The Arabic block covers Arabic letters, Arabic-Indic digits (٠–٩) and Arabic punctuation, but the set deliberately stops there — no presentation-form ligatures, rare extended letters, or bidirectional control characters, which add only ambiguity and spoofing risk. This is not framed as “the AANI set”: AANI imposes no character class of its own (it length-checks the field and passes the value through), so the constraint exists to give LFI core systems one predictable set. The same pattern applies wherever the current v2.1 free-text reference is defined, so validation is identical across PAR, Bank Service Initiation, Consent Manager, Consent Events, and Ozone Connect. The 35-character limit is counted in Unicode characters, and the API Hub normalises to Unicode NFC before validating.
The structuring convention is defined in the TPP standards as a requirement — it is not restated here. See the Structured Reference requirement under Single Instant Payment → Consent Creation (the same requirement applies to each multi-payment type). In short: where a use case does not dictate the reference, the TPP puts the User’s free-text reference first (to a maximum of 22 characters), then the Creditor LFI bank name, an optional Merchant name, and the TPP name — to a maximum of 35 characters in total.
What changes in the spec
A single, additive change — a character-set pattern on the current reference definition — applied identically everywhere the references appear.
Add a pattern that defines the allowed character set to the plain-string Debtor and Creditor reference schemas — AEBankServiceInitiation.AEDebtorReference / AECreditorReference in the standards, the same plain AEDebtorReference / AECreditorReference in Ozone Connect, and the current-version branch of the AEServiceInitiationDebtorReference / AEServiceInitiationCreditorReference anyOf in Consent Manager and Consent Events. minLength 1, maxLength 35, and free-text-first all stay. The deprecated structured variants retained for older versions are not touched.
Unchanged. The Structured Reference requirement in the TPP standards remains the convention for structuring the reference — free text first, then bank / merchant / TPP names. This proposal adds the character-set validation underneath it; it does not reinstate a structural pattern.
A reference containing a character outside the agreed set fails schema validation at the API Hub and is rejected before the request reaches the LFI — returned as a standard request-validation error, not silently sanitised on the TPP’s behalf.
# v2.1 today — free text, no character validation AECreditorReference: type: string minLength: 1 maxLength: 35 # any UTF-8 character is accepted; each LFI is left to guess # what its own systems can store and reconcile
# Proposed — free text, one agreed character set (Latin + Arabic)
AECreditorReference:
type: string
minLength: 1
maxLength: 35 # counted in Unicode characters
pattern: "^[A-Za-z0-9 /?:().,'+\u0600-\u06FF-]+$" # SWIFT "x" set + Arabic block
description: >-
A Creditor Reference is a note for a given Creditor or Creditor LFI
that supports reconciliation of a payment instruction. Characters are
limited to the Open Finance reference set — the Latin "x" set plus the
Arabic block (U+0600–U+06FF) — so every LFI can accept and store it.Invoice 12345plain Latin free textRent-Jun/2026dash and slashSalary (June)parentheses and spaceRef: 9981, paidcolon and commaAhmed-ENBD-Leanstructured: text – bank – TPPفاتورة ٢٠٢٦Arabic letters with Arabic-Indic digitsدفعة Leanmixed Arabic and Latin
Pay @ Ahmed“@” is outside the setOrder #4471“#” is outside the set100% deposit“%” is outside the setA/C <12345>“<” and “>” are outside the setNote; DROP“;” is outside the setCafé Milanoaccented “é” is not in the Latin setЗаказ 12Cyrillic script is not includedTip 😀emoji are not included
Length is enforced separately — a reference over 35 characters fails on maxLength, not on the pattern.
What a uniform character set buys
- ✓Every LFI knows exactly which characters it must accept and store — no per-institution guesswork about an unbounded UTF-8 string.
- ✓One uniform rule across PAR, Bank Service Initiation, Consent Manager, Consent Events, and Ozone Connect — a reference that validates at the API Hub will not be rejected downstream by an LFI.
- ✓Still free text: the customer’s reference comes first and is not squeezed behind a machine prefix, so the v1.2/v2.0 truncation problem does not return.
- ✓Supports Arabic as well as Latin, so a customer can use a reference in their own script rather than a transliteration.
- ✓A known character set removes a class of encoding, storage, and injection edge cases that an unrestricted string invites.
- ✓Validation is enforced centrally at the API Hub, so a malformed reference is rejected before it ever reaches an LFI.
What it costs
- ×TPPs must sanitise or transliterate customer input to the agreed set before submitting.
- ×Arabic characters are two bytes each in UTF-8, so an all-Arabic 35-character reference is roughly 70 bytes — LFI cores that size this field in bytes rather than characters must allow for it.
- ×Reintroducing a pattern is a validation change every implementer must adopt, even though the field’s shape and length are unchanged.