Fraud platforms are usually chosen on a vendor's headline detection rate, then judged in production on something else: how many good customers they block, how fast they answer and whether analysts can explain a decision. The category covers device and behavioural intelligence, transaction scoring, account protection, case management and consortium data, sold as point products or as one decisioning platform. Labels such as "fraud prevention", "risk decisioning" and "trust and safety" overlap, so the use cases, signals and integrations matter more than the name. This vendor-neutral buyer's guide is for fraud, payments, digital identity and security leaders writing requirements or running a selection. It covers what to define first, the criteria to score, the questions that expose weak answers, the red flags and a proof of concept based on your own historical data.
Key takeaways
- Start from your fraud losses, not the feature list. Rank use cases by money and customer harm: fake account opening, account takeover, card-not-present payments, authorised push payment scams, promotion abuse.
- Measure the cost of false positives. Declined good customers, step-up friction and manual review time often cost more than the fraud stopped. Score every vendor on both sides.
- Explainability is a requirement, not a nice to have. Analysts need reason codes, customers may have a right to challenge automated decisions, and model changes need governance.
- Signals decide accuracy. Device, behavioural, network, identity and consortium data each catch different attacks, and each brings its own privacy obligations.
- The platform is a privileged insider. It sees customer data, can block payments and accounts, and holds API credentials into your payment, identity and case systems. Secure it accordingly.
Define requirements
Agree the following internally before vendor demos, and write them into the RFP.
- Use cases and decision points: where the platform must score (onboarding, login, profile change, payee creation, payment, refund, promotion redemption) and what it must return at each point: allow, step up, hold, decline or refer.
- Latency and volume: the time budget at each decision point (a login or payment authorisation path may allow only a few hundred milliseconds), peak transactions per second and the behaviour you want if the platform times out (fail open or fail closed).
- Loss baseline: fraud losses, chargebacks, reimbursements, manual review hours and false positive rate by use case for the last 12 months. Without a baseline you cannot measure the platform.
- Regulatory context (brief, not legal advice): in the UK, the PSR's APP scam reimbursement requirement (live since 7 October 2024, up to £85,000 per claim, cost split 50:50 between sending and receiving firms) makes inbound mule detection as valuable as outbound scam detection. Under PSD2, the SCA RTS Article 18 transaction risk analysis exemption depends on real-time risk scoring and on keeping your fraud rate under Annex reference rates (for remote card payments 0.13% up to EUR 100, 0.06% up to EUR 250, 0.01% up to EUR 500). See the Authorised Push Payment (APP) Fraud Guide and the Payment Fraud Guide.
- Privacy: lawful basis for profiling (GDPR Recital 47 recognises processing "strictly necessary for the purposes of preventing fraud" as a legitimate interest), whether any decision is solely automated with significant effects under Article 22, data residency and retention, and a DPIA before go-live.
- Build, buy or both: whether you have data scientists and engineers to run your own models, or want vendor models with your own rules on top.
| Use case | Key signals | Typical action | Related guide |
|---|---|---|---|
| Account opening and synthetic identity | Identity data checks, document and liveness results, device reputation, email and phone age, velocity across applications | Approve, step up to stronger verification, refer | Identity Verification Buyer's Guide |
| Account takeover | Device change, impossible travel, credential stuffing patterns, session behaviour, recovery and profile changes | Step-up authentication, session kill, hold sensitive changes | Account Takeover Prevention Guide |
| Card-not-present and payments | Transaction history, amount and merchant patterns, device, 3-D Secure outcome, payee risk | Frictionless approval, challenge, decline | Payment Fraud Guide |
| APP scams and mules | New payee plus unusual amount, remote access tools in session, coached behaviour, inbound funds rapidly moved out | Warning, delay, call-back, hold inbound funds | Authorised Push Payment (APP) Fraud Guide |
| Promotion and bot abuse | Device and network clustering, automation signals, account linkage, redemption velocity | Block, limit, rate control | Bot Management Guide |
Evaluation criteria
An illustrative weighting is 30% detection on your data (including false positives), 20% signals and data, 15% decisioning and explainability, 10% case management, 10% integration and latency, 15% security, privacy and commercial terms. Adjust it to your use cases.
| Criterion | What good looks like | Weak signs |
|---|---|---|
| Signals | Device intelligence resilient to emulators and spoofing, behavioural biometrics, IP and network reputation, identity data, and optional consortium data with a clear statement of what you contribute and receive | One signal sold as the whole answer; no detail on how consortium data is collected or shared |
| Decisioning: rules and ML | Rules engine analysts can change safely, supervised and unsupervised models, champion and challenger testing, shadow mode, simulation of a rule against history before release | Black-box score only; rule changes need a vendor ticket |
| Explainability | Top contributing features or reason codes per decision, readable by an analyst and usable in a customer explanation | A score with no reasons |
| Model governance | Documented features, training data and validation; drift and performance monitoring; outcomes analysis against confirmed fraud; change log; independent challenge in line with long-standing model risk guidance such as the US SR 11-7, which says validation applies equally to vendor models | "Our model retrains itself" with no monitoring or approval step |
| Case management | Queues by risk and value, linked-entity graph view, full event timeline, disposition labels that feed back into models, SAR and reporting exports, maker-checker for overrides | Labels not fed back; alerts reviewed in spreadsheets |
| Latency and scale | Published p95 and p99 latency at your peak volume, regional deployment, documented timeout behaviour, tested failover | Average latency only; no load test evidence |
| Integration | APIs and SDKs for web and mobile, payment gateway and core banking connectors, identity provider and CIAM hooks for step-up, streaming events to the SIEM and data lake | Batch-only feeds; no step-up integration |
| Privacy of behavioural data | Data minimisation, configurable retention, regional processing, no use of your customers' data for other clients without agreement, support for the DPIA | Vague answers on what behavioural data is captured and where it goes |
Explainability, profiling and the AI Act
A fully automated decline or account closure can be a decision with significant effects under GDPR Article 22. Recital 71 allows automated decisions where authorised by law "including for fraud and tax-evasion monitoring and prevention purposes", but expects safeguards such as human intervention, an explanation and a way to challenge the decision. The ICO notes that human review must be more than "a token gesture". Behavioural biometrics can be biometric data, and become special category data under Article 9 when used to uniquely identify a person, so check how the vendor uses them. Under the EU AI Act, Annex III point 5(b) lists credit scoring as high-risk "with the exception of AI systems used for the purpose of detecting financial fraud", but a fraud platform that also feeds credit or eligibility decisions needs separate assessment.
The platform's own access
A fraud platform receives customer identity, device and payment data in real time, and its decisions can block payments or lock accounts. It also holds API keys, OAuth clients and service accounts for your payment gateway, identity provider and case systems. Require SSO with phishing-resistant MFA for analysts, role separation between rule authors and approvers, a full audit trail of rule and model changes, least-privilege and rotated integration credentials, and alerting on bulk data export. An attacker or insider who can edit a rule can quietly allowlist their own mule accounts. See the Service Account Security Guide.
Questions to ask vendors
- Will you score our labelled historical data blind, and report detection rate and false positive rate at several thresholds, with the cost of each?
- What are your p95 and p99 latencies at our peak volume, and what does the API return when you time out?
- Show the reason codes for a declined transaction and how an analyst would explain it to a customer.
- How are models trained, validated, monitored for drift and approved for release, and can we see the change log?
- If we join your consortium, what data do we contribute, who else sees derived signals, and how is that covered in the contract and our privacy notice?
- What behavioural and device data does your SDK collect, where is it processed, and how long is it kept?
- How do you support the PSD2 transaction risk analysis exemption and APP scam detection on inbound payments?
- How are analyst access, rule changes and integration credentials controlled and logged? Can we stream your audit log to our SIEM?
- What does pricing count (API calls, transactions, accounts, modules), and how does cost change at twice our volume?
Red flags
- Detection claims based only on the vendor's own data, with no false positive figures.
- Scores with no reason codes, or model updates pushed without notice or approval.
- Refusal to run in shadow mode before going live.
- Consortium terms that let your customers' data train models for others without clear agreement.
- No answer on behavioural data retention, residency or the DPIA.
- Shared analyst accounts, no maker-checker on rule changes, or no exportable audit log.
- Pricing that penalises scoring more events, which pushes you to skip decision points.
Proof of concept
- Prepare the data: extract 6 to 12 months of events with confirmed fraud and good-customer labels for two priority use cases. Pseudonymise where possible and agree a data processing addendum before sharing.
- Run a blind retrospective test: vendors score the history without seeing labels. Compare detection, false positives and value detected at the same review capacity.
- Go live in shadow mode: send real traffic for four to six weeks, take no action on the score, and compare with your current controls and confirmed outcomes.
- Test operations: have analysts work real alerts in the case manager, write and simulate a new rule, and check reason codes and feedback loops.
- Test resilience and security: load test at peak, force a timeout, review analyst roles and the audit log, and confirm integration credentials are least privilege.
- Roll out in stages: start with one channel or a small traffic share using step-up rather than decline, then widen. Keep the old controls ready to restore until the new platform has met agreed thresholds.
Track a small set of numbers from day one: fraud losses per use case, false positive rate and good-customer insult rate, manual review rate and time to decision, p99 latency, and the share of decisions with usable reason codes. See the Fraud Prevention Guide for Digital Businesses. MITRE's Center for Threat-Informed Defense has also published the Fight Fraud Framework (F3), which extends the ATT&CK model to cyber-enabled financial fraud and can help structure test scenarios.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support for fraud, customer identity and identity security platforms. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Fraud Prevention Guide for Digital Businesses · Account Takeover Prevention Guide · Authorised Push Payment (APP) Fraud Guide · Payment Fraud Guide · Bot Management Guide. This guide summarises regulatory points for buyers and is not legal advice.