The decline has no owner
Fraud losses have a line in the accounts. Revenue lost to a wrongly declined payment does not, so the rule that caused it is never questioned.
Fraud · Transactions
Payment Fraud
Each declined payment involves a decision concerning revenue as much as it does risk. When a payment is authorized, Complead evaluates it and, on the same screen, displays both aspects of the result — that is, the fraud stopped by a rule and the good customers it rejected — for each rule.
Authorization
DECISION BEFORE THE PAYMENT CLEARS
Both sides
FRAUD PREVENTED AND REVENUE LOST
Per rule
PRECISION MEASURED, NOT ASSUMED
Evidence kept
FOR THE DISPUTE THAT FOLLOWS
Why this matters
The damage caused by a false decline is greater than the fraud it stopped.
Fraud shows up in the chargeback file, so we measure it. A false decline shows up as a customer who tried once and went somewhere else, so nobody measures it. Approval rate sits in the commercial report, fraud rate sits in the risk report, and different people optimize the two against different targets. The rule that looks excellent in one report is the reason the other one is missing its number.
The ratio moves after the quarter
The charges do not arrive until weeks after the payment has been made. When the ratio shows that something has changed, the exposure has already been recorded.
Tightening is the only available move
If the rule does not specify precision, the only option is to lower the threshold, and each adjustment of it results in customers having to buy a smaller amount of fraud.
How it works
Scroll to advance
Four steps, from authorisation to the dispute
-
Step 01
Score the payment in context
The velocity is assessed in relation to the cards, devices, and merchants involved, the age of the beneficiary or of the card on file, the corridor and merchant category risk, and the customer's own history, with the device and behavioral signals from the session arriving together rather than as a separate check.
-
Step 02
Decide at authorization
You can approve, decline, review, or request a step-up, and the item will be returned before the payment clears with the reason given; step-up actions proceed according to either your flow or ours, and the result is sent back to the same record.
-
Step 03
Measure what the rule cost
Each rule includes two figures: the number of fraud cases it has prevented and the number of approved payments it has rejected. Since precision can be assessed separately for each rule, each segment, and each merchant category, adjusting the rules becomes a transaction that can be priced rather than something to be guessed at.
-
Step 04
Defend the ones that get disputed
All the evidence needed in order to deal with a disputed approved payment is already in place, including the device's continuity across this and previous orders, the session, the decision and the signals that led to it, all of which have been prepared for presentation.
complead / receive
- payment#A4-77219
- CARDon file 4 days
- VELOCITY6 cards, same device, 1h
- MCChigh risk
- CUSTOMER HISTORY14 months, clean
- SESSIONdevice known, behaviour normal
complead / score
- DECISIONstep_up
- REASONcard on file age + velocity
- CONFIDENCE0.71
- FALLBACKapprove if challenge passed
complead / decide
- card-on-file velocityv2, 90d
- DECLINES1,204
- CONFIRMED FRAUD388
- FALSE DECLINES816
- PRECISION32.2%
- Estimated revenue lost214,000 EUR.
complead / learn
dispute ~ #D-1188
DEVICE ~ same as 7 prior orders
SESSION ~ behavior matched baseline
DECISION ~ approve. 0.12 risk
EVIDENCE PACK ~ ready
Apply
SCORE
DECIDE
MEASURE
DEFEND
Capabilities
What the product actually does
Authorization-time decisioning
You can approve, decline, review or upgrade the entry before the payment has cleared, giving a reason attached so that your own systems can act on the reason rather than just the action.
The testing of cards and the detection of enumeration
The small-value probes, the sequential card numbers, the repeated rejections within a BIN range, and the same device or IP address using a large number of different cards were identified as part of a campaign rather than as separate instances of failed payments.
Both sides of every rule
Fraud has been prevented and revenue has been stopped, in accordance with the rules, by segment and by merchant category. Since precision is a matter of a number not of belief, a rule can be adjusted, replaced or withdrawn on the basis of evidence rather than out of concern about loosening it.
Simulation before publication
The system first checks your own payment history whenever there is a threshold change; fraud cases it would have detected would still be detected and the estimated impact on revenue would be calculated, even before any actual payment is processed.
Evidence of dispute and representation
The device's continuity in respect of the contested order and all previous ones, together with information about the session, the decision and its signals, is retained and can be exported as an evidence pack.
Scheme ratio tracking
The fraud and chargeback ratios are projected ahead rather than stated in reverse so that you can see the trend while it is still within your power to alter it.
Product tour
Three screens, and one of them prices the argument
Every payment, and why
The decisions when they occur, together with the signals that caused them and one action from the row.
- Decision and reason on every payment
- Session and device signals inline
- Override with a recorded reason
- Latency on every call
complead / live-decisions
- DECLINE #A4-77219, velocity
- STEP_UP #A4-77204, card age
- APPROVE #A4-77198
- REVIEW #A4-77187, MCC + amount
What each rule earns and what it costs
Fraud prevented against revenue turned away, with a simulated alternative beside it.
- Fraud prevented, per rule
- False declines and estimated revenue
- Precision per segment
- Simulate a change in history
complead / decision-detail
- card-on-file velocityv2
- PRECISION32.2%
- REVENUE LOST214,000 EUR
- FRAUD PREVENTED96,000 EUR
- DECLINES1,204 → 402
- FRAUD CAUGHT388 → 371
The evidence, already assembled
The disputed payments, including their device history, session, and decision details, are being prepared for presentation.
- Device continuity across prior orders
- Session behavior at the time
- The decision and its signals
- Export as an evidence pack
complead / performance
- #D-1188 chargeback, CNP
- DEVICE 8 orders, 14 months
- SESSION baseline match
- DECISION approve, 0.12
- PACK exported
Case study · Acquirer
Read the case study
A payments firm raised approvals and cut fraud at the same time
The level of fraud was under control, but the approval rate was the issue and no one could determine which of the rules was to blame. By examining the amount of fraud prevented against the revenue that was turned away for each rule, it was found that three rules caused more commercial damage than the losses they prevented, and two rules were worth tightening.
+2.1pt
APPROVAL RATE
−18%
FRAUD LOSSES
3 rules
RETIRED WITH EVIDENCE
For a period of two years we had been talking about the threshold, and it soon became evident that we had been referring to the wrong rule.
HEAD OF PAYMENT RISK, TryCrew
FAQ
Before you ask us
Can it decline a payment, or only score it?
It decides. Every authorization returns one of four outcomes, approve, decline, review or escalate, with the reason behind it.
How do we know what a false decline costs us?
Declines that were not fraud are attributed to the rule that caused them and priced at the payment amounts involved. It stays an estimate, because a customer who walks away never tells you, but it sits on the same screen as the fraud number instead of in nobody's report.
Can we test a threshold change before it goes live?
Yes. Any change is replayed against your own payment history first, showing the declines it adds or removes, the fraud it still catches, and the estimated effect on revenue.
Can it detect card testing and enumeration?
Yes. Small-value probes, sequential card numbers, repeated declines inside a BIN range and one device running many cards are read as a single campaign, not as a scatter of failed payments.
What happens when an approved payment is disputed?
The evidence is already on record: the decision and the signals behind it, the session behavior, and the device's history across the disputed order and the ones before it. It exports as an evidence pack you can submit.
Are device and behavioral signals used here too?
Yes. They arrive with the payment rather than as a separate check, so a familiar device behaving normally can carry a payment that would otherwise look risky.
Device Fraud & Behavior AnalysisDoes the customer's risk rating affect the payment decision?
Yes. Tier and segment are conditions inside payment rules, so a high-risk customer meets different logic rather than the same logic at a higher threshold. Confirmed fraud raises the tier for the next payment.
How does this relate to transaction monitoring?
Payment fraud decides whether to authorize a payment. Transaction monitoring decides whether behavior over days and weeks should be reported. Both run on the same customer record: scoring is a synchronous call at authorization, and webhooks carry disputes, confirmations and rule changes.
Testimonials
All case studies
What compliance teams say
Complead provides ultimate control via its case management and safelist systems. Automated API operations significantly reduced my team's manual workload.
Using the API we run AML controls automatically and stay compliant, while reducing our team's daily workload.
With Complead we offer fast, easy, secure onboarding. We focus on real risks, not false positives.
Price a rule you have never touched
Include three months of payment history along with any declines. Within thirty minutes you will be able to see which rule prevented a transaction, which ones turned people away, and those that are costing more than they save.
At authorisation
DECISION BEFORE IT CLEARS
Both sides
FRAUD AND REVENUE, ONE SCREEN
Evidence kept
FOR THE DISPUTE THAT FOLLOWS