Deceased Identity Fraud: Ghosting and Death Data Matching

When someone dies, their identity keeps working in thousands of systems that have not yet been told, and fraudsters use that gap to open credit, claim payments and take over the accounts the person left behind. This guide covers deceased identity fraud from the organisation's side: new-account fraud using a dead person's details (often called ghosting), takeover of existing accounts during estate administration, and the death data sources and matching controls that close the gap. It is written for fraud, identity proofing and customer operations teams at banks, lenders, insurers, public bodies and online services, and for IAM teams who still hold accounts for staff who have died. It uses United States and United Kingdom death data services as worked examples because both publish how their schemes work.

Key takeaways

The risk window is the reporting lag. Fraud happens in the time between a death and the moment each organisation's records reflect it, so speed and coverage of death data matter more than any single check.
Death data is incomplete by design. The US Social Security Administration states its records are not a comprehensive record of all deaths, and the public file it shares excludes state death records, so no single list should be treated as the answer.
Identity proofing standards now require a death check. NIST SP 800-63A Rev. 4 requires a death records check for all identity proofing processes, alongside a documented policy for handling a subscriber's account after death.
Bereavement journeys are an attack surface. Notification portals, executor access and account closure processes need the same proofing and authorisation rigour as account recovery, because fraudsters pose as executors too.
Insiders and close associates are a real source. People with access to the deceased's documents and devices can commit this fraud, so controls must not rely only on knowledge a relative would have.

How deceased identity fraud works

Deceased identity fraud uses the personal data of someone who has died. It is closely related to application fraud and to synthetic identities, where real identifiers are blended with invented ones; see the Account Opening and Application Fraud Guide. It differs in one useful way for defenders: the identity has a hard end date that an authoritative source can confirm.

Pattern	What happens	Typical signals	Who sees it first
Ghosting (new-account fraud)	A fraudster applies for credit, utilities or services using a dead person's name, date of birth and national identifier	Application after date of death; new contact details with no history; credit file carrying a deceased indicator	Lenders, card issuers, telecoms, credit reference agencies
Existing account takeover	Someone with access to devices, post or documents keeps using or drains the deceased's accounts	Activity after date of death; contact detail and payee changes; new device sign-ins	Banks, payment providers, online services
Fraudulent executor or notifier	An impostor reports a death or claims executor authority to redirect funds or gain account access	Notification with no registry match; documents that fail validation; pressure for urgent release	Bereavement teams, contact centres
Benefit, pension and payment fraud	Recurring payments continue after death and are collected by someone else	Payments to accounts with no other activity; life certificate not returned	Public bodies, pension schemes, insurers
Tax and refund fraud	Returns or refund claims are filed in the deceased's name	Claims for a taxpayer reported deceased; changed bank details	Tax authorities
False death claims	A living person is reported dead to escape debt or claim insurance	Death report with no registry match; activity continuing after the reported date	Insurers, lenders

The California Attorney General's guidance on identity theft and the deceased notes that delays in reporting a death give thieves time, that warning signs include creditor or collector contact about accounts opened after the death, and that merchants and banks bear losses alongside families. Sources of the data include obituaries, death notices and documents held by people close to the deceased, which is why controls must assume the fraudster may know the answers to knowledge-based questions.

Death data sources and their limits

Every organisation that matches against death data needs to know what its source covers and how quickly it updates. The examples below are the published schemes in the US and UK.

Source	Operator	What it contains or does	Who can use it	Limits to plan for
Death Master File, full file	US Social Security Administration	Death data including state death records, built from SSN records; entries may include SSN, name, date of birth and date of death	Certain federal and state agencies under section 205(r) of the Social Security Act	SSA states its records are not a comprehensive record of all deaths
Limited Access Death Master File (LADMF)	NTIS, US Department of Commerce	The public version of the DMF, excluding state death records	Certified subscribers with a legitimate fraud prevention interest or a legitimate business purpose, under 15 CFR Part 1110 and section 203 of the Bipartisan Budget Act of 2013	Excludes state records; certification renews annually and attestation and firewall every three years
Credit file deceased indicator	Credit reference agencies	Flag added from lender reports, SSA death notices or a family member's submission with a death certificate	Lenders and others checking credit files	Depends on someone reporting; timing varies
Tell Us Once	UK government	Reports a death once to HMRC, DWP, HM Passport Office, DVLA, local councils, Veterans UK, Social Security Scotland and some public sector pension schemes	The person dealing with the death, using a registrar's reference number valid for 28 days	England, Scotland and Wales only; does not notify banks, insurers, utilities or private pensions
Death Notification Service	Developed by UK Finance, hosted by Equiniti	One online notification to multiple participating financial firms, checked against the General Register Office database to guard against fraudulent notifications	The public, free of charge	Covers participating firms only; firms are asked to contact the notifier within 10 calendar days

