Community Site
Navigation
Program
PoliciesDocument Repository
Developer Docs
TPP — Open Finance StandardsLFI — Integration GuideAPI SpecsKnowledge BaseRelease Notes & Erratas
MetricsNewsGitHub
Post-publication corrections · v2.1

Erratas

The authoritative register of corrections to published documentation against v2.1 — the TPP Standards, LFI Integration Guide, and OpenAPI specifications. Each entry records what was corrected, why the change was required, and the effective date.

13corrections
1errata release
10specs touched
Filter the register

Find a correction

Narrow by audience, functional area, or spec. Add a keyword to refine further. Click any chip on a result row to toggle that spec as a filter.

Audience
Functional area
Spec
Keyword
13 of 13 sections
v2.1-errata1
13 corrections
§1
Account Information — Permissions array flattening
The Permissions field on consent responses is now a flat array of strings (previously a nested array of arrays).
→
§2
Account Information — TrustFrameworkCode enum corrected to FI
The TrustFrameworkCode enum on party responses now declares FI (previously the unemittable Undefined).
→
§3
Authorization Endpoints — POST /token restructured as oneOf; client_credentials grant added; client_id optional
POST /token response is now a oneOf across grant types, client_credentials is documented, and client_id is optional to reflect mTLS client authentication.
→
§4
Confirmation of Payee — 204 response description corrected
The 204 response description on POST /confirmation now reads "IBAN is not recognised" rather than the previous opt-out wording.
→
§5
Confirmation of Payee — aud claim tightened from array to single string
The aud claim on every *BodySigned JWT payload on CoP is now a single string (previously an array of strings).
→
§6
Monetary Amount pattern — double-escaped regex corrected across five specs
The Amount monetary regex, previously published with doubled backslashes, is corrected to ^\d{1,13}$|^\d{1,13}\.\d{1,5}$ across the affected specs.
→
§7
Webhook Template — Permissions array flattening
The Permissions field on consent webhook payloads is now a flat array of strings, matching §1.
→
§8
API Hub Consent Manager — unused AERiskExternalAccountIdentificationCode schema removed
The unused namespaced AERiskExternalAccountIdentificationCode schema has been removed from the Consent Manager spec.
→
§9
API Hub Consent Manager — AEExternalAccountTypeCode collapsed into AEAccountTypeCode; SME added
The duplicate AEExternalAccountTypeCode enum has been folded into AEAccountTypeCode, which now declares [Retail, SME, Corporate].
→
§10
API Hub Consent Manager — duplicate OnBehalfOf collapsed into AEOnBehalfOf
The unprefixed OnBehalfOf schema has been folded into the canonical AEOnBehalfOf.
→
§11
Consent Manager & Consent Events Actions — duplicate EventNotification and Amount schemas collapsed
Two pairs of duplicate schemas have been consolidated on the canonical AE-prefixed definitions.
→
§12
Ozone Connect User Operations — duplicate AEAddressItem and Amount schemas collapsed
Two pairs of duplicate schemas under the OzoneConnectConsentEventActionAPIs namespace have been consolidated.
→
§13
Ozone Connect Health Check — echo-cert clientCertificate described as mTLS client cert, not server cert
The clientCertificate.subject description and example on GET /echo-cert now describe the caller’s mTLS client certificate; the issuer example has been refreshed to the Sandbox Trust Framework issuing CA.
→
Governance

How this register works

The Errata register is bound by the policies that control how published content evolves. Once a version is published, its existing content MUST NOT be changed without an associated Errata record.

Policy

Changes to Published Documentation

How published content may change after release — what requires an Errata, what does not, and how corrections are communicated.

Read policy→
Policy

Version Management

How versions are numbered, when errata releases are cut, and how the relationship between Standards, API Hub, and Ozone Connect versions is maintained.

Read policy→
Operating rules
  • Each entry has a unique identifier in the form <version>-errata<n> — for example, v2.1-errata1.
  • Each entry states the affected document(s) and section(s), what changed, why the change was required, and the effective date.
  • Existing published content MUST NOT be changed without an associated Errata record.
  • Pre-publication content (for example -rc, -rc-final) can be updated without an Errata.
For changes to operational systems rather than documentation, see the Release Notes for API Hub or Trust Framework.