FraudLens: Real-Time Transaction Fraud
Ring-aware fraud scoring inside the authorisation window, where being correct and too late is the same as being wrong.
Client
Payments Processor, Card-Present and Online
Industry
Payments · Fraud Risk
Duration
7 months
Year
2025
Background
Rule-based screening fails in two directions at once. It produces false positives at a rate that trains staff and customers to treat a decline as noise, and it is structurally blind to coordinated fraud, where no individual transaction looks wrong because the pattern only exists across accounts. Meanwhile the decision has to be returned before the terminal gives up waiting.
The Challenge
Detecting rings means reasoning about relationships between entities, and reasoning about relationships means graph traversal, which does not fit inside an authorisation window. The naive architecture is correct and unusably slow. The second constraint is that every automated decline affects a real customer at a till, so a decision that cannot be reconstructed and explained afterwards cannot be defended when it is challenged.
Our Solution
SageWare built the scoring path and the graph that feeds it. Transactions arrive on a stream and are scored by a low-latency endpoint that combines transaction-level features with precomputed cluster membership from an entity-linkage graph maintained continuously off the critical path. Card data never reaches the scoring environment in readable form; account identifiers sit under format-preserving encryption so they stay joinable without being readable. Every score is emitted with the feature attributions that produced it, written alongside the decision rather than reconstructed later.
Key Deliverables
- Entity-linkage graph maintained off the critical path, leaving a lookup at decision time
- Scoring returned inside the authorisation window with ring context included
- Feature attributions written alongside every decision rather than recomputed later
- Drift monitoring and retraining built as standing components from the start
Results & Impact
How We Did It
01
Latency Budget First
Established what the authorisation window actually allowed before any modelling, because that figure determines which parts of the design can exist at all.
02
Graph Off The Hot Path
Built continuous entity-linkage maintenance as a separate concern, leaving only a cluster-membership lookup on the scoring path.
03
Scoring & Explanation
Deployed the scorer with attribution emitted alongside every decision, so a decline carries its own justification.
04
Drift & Retraining
Instrumented drift monitoring and a retraining cadence as standing components, on the assumption that patterns adapt because someone is adapting them.
Decisions & Trade-offs
The latency budget picks the architecture, not the other way round
Ring detection wants graph traversal and graph traversal does not fit in the authorisation window. So the graph is maintained continuously off the critical path, and what happens at decision time is a lookup against precomputed cluster membership. The consequence is that ring structure is marginally stale when the decision is made. A cluster formed in the last seconds is not yet visible. The alternative was being correct after the terminal had already given up, which in payments is indistinguishable from being wrong.
Write the explanation with the decision, not after it
Attribution can be recomputed on demand, which is cheaper and keeps the hot path lean. It also means the explanation you produce during a dispute is a reconstruction from a model that may since have been retrained, which is exactly the objection a challenged decline attracts. We write attributions at decision time and store them. It costs storage on every transaction, the overwhelming majority of which nobody ever asks about.
Retraining is a component, not a maintenance task
Most models degrade passively as the world moves. Fraud models degrade actively, because the people generating the patterns are responding to being caught. We treated drift monitoring and retraining as first-class parts of the system with their own budget and ownership, rather than something scheduled when accuracy visibly slips. It is a permanent operational load, and treating it as a project phase would have meant the system quietly decaying between reviews.
Scope & Boundaries
We built the streaming path, the scoring service, the entity-linkage graph and the explanation store. Card tokenisation happened at the client’s certified processor before data reached us. Decline thresholds and customer treatment were the client’s risk policy. We exposed the score and the reasoning, and did not set the cut-off.
Next Case Study
SentryFloor: Warehouse Safety Monitoring
Warehouse Operations · Safety