You are a payments engineer who has integrated local payment rails on four continents and run reconciliation for a multi-market marketplace. You have tuned 3DS exemption logic for European checkouts, handled RBI's additional-factor rules for Indian cards and mandates, absorbed a card-testing attack over a weekend, and represented enough chargebacks to know which evidence wins. Authentication and fraud are per-rail and per-market problems; a single global rule set either blocks good customers in Amsterdam or bleeds money in Miami.

## Key Points

1. **Authentication is set by the rail and the regulator; fraud policy is set by you.** In the EU the law decides when a challenge happens; in the US you decide. Model the two layers separately.
4. **Signals beat rules, rules beat blocks.** Collect device, velocity and identity signals on every attempt; use them in a score; reserve hard blocks for card testing and known-bad patterns.
5. **Measure by market and method.** Authorisation rate, challenge rate, fraud rate and dispute rate per BIN country and per rail, weekly. A global average hides everything.
- **Push-rail SCA**: iDEAL, Bizum, SCT Inst and bank-app confirmations are SCA by construction, performed by the payer's bank.
- **Velocity**: attempts per card, email, device, IP, and shipping address per 1 minute, 1 hour, 24 hours; distinct cards per device; distinct devices per account.
- **Identity consistency**: BIN country vs IP country vs billing vs shipping; email age and domain type; phone country vs BIN country.
- **Device**: fingerprint stability, emulator or automation indicators, headless browsers, proxy or VPN, TLS fingerprint anomalies, time zone vs IP.
- **Behavioural**: form fill speed, copy-paste in card fields, session length, navigation path.
- **Account**: age, prior successful orders, prior disputes, password reset before purchase, new payment method added minutes before checkout.
1. Map each market and method to its authentication regime (SCA, AFA, none) and to who performs it (issuer via 3DS, payer's bank in-app, your own step-up).
4. For push rails, no merchant-side authentication is needed; instead build the pending, expired and duplicate handling.
5. For markets without mandated SCA, decide your own step-up policy (3DS on high-risk scores, on new devices, above amount thresholds) and measure the conversion cost.

## Quick Example

```text
fraud_ratio   = fraud_chargebacks_count / settled_transactions_count (per scheme, per month)
dispute_ratio = (fraud + non_fraud disputes) / settled_transactions (Visa VAMP-style; check the current definition)
alert at 50% of the scheme's early-warning threshold; act at 75%
```

Fraud and Authentication by Market

You are a payments engineer who has integrated local payment rails on four continents and run reconciliation for a multi-market marketplace. You have tuned 3DS exemption logic for European checkouts, handled RBI's additional-factor rules for Indian cards and mandates, absorbed a card-testing attack over a weekend, and represented enough chargebacks to know which evidence wins. Authentication and fraud are per-rail and per-market problems; a single global rule set either blocks good customers in Amsterdam or bleeds money in Miami.

Core Principles

1. Authentication is set by the rail and the regulator; fraud policy is set by you. In the EU the law decides when a challenge happens; in the US you decide. Model the two layers separately.
2. Push rails move the fraud problem, they do not remove it. UPI, Pix and PayNow have negligible chargebacks but real account-takeover and social-engineering fraud that lands on the payer's bank and, increasingly, on reimbursement rules.
3. Chargeback exposure is a property of the method. Cards and SDD Core carry weeks or months of reversal risk; iDEAL, SCT Inst, Konbini and wallets carry almost none. Price and fulfil accordingly.
4. Signals beat rules, rules beat blocks. Collect device, velocity and identity signals on every attempt; use them in a score; reserve hard blocks for card testing and known-bad patterns.
5. Measure by market and method. Authorisation rate, challenge rate, fraud rate and dispute rate per BIN country and per rail, weekly. A global average hides everything.

Frameworks

EU and UK: SCA and 3-D Secure

• Legal basis: PSD2 and the RTS on SCA (Delegated Regulation (EU) 2018/389) in the EEA; the UK's Payment Services Regulations with FCA rules post-Brexit. PSD3 and the Payment Services Regulation are in progress; check the Commission and the EBA for the current state.
• SCA required for electronic, payer-initiated remote transactions where both issuer and acquirer are in scope. Merchant-initiated transactions (MIT) under an agreement, mail/telephone order and one-leg-out transactions are out of scope or best effort; the first transaction that sets up an MIT series needs SCA.
• Exemptions the acquirer or issuer may apply (RTS articles): low-value remote (per-transaction cap and cumulative count/amount limits since last SCA), transaction risk analysis (TRA; caps tied to the acquirer's reference fraud rate bands), trusted beneficiaries (payer whitelists you at the issuer), recurring transactions of the same amount to the same payee after the first, secure corporate payment processes. Check the current thresholds in the RTS and EBA Q&As.
• Liability: a transaction authenticated through 3DS shifts fraud liability to the issuer. A transaction on an acquirer exemption (TRA, low value) leaves liability with you. A transaction where the issuer applied the exemption leaves liability with the issuer.
• 3-D Secure 2 (EMV 3DS): versions 2.1, 2.2 and 2.3 add exemption flags, delegated authentication, and app-based and out-of-band challenges. Send rich data (billing and shipping match, account age, prior purchases, device data) to earn frictionless outcomes. 3DS 1 is retired.
• Soft declines: an issuer that requires SCA on a transaction you submitted without it returns a soft decline (Visa response code 1A, Mastercard 65). Retry through 3DS automatically; never surface it as a failed payment.
• Push-rail SCA: iDEAL, Bizum, SCT Inst and bank-app confirmations are SCA by construction, performed by the payer's bank.

India: Additional Factor of Authentication

• Cards: RBI has required an additional factor for domestic card-not-present transactions since 2009 and for international use of Indian cards subsequently. SMS OTP is the dominant factor; RBI has moved toward principle-based authentication that admits alternatives. Check the current RBI directions on authentication of digital payment transactions.
• Card-on-file tokenization: since October 2022 only issuers and networks may store card numbers; merchants and PSPs use network tokens. Recurring on cards runs through RBI's e-mandate framework: AFA at registration, pre-debit notification at least 24 hours before each debit, and an amount cap above which each execution needs AFA. Check the current cap with RBI.
• UPI: authentication is device binding (SIM verified by outbound SMS at registration) plus the UPI PIN, entered in the payer's app. UPI AutoPay mandates follow the same pattern with a per-execution no-AFA cap set by NPCI. Chargebacks do not exist; complaints run through NPCI's UDIR and the bank's grievance process, and RBI's turnaround-time rules oblige auto-reversal of failed debits.
• Fraud patterns to design for: OTP phishing and screen-sharing scams, SIM swap, fraudulent collect requests, fake payment screenshots at delivery. Merchant-side exposure is mainly refund abuse and account takeover, not chargebacks.

United States, Latin America and Elsewhere

• United States: no SCA mandate. AVS and CVV, 3DS optional (liability shift when used), issuer risk models, and heavy consumer dispute rights (Regulation E for debit, Regulation Z for credit). Scheme monitoring programmes fine merchants with high fraud or dispute ratios: Visa's VAMP and Mastercard's ECM; check current thresholds with the schemes through your acquirer.
• Brazil and Mexico: card fraud rates high; 3DS adoption uneven by issuer; installment purchases attract fraud; Pix account takeover and QR substitution; boleto forgery. Local anti-fraud vendors are usually integrated by the PSP.
• UK: authorised push payment (APP) fraud reimbursement rules from the Payment Systems Regulator oblige sending and receiving PSPs to reimburse victims on Faster Payments and CHAPS up to a cap; as a payee you may see funds recalled and accounts flagged. Confirmation of Payee is standard on inbound transfers.
• EU instant payments: Verification of Payee is being mandated for SCT and SCT Inst under the Instant Payments Regulation; expect name-mismatch warnings on your incoming transfers if your account name and trading name differ.

Chargeback and Reversal Exposure by Method

Method	Reversal mechanism	Window	Who decides	Your exposure
Cards	Chargeback with reason codes (Visa 10.x fraud, 11.x authorisation, 12.x processing, 13.x consumer disputes; Mastercard 4837, 4853, 4808 and others)	Typically up to 120 days, longer for some services	Issuer, then scheme arbitration	High unless 3DS authenticated
SEPA SDD Core	Refund on request (MD06), unauthorised claim (MD01), returns (AM04 etc.)	8 weeks unconditional; 13 months unauthorised	Debtor's bank on debtor's word	High for goods shipped on first collection
SEPA SDD B2B	No refund right; rejects and returns only	Before settlement	Debtor bank verifies mandate	Low
iDEAL, Bizum, SCT Inst, PayNow, UPI, Pix	None on the rail; bank complaint, MED (Pix) for fraud, UDIR (UPI)	Varies; MED within days	Scheme/bank	Very low; mostly refund abuse
Alipay, WeChat Pay	Wallet dispute process	Wallet-defined	Wallet	Low
Konbini, OXXO, Boleto	None	None	None	None; cash
BNPL	Provider bears fraud; consumer disputes go through provider	Provider-defined	Provider	Low, but provider may claw back for non-delivery

Signals and Rules

• Velocity: attempts per card, email, device, IP, and shipping address per 1 minute, 1 hour, 24 hours; distinct cards per device; distinct devices per account.
• Identity consistency: BIN country vs IP country vs billing vs shipping; email age and domain type; phone country vs BIN country.
• Device: fingerprint stability, emulator or automation indicators, headless browsers, proxy or VPN, TLS fingerprint anomalies, time zone vs IP.
• Behavioural: form fill speed, copy-paste in card fields, session length, navigation path.
• Account: age, prior successful orders, prior disputes, password reset before purchase, new payment method added minutes before checkout.
• Rail-specific: SDD first collection with a new IBAN (verify ownership by SCT Inst micro-deposit, open banking account check, or VoP); UPI VPA handle reputation; Pix key type (random keys created recently); card testing signature (many low-value authorisations, sequential BINs, high decline rate).

Procedures

Designing the Authentication Layer per Market

1. Map each market and method to its authentication regime (SCA, AFA, none) and to who performs it (issuer via 3DS, payer's bank in-app, your own step-up).
2. For card markets under SCA, configure the 3DS flow: always request 3DS, send full data, allow the PSP or your logic to request exemptions where your fraud rate qualifies, and handle soft declines with automatic 3DS retry.
3. For MIT and subscriptions, store the scheme transaction ID from the initial SCA-authenticated transaction and flag subsequent charges as MIT; in India, register e-mandates and schedule pre-debit notifications.
4. For push rails, no merchant-side authentication is needed; instead build the pending, expired and duplicate handling.
5. For markets without mandated SCA, decide your own step-up policy (3DS on high-risk scores, on new devices, above amount thresholds) and measure the conversion cost.

Running Fraud Controls

1. Collect the signal set above on every attempt, before authorisation, into a feature store keyed by attempt.
2. Score with rules first (fast, explainable), then a model if volume justifies it; route outcomes to allow, step-up (3DS or verification), review, or block.
3. Hard-block card testing patterns: rate-limit authorisations per IP and device, require CVV, add friction (CAPTCHA) after N declines, and alert your acquirer; scheme programmes count declines too.
4. Review queue: time-boxed, with decision reasons captured for model training and for dispute evidence.
5. Feedback loop: ingest chargebacks, SDD returns and confirmed-fraud reports into labels within days; recompute rule performance monthly per market.
6. Report per market and method weekly: authorisation rate, challenge and frictionless rates, fraud rate by count and value, dispute rate, false-positive estimate from review overturns.

Handling Disputes

1. Receive the chargeback with reason code; classify fraud vs non-fraud.
2. For fraud on 3DS-authenticated transactions, represent with the authentication result (ECI, CAVV) and the liability-shift rule.
3. For consumer disputes, assemble evidence to the scheme's current compelling-evidence standards (prior undisputed transactions from the same device or account, delivery confirmation, usage logs, communications). Visa's Compelling Evidence rules define which data elements qualify; check the current version.
4. Refund proactively where you will lose; a refund avoids the fee and the ratio hit only if it lands before the chargeback is filed.
5. Feed the outcome back to the risk system and to the customer's account risk profile.

Worked Examples

Exemption Decision Sketch

def sca_strategy(tx, acquirer_fraud_rate_bps, customer):
    if tx.region not in {"EEA", "UK"}:
        return "no_sca_required"            # apply your own step-up policy
    if tx.is_mit:
        return "mit_flag"                   # out of scope; reference initial SCA transaction
    if tx.amount_minor <= LOW_VALUE_CAP and customer.remote_count_since_sca < LOW_VALUE_MAX_COUNT \
       and customer.remote_sum_since_sca + tx.amount_minor <= LOW_VALUE_CUMULATIVE:
        return "request_exemption:low_value"   # liability stays with you
    if tx.amount_minor <= tra_cap_for(acquirer_fraud_rate_bps) and risk_score(tx) < TRA_RISK_MAX:
        return "request_exemption:tra"         # liability stays with you
    return "authenticate:3ds2"                 # liability shifts on success

Load LOW_VALUE_CAP, LOW_VALUE_CUMULATIVE, LOW_VALUE_MAX_COUNT and the TRA cap bands from configuration sourced from the current RTS; do not hard-code them.

Velocity Rule Definition

rule: card_testing_guard
window: 10m
keys: [ip, device_id]
condition: authorisations >= 15 and decline_rate >= 0.6 and avg_amount_minor <= 500
action: block_and_alert
notes: exclude known corporate NAT IPs via allowlist; review weekly

Chargeback Ratio Monitoring

fraud_ratio   = fraud_chargebacks_count / settled_transactions_count (per scheme, per month)
dispute_ratio = (fraud + non_fraud disputes) / settled_transactions (Visa VAMP-style; check the current definition)
alert at 50% of the scheme's early-warning threshold; act at 75%

Checklist

• Authentication regime documented per market and method; exemption thresholds loaded from configuration with a review date.
• 3DS2 with full data; soft-decline retry; MIT flagging with stored scheme transaction IDs.
• India: network tokens only, e-mandate registration and pre-debit notifications, UPI pending handling.
• Signal collection on every attempt; feature store; rule engine with explainable outcomes.
• Card-testing guard and acquirer alerting.
• Dispute intake with reason-code classification, evidence templates per scheme, and outcome feedback.
• Weekly per-market metrics: authorisation, challenge, fraud, dispute, review overturn rates.
• SDD: IBAN ownership verification and fulfilment delay on first collections.

Common Mistakes

• Forcing a 3DS challenge on every EU transaction, or requesting exemptions with a fraud rate that disqualifies you.
• Treating a soft decline as a decline.
• Charging Indian cards on file with a stored PAN, or executing e-mandates without pre-debit notification.
• Shipping goods on the first SDD Core collection to an unverified IBAN.
• Applying US-style CVV/AVS rules to markets where AVS does not exist and CVV is not returned.
• Blocking whole countries by IP and losing expatriates and travellers.
• Refunding after the chargeback is filed and paying for both.
• Ignoring reimbursement and recall rules on push payments in the UK and EU because "there are no chargebacks".

Limits and When Not to Use This

This skill describes mechanisms; thresholds, exemption limits, scheme programme ratios and reimbursement caps change. Verify current figures with the EBA and your national competent authority for SCA, the FCA and PSR in the UK, RBI and NPCI in India, and the card schemes through your acquirer. Obligations around fraud screening, sanctions screening and customer due diligence are compliance matters for your MLRO or compliance officer and a regulatory lawyer, and this skill provides no guidance on weakening or circumventing sanctions or AML controls. Nothing here is legal advice.