Define validation patterns for the Leads API personal-data fields
Constrain the free-text PII on POST /leads — names, Emirates ID, and address lines — to defined, ISO-grounded patterns, reusing the validation the ecosystem already applies elsewhere, so every LFI receives predictable, well-formed lead data.
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.
Lead data arrives unvalidated
POST /leads lets a TPP hand an LFI a prospective customer — a name, an Emirates ID, a residential address, and the product categories they are interested in. Unlike a payment, this data is written into the LFI: it is stored, matched against existing records, and used to make contact. What the LFI can do with it depends entirely on it arriving in a shape the LFI can store and reconcile.
Today most of those fields carry no validation beyond a length limit. GivenName, LastName, FullName, BusinessName and each AddressLine are free-text strings with no pattern. And EmiratesId — the single most important identifier on the request — is a plain string with no pattern and no length at all: any value is accepted and passed straight through to the LFI.
This sits oddly next to the two fields in the same schema that are already validated to a standard: PhoneNumber is constrained to E.164 (^\+[1-9]\d{1,14}$) and Country to the ISO 3166-1 alpha-2 code (^[A-Z]{2}$). The discipline is already here — it simply has not been extended to the personal-data fields around them.
The most important of these has also already been solved elsewhere: the insurance specifications validate an Emirates ID with ^784-?[0-9]{4}-?[0-9]{7}-?[0-9]{1}$. Yet the same EmiratesId is left unchecked in Account Information, Account Opening, FX, and here in Leads. The ask is to close the gap on the Leads fields by reusing what the ecosystem has already agreed where a pattern exists, and defining a purpose-built one where it does not.
Reuse the patterns we already have, per field
Add a pattern to each Leads personal-data field, purpose-built for what that field actually holds, and — wherever a validation already exists in the ecosystem — reuse it verbatim. Lengths and field shapes do not change.
Emirates ID — adopt the existing insurance-spec pattern. The leading 784 is the ISO 3166-1 numeric country code for the UAE; the final digit is a checksum (which a regex validates in shape but not in value):
^784-?[0-9]{4}-?[0-9]{7}-?[0-9]{1}$
Names — a tight, Latin-only character set. Person names (GivenName, LastName, FullName) allow letters, space, apostrophe, period, and hyphen — enough for “Al-Maktoum”, “O’Brien”, “Mohd.” — but no digits. BusinessName additionally allows digits and business punctuation:
person ^[A-Za-z '.\-]+$ business ^[A-Za-z0-9 &'.,\-()/]+$
Address lines — the field already cites ISO 20022 PostalAddress27. Reuse the OFP-003 approved “x” set — the ISO 20022 / SWIFT set of Latin letters, digits, space and / - ? : ( ) . , ' +:
^[A-Za-z0-9 /?:().,'+\-]+$
The baseline is deliberately Latin-only. OFP-003 originally proposed the Arabic block (U+0600–U+06FF) and it was removed on approval, because Arabic cannot be carried end-to-end over SWIFT/UAEFTS and is transliterated to Latin before submission. Whether that reasoning should hold for stored lead PII — names and addresses that never touch the rails — is a genuine question, and is put to the ecosystem below rather than assumed here. As in OFP-003, length is counted in Unicode characters, the API Hub normalises to Unicode NFC before validating, and validation is enforced centrally at the API Hub so a malformed lead is rejected before it reaches the LFI.
What changes in the spec
Additive pattern constraints on the existing Leads schemas — lengths and shapes unchanged.
Add the person-name pattern to GivenName / LastName (AEPersonalAccountName) and FullName (AEPersonalAccountFullName), and the business-name pattern to BusinessName (AEBusinessAccountName).
On Data.EmiratesId, add the 784 pattern. The same change applies to the Lead response object, which echoes the field.
Add the “x”-set pattern to the AddressLine items in AEResidentialAddress. minItems 1, maxItems 7, and the per-item maxLength 70 are unchanged.
AEUserName and AEResidentialAddress are shared by the TPP product specification and the Ozone Connect products-data specification, so the same patterns apply identically to both — a lead that validates at the API Hub will not be rejected downstream.
A field that does not match its pattern 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.
# POST /leads · LeadRequest.Data — today
Name: # AEUserName (oneOf)
GivenName: { type: string, minLength: 1, maxLength: 70 } # no pattern
LastName: { type: string, minLength: 1, maxLength: 70 } # no pattern
FullName: { type: string, minLength: 1, maxLength: 140 } # no pattern
BusinessName: { type: string, minLength: 1, maxLength: 140 } # no pattern
EmiratesId: { type: string } # no validation at all
ResidentialAddress: # AEResidentialAddress
AddressLine: [ { type: string, minLength: 1, maxLength: 70 } ] # no pattern# POST /leads · LeadRequest.Data — proposed (patterns added, lengths unchanged)
Name:
GivenName: { maxLength: 70, pattern: "^[A-Za-z '.\-]+$" }
LastName: { maxLength: 70, pattern: "^[A-Za-z '.\-]+$" }
FullName: { maxLength: 140, pattern: "^[A-Za-z '.\-]+$" }
BusinessName: { maxLength: 140, pattern: "^[A-Za-z0-9 &'.,\-()/]+$" }
EmiratesId:
pattern: "^784-?[0-9]{4}-?[0-9]{7}-?[0-9]{1}$" # 784 = ISO 3166-1 numeric (UAE)
ResidentialAddress:
AddressLine:
items: { maxLength: 70, pattern: "^[A-Za-z0-9 /?:().,'+\-]+$" } # OFP-003 "x" set, minus ArabicAhmedGivenName — letters onlyAl-MaktoumLastName — hyphen allowedO'BrienLastName — apostrophe allowedMohd.GivenName — trailing periodACME Trading L.L.C.BusinessName — periods and spacesGulf & Co (Dubai)BusinessName — “&” and parenthesesFlat 5, Building 12AddressLine — digits and comma784-1990-1234567-8EmiratesId — hyphenated 784 form784199012345678EmiratesId — 15 digits, no hyphens
Ahmed 3rdGivenName — digits are not allowed in person namesفاطمةGivenName — Arabic is excluded from the baseline (see open questions)JoséGivenName — accented “é” is outside the Latin setFlat #5AddressLine — “#” is outside the set123-1990-1234567-8EmiratesId — must begin with 784784-90-1234567-8EmiratesId — the year block must be 4 digits
Length is enforced separately — a value over its maxLength fails on length, not on the pattern.
What validating the Leads fields buys
- ✓LFIs receive predictable, well-formed lead PII — no guessing what characters or shape a name, Emirates ID, or address line might arrive in.
- ✓Reuses a pattern the ecosystem already defines — the Emirates ID pattern from the insurance specs — so validation is consistent, not invented here.
- ✓Emirates ID gains real validation where today it has none: a malformed ID is rejected at the API Hub before it ever reaches an LFI.
- ✓Grounded in ISO where a standard exists — ISO 3166-1 for the 784 prefix and ISO 20022 PostalAddress27 for address text — matching how PhoneNumber (E.164) and Country (ISO 3166-1) are already validated in this very schema.
- ✓A defined boundary rejects a class of junk, encoding, and injection edge cases at the API Hub rather than leaving each LFI core to cope.
- ✓Field shapes and length limits are unchanged — this is additive validation only.
What it costs
- ×TPPs must sanitise or transliterate customer input — strip disallowed punctuation, transliterate names — before submitting a lead.
- ×The Latin-only baseline rejects Arabic and accented-Latin names outright, so a customer named “José” or “فاطمة” cannot be submitted verbatim until the Arabic question below is settled.
- ×Reintroducing patterns is a validation change every TPP integration must adopt, even though field shapes and lengths do not move.
- ×A regex cannot verify the Emirates ID check digit, so a shape-valid but non-existent ID still passes schema validation.
What we’re asking the ecosystem
Two points the baseline deliberately leaves open — settle these and they fold into the change.
- Q1Arabic support — should any of these fields accept the Arabic block (U+0600–U+06FF)? OFP-003 rejected Arabic for payment references because they ride SWIFT/UAEFTS, which neither carry nor store it. Lead names and addresses are stored PII, not carried over the rails, so the trade-off genuinely differs. Do we add Arabic here — per field, or not at all?
- Q2Emirates ID harmonisation — this proposal patterns EmiratesId on POST /leads only. The same field is still an unvalidated string in Account Information, Account Opening, and FX Service Initiation, while the insurance specs already carry the 784 pattern. Should the pattern be applied uniformly wherever EmiratesId appears, in one place?