It’s 9:14am. A card gets flagged. By 9:20, four people are staring at four different systems, and not one of those systems has ever heard of the other three.
That's not a scenario I'm setting up for effect. That's what a fraud investigation looks like for a client we’re working with.
The questions in that moment are the easy part. Who touched this account? Did anyone change the phone number or address? Was the access legitimate? Asking is easy. Answering is the hard part, and not because the data doesn't exist. It exists. Almost everything you’d want is already being collected: employee actions, account changes, network logins, card-to-customer links, millions of transactions a day. Every one of those systems is clean, normalized and correct on its own terms. The problem is none of them can be resolved to each other.
Account activity lives in one daily file, keyed the way that team's system needs it keyed. Profile changes live in another, built by a different team on a different schedule with its own identifier scheme. The file mapping a card to a customer lives somewhere else entirely. Network access logs come with its own format, its own quirks, and its own opinion about what a timestamp should look like. Every one of those keys is a perfectly good key. None of them were meant to line up because nobody sat down at the start and said "one day, someone's going to need to tie a card, an address change, and a network session back to the same person in the same hour." Fair enough. That's a fraud-investigation question, not a transaction-processing one, and it usually shows up years after the schema's already locked in.
The short version, if you don't have time for the rest:
One bank, 31 flagged cards, a two-month window.Before: days of manual extraction across teams before anyone could start reviewing evidence.After: 5,249 access events, changes on 2 accounts attributed to 2 named employees, and network sessions resolved to actual peopleTime to answer went from 35+ minutes on a narrower scope to under 6 minutes covering everything: 83% faster.The hard part was never the alerting logic. It was making five systems that don't know each other exist, answer one question together.
That's the problem I got pulled in to solve. Not "detect more fraud.", but resolve what's already there.
The real work is the resolution, not the dashboard
Nobody asked me for a smarter alert model, and there's a reason for that: alerting was never the bottleneck. The bank could already flag a suspicious card just fine. What it couldn't do was answer the next question fast, because that question crossed several schemas built years apart, for different jobs, before anyone had this use case in mind.
You can't always go back and re-key a decade of production systems around a question that nobody was asking when they were built. Sometimes that's a real option. Here, it wasn't. Not on the timeline a live fraud case gives you. So the answer had to live between the systems rather than inside them.
In practice, that meant a resolved trail an investigator could work from, built from what already existed instead of waiting for anyones roadmap’. Start with a card number, and every account it touches. Behind those accounts are customers. Behind the customers are every employee who looked at their records, every change anyone made, every network location that access came from. Same trail, resolved the same way, every run, including on the days the source files are a wreck. Which, in production, is most days.
I don't think about that trail as a script somebody runs at 2am and hopes for the best. I think about it as something that is operated: it has an owner (me, at the time), a defined shape (the shape of the resolved output, not the five shapes feeding into it), and it needs to keep answering when one of those inputs change without warning. Thats why the failure handling exists at all, rather than arriving as a bolt-on after after the first bad morning.
This is where it stopped being simple. Files went missing without warning. Fields appeared on some dates and vanished on others. The same customer identifier showed up in three different shapes depending on which system exported it. The system I relied on for network attribution restructured itself partway through the year with no changelog or heads-up. Any one of those kills something that assumes clean input. So I didn't build something that assumes clean input. I built something that assumes the sources will disagree with themselvesin a new way every month: fallbacks for missing files, tolerance for formats that disagree with each other, and checks that catch drift before it quietly becomesa wrong answer.
Scale turned all of that up. One reference table alone held over two billion records. If read the wrong way, the job dies before it starts. What got us through was pulling exactly what's needed, in the right order, across months of daily files, for dozens of flagged cards at once. Nobody notices this kind of work when it holds. Investigators notice immediately when it doesn't.
The numbers, once it actually resolved
One investigation, 31 suspicious cards, a two-month window.
Before this existed, that meant days of hand-assembly across multiple teams before anyone could even start reviewing evidence. That was the bottleneck. By the time it landed on someone's desk, the window to act on it had usually already closed.
With the resolver running, that same investigation returned 5,249 account access events, customer-information changes on 2 accounts attributed to 2 named employees on specific dates, and network sessions resolved to named individuals through IP resolution. One traildated and named, in a shape an investigator can work from.
The time to answer dropped from over 35 minutes on a narrower scope, to under 6 minutes on everything. That's 83% faster. In practice, an investigator can run it, follow a lead, widen the scope, and run it again while the trail's still warm.
Two caveats, because I'd be annoyed if someone glossed over them: these numbers come from one investigation window, not an average. And under 6 minutes is how long it takes to resolve the trail, not how long it takes to close the case. Judgment, escalation, and legal follow-through still take as long as they should.
Speed without reliability doesn't stick around
What I'm actually proud of is the combination, not either half. Speed by itself is a demo. Reliability alone is a slow tool people use because they have no other option. Together, a fraud team can open a case and assume the trail will be there.
Real operational data breaks assumptions constantly. This handles that by expecting it, not by hoping the environment stays still. When a file goes missing, a fallback takes over. Formats disagree, the run still finishes. Something shifts that shouldn't have? It gets flagged. Nobody throws a party for that behavior, and it's exactly why investigators kept using the tool instead of giving up on it after the first bad run.
Consistency did something I didn't fully expect. The case stopped depending on which analyst remembered which extract to pull. The same trail, the same shape, built from the same joins. The knowledge stopped living in one person's head.
What I'd ask if I were sitting on the fraud side of the table
If your fraud or risk team still answers "who touched this account?" by hopping between five systems and exporting files by hand, you don't need a better detector.
You need the data you already collect, resolved reliably enough that an investigator can move in minutes instead of days.
And that join has to survive messy files, silent source changes, and billion-row reference tables. If it only works on a good day, it won't survive its first week in production.
Six things I'd tell you upfront
Treat the resolution as an asset, not a one-off script. Give it an owner, a defined shape, and a way to notice when its inputs change under it. Sharing somebody ran once at 2am doesn't survive the second source change.
Design for messy data as the default case. Fallbacks, format tolerance, and drift checks from day one. Adding them after the first broken run is how fragile pipelines stay fragile.
Test against production-scale reference data early. Something that resolves cleanly on a 10,000-row sample fallsstraight over the first time it meets a billion-row file. Find that out in week two, not in front of an investigator.
Separate "the resolution is correct" from "the resolution is usable." A technically accurate trail that lands asfive disconnected CSVs is still a failure if the investigator can’t read it in under a minute.
Measure runtime to answer on the full scope, not a shrunk pilot. An 83% improvement only means something because the after-number covers more than the before-number did. Watch for teams that trim scope without saying so to hit a target time.
Standardize the output shape before you standardize anything else. Consistency in the report is what lets the tool survive analyst turnover. Something that produces a different-looking answer every run just moves the tribal-knowledge problem.
Where this leaves things
It’s is still running. Every morning, however messy the source files decide to be that day, the same trail resolves, and nobody has to think about it until an investigator actually needs it.
That's the whole point, and it's a smaller point than it sounds like. Not "look how clever the resolution is." Just: when someone finally asks who touched that account, there's already an answer waiting instead of a week of Slack messages and five separate exports.
If you're sitting on a version of this problem, five systems, one investigator, and no shared key between any of them, reach out to our team.
