Fraud detection for online payments: signals and scoring
Fraud detection is the practice of scoring each payment, login or payout in real time and deciding whether to allow, review or block it. Systems combine device, card BIN, velocity, email and history signals into a risk score with readable reasons. The aim is to stop stolen-card and testing fraud while keeping approval rates high.
Updated · RiskCogs team
Key facts
- Fraud detection happens before authorization, not after a chargeback arrives.
- Strong signals include velocity, device reuse, BIN country mismatches and disposable emails.
- A score is a reason to review, not proof that a person committed fraud.
- Rules should be tested on live traffic in shadow mode before they block.
What fraud detection covers
Fraud detection sits next to your payment provider. It does not move money. It looks at the context of a payment or login and returns a decision your checkout can act on: allow, step up with 3-D Secure, send to review, or decline.
Typical targets are stolen-card purchases, card testing, account takeover that spends saved cards, and patterns that later become chargebacks. Detection is only useful if outcomes (approve, fraud, chargeback) feed back into the rules.
- Card-not-present fraud and card testing.
- Account takeover on saved payment methods.
- First-party (friendly) fraud patterns over time.
- Promo and refund abuse linked by device or card.
Signals that matter
- Velocity: how often cards, devices, IPs or emails repeat in a short window.
- Device and browser signals from the checkout SDK, including automation hints.
- BIN data: card type, issuer country, prepaid or virtual flags.
- Mismatch between card country, IP country and shipping address.
- Email quality and account age versus order value.
- Prior outcomes: chargebacks and confirmed fraud on linked entities.
How to run fraud detection without hurting conversion
- Score every payment before capture and keep three bands: allow, review, block.
- Use 3-D Secure for medium risk instead of a hard decline where it fits.
- Set velocity limits per device, IP, BIN and email.
- Test new rules in shadow mode on real traffic first.
- Send chargebacks and fraud labels back through a feedback API.
- Watch false declines next to fraud loss every week.
How RiskCogs does fraud detection
RiskCogs is a risk-scoring layer beside your current payment provider; it does not process payments. POST /v1/risk-score returns a score from 0 to 100 with reasons. Default bands are allow under 40, review 40 to 69 and block from 70. Shadow mode lets you compare decisions with live outcomes before you enforce them. Pricing is on /pricing/.
See what you would have blocked — free shadow modeFrequently asked questions
What is fraud detection?
It is the real-time evaluation of payments, logins or payouts against signals and rules so you can allow, review or block before money moves. The output is usually a risk score with reasons your team can read and tune.
How is fraud detection different from fraud prevention?
Detection is the scoring and decisioning step. Prevention is the wider set of controls around it: 3-D Secure, velocity limits, refund policy, evidence for disputes and feedback loops. Most teams need both.
Will fraud detection block good customers?
It can, if rules are too strict or untested. Use shadow mode first, send borderline cases to review or 3-D Secure, and track false declines by rule so you can loosen noisy ones.
What should I look for in a fraud detection tool?
Explainable scores, rules you can edit, shadow testing on real traffic, clean integration next to your payment provider, and clear pricing. Avoid tools that only return a black-box decline with no reasons.
Sources and related reading
- EMVCo, EMV 3-D Secure Protocol and Core Functions Specification, public overview.
- PCI Security Standards Council, PCI DSS v4.0 overview.