Tuning antifrood et règles

TL; DR

L'antifrode n'est pas un « piège à intrus », mais une optimisation des profits : minimisons les Loss Expected (EL) des frondes et des chargbacks tout en limitant le Cost of Friction (CoF) et les AR_net. Schéma de base : Scoring (ML) → seuil/step-up forestier → règles (policy & velocity) → vérification manuelle. Le succès est donné par : des labels propres, des fiches stables, un seuil calibré économiquement, des sorties canaries, une idempotence stricte et la gérabilité des règles.

1) Production économique

• `EL = P_fraud(tx) × Exposure(tx)`; habituellement 'Exposure = captured_amount'.

• `CoF = (Abandon_on_Friction × LTV_new/ret) + Opex_review + Fees_stepup`.

• `Profit = GGR − Cost_payments − EL − CoF`.

Seuil optimal 'τ' : on sélectionne un score-cutoff tel que 'd (Profit )/d τ = 0', ou par maille min ('EL + CoF'). En pratique - cost-sensible ROC/PR avec des poids : « w _ fraud = Exposure », « w _ fp = LTV_loss + opex ».

2) Bûcheron d'authentification (step-up ladder)

1. Auto-approve (faible risque) : passage instantané, 3DS frictionless où vous pouvez.
2. Step-up A: 3DS challenge / SCA / device-challenge / reCAPTCHA.
3. Step-up B: легкий KYC (doc selfie/face-match, liveness).
4. Manual review : le cas de l'analyste (SLA, reason-codes).
5. Auto-decline : risque élevé/sanctions/mules/anomalies de coupon.

Le seuil/branche dépend du score de scoring, de la somme ('ticket _ size'), du pays, du BIN/issuer, des fiches comportementales et du contexte (campagnes bonus, fenêtres de nuit, velocity).

3) Signaux et fiches (base minimale)

Paiement : BIN/IIN, issuer_country, ECI/3DS flow, AVS/CVV match, codes soft-decline, retours/disputations dans l'histoire.
Comportemental : vitesse des événements (velocity : 'cards/device/ip/email'), heure de la journée, first-seen/last-seen, « topologie » des comptes (graphe de communication : common device/cards/portefeuille).
Appareil/réseau : device fingerprint, émulateurs/jale/ruth, proxy/VPN/TOR, ASN/hébergement.
Anti-bonus : syndiqués de référence, bonus de « pompage », modèles anormaux depozit→vyvod sans jeu.
Paiements/portefeuilles/bons : répétitions de PIN, géo-mismatch, radimes « rapides », cascades de muling.
KYC/KYB : niveau, validation, drapeaux SoF/SoW.
Sanctions/RER/listes de blocs : correspondances sur les listes, FIO-match/adresses.

4) Pile : ML + règles

5) Métriques de qualité (avec des bases claires)

AR_clean = `Auth_Approved / (Auth_Attempted − Fraud_preblocked − Abandon_3DS)`

Taux de Fraud (par capture) = 'Fraud _ captured _ amount/ Captured_amount'

Taux de charge = 'Chargeback _ count/ Captured_Tx' (ou montant)

False Positive Rate (FP) = `Legit_declined / Legit_attempted`

Step-up Rate = `StepUp_tx / Auth_Attempted`, Abandon_on_StepUp

Auto-approve %, Manual review %, Review SLA/TtA

Net Profit uplift après tuning (contrôle AB-différence EL + CoF vs).

Points de référence : FP pour les nouveaux utilisateurs ≤ 1-2 % (en volume), Fraud (en montant) - dans le couloir cible de la licence/des schémas.

6) Seuils et politiques de réglementation

6. 1 Étalonnage du seuil

On construit un cost-curve : pour chaque 'τ' on compte 'EL (τ) + CoF (τ)'.
Nous choisissons 'τ' avec un minimum. Pour un ticket haut, un 'τ _ hi' séparé.

6. 2 Règles types (pseudo-code)

yaml
- name: SANCTIONS_HIT when: sanctions_match==true action: DECLINE reason: "Sanctions/PEP match"

- name: BIN_RISKY_3DS when: bin in RISKY_BINS and score in [τ_low, τ_mid)
action: STEPUP_3DS

- name: DEVICE_VELOCITY_LOCK when: device_id in last_10min.deposits > 3 action: DECLINE_TEMPORARY ttl: 2h

- name: BONUS_ABUSE_GUARD when: (bonus_received and gameplay_turnover < Xdeposit_amount) and payout_request action: HOLD_REVIEW reason: "Turnover not met"

6. 3 Limites dynamiques

Limite du montant et du nombre de transactions par niveau de risque (risque-tier) : 'R1/R2/R3'.
Limites adaptatives pour les nouveaux comptes, en se réchauffant avec une bonne histoire.

7) Cycle de vie des règles (governance)

DSL/registre de règles avec versions, propriétaire et description de l'effet.
Shadow mode → canary (5–10%) → full rollout.
RACI: Owner (Payments Risk), Approver (Compliance/Legal), Consulted (Support/Treasury), Informed (Ops).
Audit-journal : qui/quand a changé, quelles métriques/AV, retour en arrière.
Durée de conservation de la règle et réévaluation (p. ex. 30/60 jours).

