This is v2.2-draft — a working draft of 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-draft changelog for every change in this version.
Data Deletion Confirmation 5 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, Expired, and Consumed. 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 the events the TPP has posted against that consent, most recent first, each paired with its receipt.
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.
The 45-day deadline
The Attestation Event MUST reach the API Hub within 45 days of the consent reaching its terminal status. The API Hub stamps every event with RegulatoryDeadlineMetIndicator, stating whether it arrived inside that window.
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. Which event is surfaced in reporting is a reporting-layer matter, not consent state.
AttestationType is the extension point. A future obligation to attest to something else against a consent becomes a new type — not a new API.