Catching transactions that do not fit the pattern
payments business · Gulf
The shape of this problem
The same judgment, made differently every time
This is one of our own builds, not a client engagement. It is capability evidence and it is described as such.
The problem
Payment teams needed to identify unusual transactions in highly imbalanced data without overwhelming investigators with false alerts. Imbalance is what makes this deceptive: a model that flags nothing is over 99% accurate, so headline accuracy is not merely uninformative but actively misleading. The binding constraint is also not detection but investigator capacity - an alert nobody has time to open is indistinguishable from an alert that was never raised.
What we built
We built an anomaly-detection service over credit-card transaction data using preprocessing, feature scaling, isolation-based models, evaluation against labeled events, and configurable risk thresholds feeding review queues.
What moved
| Measure | Before | After |
|---|---|---|
| High-risk transaction detection | † | up 25% |
| False-positive alerts | † | down 20% |
| Initial screening time | † | down 55% |
† Measured against the prior level of the same measure. The source publishes the size of the movement, not the figure it moved from.
High-risk transaction detection
Measured against the client's own prior process, indexed to 100. The source publishes the size of the movement, not the absolute figure it moved from.
False-positive alerts
Measured against the client's own prior process, indexed to 100. The source publishes the size of the movement, not the absolute figure it moved from.
Initial screening time
Measured against the client's own prior process, indexed to 100. The source publishes the size of the movement, not the absolute figure it moved from.
Figures are drawn from the practice's own delivery records for the engagement named, measured against the process that preceded it. They have not been through third-party audit, and none is presented as an average across clients.
What it turned on
The service kept its own boundary explicit. Feature anonymisation is a privacy control, and it constrains how fully a score can be explained - so the output drives prioritisation and threshold policy, while acting adversely on a customer still requires interpretable customer, merchant, device, and transaction evidence.
- Service line
- Risk & Anomaly Detection
The weakest line we list. Do not build a pitch on it. It is a legitimate answer when a prospect raises it, and it belongs in a T1 scope rather than a proposal.
Start here
Which of the four is yours?
Tell us the documents and the monthly volume and we will send the two closest records, with the proof behind each and the honest note where the match is partial.
You get a reply within one working day, from the engineer who would do the work - not a sales sequence.