Le piège n° 1 : le dénominateur
Le dénominateur d’un indicateur de paiement désigne la population à laquelle le numérateur est rapporté. Le parcours d’encaissement en fournit cinq, de la session ouverte au formulaire jusqu’à la transaction réglée. L’énoncé « notre taux d’autorisation est de 92 % » ne devient interprétable qu’une fois nommée la population comptée, autrement dit 92 % de quoi : les tentatives soumises au réseau, les tentatives du client, les transactions capturées, les transactions réglées. Ces cinq populations n’ont ni la même taille, ni le même propriétaire, ni les mêmes leviers. Un même mois de données produit des taux qui s’étalent sur plus de dix points, selon la population retenue en bas de la fraction. Cette imprécision reste de très loin la première cause de réunions stériles entre un marchand et son prestataire. Les deux parties y avancent des chiffres exacts qui ne portent pas sur la même population.
| Population au dénominateur | Volume | Ce qu’elle contient | Ce qu’elle exclut | Qui la maîtrise |
|---|---|---|---|---|
| Sessions entrées au checkout | 10 000 | Tout visiteur ayant affiché le formulaire de paiement | Les abandons de panier en amont | Produit, UX, acquisition |
| Tentatives de paiement client | 9 200 | Chaque validation du formulaire, y compris celles que les règles du marchand refuseront | Les sessions sans aucune tentative | Marchand (parcours, moyens proposés) |
| Demandes d’autorisation soumises | 8 615 | Les messages réellement envoyés au réseau, relances incluses | Les refus du moteur de fraude et les échecs d’authentification : aucune autorisation n’est partie | PSP + paramétrage marchand |
| Autorisations approuvées | 8 020 | Les réponses positives des émetteurs | Les refus émetteur, dont les soft declines rejouables | Émetteurs (subi), qualité des données (agi) |
| Transactions réglées (settled) | 7 985 | Ce qui est capturé puis compensé : base de la facturation PSP et des ratios de réseau | Les autorisations expirées ou annulées avant capture | Marchand (capture) + acquéreur |
Taux d’autorisation ≠ taux d’acceptation
Le taux d’autorisation rapporte les demandes approuvées aux demandes effectivement envoyées aux émetteurs, ce qui en fait une vue réseau. Le taux d’acceptation rapporte les paiements aboutis à l’ensemble des tentatives du client, ce qui en fait une vue client. Ce sont les deux indicateurs les plus confondus du métier. Le second englobe des tentatives que le premier ignore, notamment celles que le moteur de fraude du commerçant a refusées et celles qui se sont perdues dans une authentification. La conséquence est contre-intuitive, et pourtant systématique. Un filtre anti-fraude qui bloque 5 % du trafic en amont améliore mécaniquement le taux d’autorisation et dégrade le taux d’acceptation, puisqu’il retire du dénominateur du premier des tentatives qui restent au dénominateur du second. La divergence des deux courbes ne traduit donc pas une erreur de mesure : elle chiffre la part des refus décidés par le commerçant lui-même, et constitue à ce titre le signal le plus utile du tableau de bord.
# 1. TAUX D'AUTORISATION (« authorization rate ») - vue reseau
nombre de demandes d'autorisation APPROUVEES
TxAuth = ---------------------------------------------------
nombre de demandes d'autorisation SOUMISES au reseau
Exclut : les paniers abandonnes, les refus du moteur de fraude en amont,
les echecs d'authentification (aucun message n'a ete emis),
les verifications de compte a 0,00 EUR (account verification).
Piege : les relances gonflent numerateur ET denominateur.
Publier deux versions : au 1er essai / apres relances.
# 2. TAUX D'ACCEPTATION (« acceptance rate ») - vue client
nombre de paiements ABOUTIS (autorises puis captures)
TxAccept = -----------------------------------------------------------
nombre de TENTATIVES DE PAIEMENT initiees par le client
(y compris refus des regles internes du marchand, abandons 3DS)
# 3. TAUX DE CONVERSION DU CHECKOUT - vue business
nombre de commandes payees
TxConv = --------------------------------------
nombre de sessions entrees au checkout
# Sur une meme periode : TxAuth >= TxAccept >= TxConv, toujours.
# Un ecart TxAuth - TxAccept qui s'ecarte = les refus internes augmentent.Lire les refus : le mix de codes vaut mieux qu’un taux
Le code de réponse d’une demande d’autorisation vient de l’émetteur et figure dans le champ 39 du message ISO 8583. Il désigne le motif du rejet, là où un taux global se borne à en constater le volume. Un taux d’autorisation ayant perdu 1,5 point ne désigne aucun correctif, tandis que la distribution des codes de refus oriente directement le travail de correction. Ce code est souvent accompagné d’un Merchant Advice Code, qui précise si une nouvelle tentative est permise. Le suivi quotidien de la part des cinq premiers codes, segment par segment, remplace à lui seul dix tableaux de bord. Cette lecture sépare l’incident d’émetteur, concentré sur quelques identifiants, de l’erreur de paramétrage, qui touche tous les segments au même instant.
| Code | Libellé réseau | Traduction opérationnelle | Relance ? | Correctif durable |
|---|---|---|---|---|
05 | Do not honor | Refus discrétionnaire de l’émetteur, sur son propre score de risque : le fourre-tout du refus à distance | Possible, rendement faible | Enrichir les données envoyées (adresse, e-mail, indicateurs de transaction), passer en 3-D Secure sur le segment concerné |
51 | Insufficient funds | Provision insuffisante, un refus temporaire, pas un refus de risque | Oui, mais en différé | Relance calendaire (lendemain, jour de paie), pas d’insistance immédiate |
54 | Expired card | Carte périmée dans le parc de coordonnées stockées | Non, tant que la donnée n’est pas rafraîchie | Brancher les services de mise à jour (Visa Account Updater, Mastercard Automatic Billing Updater), tokeniser |
14 | Invalid card number | Numéro erroné… ou test de cartes volées en rafale | Non | Contrôle de clé de Luhn côté formulaire, limitation de débit, alerte énumération |
65 (Mastercard) / 1A (Visa) | Soft decline, authentification forte requise | L’émetteur refuse l’exemption demandée et exige une authentification : le refus vient du paramétrage marchand, pas du client | Oui, une fois, via un challenge 3-D Secure | Réduire le périmètre d’exemption sur ce segment, vérifier la reprise automatique en challenge |
12 | Invalid transaction | Un champ du message est incohérent : indicateur de transaction initiée par le marchand, devise, MCC, type d’opération | Non avant correction | Audit champ par champ du message d’autorisation, rejeu comparatif avant/après déploiement |
57 | Transaction not permitted to cardholder | Le produit carte n’autorise pas cet usage : prépayée, carte commerciale, restrictions d’usage | Non | Proposer un autre moyen de paiement, segmenter le suivi par type de carte |
04 · 41 · 43 · 59 | Carte à conserver, perdue, volée, suspicion de fraude | Décision ferme de l’émetteur | Jamais (Merchant Advice Code 03) | Arrêt immédiat des tentatives, mise à l’écart du moyen de paiement, contrôle de la piste de fraude |
Émetteur, paramétrage ou produit ? L’arbre de diagnostic
Toute dégradation de performance de paiement appartient à l’une de trois familles, que le diagnostic doit séparer avant toute correction. Un problème d’émetteur est subi par le commerçant et relève de l’escalade auprès de l’acquéreur, puis du réseau. Un problème de paramétrage provient des réglages du commerçant lui-même et se corrige en heures, une fois le champ fautif identifié. Un problème de produit tient au parc de cartes, à la tarification, à la livraison ou au mix client. L’attribution spontanée à l’émetteur se révèle inexacte dans la majorité des cas, et le critère qui départage les trois familles porte sur la façon dont l’anomalie se répartit entre les segments. Plus une anomalie est concentrée, plus elle est identifiable. Un incident d’émetteur réel frappe un ou deux BIN et laisse tous les autres segments parfaitement plats. Un défaut de paramétrage frappe au contraire tous les segments à la fois, à partir d’un instant précis qui coïncide avec un changement daté côté commerçant.
| Symptôme observé | Hypothèse | Test discriminant | Correctif |
|---|---|---|---|
| Chute concentrée sur un BIN ou un émetteur, autres segments plats | Émetteur : changement de score, incident, migration de plateforme | Même heure J vs J−7 sur ce BIN seul ; demander à l’acquéreur si d’autres marchands de son portefeuille le voient | Escalade acquéreur → réseau ; en configuration multi-acquéreur, router temporairement ce BIN ailleurs |
| Chute transverse à tous les émetteurs, à une heure précise | Paramétrage : déploiement, certificat, champ manquant, mauvaise version d’API | Rejouer un message d’autorisation d’avant et d’après le déploiement, comparer champ par champ | Retour arrière, puis correction du champ fautif (indicateur d’initiateur, montant, devise, MCC) |
Explosion des 65 / 1A (soft declines) | Paramétrage : périmètre d’exemption SCA trop large | Taux de soft decline par tranche de montant et par pays : il grimpe exactement là où l’exemption est demandée | Resserrer le périmètre d’exemption, garantir la reprise en challenge sans nouvelle saisie du client |
Hausse des 54 / 14 sur les abonnements uniquement | Produit : parc de coordonnées stockées vieillissant | Âge moyen des coordonnées refusées vs âge moyen du parc | Mise à jour automatique des cartes, tokenisation, relance client sur les cartes bientôt périmées |
| Taux d’autorisation stable mais taux d’acceptation en baisse | Produit / règles internes : le refus vient du marchand | Décomposer les tentatives arrêtées avant l’envoi réseau (moteur de fraude, contrôles panier, plafonds) | Réviser les règles, mesurer les faux refus par groupe de contrôle |
Rafales de 14 / 05 sur des montants minuscules | Attaque d’énumération de cartes (card testing), pas un problème de paramétrage | Distribution des montants, des IP et des e-mails : quelques centimes, numéros séquentiels, adresses jetables | Limitation de débit, CAPTCHA, blocage temporaire ; le ratio d’énumération est surveillé par Visa (voir section suivante) |
Fraude, chargebacks, récupération : les ratios que le marchand ne fixe pas
Sur ce périmètre, la définition des indicateurs relève des réseaux, et leurs ratios sont ceux qui déclenchent des pénalités. Deux objets distincts sont constamment confondus. Le taux de fraude se construit à partir des déclarations des émetteurs, transmises par l’acquéreur sous la forme de fichiers TC40 chez Visa et SAFE chez Mastercard. Le taux de chargeback se construit à partir des litiges effectivement ouverts. Une fraude déclarée ne devient pas toujours un chargeback, et un chargeback ne correspond pas toujours à une fraude. Une part substantielle des litiges relève de la non-livraison ou du produit non conforme, dont la correction ne passe pas par les mêmes outils qu’une fraude. Le suivi séparé des deux séries, chacune avec son découpage par motif, évite de traiter un problème de logistique par un durcissement du moteur de fraude.
# 1. TAUX DE FRAUDE, en points de base de la VALEUR (vision reseau)
montant des transactions declarees frauduleuses par les emetteurs
bps_fraude = ---------------------------------------------------------------- x 10 000
montant des transactions REGLEES sur la periode
Source : fichiers TC40 (Visa) / SAFE (Mastercard) relayes par l'acquereur.
Ce n'est PAS le fichier de chargebacks du marchand, et il arrive plus tot.
# 2. TAUX DE CHARGEBACK, en NOMBRE - deux dénominateurs officiels
Visa (ratio VAMP, mensuel) :
(nb de fraudes TC40 + nb de litiges TC15) / nb de transactions CNP REGLEES du mois
Mastercard (programme ECM, mensuel) :
nb de chargebacks recus le mois M / nb de transactions du mois M-1
-> Meme realite, deux chiffres. Un mois de forte croissance FLATTE le ratio
Visa (denominateur du mois courant) et DEGRADE le ratio Mastercard des le
mois suivant, sans qu'un seul litige ait change de nature.
# 3. TAUX DE RECUPERATION (a ne pas confondre avec le taux de gain)
Taux de gain = litiges gagnes / litiges CONTESTES
Taux de recuperation = montant recupere / montant total des chargebacks RECUS
-> Seul le second entre dans le compte de resultat. Un taux de gain de 70 %
sur 10 % des litiges contestes = 7 % de recuperation reelle.
# 4. PERTE NETTE DE FRAUDE (le chiffre qui paie les salaires)
perte_nette = chargebacks de fraude perdus + frais de litige
+ remboursements de complaisance - montants recuperes
a rapporter au CA encaisse de la MEME cohorte de transactions.| Programme | Ratio surveillé | Seuil | Plancher de déclenchement | Conséquence |
|---|---|---|---|---|
| Visa VAMP, marchand (remplace VFMP et VDMP depuis le 1er avril 2025) | (fraudes TC40 + litiges TC15) ÷ transactions à distance réglées, par mois | Excessive : 1,50 % depuis le 1er avril 2026 (2,20 % auparavant ; la région CEMEA reste à 2,20 %) | Au moins 1 500 événements fraude + litige dans le mois (CEMEA : 150 et 75 000 $) | Frais annoncés à 8 $ par événement, plan de remédiation, pression immédiate de l’acquéreur |
| Visa VAMP, énumération (card testing) | tentatives d’autorisation énumérées ÷ tentatives d’autorisation totales | 20 % | De l’ordre de 300 000 tentatives énumérées dans le mois | Enrôlement dans le volet énumération, frais par tentative |
| Visa VAMP, portefeuille de l’acquéreur | le même ratio, agrégé sur tout son portefeuille | Above standard 0,50 % · Excessive 0,70 % | – | L’acquéreur peut rompre la relation bien avant le seuil du marchand : c’est son ratio qu’il protège, pas celui de son client |
| Mastercard ECM | nb de chargebacks du mois M ÷ nb de transactions du mois M−1 | 1,5 % ET ≥ 100 chargebacks dans le mois | Les deux conditions, cumulatives | Amendes mensuelles croissantes, Issuer Recovery Assessment, risque d’inscription sur la liste MATCH |
| Mastercard HECM (palier haut) | idem | 3 % ET ≥ 300 chargebacks | Cumulatives | Pénalités très supérieures, sortie conditionnée à plusieurs mois consécutifs sous le seuil |
| Mastercard EFM (fraude) | chargebacks de fraude ÷ transactions e-commerce du mois précédent | 50 points de base ET ≥ 1 000 transactions e-commerce ET ≥ 50 000 $ de fraude ET moins de 10 % du volume en 3-D Secure (50 % dans les pays dits régulés) | Les quatre conditions, cumulatives | Programme fraude ; en Europe, le critère 3-D Secure écarte de fait les marchands conformes à la DSP2 |
| Exemption TRA, seuil réglementaire, pas de réseau | taux de fraude du PSP, en valeur (pas celui du marchand) | 0,13 % jusqu’à 100 € · 0,06 % jusqu’à 250 € · 0,01 % jusqu’à 500 € (RTS (UE) 2018/389, annexe) | – | Au-delà, le PSP perd le droit d’exempter à ce palier : les challenges remontent sans aucun changement côté marchand |
Le temps : le taux de fraude de juin n’est pas encore connu
Les événements de risque attachés à une transaction se déclarent après elle, à des délais qui diffèrent selon leur nature. Une déclaration de fraude parvient au commerçant en quelques jours, un chargeback en quelques semaines, une contestation légale jusqu’à treize mois plus tard. Un taux de fraude calculé sur la date de réception des fichiers additionne des événements issus de mois d’origine différents, et il sous-estime systématiquement les périodes récentes. Le mois le plus proche de la date de calcul paraît toujours excellent, parce que ses événements ne sont pas encore arrivés. Toute mesure corrective y semble efficace immédiatement. Ce mécanisme est celui du biais de survie, connu des tableaux de bord de crédit, et il produit les mêmes effets sur les indicateurs de paiement.
Segmenter, sinon rien : un taux global ne dit rien
Un taux global agrège des populations dont les niveaux de risque et les comportements diffèrent fortement, et sa valeur dépend alors du poids relatif de chacune. Les statistiques nationales de la fraude en donnent une illustration à grande échelle. En France, au 1er semestre 2025, le taux de fraude carte vaut 0,010 % en paiement de proximité et 0,129 % sur internet, soit un rapport de 1 à 13 (OSMP). Sur les seuls paiements internet, il vaut 0,07 % en national, 0,24 % vers l’EEE et 0,55 % hors EEE. Aucune de ces valeurs ne constitue à elle seule le taux de fraude, chacune décrivant une population différente. La segmentation précède donc l’interprétation d’un indicateur de paiement.
| Axe | Ce qu’il révèle | Ordre de grandeur observé (source) | Décision qu’il déclenche |
|---|---|---|---|
| Pays du porteur / corridor | Frontières réglementaires (authentification forte obligatoire ou non), comportement des émetteurs, habitudes locales | Fraude internet France : 0,07 % national, 0,24 % France→EEE, 0,55 % France→hors EEE (OSMP, S1 2025) | Acquisition locale, routage par corridor, règles de fraude différenciées |
| Réseau (CB, Visa, Mastercard, autres) | Choix de marque sur les cartes co-badgées, coût d’interchange, comportement d’autorisation | – | Priorité de routage, arbitrage tarifaire |
| Émetteur / BIN | Le seul niveau où un incident d’émetteur devient visible | – | Escalade acquéreur, bascule d’acquéreur, test A/B de champs |
| Type de carte (débit, crédit, prépayée, commerciale) | Refus structurels (57), provision insuffisante (51), et surtout le coût | Plafonds d’interchange UE : 0,2 % en débit et 0,3 % en crédit pour les cartes de consommateurs (règlement (UE) 2015/751, art. 3 et 4) ; cartes commerciales et cartes non-EEE non plafonnées | Tarification, moyens alternatifs mis en avant, relances calendaires |
| Canal | L’axe qui domine tous les autres | Fraude carte France : 0,010 % en proximité, 0,013 % en paiement mobile, 0,129 % sur internet, 0,246 % à distance hors internet (OSMP, S1 2025) | Budget anti-fraude, périmètre 3-D Secure, choix de MCC |
| Flux d’authentification (challenge, sans friction, hors 3-D Secure, initié par le marchand) | L’effet réel du paramétrage SCA, invisible ailleurs | Fraude des paiements initiés par le marchand non authentifiés, en France : 0,241 % au S1 2025 contre 0,314 % en 2024 (OSMP) | Périmètre d’exemption, bascule en challenge, correction des indicateurs de transaction |
| Tranche de montant | Les seuils d’exemption et la signature des attaques de test | Paliers réglementaires de l’exemption TRA : 100 €, 250 €, 500 € (RTS (UE) 2018/389) | Bornes d’exemption, plafonds de vélocité, règles de relance |
p observé sur n transactions, l’incertitude à 95 % vaut environ 1,96 × √(p(1−p)/n). Un taux d’autorisation de 90 % mesuré sur 200 transactions se lit 90 % ± 4 points. Un écart de 3 points entre deux BIN de ce volume n’existe pas au sens statistique, puisqu’il tient entièrement dans l’intervalle d’incertitude de chacune des deux mesures. Pour distinguer honnêtement 90 % de 91 %, il faut environ 3 500 transactions dans le segment. Un n minimal se fixe donc par convention, les segments plus petits étant regroupés sous une rubrique « autres », et aucune investigation n’est ouverte sous ce seuil. Les données publiées font apparaître un second effet, moins intuitif. En France, le parcours sans friction affiche un taux de fraude plus bas que le parcours avec authentification forte (0,054 % contre 0,089 % en 3-D Secure, OSMP, S1 2025). Cet écart ne renseigne pas sur l’efficacité de l’authentification forte. Il tient à la constitution des deux populations, l’analyse de risque orientant vers le parcours sans friction les transactions qu’elle estime les moins risquées. Deux segments constitués par des règles de sélection différentes ne sont pas comparables, l’écart observé reflétant la règle de sélection autant que le parcours lui-même.Le coût total d’acceptation : additionner ce que personne n’additionne
Le coût total d’acceptation désigne la somme des charges supportées par le commerçant pour encaisser un paiement, au-delà de la seule commission facturée par son prestataire. Il additionne les frais, les pertes de fraude nettes, les frais de litige et l’immobilisation de trésorerie. Il y ajoute le manque à gagner des refus injustifiés, poste le plus souvent absent des tableaux. La commission de service commerçant n’en constitue que la partie visible et facturée. Ce coût s’exprime en points de base du volume traité, seule unité comparable d’un mois, d’un pays ou d’un prestataire à l’autre.
| Composant | Nature | Où le lire | Levier réel |
|---|---|---|---|
| Interchange | Reversé à l’émetteur ; plafonné dans l’UE à 0,2 % en débit et 0,3 % en crédit pour les cartes de consommateurs | Détail non groupé du rapport d’acquisition (règlement (UE) 2015/751, art. 9 et 12) | Qualité des données d’autorisation, mix de types de cartes, corridor ; rien à négocier sur le plafond lui-même |
| Frais de réseau (scheme fees) | Facturés par Visa, Mastercard, CB : souvent une dizaine de lignes distinctes | Même détail non groupé, ligne à ligne | Peu négociables mais très auditables : les erreurs de qualification y sont fréquentes |
| Marge de l’acquéreur / du PSP | Le seul poste réellement négociable | Contrat et facture mensuelle | Mise en concurrence, tarification interchange++ plutôt que tarif mélangé |
| Frais par autorisation | Facturé y compris quand la transaction est refusée | Lignes de volumétrie de la facture PSP | Supprimer les relances non rejouables, bloquer l’énumération |
| Authentification 3-D Secure | Frais par authentification, parfois majoré par challenge | Facture PSP | Périmètre d’exemption, en gardant en tête le coût des refus qu’il provoque |
| Remboursements et litiges | Frais fixes par remboursement et par chargeback (usuellement quelques dizaines d’euros par litige selon contrat) | Facture PSP et rapports de litige | Prévention avant litige, qualité de la livraison, contestation ciblée sur les motifs gagnables |
| Change | Marge appliquée au taux (FX markup), à distinguer du taux de référence | Rapport de settlement, colonne du taux appliqué | Comparer au taux de référence du jour, négocier la marge, encaisser en devise locale |
| Immobilisation de trésorerie | Délai de versement et réserve glissante | Rapports de settlement et relevés bancaires | Négocier le délai (J+1 contre J+7) et le pourcentage de réserve |
| Faux refus | Le coût invisible : la marge perdue sur des clients solvables refusés | Nulle part : il faut l’estimer | Groupe de contrôle : laisser passer une fraction du trafic limite et mesurer la fraude réellement constatée |
Perimetre : 1 mois, e-commerce, 100 000 transactions reglees, panier moyen 60 EUR
Volume regle = 6 000 000 EUR
FRAIS DIRECTS
Interchange (0,21 % moyen pondere) 12 600 EUR
Frais de reseau 3 400 EUR
Marge acquereur / PSP (0,15 % + 0,05 EUR / tr) 14 000 EUR
Frais d'autorisation (0,02 EUR x 108 000 tentatives) 2 160 EUR
3-D Secure (0,03 EUR x 92 000 authentifications) 2 760 EUR
Remboursements (900 x 0,20 EUR) 180 EUR
Litiges (180 chargebacks x 15 EUR) 2 700 EUR
Marge de change (0,45 % sur 300 000 EUR) 1 350 EUR
-----------
Sous-total frais 39 150 EUR = 65 bps
PERTES DE RISQUE (cohorte, apres recuperation)
Fraude nette perdue 11 000 EUR = 18 bps
COUT DU CAPITAL
7 jours de decalage de versement + 5 % de reserve
~ 1 500 000 EUR immobilises a 3,5 % / an 4 375 EUR = 7 bps
-----------
COUT TOTAL D'ACCEPTATION 54 525 EUR = 91 bps
MANQUE A GAGNER (hors cout, mais decisif dans l'arbitrage)
600 faux refus estimes x 60 EUR x 25 % de marge 9 000 EUR
-> l'equivalent de 15 bps : durcir les regles de fraude
peut couter plus cher que la fraude evitee.Le tableau de bord minimal : sources, fréquences, seuils d’alerte
Un tableau de bord de paiement opérationnel tient en une douzaine d’indicateurs et trois cadences de publication. Il s’alimente à cinq sources de données : rapports transactionnels du PSP, rapports de règlement, fichiers de fraude transmis par l’acquéreur, fichiers de litige et relevés bancaires. Les rapports transactionnels sont obtenus par API ou par dépôt de fichiers, et les relevés bancaires se présentent au format camt.053, ou CFONB120 en France. Ces relevés assurent le bouclage avec la trésorerie. Les analyses produites en dehors de ces sources et de ces cadences relèvent de l’étude ponctuelle, et non du pilotage régulier.
| Indicateur | Source | Fréquence | Règle d’alerte | Décision |
|---|---|---|---|---|
| Taux d’autorisation au premier essai | Rapport transactionnel PSP | Quotidien | −2 points contre le même jour de la semaine précédente, sur un segment ≥ 3 500 transactions | Ouvrir l’arbre de diagnostic (mix de codes, déploiements) |
| Mix des cinq premiers codes de refus | Rapport transactionnel PSP | Quotidien | Un code gagne 5 points de part | Qualifier : émetteur, paramétrage ou produit |
| Taux d’acceptation client | Journal du checkout + PSP | Quotidien | Divergence avec le taux d’autorisation | Revoir les règles de refus internes |
| Écart de rapprochement versement ↔ banque | Rapports de settlement + camt.053 / CFONB120 (France) | Quotidien | Tout écart inexpliqué au-delà de 24 h | Ouvrir un dossier d’investigation, ne rien laisser en compte d’attente |
Taux de soft decline SCA (65 / 1A) | Rapport transactionnel PSP | Hebdomadaire | Hausse concentrée sur une tranche de montant ou un pays | Resserrer le périmètre d’exemption |
| Taux de challenge et taux d’abandon en challenge | Rapports du serveur 3-D Secure | Hebdomadaire | Abandon en challenge en hausse | Renégocier le périmètre, tester l’authentification déléguée |
| Taux de fraude en points de base de la valeur | Fichiers TC40 / SAFE via l’acquéreur | Mensuel, en cohortes | Trajectoire atteignant 70 % du seuil de réseau | Plan de remédiation avant l’enrôlement, pas après |
| Ratios VAMP et ECM, calculés avec leur dénominateur | Fichiers de litige + transactions réglées | Mensuel | 70 % du seuil, ou franchissement du plancher d’événements | Alerter l’acquéreur, activer la prévention avant litige |
| Taux de récupération sur litiges | Fichiers de litige PSP | Mensuel | Baisse du montant récupéré rapporté au montant reçu | Revoir les dossiers de preuve, cibler les motifs gagnables |
| Coût total d’acceptation en points de base | Factures PSP + détail non groupé + rapports de settlement | Mensuel | +3 bps sans changement de mix | Audit de facturation, mise en demeure amiable de l’acquéreur |
| Faux refus estimés | Groupe de contrôle + relances abouties | Mensuel | Coût des faux refus supérieur à la fraude évitée | Assouplir les règles sur le segment concerné |
| Délai de versement effectif | Rapports de settlement + relevés bancaires | Mensuel | Dérive du délai moyen ou hausse de la réserve retenue | Renégociation contractuelle, ajustement du plan de trésorerie |