Settld Compatibility Guide

Overview#

Settld ↗ (formerly Estate Registry) is a UK-based bereavement notification platform that enables executors and next-of-kin to notify service providers of a death through a single online process. Rather than contacting each bank, utility company, insurer, and pension provider individually — a task that typically requires dozens of separate phone calls, letters, and forms — Settld acts as a centralised notification hub, distributing death notifications to over 1,400 service providers on behalf of the bereaved.

The bereavement notification problem is both emotionally and logistically significant. When a person dies in the United Kingdom, the executor or next-of-kin must notify every organisation the deceased held an account or policy with. Research by the Bereavement Standard Working Group and others consistently shows that families contact an average of 20-30 organisations during estate administration, with each notification requiring identification of the deceased, proof of death, proof of authority, and account details. The process is repetitive, time-consuming, and occurs at a time of acute emotional distress.

Settld addresses this by collecting the deceased’s details, verifying the death (typically via the General Register Office death certificate), and then transmitting structured notifications to each relevant service provider. The executor enters the information once, and Settld handles the distribution.

Current integration status (as of April 2026): Based on publicly available information, Settld does not currently offer a public API. References to a “Bereavement API” in public materials describe a future capability. This guide is therefore a proposed compatibility specification, mapping INHERIT’s data model to Settld’s known data entities and outlining how INHERIT could serve as the interchange format if such an API becomes available.

Why this matters: There is no open data standard for bereavement notifications in the United Kingdom or anywhere else. Each service provider currently receives death notifications in a different format — some via proprietary API integrations with Settld, some via email, some via post. The UK’s Bereavement Standard Working Group has been working towards standardising death notification processes, but no machine-readable data standard has emerged. INHERIT is positioned to fill this gap.

Proposed Integration#

INHERIT could serve as the data format underlying Settld’s bereavement notification workflow in two complementary ways:

1. INHERIT as the Bereavement API payload format#

When Settld’s Bereavement API becomes available, INHERIT documents could serve as the request and response format. An executor’s estate planning platform (e.g. Clio, Actionstep, or a consumer tool) would export an INHERIT document containing the deceased’s details, death verification, asset references, and organisation references. Settld would consume this document, extract the relevant data, and distribute notifications to the referenced service providers.

2. INHERIT as the notification record format#

Settld could use INHERIT’s notification.json schema to record the status and outcome of each bereavement notification it sends. This creates a structured, portable audit trail of which organisations were notified, when, through which channel, and what the delivery status was.

Data flow#

Estate Platform                  Settld                    Service Providers
(Clio, Actionstep,     -->    Bereavement API     -->    Banks, Utilities,
 consumer app)                (INHERIT format)            Insurers, Pensions

     |                              |                           |
     |  INHERIT document            |  Notification             |
     |  (person, estate,            |  dispatched per           |
     |   deathVerification,         |  organisation             |
     |   assets, orgs)              |                           |
     |                              |                           |
     |  <-- Notification records <--|  <-- Acknowledgements <---|
     |      (notification.json)     |      (provider responses) |

What INHERIT provides that Settld currently lacks#

Conceptual Field Mapping#

The following tables map Settld’s known data entities to INHERIT schemas. Because Settld does not publish a public data model, these mappings are inferred from Settld’s public-facing forms, published guidance, and the logical requirements of bereavement notification.

Deceased details –> INHERIT person.json + estate.json#

Death certificate verification –> INHERIT estate.deathVerification#

Settld verifies deaths primarily through the General Register Office (GRO). This maps directly to INHERIT’s deathVerification object.

Account and service notifications –> INHERIT notification.json + asset.json + organisation.json#

Provider records –> INHERIT organisation.json#

Provider category mapping:

Bereavement Standard Alignment#

The Bereavement Standard Working Group#

The UK’s Bereavement Standard Working Group — convened by the Department for Work and Pensions (DWP) with participation from HM Treasury, the Financial Conduct Authority (FCA), and major industry bodies — has been working towards improving the experience of bereaved people interacting with service providers.

Where INHERIT fits#

An open data standard like INHERIT could support the Working Group’s agenda at the data layer:

• A machine-readable death verification format. The estate.deathVerification object provides a structured record of how the death was verified, by whom, to what trust level, with a reference number that providers can independently verify.
• A standard vocabulary for deceased details. INHERIT’s person.json schema captures the deceased’s details in a format that every provider can parse.
• Typed organisation records with regulatory verification. INHERIT’s organisation.json includes registrations[] with regulatory body references and live-check capabilities.
• A portable notification audit trail. Every notification is recorded in notification.json with type, channel, timestamp, and delivery status.

Tell Us Once and INHERIT#

The UK government’s Tell Us Once service currently notifies participating government departments when a death is registered, but does not extend to private-sector organisations. An open data standard like INHERIT could potentially bridge the gap between Tell Us Once and private-sector notification.

Appendix: INHERIT extension for bereavement notifications#

INHERIT’s extension mechanism (x-inherit-* properties) allows domain-specific data to be included without modifying the core schemas. A bereavement notification extension (x-inherit-bereavement) could include:

Extended notification types#

Example notification with extension#

{
  "id": "a1b2c3d4-...",
  "notificationType": "x-inherit-bereavement-death_notification",
  "recipientType": "organisation",
  "recipientId": "e5f6g7h8-...",
  "channel": "in_app",
  "sentAt": "2026-03-15T10:30:00Z",
  "status": "delivered",
  "x-inherit-bereavement": {
    "providerAcknowledgedAt": "2026-03-15T14:22:00Z",
    "providerActionTaken": "Account frozen pending grant of probate",
    "providerReferenceNumber": "BRV-2026-00451",
    "estimatedCompletionDate": "2026-05-15",
    "documentsRequired": [
      "Certified copy of grant of probate",
      "Original death certificate"
    ]
  }
}