I’m not an engineer.

How the identity-resolution technology banks use for KYC and sanctions screening found 61 missing people in hospital beds.

My wife is Venezuelan, so the two earthquakes that hit the coast near Caracas on June 24th weren’t an abstract news story in our house*.

She’s the one who got me into this. The next day, she was following the missing-persons effort on social media, and she kept seeing the same complaint from families and volunteers: the public registry where people reported the missing was drowning in duplicates. The same person entered over and over, spelled a little differently each time, ages off by a year, half the fields blank, until the lists were nearly impossible to use. That evening she asked if I could do something about it.

I run a company that does exactly this. Tilores does entity resolution — the arguably unglamorous business of working out when a pile of records from disparate sources refer to the same real person. Banks use the same techniques to screen customers against sanctions lists, where “Catherine,” “Katherine,” and “Kathryn” with a missing birth date all have to link to one human. A disaster registry has the same problem, just in a different context. In a bank you’re trying not to miss a sanctioned customer. Here you’re trying not to forget someone who might still be alive.

But I’m the CEO. I’m not an engineer. I (shameful admission) don’t really know how to use an API; most of my days are spent doing sales calls or pitching VCs, not writing code. A week earlier, “can we do something about it?” would have meant pulling an engineer off paying work, explaining the whole mess to them first, and waiting.

What changed sounds like plumbing but I think it is important. A few days before, our team had quietly shipped an MCP server for Tilores.

If you haven’t run into one yet: an MCP server is the piece that lets an AI assistant actually operate a tool rather than just describe it. With it connected, I could sit down with an AI assistant (Claude in my case) in the evening, point it at the registry, and say in plain English: here are tens of thousands of missing-persons reports, help me find the duplicates. And then genuinely do it — shape the rules for when two reports are the same person, test them against real cases, run the whole dataset through, and look hard at what came out. I did this. Not an engineer I’d briefed.

So that’s what happened. 53,693 missing person reports resolved down to 51,622 distinct people, with around 2,071 duplicates folded into someone else. (The live numbers are public, updated as new reports come in.)

The matching rules are the important part, and where doing it myself, with Claude explaining the trade-offs, actually mattered. You must not merge two different siblings who share a surname. You must not merge a “Maria y José” entry — two people crammed into one report — into either of them. Get those wrong and you’ve made the lists worse than the duplicates did. And 273 duplicate cases fell out where the same person carried both a “missing” report and a “found” or “safe” one. Those went straight to humans to verify, because if the match is correct, a family can stop searching.

A few days in, the project found its second calling. Someone running a separate site, a volunteer effort collecting lists of patients who’d turned up in hospitals got in touch and asked if we could cross-reference their patients against the missing list. Some of those hospital lists weren’t typed lists at all. They were photos of names handwritten on a wall, the kind of board a hospital puts up so families can scan it in person, transcribed by hand before anyone could run them against anything. And once we were doing it, the shape of the problem was familiar: a messy, inconsistently spelled list of names that needs matching against a master list is exactly the work we do every day running screening for financial services clients against sanctions lists.

If a family reports someone missing, and that same person is lying in a hospital bed under a slightly wrong name, those two facts sit in two databases that never speak to each other. Connecting them is, potentially, a record linkage that ends a search.

We took 9,053 patient records and checked each against the resolved registry. 751 came back with a possible match. Here we needed to be careful. A national-ID match feels authoritative — until you notice one where the ID matches exactly but the names share nothing, which isn’t a match, it’s a typo in an ID field. So we added a plain check: do the two names actually agree? That split the confident-looking matches into the ones you can trust and the ones you can’t.

A difficult decision: we threw away 6,357 patients. A single first name and no ID can’t be matched against anything. Better to say nothing than to say something wrong. What we handed the humanitarian teams was deliberately small — 61 high-confidence cases where someone still listed as missing looks very likely to be in a hospital right now. Candidates, for a human to confirm.

None of this is a story about AI being magic. Entity resolution as a field is 60+ years old, and it is not (shock, horror!) based on AI (bias alert: yes, LLMs can do entity resolution, but they probably shouldn’t be used in production).

What’s different is just the ease with which I could do this — thanks to AI and an MCP server. A couple of weeks earlier this would have sat in a backlog behind an engineer’s real priorities, or, more honestly, never happened at all. The new thing isn’t that a registry can be deduplicated. It’s who can now reach in and do it — i.e. non-technical people like me. I would have previously felt quite helpless — now I feel empowered that I can actually help people.

The missing list keeps fluctuating, so there’s a job pulling new reports every fifteen minutes and feeding them through. When a name comes in that’s already sitting in a hospital list under a mis-spelling, those two facts now link automatically. That used to need an engineer (or at least someone more technical than me). This week it didn’t.

I also learned there isn’t just one missing-persons registry. Several overlapping lists exist, run by different groups, each with its own gaps and its own duplicates, and none of them talking to each other. I have given one of the teams API access so they can query our database in real-time. Otherwise, I have been sending batch deduplicated csvs by email.

We never built Tilores with this use case in mind. It was designed for banks, marketplaces, and risk teams, not disaster registries. But having seen what it can do here, we want to make it available, free, to any organization doing this kind of work: deduplicating registries, cross-referencing lists, matching names across messy data, for emergency humanitarian response. Contact me directly if you have an emergency use case: steven@tilores.io

The current numbers, refreshed as new reports come in, are public at tilores.io/venezuela-te-busca-en.

*My wife’s family and friends are all safe, as far as we know. However, her childhood family holiday home in La Guaira is destroyed, which is surreal and upsetting.