The first pillar is catching the right fraud signals at the right time — before they become chargebacks, not
after.
Real-time vs. batch: where most stacks break
Most mid-market fraud stacks operate in batch mode: transactions are scored periodically, rules run on a
delay, and by the time a fraud pattern is identified, dozens of transactions have already settled. Real-time
detection requires scoring at decision time — before authorisation, not after.
The gap between real-time and batch is not a technology problem. It is an integration architecture problem.
Your fraud system needs to sit in the authorisation flow, not downstream of it. If your current vendor
processes transactions after settlement, you are catching fraud after the money has already moved.
What your current stack typically misses
- Cross-account fraud rings. Individual transaction scores look clean. Cluster-level analysis
reveals shared device fingerprints, email domains, or shipping addresses across accounts that individually
pass rules.
- Velocity signals across time windows. A customer with three transactions in 30 days looks
fine. The same customer with 15 transactions in 6 hours does not — but only if you're measuring the right
window.
- Friendly fraud patterns. First-party misuse is harder to detect than third-party fraud
because the account, device, and behavioural signals are legitimate. Outcome-linked scoring — connecting
transaction signals to eventual dispute outcomes — is the only reliable approach.
- Processor-specific signals. Adyen, Stripe, and Checkout.com each surface different data
fields in their transaction objects. A rules engine built for one processor misses signals native to another.
The closed-loop principle: Signal detection is only meaningful when detection outputs are
connected to dispute outcomes. A system that flags transactions but never learns from whether those flags led
to confirmed fraud, false positives, or chargebacks is operating open-loop. Open-loop detection degrades over
time.
Flagged transactions need to go somewhere. How your team handles the queue between detection and decision is
where most operational efficiency is lost.
Consolidation: the single-case view
A fraud investigator working on a disputed transaction needs to see the complete picture in one place:
transaction history, device fingerprint, account age, previous disputes, chargeback outcomes, and the
detection signal that flagged it. If that information lives across three systems and requires manual lookup,
the investigation takes 40 minutes instead of 4. At scale, that is the difference between a team of 2 and a
team of 8.
Timeline reconstruction
For chargeback representment, you need to reconstruct the customer's journey: what they did, when, and on what
device — in a format that satisfies card scheme evidence requirements. This means timestamped event logs, not
just transaction records. If your fraud system doesn't maintain this timeline, your dispute team is building
it manually from incomplete sources — and losing representments they should win.
Analyst triage: working the right queue
Not all flagged transactions require the same level of investigation. A triage layer — routing high-confidence
fraud flags to auto-decline, medium-confidence flags to analyst review, and low-confidence flags to enhanced
monitoring — reduces analyst load by 40–60% without increasing fraud loss. Most mid-market teams don't have
this layer. Everything goes into one queue, and analysts spend the same time on a 95%-confident fraud flag as
on a borderline case.
Chargebacks are not just a fraud cost — they are a data source. How you handle disputes determines both your
win rate and the quality of your detection feedback loop.
Evidence generation
Winning a chargeback dispute requires evidence that the transaction was authorised, legitimate, and consistent
with the customer's historical behaviour. The evidence package for Visa or Mastercard representment requires
specific fields in a specific format — and the clock starts when the dispute is filed.
If your fraud system doesn't automatically compile evidence packages at dispute time — pulling the relevant
transaction log, device fingerprint, IP record, and authentication confirmation into a structured package —
your dispute team is doing this manually. That manual process takes time you often don't have.
Representment: what card schemes actually require
-
Visa: timestamped transaction record, device fingerprint, IP address, 3DS authentication status, customer
communication history
-
Mastercard: equivalent requirements, plus merchant category-specific documentation for high-risk MCC codes
-
Both: evidence submitted within the response window (typically 20–45 days from chargeback date depending on
reason code)
VAMP threshold management
The Visa Acquirer Monitoring Programme flags acquirers whose merchants exceed the VAMP ratio threshold of 0.9%.
Exceeding this triggers a formal remediation programme and, ultimately, fines to the acquirer — which are passed
downstream to you. Chargeback rate visibility is not optional; it is a contractual requirement of your
acquiring relationship.
VAMP note: The 0.9% threshold applies to Visa's VAMP ratio calculation, which differs from a
simple chargeback rate. Confirm the exact calculation methodology with your acquirer before using this figure
in internal reporting.
Compliance is not a separate workstream from fraud operations. The documentation your regulators will ask for
in August 2026 is the same documentation your fraud team needs to operate effectively.
EU AI Act audit trail
Under Article 13 of the EU AI Act, every automated fraud decision must be explainable, documented, and
auditable. This means your system needs to maintain a per-decision log — timestamped, with the input features
and their weights, the model version, the output, and the outcome. See the
EU AI Act Compliance Guide for the full specification.
The practical challenge for most teams is that this requirement cannot be retrofitted easily. If your fraud
system doesn't generate feature-level explainability at decision time, there is no way to reconstruct it after
the fact. Building the audit trail needs to start before August 2026 — not in response to a regulatory request.
GDPR and data subject rights
Fraud decisioning that involves personal data — which all transaction-level fraud decisioning does — is subject
to GDPR obligations. Data subjects have the right to request an explanation of automated decisions that
significantly affect them. If a customer asks why their transaction was declined, you must be able to answer in
terms they can understand. "Our system flagged it" is not compliant.
Card scheme documentation requirements
Visa and Mastercard both require documented fraud management processes as part of their acquirer agreements.
The specific requirements vary by programme (VAMP, MATCH, dispute management), but the common thread is that
you need to demonstrate a systematic approach to fraud detection, investigation, and outcome tracking — not ad
hoc rule changes and manual review.
The fifth pillar is what separates a fraud system from a fraud infrastructure. Without a feedback loop, your
detection is always chasing last quarter's fraud patterns.
Dispute outcomes → model retraining
Every resolved dispute is a labelled data point: confirmed fraud, friendly fraud, or false positive. If those
outcomes don't flow back into your detection model — updating feature weights, adjusting thresholds, flagging
new fraud patterns — your model's accuracy degrades over time as fraud tactics evolve.
Most mid-market fraud stacks have no formal mechanism for this. Rules are updated manually when an analyst
notices a pattern. Model weights are adjusted by the vendor on a quarterly basis, if at all. The feedback loop
is informal, slow, and incomplete.
Continuous improvement: what it actually requires
- Outcome linkage. Every fraud flag must be traceable to an eventual outcome: no chargeback,
chargeback filed, representment won, representment lost. Without this linkage, you can't measure false
positive rate or model precision.
- Segment-level reporting. Aggregate fraud rates hide the real picture. You need fraud rates
broken down by transaction type, customer segment, geography, and channel — so you can identify where your
detection is failing and where it's creating unnecessary friction.
- Threshold review cadence. Fraud tactics change. Your detection thresholds need to change
with them. A quarterly review of rule performance, false positive rates by segment, and new fraud pattern
signals is the minimum. Monthly is better.
- Model drift monitoring. If your fraud model was trained on data from 12 months ago and
hasn't been updated since, it is operating on stale assumptions. Drift monitoring — comparing current feature
distributions to training distributions — tells you when the model needs retraining before your chargeback
rate tells you.
The closed-loop principle, revisited: Pillars 1 through 4 feed Pillar 5 — the feedback loop that compounds
accuracy over time. For SENTR's operational five-stage architecture (detection through audit),
see how the loop works →