Managing a fraud crisis. 6 chapters and a final quiz.

Chapter 1. Anatomy of an attack: card testing, ATO, data breach.

In fraud, the question is not whether your platform will be attacked but when, and above all how long it will take you to notice. Modern attacks are industrialized: botnets, card lists bought on criminal marketplaces, scripts that hit your APIs thousands of times an hour. Three scenarios cover most of the crises a payments team must be ready to handle.

Card testing deserves special attention because it has become massive and automated. The attacker starts from a BIN, the first 8 digits of a card range, and uses a script to generate combinations of PAN, expiration date, and CVV. Each approved authorization “validates” a card that will be resold at a higher price or used immediately on other sites. Your platform becomes a free test bench, and you pay the fees.

Chapter 2. Detecting in minutes: metrics, thresholds, and alerts.

The difference between a €500 incident and a €500,000 crisis almost always comes down to time to detection. An attack leaves traces at every step of the transaction flow. That is where your sensors belong, with thresholds calibrated on your normal traffic.

Metrics to monitor in real time

• Authorization decline rate in 5-minute buckets, overall and by issuer BIN: the fire alarm for card testing.
• Velocity: number of attempts per card, IP address, device fingerprint, and email address over rolling 1-, 15-, and 60-minute windows.
• 3DS authentication failure rate and share of transactions abandoned at the challenge: a spike signals stolen cards without access to the cardholder’s phone.
• Account creations and password resets per hour, cross-checked against IP geolocation: the ATO signature.
• New payment methods added to long-standing accounts, followed by a quick purchase: the classic move after a takeover.
• External alerts: cardholder emails, reports from your PSP, compromise (CPP) lists passed on by issuers.

rule: card_testing_burst
scope: checkout + add_card + donation
window: 5m
conditions:
  - auth_attempts_per_ip >= 15
  - decline_rate_per_bin >= 0.60      # 60% declines on the same BIN
  - avg_amount <= 5.00                # small amounts typical of testing
actions:
  - challenge: captcha                # targeted friction, no global block
  - alert: fraud_oncall (PagerDuty, severity P2)
  - tag: enumeration_suspect
escalation:
  if: auth_attempts_per_ip >= 100 in 15m
  then: block_ip + alert P1 + notify war_room

Chapter 3. Activating the war room: roles, cadence, crisis log.

The P1 alert just fired. The first hour, the golden hour, determines how much damage is ultimately done. The classic mistake is letting three people hack together blocks in parallel with no coordination. Run a fraud crisis like a major production incident: a framework, roles, a cadence.

Chapter 4. Emergency measures: rules, forced 3DS, BIN blocking.

The containment toolkit ranges from targeted friction to shutting down the checkout flow entirely. Two principles guide the choice. Proportionality means choosing the measure that stops the attack while sacrificing the least revenue. Reversibility requires that anything switched on in an emergency can be switched off just as fast, with an explicit review date.

Forcing the 3DS challenge: the standard heavy artillery

In normal times, a large share of your transactions go through frictionless thanks to PSD2 exemptions: transaction risk analysis, low-value payments. In a crisis, you flip the logic. A systematic challenge shifts authentication to the issuing bank, a step the fraudster usually can’t pass without the cardholder’s phone. At most PSPs, a single setting does it.

POST /v1/payment_intents
{
  "amount": 4900,
  "currency": "eur",
  "payment_method_options": {
    "card": {
      "request_three_d_secure": "challenge"   // forces the challenge, ignores TRA exemptions
    }
  },
  "metadata": {
    "crisis_mode": "true",                     // tag to measure impact and roll back
    "activated_by": "war-room-2026-07-11"
  }
}

BIN blocking is the other reflex response to card testing, because enumeration attacks often concentrate on a few BINs from the same issuer. Blocking those ranges at the PSP or in your risk engine shuts the attack down instantly, but a BIN covers tens of thousands of legitimate cardholders. The block must be temporary, logged, and reviewed every 24 hours.

Chapter 5. Communicating: acquirer, schemes, CNIL, customers.

A fraud crisis is fought as much in communications as in technology, and each stakeholder has its own deadline, channel, and level of detail. The guiding principle never changes: inform early, factually, and in writing. A partner who learns about the incident from the press or its own alerts becomes an adversary.

With customers, the classic trap is the temptation to downplay, yet a clear message costs less than a denial followed by a correction. It says what happened, what you did, and what the customer should do. Prepare customer service too, with response scripts, an internal FAQ, and extra staff. In a mass ATO, customer service absorbs the brunt of the calls.

Chapter 6. Post-mortem and resilience plan.

The crisis is over and the metrics are back to normal. Now the most valuable work begins. A blameless post-mortem, held within two weeks, turns the incident into lasting improvement. The goal is to understand why the system (tools, processes, organization) let the attack through and took so long to react. Finding a culprit is out of scope.

• Factual timeline reconstructed from the crisis log: first trace of the attack, first alert, first action, containment, resolution.
• Root cause analysis: the “5 whys” method applied to both the entry vector (why was the endpoint vulnerable?) and time to detection (why did the alert take 6 hours?).
• Full costing: net fraud, technical fees, team hours, revenue lost to countermeasures, notification and remediation costs.
• Action plan: every action has an owner, a deadline, and a verification criterion. A post-mortem without action tracking is a group therapy session, not a resilience tool.
• Sharing: wide internal distribution and a debrief with the acquirer and PSP, who see dozens of crises and will enrich your analysis.

The wave of chargebacks that follows a breach or a successful fraud episode arrives several weeks later, as cardholders dispute charges when they see their statements. Plan for it in your provisions and your discussions with the acquirer, because it can push you over Visa and Mastercard monitoring program thresholds long after the attack is over.

From post-mortem to resilience plan