Fraud platform RFPs are often won on a demonstration of a polished case screen and a claimed detection rate, when what decides the outcome is how the platform performs on your own historical data, how fast it decides in the payment path and how many good customers it stops. This template gives you a ready-to-issue request for proposal for a fraud prevention platform: real-time event ingestion and decisioning, rules and machine learning models, device and behavioural signals, case management, consortium data, model governance and pricing per transaction or event. Requirements are numbered, typed and written so that each answer can be tested in a back-test and a proof of concept, then scored. It is vendor-neutral and written for fraud strategy and operations leads, risk and data science teams, security architects and procurement. For the market view, read the Fraud Prevention Platform Buyer's Guide; for the selection process, the Security Vendor Evaluation and RFP Guide.
How to use this template
- Replace text in square brackets, such as [Organisation], [events per second] and [payment rails], with your own details. Delete requirements that do not apply rather than leaving them unscored.
- Each requirement has an ID (for example FPP-DM-02) and a type: M mandatory (pass or fail), S scored (0 to 5, weighted) or I informational.
- Weights, volumes and latency targets in brackets are illustrative. Set them from your own losses, volumes and payment scheme rules before issue, and do not change them after responses arrive.
- Prepare a labelled, pseudonymised historical dataset before issue. The back-test in section 9 is the single most useful evidence you will get, and it takes weeks to prepare.
- Issue sections 1 to 9 to bidders. The Implementation guidance section is for your evaluation panel only.
- Ask for responses in a spreadsheet with one row per requirement ID and a documentation link for every "available now" answer.
1. Purpose and scope
[Organisation] invites proposals for a fraud prevention platform and associated services, to detect and prevent [account takeover, payment fraud, authorised push payment scams, application fraud, promotion abuse, money mule activity] across [online banking, mobile app, card, ecommerce checkout, contact centre].
- In scope: event ingestion from [channels]; real-time scoring and decisioning; rules authoring; machine learning models; device, network and behavioural signals; entity and link analysis; case management and alert handling; consortium or shared intelligence [if offered]; reporting; APIs.
- Out of scope: [identity verification at onboarding, procured separately]; [anti-money laundering transaction monitoring]; [chargeback management].
- Drivers: [fraud losses of value per year]; [reimbursement obligations for authorised push payment scams]; [false positive rate and customer friction]; [end of life of current rules engine].
- Contract term: [three] years with an option to extend by [two].
2. Organisation background and current state
| Item | [Organisation] value |
|---|
| Events per day and peak events per second, by type | [logins], [payments], [account changes], [applications] |
| Payment rails and schemes | [Faster Payments, CHAPS, SEPA Instant, card schemes, wallets] |
| Fraud losses by type, last 12 months | [value and count per type] |
| Current alert volume, analysts and false positive ratio | [number] / [number] / [ratio] |
| Current tools | [rules engine], [device intelligence], [case management], [data platform] |
| Decision latency budget in the payment path | [ms] at p99 |
| Regulatory drivers | [strong customer authentication and transaction risk analysis], [scam reimbursement rules], [consumer duty or equivalent] |
| Data residency requirements | [regions] |
3. Instructions to bidders
- Timeline: RFP issued [date]; clarification questions by [date]; responses due [date, time, time zone]; back-test [dates]; proof of concept [dates]; decision [date].
- Single point of contact: [name, email].
- Response scale: for each requirement state available now, available with configuration, requires custom development, third-party component, roadmap (committed date) or not supported. Roadmap answers score zero unless the date is contractual.
- Evidence: documentation page per answer; for any performance claim, the population, fraud type, period and how detection and false positive rates were measured. Claims without these details are not scored.
4. Functional requirements
4.1 Ingestion and real-time decisioning
| ID | Type | Requirement |
|---|
| FPP-DM-01 | M | Synchronous decision API returning allow, challenge, hold or decline with reason codes within [ms] at p99 at [events per second], demonstrated in the proof of concept. |
| FPP-DM-02 | S | Ingestion of arbitrary event types (login, profile change, payee added, payment, application) with a customer-defined schema and no vendor change request. |
| FPP-DM-03 | S | Customer, account, device, payee and counterparty profiles with real-time aggregates (velocity, first-seen, typical amount) available to rules and models. |
| FPP-DM-04 | M | Documented fail-open or fail-closed behaviour per event type if the platform is unreachable, configurable by [Organisation]. |
| FPP-DM-05 | S | Decision outputs that support a strong customer authentication exemption decision based on transaction risk analysis, where [Organisation] applies one, with the fraud rate monitoring against the reference fraud rates that Articles 18 and 19 of Delegated Regulation (EU) 2018/389 require. |
| FPP-DM-06 | S | Ability to trigger step-up through [customer identity platform] and to receive its outcome as an event. |
4.2 Rules and models
| ID | Type | Requirement |
|---|
| FPP-RM-01 | S | Rules authored by fraud analysts without code, with versioning, peer approval before publish, and simulation against historical data before go-live. |
| FPP-RM-02 | S | Shadow (champion and challenger) mode for rules and models, with side-by-side performance reporting. |
| FPP-RM-03 | S | Supervised models trained on [Organisation]'s labelled data, with documented retraining frequency and the labels required. |
| FPP-RM-04 | S | Explanations per decision: top contributing features in plain language for analysts and for customer complaint handling. |
| FPP-RM-05 | S | Model governance pack: design documentation, validation results, drift monitoring, bias testing and change log, suitable for [Organisation]'s model risk policy. |
| FPP-RM-06 | S | Support for importing [Organisation]'s own models and scores as features. |
See the Fraud Rules and Machine Learning Models Guide for rule and model design.
4.3 Signals and scam detection
| ID | Type | Requirement |
|---|
| FPP-SG-01 | S | Device intelligence for web and mobile: persistent device identifier, emulator, remote access tool and rooted or jailbroken device detection. |
| FPP-SG-02 | S | Behavioural signals (typing, navigation, hesitation, active phone call during a session) that indicate coaching or social engineering, with the consent and privacy basis described. |
| FPP-SG-03 | S | Account takeover detection: credential stuffing (ATT&CK T1110.004), new device plus credential change patterns, SIM swap or number port signals where available in [countries]. |
| FPP-SG-04 | S | Payee and beneficiary risk: first payment to a new payee, confirmation of payee result, inbound mule account indicators. |
| FPP-SG-05 | S | Graph or link analysis across customers, devices, payees and identifiers to expose mule networks and organised rings. |
| FPP-SG-06 | I | Describe detection of AI agent and automated traffic acting for customers, and how legitimate agents are distinguished from bots. |
See the Authorised Push Payment (APP) Fraud Guide and the Money Mule Detection Guide.
4.4 Case management and operations
| ID | Type | Requirement |
|---|
| FPP-CM-01 | S | Alert queues with prioritisation by risk and value, service level timers, assignment and four-eyes approval for releases above [value]. |
| FPP-CM-02 | S | Single case view of customer, events, devices, linked entities and previous cases, with analyst notes and outcome labels that feed models. |
| FPP-CM-03 | S | Reimbursement and claim workflow for scam cases, including evidence capture and timers aligned to [Organisation]'s reimbursement obligations, and data exchange with the receiving payment service provider. |
| FPP-CM-04 | S | Customer contact integration (in-app message, SMS, call back) for confirming held payments, with outcomes recorded. |
| FPP-CM-05 | S | Reporting on detection rate, value detection rate, false positive ratio, alert handling time and losses by type, at the definitions [Organisation] sets. |
See the Fraud Operations and Case Management Guide and the Fraud Metrics and KPIs Guide.
4.5 Consortium and shared intelligence
| ID | Type | Requirement |
|---|
| FPP-CO-01 | I | Describe any consortium data: which data elements [Organisation] would contribute and receive, how they are pseudonymised, the legal basis and how contributions can be withdrawn. |
| FPP-CO-02 | S | Ability to consume [Organisation]'s existing industry data sharing feeds as signals. |
| FPP-CO-03 | M | No use of [Organisation]'s data to benefit other customers beyond the documented consortium terms without written agreement. |
5. Data protection and model governance
| ID | Type | Requirement |
|---|
| FPP-DP-01 | M | Event data, profiles, models and case data stored and processed only in [regions], including backups, logs and support access. |
| FPP-DP-02 | S | Configurable retention by data type with automatic deletion. |
| FPP-DP-03 | S | Support for [Organisation]'s data protection impact assessment, including for behavioural and device data and automated decisions with significant effects. |
| FPP-DP-04 | S | Field-level controls so analysts see only the data needed, with masking of payment card and account data. |
| ID | Type | Requirement |
|---|
| FPP-PS-01 | M | Independent assurance: [ISO/IEC 27001 certificate, SOC 2 Type II report, PCI DSS attestation if card data is processed], plus a penetration test summary. |
| FPP-PS-02 | M | Contractual availability of at least [99.95%] for the decision API, active-active across [regions], with service credits and status history. |
| FPP-PS-03 | S | Console access through [identity provider] with phishing-resistant MFA; separation of rule authoring, rule approval and data export roles; full audit of rule and model changes. |
| FPP-PS-04 | S | API credentials scoped per channel and environment, rotatable without downtime, with mutual TLS or signed requests. |
| FPP-PS-05 | S | Alerts, decisions and audit events streamed to [SIEM] and [data platform] in near real time. |
| FPP-PS-06 | S | Vendor staff access to tenant data requires customer approval, is time-bound and logged. |
A rule change is a production change that can block payments or release fraud. The approval and audit controls in FPP-PS-03 matter as much as model accuracy.
Vendor security questions
- How do you stop a rule or model change from reaching production without approval, including changes made by your own staff?
- How is customer event data separated between tenants, and between tenant data and consortium data?
- Which of your staff can view customer event or case data, under what approval, and how is that access logged and reported to us?
- How are device and behavioural SDKs protected against tampering and replay, and how are their updates signed?
- What happens to scores if an attacker learns your reason codes or probes the decision API repeatedly?
- Describe any security incident in the last [three] years that affected customer data, and the notification you gave.
- Which subprocessors receive event, device or behavioural data, and in which countries?
- How quickly are vulnerabilities in the platform and SDKs fixed, and how are customers told?
7. Implementation and support
- FPP-IM-01 (S): implementation plan with data integration, rule migration and model training phases, and named staff.
- FPP-IM-02 (S): fraud consulting or managed rule service [if required], with the staff experience offered.
- FPP-IM-03 (S): [number] references in the same sector and payment rails.
- FPP-IM-04 (S): support with 24x7 cover for decision API incidents and response times by severity.
- FPP-IM-05 (M): exit: export of rules, case data, labels and event history in a documented format.
8. Pricing schedule
| Cost element | What to state |
|---|
| Pricing metric | Per event scored, per transaction, per account or per value protected; which event types are chargeable |
| Modules | Price for device intelligence, behavioural signals, consortium data, case management and model services |
| Volume model | Total cost at [current], [1.5x] and [3x] event volumes over the term; minimum commitments; cap on renewal increases |
| Performance-linked terms | Any fee linked to fraud losses avoided, and how avoided loss is measured |
| Services | Implementation price, day rates, managed service fees |
9. Evaluation method and proof of concept
| Criterion | Weight | Evidence |
|---|
| Detection performance on [Organisation] data (4.2, 4.3) | [30%] | Blind back-test results |
| Real-time decisioning and resilience (4.1, 6) | [15%] | Latency and failover test |
| Case management and operations (4.4) | [15%] | Analyst trial |
| Governance, data protection and security (5, 6) | [15%] | Governance pack, assurance reports |
| Three-year cost (8) | [25%] | Pricing schedule |
Scores: 0 not met; 1 roadmap only; 3 met with configuration; 5 met and demonstrated. Evaluation runs in two stages:
- Blind back-test: provide [months] of pseudonymised events with labels withheld for the final [months]. Bidders return scores per event; [Organisation] calculates detection rate, value detection rate and false positive ratio at a fixed alert budget of [alerts per day].
- Latency test: replay events at [events per second] and record p50, p99 and error rates.
- Analyst trial: [number] analysts work a queue of historical cases and rate the case view and time per case.
- Rule change test: author, simulate, approve and publish a new rule; confirm the audit trail.
- Failure test: simulate platform unavailability and confirm the configured fail-open or fail-closed behaviour.
- Data handling: confirm deletion of all proof of concept data at the end.
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Compare at a fixed alert budget: detection rates mean nothing unless measured at the same number of alerts your team can actually work.
- Keep the back-test blind: withhold labels for the test period, or bidders will tune to them.
- Price on events, not transactions: logins and profile changes often outnumber payments; check which are chargeable.
- Score friction explicitly: record the challenge rate and the share of challenged customers who were genuine in the back-test, and weight it alongside detection. A platform that stops more fraud by challenging far more good customers moves cost into complaints and abandonment.
- Protect the platform's own credentials: decision API keys and console administrator accounts can switch off controls across every channel. Inventory them, scope them and rotate them like any other privileged machine credential.
- Bring model risk in early: the governance pack in FPP-RM-05 often takes longer to approve than the integration takes to build.
- Know your reimbursement rules: in the UK, authorised push payment scam reimbursement covers Faster Payments and CHAPS, with most victims to be repaid within five business days and costs shared equally between sending and receiving firms, according to the Payment Systems Regulator. Case workflow must meet those timers.
Common failure patterns
- Demo data decisions: selection based on a vendor's showcase dataset rather than a blind test on your own events.
- Ignoring friction: a platform that blocks more fraud by challenging far more good customers raises complaints and abandonment.
- Uncontrolled rule changes: analysts publish rules straight to production with no simulation or approval.
- Latency discovered late: the decision API meets the budget in a test, then adds seconds at peak in the payment path.
- Labels never fed back: case outcomes are not recorded consistently, so models never improve after go-live.
Framework mapping
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|
| Real-time detection and signals (4.1, 4.3) | SI-4 | DE.CM-09 |
| Case management (4.4) | AU-6 | DE.AE-02 |
| Account takeover controls (4.3) | IA-2, IA-8 | PR.AA-02 |
| Data protection (5) | PT-2 | GV.SC-06 |
| Supplier assurance (6, 7) | SA-9, SR-6 | GV.SC-06 |
Standards and references
Related NHI Mgmt Group resources: Fraud Prevention Platform Buyer's Guide · Transaction Monitoring and Behavioural Biometrics Guide · Account Takeover Prevention Guide · Identity Verification RFP Template