Confirm data deletion when a consent is revoked

Add an attestations sub-resource to each consent. A TPP POSTs an Attestation Event to confirm it has completed its data review and deletion once the consent ended, whether revoked, expired, or consumed. A TPP GETs the sub-resource to read the events it has posted. The event hangs off the consent it concerns, so the confirmation is allied to the consent with nothing to reconcile.

# PROPOSED — post an immutable Attestation Event to the consent
POST /account-access-consents/{ConsentId}/attestations   # Bank Data Sharing
POST /payment-consents/{ConsentId}/attestations          # Bank Service Initiation
POST /insurance-consents/{ConsentId}/attestations        # Insurance (all types)

{
  "Data": {
    "AttestationType": "DataRetentionDeletion",
    "AttestationStatusAppliedDateTime": "2026-07-08T17:30:00Z",
    "DataAccessCeasedDateTime": "2026-07-01T09:15:30Z",
    "ConsentRevocationDateTime": "2026-07-01T09:15:00Z",   # only if revoked at the TPP
    "DataActions": [
      { "AttestationType": "Deleted",
        "DataCategory": "AllConsentedData",
        "AttestationDate": "2026-07-08T17:00:00Z" }
    ]
  }
}
# 201 Created — a receipt, not a status transition. Authorised with the same
# client credentials token used to create/get the consent; no new auth, no state.

A TPP's answer is not a single flag: the same data was not necessarily all handled the same way. So the event carries a DataActions array with one entry per category of data — and an event must list every category the consent covers. Each entry states its AttestationType: Deleted (the data is gone), or Retained / Anonymised / ArchivedRestricted (the data is kept in some form — a RetentionReason, a RetainedUntilDate, and an AccessRestriction are then required). The category is AllConsentedData where one action covers everything, or a specific Permission Code, AnalyticsData, or AuditRecords where it does not:

# One event lists every data category the consent covers, and states what
# happened to each — deletion is not always the whole story.

"DataActions": [
  { "AttestationType": "Deleted",
    "DataCategory": "AllConsentedData",
    "AttestationDate": "2026-07-08T17:00:00Z" },

  # Retained under a lawful basis — reason, retained-until, and restriction required:
  { "AttestationType": "Retained",
    "DataCategory": "AuditRecords",
    "AttestationDate": "2026-07-08T17:01:00Z",
    "RetentionReason": "RegulatoryOrLegalObligation",
    "RetainedUntilDate": "2031-07-01",
    "AccessRestriction": "RestrictedUseOnly" },

  # Anonymised for analytics:
  { "AttestationType": "Anonymised",
    "DataCategory": "AnalyticsData",
    "AttestationDate": "2026-07-08T17:02:00Z",
    "RetentionReason": "AnonymisedOrAggregatedData",
    "RetainedUntilDate": "2027-07-01",
    "AccessRestriction": "NotRestricted" }
]

Each POST records a new, immutable event, treated as a single atomic event uncorrelated with any other. There is no state model and no correction endpoint: an AttestationType is data on the event, not a status the consent moves through, the Hub applies no de-duplication, and all successfully recorded events are stored. If a TPP posts more than once, it has still met its obligation; which event is surfaced in reporting — the earliest, the latest, or all — is a reporting-layer matter, not consent state. The event's top-level AttestationType is the extension point — DataRetentionDeletion is the only value defined today, and a future obligation to attest to something else against a consent becomes a new value, not a new API. The 201 response is a receipt, and a GET returns the list:

# The 201 response is a receipt — including whether the 45-day deadline was met:
{ "Data": {
    "AttestationId": "3f1c8b1e-9a2d-4c7e-bf10-1d2e3f4a5b6c",
    "AttestationReceivedDateTime": "2026-07-08T17:30:04Z",
    "RegulatoryDeadlineMetIndicator": true
} }

# GET the Attestation Events a TPP has posted against this consent:
GET /account-access-consents/{ConsentId}/attestations

{
  "Data": [
    {
      "Attestation": { "AttestationType": "DataRetentionDeletion", "...": "..." },
      "Receipt": {
        "AttestationId": "3f1c8b1e-9a2d-4c7e-bf10-1d2e3f4a5b6c",
        "AttestationReceivedDateTime": "2026-07-08T17:30:04Z",
        "RegulatoryDeadlineMetIndicator": true
      }
    }
  ]
}

The sub-resource is a child of the consent (nothing to reconcile) and append-only (no state model) — two properties the other shapes we looked at could not both offer, as Alternatives considered below sets out. Authorisation is the same as getting a consent: the sub-resource is called with the very client credentials access token a TPP already uses to create and retrieve the consent itself (for example GET /account-access-consents). So there is no new auth flow, and no dependence on a token that dies with the consent. The attestation obligation and its 45-day window are documented on the consent requirements page; whether every required attestation was posted is a reporting-layer question, kept out of the consent itself.

Two other shapes were worked through first. Both can be made to work; each carries a cost the sub-resource avoids.

A field on the consent revoke (PATCH). The first instinct was to add a DataDeletion object to the existing consent PATCH body — a small Status (say Completed, NotRequired, RetainedUnderLegalObligation) and a timestamp — so the TPP confirms deletion in the same call it uses to revoke. It is appealingly small and needs no new operation. But it couples an attestation to a status transition, and the two do not share a lifetime. Once the consent has already ended — revoked at the LFI, or expired — which is exactly when the confirmation is needed, there is no transition left to make: the PATCH would have to be relaxed to accept a body with no status change, on a consent already in a terminal state. That is a carve-out in the revoke contract — and because the field would live on the consent itself, the consent now carries deletion state, the very thing the requirement does not ask it to hold. (An AttestationType on a separate, immutable Attestation Event, as recommended above, is different: it describes a single confirmation, and the consent holds no deletion state of its own.)

A standalone events API. The other option was a new top-level resource — a /revocation-events endpoint, say — that the TPP posts to. This cleanly separates the report from the consent, but it buys a new problem: every event must then be reconciled back to the consent it concerns, with its own rules for matching, ordering, and orphaned records. It is not the endpoint that is expensive so much as the reconciliation around it.

The sub-resource takes the good part of each. Like the events API it is a distinct, append-only Attestation Event rather than a field bolted onto a status change — so it behaves identically whether the consent is active, revoked, expired, or consumed. Like the PATCH field it is allied to the consent — the event is a child of the consent, so there is nothing to reconcile. And because each post is an immutable event, there is no state model to build or enforce in the consent layer. Any enforcement that emerges later — checking a required attestation was posted by its deadline — sits in the reporting layer over these events, leaving the events themselves immutable and the consent stateless.

Every consent type carries data the TPP may have retrieved and stored, so the sub-resource applies uniformly to all three:

Service Initiation is the one to call out, because it is the easiest to wave through. It is filed under "payments", not "data sharing", so it is tempting to assume a payment consent holds nothing to delete once the money has moved. That is wrong. A Service Initiation consent carries data: the debtor and creditor account identifiers and names, the amounts, references, and the charge and exchange-rate information attached to the consent (Charges, ExchangeRate) — and any account data the TPP retrieved to set the payment up. That is personal and financial data held under a consent, and when the consent ends — revoked, expired, or consumed — it falls under the same deletion obligation as any Data Sharing consent. Excluding Service Initiation would leave exactly the data people assume is not there.