Beyond the Death: Turning Obituary Data Into Fraud Detection Signals 

Every year, pension funds and insurers pay out benefits to people who are no longer alive to receive them. The infrastructure meant to catch a death hasn’t caught up yet, so checks keep getting cut and policies stay active while the record goes unverified. 

The Social Security Death Master File (DMF) is the default source that most financial institutions usually rely on. However, it lags the actual date of death by 4 to 6 months. In that window, checks can keep getting cut, policies stay active, and beneficiary records go unverified. 

To close that gap, death audit and locator service providers work with pension funds, insurers, banks, and healthcare providers. 

How? With a simple insight:

Obituaries are often published within days of a death, long before any government database catches up. If you could reliably turn obituary listings into structured, searchable data, you’d have a fraud and compliance signal faster than almost anything else available.

But there’s a catch, obituaries are not built to be structured data. They’re prose, written by grieving families, published on funeral home and memorial sites with no consistent format. 

Getting a name, a date of birth, or a service location out of that text reliably, and at scale, meant solving a very different kind of extraction problem than most scraping projects Grepsr faces.

The Client and Their Requirements

This is a story about a client that is a death audit and locator service provider. They work with pension funds, insurers, banks, and healthcare providers to catch deaths faster than traditional record sources. 

Their business depends on closing exactly the kind of gap described above: the earlier a death is confirmed, the sooner a benefit payment stops, a policy gets flagged, or a beneficiary record gets updated.

They came to Grepsr with a specific, two-source obituary data project:

• For one site they requested a full scrape of every available listing, followed by a daily scrape to catch new obituaries as they’re published. This wasn’t a one-time pull; it needed to run as an ongoing, recurring pipeline to keep pace with the site.

• For another site, instead of an exhaustive crawl, the client wanted a randomized sample of 100,000 listings drawn from across the U.S. So they can have a representative dataset without the overhead of scraping the entire site.

Each obituary had to be turned into structured and usable fields:

Full name; date of birth, date of death, and age; the obituary text itself; the source URL; funeral home name and address; funeral service date and location, and more. 

The Real Challenge: Turning Prose into Data

Usually, the data extraction projects Grepsr gets are structured, with prices in price fields, product names in title tags, and everything else following a predictable layout. Obituaries, on the other hand, don’t work that way. 

They’re a short piece of prose written by a grieving family member or funeral home staffer. The facts a fraud-detection system actually needs, like date of birth, date of death, and age, are buried inside sentences rather than sitting in labeled fields.

That created a few distinct extraction problems.

Names had to be split without a reliable pattern. 

Full names on the page came as a single string, sometimes with a nickname in quotes, a maiden name in parentheses, or a suffix. Splitting that reliably into first, middle, and last name meant handling different formats for each individual obituary.

Dates and age lived inside narrative sentences, not fields. 

A date of birth or death might appear as “born on March 4, 1952” in one obituary and “entered eternal rest on 3/4/2021 at the age of 68” in another. There was no consistent structure to hook into, so DOB, DOD, and age all had to be parsed out of free text with enough reliability to trust downstream.

Service details multiplied per record. 

A single obituary could reference several distinct events: a visitation, a funeral mass, a graveside burial, each with its own date and location. Some records in the dataset carried as many as six separate events. Each one needed to be captured as its own structured entry rather than flattened into a single field.

Funeral home and publisher attribution weren’t standardized across sites. 

Obituary sites present this information differently, so the extraction logic had to normalize funeral home name, address, and “published by” text consistently across two sites that don’t share a layout.

What especially made it hard was doing it at scale, across two different sites, on a recurring daily basis, without the parsing breaking every time an obituary was worded a little differently than the last one.

The Approach

Grepsr built two distinct obituary data collection strategies matched to two distinct goals, rather than treating both sites as a single uniform scrape.

• For the primary obituary platform, the initial run captured every available listing to establish a full baseline.
  The daily incremental scrape that followed didn’t re-crawl the entire site each time; it used date-wise filtering to isolate newly published listings and exclude records already captured, keeping the pipeline efficient as the dataset grew.
• For the secondary memorial site, the 100,000-listing sample was pulled through random URL sampling across the site’s U.S. listings. Rather than targeting specific regions or date ranges, the resulting dataset reflected a broad, unbiased cross-section rather than a skewed slice.
• Parsing free-text obituaries into structured fields, names, dates, ages, and service events, isn’t something Grepsr trusted to automation alone. A human-in-the-loop QA step reviewed the collected obituary data output before delivery, catching the edge cases that inconsistent obituary formatting is prone to producing. Such as a misread nickname as a middle name, a service date parsed from the wrong sentence, and so on.
• Grepsr delivered the final dataset to the client as a CSV file via email, on the same recurring cadence.

The Outcome

With this ongoing project, now our client, the death audit service provider can

1. Get an early death-detection signal that financial and healthcare institutions couldn’t get from government death records alone. All before a stale record turns into an overpayment, an unflagged policy, or an unverified beneficiary claim.
2. Feed obituary data directly into their own matching and verification systems. Since it arrives pre-structured- name, DOB, DOD, funeral details, service events, instead of as raw text they’d otherwise have to clean up first. 
3. Trust the data enough to act on it quickly. Because a human-in-the-loop QA step means efficiency never comes at the cost of accuracy. 
4. Offer the institutions they serve a faster confirmation loop, a death identified through an obituary, verified, and surfaced well before it would show up through traditional channels. 
5. Strengthen their own value proposition to pension funds, insurers, and banks. Since faster and more reliable death detection translates directly into reduced overpayment and fraud exposure for the clients they serve. 

Takeaway

The most valuable data isn’t always sitting in a structured database somewhere, waiting to be queried. Sometimes it’s published every day, in plain text, by people who have no idea they’re creating a signal anyone else needs. 

Obituaries were never designed to be a fraud detection tool. But once that free text gets parsed, structured, and delivered reliably, it becomes exactly that: a faster, more human source of truth than the records built to replace it. 

This project is also a reminder that web scraping, done well, isn’t just pulling records off a page. It’s deriving meaning from what’s already public. Anyone can grab the text of an obituary.
Turning a grieving family’s words into a clean, structured, trustworthy dataset, at scale, every single day, is a different problem entirely. That’s the part that actually matters. 

If your business depends on knowing something before everyone else does, the data you need might already be public. It just hasn’t been scraped and structured yet.
Talk to Grepsr about a tailored scraping solution built to surface the signals your business can’t afford to miss. \

Data to make or break your business

Get high-priority web data for your business, when you want it.

Get started