Two design lessons follow. First, combine sources: a negative result from one list is not proof that a person is alive. Second, treat incoming notifications as untrusted input, which is why the Death Notification Service checks against the official register before passing a notification to firms.

Prevention controls at onboarding

NIST SP 800-63A Rev. 4 section 3.2 requires credential service providers to run a fraud management programme and to implement a death records check for all identity proofing processes, confirming with a credible, authoritative or issuing source that the applicant is not deceased. NIST notes this helps prevent synthetic identity fraud, use of stolen identity information and exploitation by close associates or relatives. Section 2.4.2.3 requires core attributes to be validated against an authoritative or credible source, and section 2.4.2.4 gives the SSA as an example of an issuing source.

Death check on every proofing event: run it at account opening, on step-up proofing and when an identity is re-verified after a long gap, not only at first contact. See the Identity Proofing and KYC Guide.
Check the credit file flag: a deceased indicator on a credit report should stop automated decisioning and route to review.
Do not rely on knowledge questions: NIST prohibits knowledge-based verification for identity verification, and relatives can often answer them.
Corroborate contact details: new phone numbers, email addresses and postal addresses with no history are the usual fraudster footprint; NIST recommends checks such as account tenure, mailing address checks and SIM swap detection as fraud signals.
Watch for age outliers: applications for very old dates of birth, or identifiers issued long ago with no recent activity, deserve a manual look.

Protecting existing accounts after a death

Once a death is reported, the account is in its most exposed state. Funds are waiting for distribution, family members are under stress, and several people may legitimately hold credentials or devices. Treat bereavement as a high-risk account lifecycle event, in the same way the Account Takeover Prevention Guide treats recovery and contact detail changes.

Verify the death: match the notification against an authoritative source (registry, death certificate validation or a trusted notification service) before changing account state.
Freeze changes, not information: block payee additions, contact detail changes, new credentials and new devices, while still letting authorised parties see balances and statements.
Verify authority separately: confirm executor or administrator status from legal documents (grant of probate, letters of administration or the local equivalent) through a channel the requester did not supply.
Review recent activity: look back from the date of death for transactions, sign-ins and changes that suggest misuse, and refer them to fraud operations.
Close or convert: close, or convert to an estate account, under documented authority; revoke tokens, sessions and stored payment credentials.
Record the reason: keep the evidence used to verify both the death and the authority, so disputes can be resolved later.

The California guidance asks families to tell creditors in writing when an account was opened or used fraudulently after a death, to ask for it to be closed and for a death notice to be placed on it. Bereavement teams should have a defined route for exactly this letter, so it reaches fraud operations rather than collections.

Online accounts and legacy features

Large platforms provide planned routes for access after death, and organisations should point families to them instead of improvising. Apple's Legacy Contact requires an access key generated by the account holder and a death certificate before granting access to data such as photos, messages, notes and files; iCloud Keychain passwords, passkeys and payment information are excluded. Google's Inactive Account Manager shares chosen data with up to 10 trusted contacts after an inactivity period the user sets, with a phone number required for each contact so only that person can download the data. Your own service needs an equivalent: NIST SP 800-63A section 3.1 asks credential service providers for a documented policy on accessing or removing a subscriber's account after death or incapacitation.

Where identity fits: workforce and machine accounts

Organisations also hold identities for employees, contractors and customers who have died. A deceased employee's account is a leaver account with extra sensitivity: HR may be slow to process the change out of respect for colleagues, and managers may ask for mailbox access. An enabled account with a known password and no owner is exactly the valid account (ATT&CK T1078) an attacker wants.

