Ask what data the model needs
A fraud model is only as good as the signals it receives: transaction history, device and network data, account relationships and confirmed outcomes. A serious vendor starts by auditing your data and labels, not by promising a detection rate.
Be cautious of any claim of near-perfect accuracy; fraud is rare and adaptive, so performance should be reported as fraud caught at a fixed review capacity and false positives among good customers.
Rules and machine learning together
The strongest systems combine clear rules for known patterns with a scoring model for subtle ones, and a review queue that feeds confirmed outcomes back as labels. Ask how the vendor handles the first weeks, when there is little labelled data, and how they run a model in shadow mode before it affects customers.
Latency, explainability and drift
Checkout decisions have to be fast, so ask for the latency budget and the fallback when scoring times out. Each decision should be explainable and logged for disputes and audits. Finally, ask how drift is monitored and how often models are retrained.
A scorecard for fraud detection vendors
Rate vendors on data readiness assessment, combination of rules and models, scoring latency, explainability, review tooling, drift monitoring and integration with your payment flow. Honest measurement should carry extra weight: a vendor who reports fraud caught at fixed review capacity and false positives is easier to trust than one quoting a single accuracy figure.
Fraud detection vendor comparison at a glance
| What to check | A strong answer | A warning sign |
|---|---|---|
| Data audit | Starts by reviewing your data and labels | Quotes before seeing any data |
| Approach | Rules plus models, with a review queue feeding back labels | Model only, or rules only |
| Measurement | Fraud caught at fixed review capacity, false positives reported | A single accuracy figure |
| Latency | States the scoring budget and the timeout fallback | No answer on timeouts |
| Monitoring | Tracks drift and retrains on schedule | Delivered once, never revisited |
Questions to ask in the first call
Ask what data they need, how they handle the first weeks with few labels, how a model runs in shadow mode, and what happens when scoring times out. Ask how an analyst can see why a transaction was flagged and how their decisions feed back into the system.
- Ask what data they need and how they handle the first weeks with few labels.
- Ask how a model runs in shadow mode before it affects customers.
- Ask what happens when scoring times out: fail open or fail closed.
- Ask how an analyst sees why a transaction was flagged.
- Ask how drift is detected and how often models are retrained.
Phases of a fraud detection project
A staged path works best: instrument and log decisions, ship a small set of owned rules, add a review queue with reason codes, train a first model in shadow mode, compare it with the rules, then let it influence decisions starting with the review queue. Each stage produces the data the next one needs.
Mistakes buyers make
Common mistakes are expecting a model to work without labelled history, tuning only for fraud caught while ignoring good customers declined, ignoring drift, and failing to decide whether a timeout fails open or closed. Each decision has a cost, and the right setting differs by product and amount.
How NNT Software approaches fraud detection
We build hybrid engines that combine your existing rules with supervised models behind a real-time scoring layer, validated in shadow mode before enforcement. We respond to every enquiry within 10 minutes, set up a meeting to understand your requirements, share a demo within 24 hours of that meeting, and then send a proposal that matches your budget.
We build the engine so that every decision is logged with its features and score, which lets your team explain and replay outcomes. A free 90-day defect warranty follows go-live and support can continue under an agreement.
Example scenario: reducing false declines in a payments flow
Illustrative scenario, not a client case: a payments business relies on fixed rules that block many genuine customers while some fraud still gets through. A careful project starts by collecting labelled outcomes, chargebacks and manual review decisions, and measuring today’s false-positive rate as a baseline.
A supervised model is then trained alongside the existing rules and run in shadow mode, scoring live transactions without acting on them. Once its precision beats the baseline on real traffic, it begins to approve or step up verification for a small share of transactions, with every decision logged with its features so analysts can explain and replay it.
Red flags to walk away from
Distrust any vendor who promises near-perfect accuracy or who cannot explain a single flagged transaction to your review team. Fraud is rare and adaptive, so honest reporting matters more than a headline number.
Also question a plan that switches a new model on for all traffic at once. A staged rollout, starting in shadow mode and then the review queue, protects good customers.
Build or buy, and what it costs
Off-the-shelf tools suit standard cases; a custom build suits unusual products or data. NNT Software’s rates are US$15–40 per hour, and the final charge depends on your data, integrations, timeline and the team assigned to the project.
Sources and further reading
More buyer guides
How NNT Software delivers projects like this
- Discovery — workshops, requirements and a written scope with a fixed estimate within days.
- Design — user flows, a clickable prototype and an architecture review before coding starts.
- Build — two-week sprints with demos, a shared backlog and code in your own repository.
- Test — dedicated QA, automated regression tests, performance and security checks.
- Launch — zero-downtime deployment, monitoring and user training.
- Support — SLA-backed maintenance and continuous improvement after go-live.