Correlating SIM-Swap Events with Wallet Transactions: Why It’s an Architecture Problem, Not an Analytics One
The mobile money fraud wallet platform is invisible not because it’s clever, but because the evidence is split across two systems that were never joined. If that’s true, the fix sounds simple, join them. This article is about why “just join them” is harder than it sounds, and what it actually takes.
Why this isn’t a quick integration
The instinct, hearing “correlate SIM-swap events with wallet transactions,” is to reach for an integration, a feed from the network team into the fraud system, a lookup, a flag. People try this, and it usually disappoints. Here’s why.
The two data worlds don’t share a key. The wallet thinks in accounts and MSISDNs. The network thinks in IMSIs, IMEIs, SIM serial numbers, cell IDs. Lining up “this transaction” with “this SIM swap” means resolving identities across systems that were never designed to be joined, where the same subscriber is represented differently on each side and the mapping itself changes over time, which is the whole point when a SIM swap is exactly a change in that mapping.
They don’t share a clock, either. Transaction events and signalling events arrive at different speeds, with different latencies, timestamped by different systems that may not even agree on the time. And the fraud signal is specifically about ordering in time , SIM swap, then reset, then beneficiary, then transfer. If you can’t reliably sequence events from two sources, you can’t see the pattern that is the fraud.
And they don’t share a retention window. Network teams keep signalling data for their own operational reasons, often briefly. Wallet platforms keep transactions far longer. A correlation that needs the SIM-swap event still to be available when the suspicious transaction happens (potentially days later)fails silently if the network event was already aged out. The evidence existed; it’s just gone by the time you need it.
So “join the two systems” runs straight into three structural mismatches: identity, time, and retention. A point-to-point integration between a fraud tool and a network feed tends to break on all three. That’s why this is an architecture problem, not an integration task.
What actually solves it
The approach that works is to bring both event streams into one store designed to hold them together, at full detail, long enough and keyed well enough that the sequence can be reconstructed. That is what a data lakehouse is for, and it’s the architecture Synaptique uses for exactly this.
Concretely: the network signals (SIM changes, device changes, authentication events, cell and location, roaming status) and the wallet events (transactions, beneficiary changes, credential resets) both land in one open store. On the Synaptique platform that’s Apache Kafka and Apache NiFi handling the streaming ingestion from each side, written into Apache Iceberg tables on storage the operator controls. Both streams, one place, kept at the event level.
Then three things become possible that the integration approach couldn’t deliver:
Identity gets resolved once, centrally, with history. Because the store keeps the full timeline of SIM-device-account relationships, it can answer “which account did this SIM belong to, at this moment” even across a swap, the mapping over time is itself the data, not a lookup that’s already been overwritten.
Events from both sides get sequenced on a common timeline. With both streams in one store, you can order a subscriber’s network events and wallet events together and ask the question that matters: did a SIM change, then a reset, then a new beneficiary, then a large transfer, within a tight window, from an unfamiliar cell? That’s one query against one store, not a fragile reconciliation across two systems.
History is retained on the terms the fraud needs, not the terms each source system happened to keep. The store holds the network events long enough to still be there when the suspicious transaction arrives days later. The correlation stops failing silently because the evidence is no longer aged out from under it.
The rule, once the data is joined, is simple
Here’s the irony worth dwelling on. Once both streams are in one place and sequenceable, the fraud logic is almost embarrassingly straightforward. A transfer above a threshold, within N hours of a SIM or device change on that line, with a credential reset in between, from a cell the subscriber hasn’t transacted from before; hold it and review it. That’s a rule a fraud analyst can write in an afternoon.
It was never catchable before, not because it was too subtle, but because no system held all four facts at once. Each fact was unremarkable alone; the sequence was the signal; and the sequence spanned two worlds. The architecture is what makes the simple rule possible. That’s the whole thesis: the intelligence was always within reach, the plumbing wasn’t there.
What this takes honestly, and what it doesn’t fix
Two honest caveats, because this isn’t magic.
It needs genuine cooperation between the network side and the mobile money side of the business. The data lives with different teams, and in some groups those teams barely speak. The architecture can join the data, but someone has to agree to let it be joined. In my experience that organisational step is harder than the technical one, and it’s worth naming up front rather than discovering it mid-project.
And it does not eliminate false positives, it reduces them. Legitimate SIM swaps happen constantly; people lose phones, upgrade devices, replace damaged SIMs. The correlation makes a legitimate swap distinguishable from a fraudulent one by the sequence and timing that follows, which is far better than treating every swap as suspect or every large transfer as suspect. But a legitimate customer can still trip the pattern, and a human still reviews the holds. What changes is that the review queue is now full of genuinely suspicious sequences instead of guesses from transaction data alone.
Where to start
The honest first step is a backward-looking one, and it’s cheap: take a period you’ve already lived through, pull your confirmed account-takeover fraud cases from that period, and check how many were preceded by a SIM or device change in the days before that nobody connected at the time. Line the network events up against the wallet events after the fact and count.
If almost none of your confirmed fraud had a preceding network signal, then your fraud genuinely lives in the transaction stream and you can stop here. In practice, for mobile money, that is not how the count comes back. It comes back high enough to change the conversation about what your fraud team should be able to see.
Synaptique runs that correlation as a scoped engagement: your network events and your wallet events, joined on your own data for one period, with the takeovers a sequence-based rule would have caught. It’s the cleanest way to find out how much of your fraud has been hiding in the seam between two systems.
If you want to measure that gap on your own data, that’s the conversation to have. Contact synaptique team.