8) Données et formation sur les modèles

Séparées dans le temps, sans fuite (fonctionnalités uniquement de la fenêtre précédente).
Label cible : confirmed fraud/chargeback ; labels individuels bonus abuse.
Reweighing classes par la somme (amount-weighted loss).
Drift-monitoring : PSI pour les fiches clés, KS pour les pelles, stabilité baseline.
Triggers Retrain : PSI> 0. 25, chute de KS, changement de trafic/juridictions.

9) L'explication et le sapport

Pour chaque solution, nous générons des reason_codes (jusqu'à 5 raisons) avec des indices humaines.
Macros de Sapport par step-up/pannes (3DS, KYC, turnover).
Controverses/disputes : la rétroaction entre dans le labeling pipeline (nous fermons le cycle).

10) Conformité et vie privée

RGPD/DSAR : droit d'expliquer la décision ; minimiser les IPI ; hachage (salted) des identifiants (email/phone/PAN token).
PCI-DSS : flux PAN-safe, tokenization.
Sanctions/AML : circuit de dépistage distinct + escalade MLRO.
Retraite : politiques de stockage des signaux et des justifications de décision.

11) Surveillance et alertes (toutes les heures/tous les jours)

AR_clean, Fraud (amt%), FP (retention-weighted), Step-up/Abandon, Review SLA, Chargeback Rate (lagged).
Spike velocity, croissance des hébergements TOR/Proxy/ASN, dégradation BIN, coupon redim.
Alert sous : FP> couloir, Fraud> target, Abandon> bases + X p.p., dérive PSI/KS.

12) tranches SQL (exemple)

12. 1 Métriques de base

sql
WITH base AS (
SELECT
DATE_TRUNC('day', attempt_ts) d, country, provider, method_code,
COUNT() FILTER (WHERE auth_status='ATTEMPTED') AS attempted,
COUNT() FILTER (WHERE auth_status='APPROVED') AS approved,
COUNT() FILTER (WHERE decision='DECLINE' AND label='LEGIT') AS fp_cnt,
SUM(captured_amount) AS cap_amt,
SUM(CASE WHEN label='FRAUD' THEN captured_amount ELSE 0 END) AS fraud_amt
FROM payments_flat
GROUP BY 1,2,3,4
)
SELECT d, country, provider, method_code,
approved::decimal/NULLIF(attempted,0) AS ar_clean,
fraud_amt::decimal/NULLIF(cap_amt,0)  AS fraud_rate_amt,
fp_cnt::decimal/NULLIF(attempted,0)  AS fp_rate
FROM base;

12. 2 Proportion d'échecs step-up et d'échecs par rasoir

sql
SELECT
DATE_TRUNC('day', attempt_ts) d,
WIDTH_BUCKET(score, 0, 1, 10) AS bucket,
AVG(CASE WHEN decision='STEPUP' THEN 1 ELSE 0 END) AS stepup_share,
AVG(CASE WHEN decision='DECLINE' THEN 1 ELSE 0 END) AS decline_share,
AVG(CASE WHEN stepup_abandon THEN 1 ELSE 0 END) AS abandon_after_stepup
FROM risk_events
GROUP BY 1,2
ORDER BY d, bucket;

13) Pleybooks tuning

La croissance de Fraud (amt %) avec un FP stable → augmenter « τ », renforcer la velocity par appareil/ASN, inclure les 3DS-challenge sur les BIN vulnérables.
Le FP élevé chez les nouveaux → d'atténuer « τ » pour un ticket bas, de transférer une partie à Step-up A au lieu de rejeter.
Abdon à 3DS↑ → négocier avec PSP sur les paramètres 3DS2, améliorer l'UX, réduire le step-up sur les mobiles pour low-risk.
Réseaux de bonus syndiqués → fiches graphiques, limiter les paiements « parallèles », règles turnover.
Anomalies de coupon → velocity par PIN/Reteiler/geo, device-binding, hold avant vérification.

14) Mise en œuvre : chèque-feuille

• Étalonnage économique du seuil (« EL + CoF »), « τ » séparé par segment.
• Registre des règles (DSL), shadow→canary→rollout, audit et restauration.
• Reason-codes et modèles de communication.
• Suivi PSI/KS, dérive fich/score, retraite régulière.
• Canal de rétroaction (disputy→leybly).
• Les politiques KYC/step-up, SLA review et TtA/TtR.
• Privacy : hachage des identifiants, minimisation des IPI.

15) Résumé

L'antifroda tuning est une optimisation systémique des profits avec une friction contrôlée : ML-scoring + step-up de bois réfléchi, des règles légales strictes et des limites de velocity soignées. L'étalonnage économique du seuil, les labels purs, les canaries et la gestion rigoureuse donnent un Fraud bas en somme, un FP bas en nouveaux, un AR_net élevé - sans surprise pour la complication et l'UX.