Financial services
Payments fraud detection with entity resolution
Fraud scoring that first works out who is transacting — because fraud is a property of the actor, not the transaction.
This page describes a problem class and the architecture we deploy for it, written against a named public benchmark — the open dataset or competition where the world's data scientists have tested approaches to this exact problem against a hard metric. It is not a client engagement, and the benchmark's results, prizes and rankings belong to its host and participants, not to us. Client work is confidential and is only ever published with written permission.
The problem
What it costs when this goes unsolved.
Card-not-present fraud sits at a few percent of volume, but the cost is asymmetric: every miss is a chargeback, and every false positive is a good customer declined at checkout — who often does not come back. Scoring transactions in isolation caps how well either number can get, because the fraudster's giveaway is behaviour across transactions, not within one.
Payments data arrives as hundreds of sparse, anonymised features per transaction, with the identities deliberately absent. The published state of the art on this problem was won by entity resolution: reconstructing stable actors from card, address and timing fingerprints, then aggregating behaviour per actor. It is also where the leakage risk concentrates — an entity feature built carelessly across the train/test boundary inflates validation and collapses in production.
How we build it
The architecture, stage by stage.
01
Entity resolution first
Stable actor identities reconstructed from card, device, address and timing signals — the layer that separates a production fraud system from a textbook classifier.
02
Behavioural aggregation per actor
Velocity, novelty and deviation features per resolved entity, each checked for time-consistency before it enters the model.
03
Imbalance handled honestly
Precision-recall-first evaluation with operating points priced in your chargeback and decline costs — never accuracy theatre on a 3% positive rate.
04
Adversarial validation for drift
Fraud shifts distribution constantly. Adversarial validation detects train/serve divergence before it becomes a bad quarter.
Model families on this problem class: Entity resolution · XGBoost / LightGBM ensembles · Adversarial validation · Stream scoring.
What you get
What an engagement hands over.
Everything below goes in the scope document before you sign it, with a fixed price or a rate with a ceiling — the same terms as every other engagement in the catalogue.
- A fraud-scoring service with an entity-resolution layer over your payment stream
- Operating thresholds priced in your actual chargeback and decline economics
- A review-queue integration that routes marginal scores to your analysts
- Drift monitoring tuned to how fast fraud patterns move in your channel
Provenance
The benchmark behind this page.
IEEE-CIS Fraud Detection, run by IEEE Computational Intelligence Society, on Vesta Corporation payments data, is the public proving ground for this problem class. The figures below are the host's, cited as context for how seriously this problem is tested in the open — they are not our results and we do not claim them.
How to buy this
The services this build draws on.
More proof
Next step
Thirty minutes on whether this fits your problem.
Bring the constraint — the regulator, the data boundary, the latency budget. If your data cannot support this build yet, the call will conclude with what to fix first, not with a proposal.