This is v2.2-rc1 — a release candidate for the v2.2 standards, published for review and not yet ratified. It MUST NOT be used as the basis for a production implementation. For the current standards, switch to v2.1 using the version selector. See the v2.1 → v2.2-rc1 changelog for every change in this version.
Data Deletion Confirmation 7 min read
When a consent ends, the TPP must review the data it holds under that consent and confirm what it did with it. That confirmation is recorded as an Attestation Event, posted to an append-only attestations sub-resource on the consent itself. For the request and response schemas, see the API Reference.
The obligation
Once a consent reaches a terminal status, the TPP MUST review every category of data it holds under that consent and record an Attestation Event stating, per category, whether the data was deleted or lawfully retained.
The terminal statuses in scope are Revoked and Expired. Rejected consents are explicitly out of scope — no data was ever shared under them, so there is nothing to attest to.
A payment consent is not empty for this purpose. It carries debtor and creditor account details, amounts, references, and charge and exchange-rate information, plus any account data the TPP retrieved in order to set the payment up. When a payment consent reaches a terminal status, that data falls under the same obligation as a Data Sharing consent.
Data the TPP holds outside the consent — data the customer supplied directly, or data obtained under a separate lawful basis — is not covered by this attestation.
The attestations sub-resource
Every consent type gains an attestations sub-resource. Each is scoped to its own API family, so a TPP only needs the scopes it already holds.
| Consent type | Path | Scope |
|---|---|---|
| Bank Data Sharing | /account-access-consents/{ConsentId}/attestations | accounts |
| Bank Service Initiation | /payment-consents/{ConsentId}/attestations | payments |
| Insurance | /insurance-consents/{ConsentId}/attestations | insurance |
POST appends a new Attestation Event. GET returns every event successfully recorded against that consent, each carrying a copy of the Attestation the TPP submitted alongside its receipt. The response is paginated.
Where a TPP has posted more than one Attestation against a consent, only the last successfully recorded one is reported on. Pass LastSubmitted=true on the GET to retrieve just that event rather than the whole history; the parameter defaults to false.
Attestations are recorded and validated wholly within the API Hub. There is no corresponding Ozone Connect endpoint and no change to the consent record an LFI holds.
Signed requests and receipts
POST does not take a JSON body. The request is a signed JWT sent as application/jwt, and the 201 response is a signed JWT in return. The Attestation itself travels in the message claim.
| Operation | Media type | Body |
|---|---|---|
POST request | application/jwt | message carries Data — the Attestation |
POST 201 response | application/jwt | message carries Data — the receipt |
GET 200 response | application/json | Unsigned — Data, Links, Meta |
Both JWTs require the iss, exp, nbf and message claims; aud and iat are optional.
The receipt repeats the submitted Attestation back in full, rather than just acknowledging it by AttestationId. That is deliberate: it puts the complete record inside the signed message, so the TPP holds a signed artefact covering both what it attested and what the API Hub recorded.
The regulatory deadline
The API Hub stamps every recorded event with RegulatoryDeadlineMetIndicator, reporting whether it arrived before the regulatory deadline for the AttestationType submitted. For DataRetentionDeletion that deadline is 45 days from the consent reaching its terminal status.
The deadline is not carried in the OpenAPI document — the specification defines only the indicator, and the API Hub applies the regulatory value for the attestation type. A change to the deadline is therefore a policy change, not a schema change.
The deadline runs from the status change, not from the moment the TPP noticed it. A TPP subscribed to the consent status webhook is notified when a consent becomes terminal; a TPP that is not subscribed MUST poll the consent to detect the transition. Either way, knowing is the TPP's responsibility.
A late event is still recorded. The API Hub does not reject it — RegulatoryDeadlineMetIndicator simply reports false. A late attestation is more useful than a missing one, and the indicator preserves the compliance signal.
Append-only and stateless
The sub-resource is append-only. Each POST records a new, immutable event; the API Hub applies no de-duplication and stores every successfully recorded event.
There is deliberately no state model and no correction endpoint. A TPP that needs to restate an attestation simply posts another event, and the last one successfully recorded is the one reported on.
AttestationType is the extension point. A future obligation to attest to something else against a consent becomes a new type — not a new API.