Transaction Fraud Is a Pattern, Not an Event: The Case for Behavioural Monitoring
Most fraud systems are built to answer a question about a single transaction: is this one suspicious? Amount, time, location, beneficiary, velocity, score them, and if the score crosses a line, act. It’s an intuitive way to think about fraud, and for crude fraud it works.
The trouble is that serious fraud isn’t a single transaction. It’s a shape across many of them, deliberately built so that no individual transaction looks wrong. If you only ever examine transactions one at a time, you are, by design, looking at fraud in exactly the way it was engineered to survive.
The structuring problem, in one example
Take structuring, splitting activity to stay under a threshold. A launderer who needs to move a large sum doesn’t move it in one transfer that trips every rule. They move it in many small transfers, each one comfortably below the reporting or review threshold, often across several accounts that don’t obviously relate to each other.
Now look at it through a single-transaction lens. Every one of those transfers is, individually, unremarkable. Small amount, plausible beneficiary, normal-looking timing. Each passes every per-transaction check, because each was specifically sized to pass. The fraud is completely invisible at the level of the individual event, and completely obvious the moment you look at the relationship between the events: the same total, broken into suspicious regularity, across accounts that share a device or a pattern.
The fraud didn’t hide. You were looking at it one piece at a time, and it only exists as a whole.
Why single-event scoring has a ceiling
This isn’t an argument that per-transaction scoring is useless. It catches the unsophisticated stuff, and there’s more of that than anyone would like. It should stay.
But it has a hard ceiling, and the ceiling is precisely the fraud that’s organised enough to matter. Mule networks (webs of accounts moving money between them to launder and obscure) are a pattern across accounts, not a property of any one transfer. Agent collusion in mobile money is a pattern over time: the agent whose commission keeps climbing while their genuine customer count stays flat. Account takeover is a pattern in sequence: the SIM change, the reset, the new beneficiary, the transfer. In each case the individual events are ordinary. The fraud is the arrangement of them.
A system that scores events one at a time cannot, even in principle, see an arrangement. It’s not a tuning problem you can solve with better thresholds. You’re asking a question about a single point when the answer only exists in the relationships between points.
What behavioural monitoring actually means
Behavioral monitoring is the shift from scoring events to scoring behaviour over time , building a baseline of what normal looks like for this customer, this account, this agent, this network of relationships, and detecting when the behaviour, not the transaction, departs from it.
Concretely, that means a few things working together. A per-customer baseline: this customer’s normal transaction sizes, times, locations, beneficiaries, so that “normal for them” is the reference, not a global threshold that treats everyone alike. Relationship awareness: which accounts move money to which others, so a mule network shows up as a structure rather than a set of unrelated transfers. And sequence awareness: the order and timing of events, so a takeover’s tell-tale chain is visible as a chain.
The payoff is twofold. You catch fraud that single-event scoring structurally cannot — the organised kind. And, less obviously but just as valuable, you cut false positives, because a transaction that looks alarming against a global threshold often looks perfectly normal against that customer’s own history. A large transfer is suspicious in the abstract; for a customer who makes large transfers every month, it’s a Tuesday. Behavioral baselining is how a fraud engine stops crying wolf.
Why this needs a particular kind of data foundation
Here’s the catch, and it’s the same catch behind most of these problems: behavioural monitoring is comparison against history, and history has to be both long and queryable at the moment of the decision.
A baseline built on a few weeks is a weak baseline, it can’t tell you this behaviour is abnormal relative to this customer’s last two years. And the comparison has to happen fast, in the flow of a transaction, against potentially years of history for that customer and their web of relationships. That combination (deep history, queryable in real time, across relationships) is exactly what a traditional transaction database struggles to provide affordably.
It’s what a data lakehouse is built for, and it’s the architecture Synaptique uses for behavioural fraud monitoring. Transaction history, and (critically for telecom and mobile money) the network signals alongside it, held at full detail in open storage the institution controls, queryable both for real-time scoring and for the pattern analysis that finds mule networks and collusion after the fact. Apache Kafka and NiFi bring the streams in; Apache Iceberg tables keep the deep history affordable to retain and fast to query. The point isn’t the component list, it's that behavioural monitoring is only as good as the history it can reach, and the architecture is what makes a long, rich, queryable history possible.
What it doesn’t do
Behavioral monitoring is not a model you switch on and walk away from. A baseline drifts, customers’ genuine behaviour changes, and the system has to relearn, or it starts flagging the new normal as anomalous. It needs maintenance and retraining, and anyone who tells you otherwise is selling.
It also doesn’t make single-transaction rules obsolete. The crude, obvious fraud is still most efficiently caught by a simple rule; keep those. Behavioral monitoring sits on top, for the organised fraud the rules can’t see. The two together are the system, not one instead of the other.
And it produces investigations, not convictions. A behavioural anomaly is a strong signal, not a verdict; a human still reviews the pattern and decides. What changes is that the queue is full of genuinely suspicious patterns instead of individually odd-looking transactions that mostly turn out to be fine.
Where to start
The most convincing first step uses fraud you’ve already confirmed. Take a set of confirmed fraud cases (ideally some organised fraud, a mule network or a structuring case) and look at whether the individual transactions in it would have tripped your current per-transaction rules. Usually, most of them wouldn’t have, individually. Then look at whether the pattern across them is visible. Usually it is, glaringly, in hindsight.
That exercise tells you, on your own confirmed cases, how much of your real fraud is pattern-shaped rather than event-shaped, which is the same as telling you how much your current approach is structurally built to miss.
Synaptique runs behavioural monitoring on an open lakehouse as a scoped engagement: your transaction history, your network signals where relevant, and the patterns your event-level rules don’t catch, shown on your own data. If you want to see what your single-transaction view is missing, that’s the conversation to have.