Trigger from HR on the same day: disable sign-in, revoke sessions and tokens, and remove privileged roles as soon as HR records the death. The Employee Offboarding Security Guide sets out the steps.
Delegate data access, not the account: grant a manager delegated access to mailbox or files for a fixed period instead of resetting the password and sharing it.
Find owned non-human identities: service accounts, API keys and automation owned by the person need a new owner before the account is removed, or they become orphaned.
Protect the help desk: callers claiming to act for a deceased colleague are a social engineering pretext; apply the Account Recovery and Help Desk Security Guide controls.

Choosing controls by organisation type

Organisation	Priority controls	Notes
Bank or lender	Death check at onboarding, credit file deceased flag, bereavement freeze, participation in an industry notification service	Highest exposure to both ghosting and account takeover
Insurer or pension scheme	Periodic matching of the full book against death data, life certificates for overseas members, false death claim checks	Recurring payments make post-death payment fraud the main loss
Public body paying benefits	Use of government death data feeds and cross-government notification, pre-payment screening	US federal programmes screen payments through Treasury's Do Not Pay service
Online service or retailer	Legacy access policy, dormant account rules, verified notification route	Stored payment cards and loyalty balances are the targets
Small organisation	Bought-in identity verification with a death check, documented bereavement procedure	Direct data access is usually impractical; rely on a provider and a clear manual process

Detection and measurement

Run death data matching both at events and in batch. Event checks stop new fraud; batch matching of the existing customer base finds accounts still active for people who have died.

Activity after date of death: alert on sign-ins, payments, applications or contact changes dated after a confirmed date of death.
Notification mismatches: log notifications that fail registry matching and review them as possible fraud.
Executor changes: monitor repeated executor claims on the same estate or one executor across unrelated estates.
Dormant reactivation: flag accounts with long inactivity that suddenly change contact details and transact.

Metrics that show the programme is working:

Percentage of identity proofing events that include a death check (target 100%).
Median days from death to account freeze, measured from the date of death on the matched record.
Number of active accounts found in batch matching per run, and the trend over time.
Losses on accounts with activity after date of death, per quarter.
Rate of failed or fraudulent bereavement notifications detected before any account change.
For workforce identities: hours from HR record of death to account disablement.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-63A Rev. 4	Section 3.2 fraud management, death records check	Requires a death records check for all identity proofing processes
NIST SP 800-63A Rev. 4	Section 3.1 and section 2.4.2.3	Policy for accounts after death or incapacitation; validation of core attributes against authoritative sources
NIST SP 800-53 Rev. 5	IA-12 Identity Proofing	Proofing controls that include the death check
NIST SP 800-53 Rev. 5	AC-2 Account Management, AC-2(3) Disable Accounts	Disabling accounts of deceased staff and customers
NIST CSF 2.0	PR.AA-02	Identities are proofed and bound to credentials based on the context of interactions
NIST CSF 2.0	PR.AA-01	Identities and credentials are managed through their lifecycle, including after death
MITRE ATT&CK	T1078 Valid Accounts	Misuse of accounts left enabled after an employee's death

Common failure patterns

One list treated as complete: relying on a single death file that excludes some records, so deaths outside it are missed.
Death check only at first onboarding: no check at re-verification, recovery or batch, so existing accounts stay live.
Unverified notifications acted on: closing or redirecting accounts on an unverified death report, which enables both false death claims and executor fraud.
Knowledge questions for bereavement calls: relatives and close associates know the answers, and they are among the people NIST names as a source of this fraud.
Bereavement letters routed to collections: a family's fraud report on a post-death account lands in a debt queue and the fraudster keeps operating.
Leaver process paused for a death: the account of a deceased employee stays enabled for weeks, with shared passwords used for mailbox access.

Practitioner checklist

Add a death records check to every identity proofing and re-verification flow.
Document which death data sources you use, what each excludes and how often it updates.
Match the existing customer or member base against death data on a schedule.
Verify every death notification against an authoritative source before changing account state.
Freeze contact, payee, device and credential changes on accounts once a death is confirmed.
Verify executor authority from legal documents through an independent channel.
Publish a legacy access policy for your service and route families to it.
Disable workforce accounts on the day HR records a death, and reassign owned service accounts and keys.
Track time from death to freeze and losses on post-death activity as standing metrics.

Deceased Identity Fraud Guide: Ghosting, Estate Account Takeover and Death Data Matching