What a Payment Fraud Detection System actually does
Scores each payment transaction in real time using ML risk signals (velocity, device, geo, BIN) and generates a plain-English explanation of why a transaction was flagged — enabling fintech operators to take confident risk decisions without a data-science team.
The core is classical ML, not an LLM: XGBoost or LightGBM models trained on velocity features, device fingerprints, geolocation signals, BIN-level risk scores, and graph-based account-link detection produce a risk score (0–100) per transaction in <100ms. The LLM role is narrow: Claude Sonnet 4.6 ($3/$15 per M tokens) generates a single-paragraph explanation of the top risk factors for flagged transactions — enabling a non-data-scientist merchant ops team to act confidently. Cost per transaction: ~$0.005 for the LLM explanation + ~$0.001 for classical ML inference = ~$0.006/transaction, orders of magnitude below Sift's $0.005–$0.015/event at enterprise pricing.
In 2026, fraud detection is the Finance & Fintech cluster's most capital-intensive build — PCI DSS 4.0.1 required all 51 future-dated requirements to be in place by March 31, 2025, including MFA for all cardholder data environment access, 12-character minimum passwords, payment-page script integrity (Req 6.4.3), and anti-skimming tamper detection (Req 11.6.1). SOC 2 Type II is table stakes for any PSP or fintech contract. Combined with FCRA adverse-action notice requirements if your model's output is used to deny credit, the compliance scaffolding exceeds the ML cost by 10×.
AI capabilities involved
Real-time transaction risk scoring (velocity, device, geo, BIN)
Graph-based account-takeover detection
LLM-generated fraud flag explanation for merchant ops
Document verification on KYC (ID OCR + selfie match)
Chargeback dispute auto-drafting
Who uses this
- Fintech founders building a payment service provider (PSP) or marketplace with first-party fraud exposure
- Marketplace platforms (B2B, consumer) where third-party seller fraud is the primary risk vector
- Chargeback-guarantee resellers building a liability-guarantee model on top of ML risk scoring
- Enterprise SaaS operators who process payments directly and cannot rely solely on Stripe's fraud signals
SaaS alternatives on the market
Real products you can sign up for today — with current 2026 pricing, honest pros and cons.
Sift
Fintechs in validation phase ($1M–$10M/mo GMV) who need production-grade fraud detection before they have enough transaction data to train their own model.
$0.005–$0.015/event (enterprise quote, volume-based)
Pros
- +Industry-leading feature engineering on device, velocity, and behavioral signals.
- +Managed model updates as fraud patterns evolve — no in-house data science required.
- +Dispute evidence generation for chargebacks included on higher plans.
- +Long track record with major marketplace and fintech clients.
Cons
- −No white-label tier — your merchants interact with Sift-branded interfaces and decisions.
- −Black-box model makes it difficult to explain flagged transactions to merchants or card networks.
- −Enterprise pricing requires 12-month contracts and volume commitments.
- −Model is not tuned to your specific merchant vertical — false-positive rates vary widely by industry.
Riskified
High-average-order-value ecommerce businesses ($200+ AOV) where the chargeback liability guarantee justifies the 0.6–1.5% fee.
0.6–1.5% of GMV (chargeback guarantee model)
Pros
- +Chargeback guarantee: Riskified absorbs the chargeback cost on approved transactions.
- +Revenue uplift: approve more borderline transactions because liability transfers.
- +Deep ecommerce optimization across 100M+ transactions for benchmarking.
- +Automated dispute representation included.
Cons
- −At 1% of GMV, a $10M/mo marketplace pays $100K/mo — $1.2M/yr to Riskified.
- −Guarantee model creates misaligned incentives: Riskified may approve high-risk transactions where their model confidence exceeds their chargeback exposure.
- −No white-label; merchants know they're using Riskified.
- −GMV-based pricing makes cost unpredictable as your volume grows.
Sardine
Crypto and digital-asset platforms that need combined KYC + AML + fraud in a single vendor without building three separate compliance integrations.
$0.05–$0.20/event (KYC + fraud combined; enterprise quote)
Pros
- +Combined KYC + fraud detection in a single API — fewer vendor integrations.
- +Behavioral biometrics layer (typing speed, tap pressure) adds device-level signal.
- +Crypto fraud specialization useful for digital-asset PSPs.
- +Strong compliance tooling for OFAC screening.
Cons
- −Higher per-event cost than Sift for pure fraud scoring at scale.
- −No white-label tier; enterprise-focused with longer sales cycles.
- −Crypto specialization is a niche fit — general ecommerce fraud detection may be weaker.
- −Pricing model is not transparent without direct sales engagement.
The AI stack
Fraud detection requires three layers: real-time ML inference (<100ms latency), graph analysis for account-link detection (batch acceptable), and LLM explainability for merchant ops (non-real-time). The ML layer is 99% of the value; the LLM is 1% of the cost.
Real-time risk scoring (classical ML)
Score each transaction in <100ms based on velocity, device, geography, BIN data, and account history.
XGBoost on Redis feature store
~$0.001/transaction (compute amortized)Any fintech with structured transaction data (amount, merchant, device, geo) and enough labeled chargebacks to train a supervised model.
LightGBM with gradient boosting
~$0.001/transaction (compute amortized)High-volume processors (10M+ transactions/mo) where training speed and inference throughput are constraints.
Our pick: XGBoost with Redis feature store for most fintechs — SHAP values enable the LLM explainability layer and satisfy FCRA adverse action documentation. Switch to LightGBM only at very high volume (10M+ transactions/mo) where training time is a weekly operational constraint.
LLM fraud explanation
Generate a merchant-readable explanation of the top 3 risk factors that drove the fraud score for each flagged transaction.
Claude Sonnet 4.6
$3/$15 per M tokens (~$0.005 per explanation)Fraud explanations that may be surfaced in FCRA adverse action notices or regulatory examinations — Sonnet's conservative phrasing is defensible.
GPT-5.4 mini
$0.75/$4.50 per M tokens (~$0.0015 per explanation)High-volume explanation generation for internal merchant dashboard use where FCRA documentation is handled separately.
Our pick: Claude Sonnet 4.6 via AWS Bedrock for all fraud explanations — the audit log and FCRA documentation need defensible, conservative language. At $0.005/explanation and typical fraud-flag rates of 1–3% of transactions, cost is negligible.
Graph-based account-takeover detection
Identify shared email/phone/device signals across accounts that indicate organized fraud rings.
PostgreSQL graph queries on shared-attribute tables
~$0 (Supabase Pro compute)Fintechs under 1M accounts where SQL-based link analysis satisfies the use case without a graph database.
Graph neural network on Neo4j or Amazon Neptune
$200–$500/mo (Neptune Serverless) or $300–$800/mo (Neo4j AuraDB)Marketplace platforms with complex multi-seller fraud rings where 2+ hop connections are the primary attack vector.
Our pick: Start with PostgreSQL shared-attribute analysis — it catches 80% of account-takeover patterns at 10× lower infrastructure cost. Graduate to Neptune/Neo4j only when GMV exceeds $5M/mo and organized ring fraud becomes the dominant loss driver.
Reference architecture
The pipeline has three execution tiers: synchronous real-time scoring (<100ms per transaction during checkout), near-real-time graph analysis (batch job every 15 minutes on new account links), and async LLM explanation generation (triggered for transactions above the flag threshold). The hardest engineering challenge is maintaining <100ms latency on the synchronous scoring path while Redis feature store is warm — the first call on a cold feature set requires a database roundtrip that can exceed the SLA.
Transaction initiated at checkout
Merchant frontend → PSP API endpointMerchant sends transaction payload (amount, card BIN, device fingerprint, IP, user_id, merchant_id) to the fraud API synchronously before authorization.
Feature lookup from Redis feature store
Redis cache + PostgreSQL fallbackVelocity features (last 24h transactions per user/card/device/IP), BIN risk score, and account-age features are pre-computed nightly and cached in Redis; cache miss triggers a PostgreSQL fallback, adding ~20ms latency.
XGBoost risk scoring (<100ms)
Python inference service (FastAPI on ECS or Lambda)XGBoost model loaded in memory (no disk I/O on inference path); SHAP values computed per prediction for the top 3 risk factors; returns {risk_score: 0–100, risk_level: low/medium/high, top_factors: [{feature, direction, magnitude}]}.
Decision routing and response to PSP
Fraud API GatewayRisk score below threshold: auto-approve. Above upper threshold: auto-decline. In the middle: review queue. Response returned synchronously within 100ms SLA; transaction proceeds or is blocked in real time.
Async LLM explanation for flagged transactions
Trigger.dev async job → Claude Sonnet 4.6 (AWS Bedrock)For transactions in review queue or above decline threshold, a Trigger.dev job fires async to generate a merchant-readable explanation from the top 3 SHAP factors. Stored in fraud_explanations table; surfaced in merchant dashboard within 5 seconds of the synchronous decision.
Graph analysis batch job
Trigger.dev cron (every 15 min) → PostgreSQL shared-attribute queryLooks for new account links (shared device_id, email, phone, IP) created in the last 15 minutes; updates account_risk_scores with elevated graph risk if a new account matches existing fraud-ring members.
Merchant dashboard review and override
Next.js merchant portalMerchants see flagged transactions with LLM explanation, risk score, SHAP factors, and a manual Review/Approve/Decline control. All override decisions are logged with reviewer_id, timestamp, and override_reason for FCRA documentation.
Estimated cost per request
~$0.0065 per transaction (~$0.001 ML inference + ~$0.005 LLM explanation + ~$0.0005 KYC OCR). At typical fraud-flag rates of 2%, only 2% of transactions trigger the $0.005 LLM explanation — effective blended cost across all transactions = ~$0.0012/transaction.
Cost calculator
Drag the sliders to model your actual usage. The numbers update in real time so you can stress-test economics before writing a single line of code.
Modeled at 100,000 transactions per month with a 2% fraud-flag rate (2,000 flagged transactions requiring LLM explanations). ML inference cost is amortized into fixed infra.
Estimated monthly cost
$430
≈ $5,160 per year
Calculator notes
- ML inference cost (~$0.001/transaction) is amortized into the ECS/Lambda fixed line — variable cost only emerges above 5M transactions/mo.
- KYC document verification (GPT-5.4 nano at ~$0.0007/document) is only triggered on new account creation, not per-transaction — typically 1–5% of transaction volume.
- PCI DSS 4.0.1 compliance tooling (firewall logs, MFA enforcement, script integrity monitoring) adds $200–$500/mo in tooling costs not included above.
- PCI QSA assessor fees ($15K–$50K/yr) and SOC 2 audit fees ($20K–$50K/yr) are annual compliance costs — amortize to $2,900–$8,300/mo in the true TCO.
Build it yourself with vibe-coding tools
There is no viable DIY path for a production payment fraud detection system with real transaction data. If you want to prototype the fraud-explanation UI or test the XGBoost model logic, use synthetic data only.
Time to MVP
Not recommended for production — demo UI only in 1 weekend
Total cost to MVP
Prototype only: $25 Lovable Pro + $30 Anthropic credits (do NOT connect real card data)
You'll need
Starter prompt
Build a DEMO ONLY fraud detection dashboard UI. Use 100% synthetic/mock data — no real card numbers, no real transaction data. Dashboard features: - Transaction feed with real-time updates (simulated via Supabase Realtime on synthetic data) - Each transaction shows: amount, merchant, risk score (0–100), risk level badge (green/yellow/red) - Flagged transaction detail panel with: risk score visualization, top 3 risk factors with bars, AI explanation paragraph, approve/decline/review action buttons - Charts: transaction volume over time, fraud-flag rate by merchant category, false-positive rate by threshold setting - Settings: risk score thresholds for auto-approve/review/decline; per-merchant risk tolerance overrides Mock data format for transactions: {id, amount, merchant_name, merchant_category, risk_score (0-100), risk_level (low/medium/high), top_factors: [{name, direction, impact}], ai_explanation, timestamp, status} Tech stack: Vite + React + TypeScript + Tailwind + shadcn/ui + Supabase (mock data only) ADD PROMINENT BANNER: 'DEMO ONLY — Uses synthetic data only. Not PCI DSS compliant. Never use with real cardholder data.'
Paste this into Lovable
Follow-up prompts (run in order)
- 1
Wire up the AI explanation generator for the demo: in the Supabase Edge Function, call Claude Sonnet 4.6 with this prompt for each mock transaction: 'You are a fraud analyst explaining a risk score to a merchant operations team. A transaction was scored {risk_score}/100 (risk level: {risk_level}). Top risk factors: 1) {factor_1_name}: {factor_1_direction} impact ({factor_1_impact}); 2) {factor_2_name}: {factor_2_direction} impact; 3) {factor_3_name}: {factor_3_direction} impact. Write 2 sentences explaining what these signals mean in plain English. Do not claim the transaction is definitely fraudulent — frame as risk indicators for human review.' Display in the transaction detail panel.
- 2
Add a synthetic data generator: create a Supabase Edge Function that generates 100 realistic mock transactions per hour with varied risk profiles — 70% low-risk (score 0–30), 20% medium-risk (31–70), 10% high-risk (71–100). Use realistic merchant names, amounts ($10–$5,000), and risk factor combinations. Trigger via Supabase cron to keep the demo dashboard live and dynamic for prospect demos.
Expected output
A demo dashboard showing synthetic fraud scores, risk factor breakdowns, and AI explanations that sales prospects can click through — without touching any real cardholder data. This is sufficient to validate the product concept with potential PSP and fintech customers before committing to a $100K+ PCI-scoped build.
Known gotchas
- !PCI DSS 4.0.1 Requirement 6.4.3 requires that all scripts loaded on payment pages have documented justification, integrity verification (SRI hashes), and authorization — this requirement alone eliminates Lovable as a path for any production payment-adjacent system.
- !The FCRA adverse action notice requirement applies even if your fraud score is never presented as a 'credit decision' — any decision that 'adversely affects' a consumer's ability to obtain financial services triggers the adverse action notice obligation. Consult a FCRA attorney before going live.
- !XGBoost models trained on historical chargeback labels are known to exhibit proxy discrimination (disparately impacting minority groups through features correlated with race/geography) — a bias audit is mandatory before using the model for any consumer-facing decision.
- !SOC 2 Type II certification takes 9–12 months minimum (6 months observation period + 3 months audit) — PSP and fintech enterprise contracts typically require an in-progress SOC 2, not just a readiness assessment. Start the audit process before launch, not after.
- !AWS Bedrock's HIPAA BAA does not extend to PCI DSS compliance — PCI requires that LLM API calls that process or log transaction data (including the fraud explanation) are excluded from PCI scope or covered by a specific PCI-DSS-aligned API agreement with the AI vendor.
- !Redis feature store TTL must be carefully calibrated: too short (< 1 hour) and the cache miss rate drives PostgreSQL latency above the 100ms SLA; too long (> 24 hours) and the velocity features become stale, missing late-breaking fraud patterns.
Compliance & risk reality check
Payment fraud detection carries the finance cluster's heaviest compliance load — PCI DSS 4.0.1, SOC 2 Type II, and FCRA are all in scope simultaneously, with MiCA adding for crypto-adjacent use cases. The compliance scaffolding cost ($60K+) exceeds the ML development cost.
PCI DSS 4.0.1 — all 51 future-dated requirements mandatory since March 31, 2025
PCI DSS v4.0.1 added 51 future-dated requirements that became mandatory on March 31, 2025. Critical for fraud detection systems: Requirement 6.4.3 mandates that all scripts loaded on payment pages (including any fraud-scoring JavaScript) have documented authorization, justification, and integrity verification (SRI hash); Requirement 11.6.1 mandates tamper-detection mechanisms on payment pages. Any system that stores, processes, or transmits Primary Account Numbers (PANs) — even as part of a fraud-analysis pipeline — is in PCI scope.
Mitigation: Engage a PCI Qualified Security Assessor (QSA) before writing production code to define your cardholder data environment (CDE) scope. Minimize CDE scope by tokenizing all PANs before they touch your fraud-scoring pipeline — Stripe Radar's pre-authorization webhook pattern lets you score transaction attributes without storing the raw PAN. Budget $15K–$50K/yr for QSA fees.
SOC 2 Type II — required by PSP and fintech enterprise contracts
SOC 2 Type II certifies that your security controls operated effectively over a 6-month observation period, covering the Trust Service Criteria (Security, Availability, Confidentiality, Processing Integrity, Privacy). Acquirers and enterprise fintech clients universally require a SOC 2 Type II report before signing a fraud-detection API contract. The observation period means you cannot shortcut from signing a deal to having a SOC 2 — it requires 9–12 months of advance planning.
Mitigation: Start SOC 2 preparation simultaneously with development. Use Vanta ($18K–$30K/yr) or Drata ($20K–$40K/yr) for automated SOC 2 evidence collection. The SOC 2 audit itself costs $20K–$50K from a licensed CPA firm. Plan for initial SOC 2 Type I (point-in-time) after 6 months and Type II (operational period) after 12 months.
FCRA (Fair Credit Reporting Act) — adverse action notices
If your fraud score is used to deny a consumer a financial product (account opening, credit application, payment processing), the FCRA requires an adverse action notice specifying the reason for the denial. The definition of 'consumer report' under FCRA may extend to fraud scores if they are used in credit-decision workflows. The key risk: if a fintech client uses your fraud API output as part of their credit underwriting or account approval decision, your data becomes a 'consumer report' and both you and the fintech must comply with FCRA.
Mitigation: Restrict your API's use-case language to 'payment fraud risk' and not 'creditworthiness assessment.' Include contractual language prohibiting clients from using your fraud score in credit decisions without appropriate FCRA disclosures. Consult a FCRA attorney before launch — the definition of 'consumer report' is broader than most fintech founders expect.
GLBA Safeguards Rule — encryption and access controls
The Gramm-Leach-Bliley Act Safeguards Rule (updated 2021, FTC enforcement authority) requires financial institutions and their service providers to implement a written information security program covering the AI models that process financial data. Specific requirements: multi-factor authentication for all access to customer financial data, encryption in transit and at rest, access controls based on need-to-know.
Mitigation: Implement MFA for all developer and ops access to the fraud system database. Encrypt all transaction data at rest (AES-256) and in transit (TLS 1.3). Log all access to the fraud database with immutable audit logs. Include the fraud system in your annual GLBA Safeguards assessment — this is a legal requirement, not optional.
EU MiCA (Markets in Crypto-Assets) — July 1, 2026 transition deadline
For fraud detection systems serving crypto asset service providers (CASPs) in the EU, MiCA's requirements for transaction monitoring and fraud prevention apply from July 1, 2026. MiCA requires CASPs to implement robust fraud detection and report suspicious transactions to national competent authorities — your fraud API may become regulated infrastructure for EU crypto clients.
Mitigation: If EU crypto clients are in scope, review MiCA Title VI (authorization of CASPs) and Title VII (ongoing obligations) with EU legal counsel. Ensure your fraud API can generate MiCA-compliant suspicious transaction reports (STRs) with the required data fields. This may require specialized output formatting beyond standard merchant-ops explanations.
Build vs buy: the real math
24–32 weeks
Custom build time
$100,000–$200,000
One-time investment
7–18 months (against Riskified 0.6–1.5% GMV)
Breakeven vs buying
The breakeven math depends entirely on which competitor you're replacing. Against Riskified at 1% GMV: a marketplace processing $2M/mo pays $20K/mo = $240K/yr. A $150K build cost recoups in 7.5 months — then $240K/yr falls to the platform's bottom line. Against Sift at $0.01/event: 1M events/mo × $0.01 = $10K/mo = $120K/yr. The $150K build recoups in 15 months. Against the DIY-Stripe-Radar baseline ($0/mo Radar + 0.07% Stripe Radar fee): a custom build only makes sense if your false-positive rate on Stripe Radar is creating unacceptable revenue loss from declined legitimate transactions. The compliance overhead ($35K–$100K/yr in PCI + SOC 2 fees) is an ongoing cost that does not decrease with model maturity — factor it into 5-year TCO, not just year-1 build cost.
Skip the DIY — RapidDev builds the production version
A Lovable MVP gets you a demo. Production needs auth that doesn't leak data, AI calls that don't bankrupt you, observability when models drift, and code you can audit. That's what we ship.
Discovery call (free)
30 minWe map your exact Payment Fraud Detection System use case: who uses it, target volume, AI model choice, integrations, compliance scope. You get a detailed scope document and fixed-price quote within 48 hours.
AI-accelerated build
24–32 weeksOur engineers use Claude Code, Lovable, and custom tooling to ship 3–5x faster than agencies. You see weekly progress in a staging environment — not a black box.
Launch + handoff
1 weekWe deploy to your infrastructure, transfer the GitHub repo, set up CI/CD and monitoring, and train your team. You own 100% of the source code, prompts, and model configurations.
What you get
Timeline
24–32 weeks
Investment
$100,000–$200,000
vs SaaS
ROI in 7–18 months (against Riskified 0.6–1.5% GMV)
30-min call. Fixed-price quote within 48 hours. No commitment.
Frequently asked questions
How much does it cost to build a white-label AI fraud detection system?
RapidDev builds this for $100,000–$200,000 over 24–32 weeks. The range reflects PCI and SOC 2 scaffolding: the lower end covers ML inference pipeline, Redis feature store, LLM explanation via AWS Bedrock, merchant dashboard, and basic SOC 2 controls documentation; the upper end adds PCI QSA engagement support, full SOC 2 evidence collection automation (Vanta integration), FCRA adverse action notice workflow, and graph-based ring-fraud detection. PCI QSA assessor fees ($15K–$50K/yr) and SOC 2 audit fees ($20K–$50K/yr) are separate from the build cost and must be budgeted annually.
How long does it take to ship an AI fraud detection platform?
24–32 weeks from project start to production. The timeline is dominated by PCI DSS scope definition (2–4 weeks with QSA), SOC 2 control implementation (ongoing throughout), ML model training (requires 90+ days of labeled transaction data), and false-positive calibration in staging (4–8 weeks). A demo dashboard with synthetic data can be built in a week — do not confuse demo speed with production readiness.
Can RapidDev build this for my fintech or PSP?
Yes. RapidDev has built transaction processing pipelines and ML inference systems for fintech clients. For fraud detection, we engage a PCI QSA partner during the architecture phase to define CDE scope before writing any code — the data-flow diagram and scope definition drive every infrastructure decision. We also work with SOC 2 automation tools (Vanta, Drata) from day one. Book a free 30-minute consultation at rapidevelopers.com.
Can I use Stripe Radar instead of building my own fraud detection?
For most fintechs under $5M/mo GMV, yes — Stripe Radar at 0.07%/transaction ($0.07 per $100 in volume) is cost-effective and PCI-scope-minimizing. Stripe absorbs the CDE responsibility for card data storage and processing. The case for a custom fraud system emerges when: (1) your vertical has fraud patterns that Stripe Radar's general model misses (marketplace seller fraud, synthetic identity, crypto-adjacent fraud); (2) you're processing $10M+/mo where the Radar fee compounds significantly; or (3) you need white-label fraud risk scores to sell to your own merchant base.
What is the false-positive rate risk with a custom fraud model?
In the first 90 days after launch, a custom model trained on your specific transaction history typically has a higher false-positive rate than Sift or Riskified, which are trained on billions of transactions across many merchants. The model improves over 180–360 days as it accumulates labeled fraud examples specific to your merchant mix. Set a conservative risk threshold initially (only auto-decline very high-confidence fraud; put borderline scores in review queue) to avoid rejecting legitimate customers while the model calibrates. Plan for a 3–6 month false-positive tuning period with a human review queue.
Does FCRA apply to my fraud API?
Potentially, if your fintech clients use your fraud score in account-opening or credit decisions. The FCRA definition of 'consumer report' includes any communication 'bearing on a consumer's creditworthiness, credit standing, credit capacity, character, general reputation, personal characteristics, or mode of living.' A fraud risk score used to deny an account application can fall within this definition. The safe harbor is restricting your API to payment transaction fraud only (not creditworthiness) and including contractual prohibitions on clients using your score in credit decisions. Consult a FCRA attorney before launch.
Want the production version?
- Delivered in 24–32 weeks
- You own 100% of the code
- AI cost monitoring built in
30-min call. No commitment.