Référence⚙️ Monétique & réseauxAvancé⏱ 20 min de lecture

🔢 Nomenclatures monétiques

MCC, BIN/IIN, ARN, RRN, STAN, ECI, transaction codes : le lexique codifié de la monétique et comment lire un ticket ou un relevé

MCC : le code catégorie commerçant

Le MCC (Merchant Category Code, ISO 18245) est un code à 4 chiffres, attribué par l'acquéreur, qui classe l'activité du commerçant. Il circule dans chaque autorisation (DE18) et dans chaque présentation en compensation. Il commande des traitements de nature très diverse : grilles d'interchange, éligibilité à des programmes, plafonds stand-in, restrictions d'usage (cartes affaires, cartes jeunes), cashback des porteurs, obligations déclaratives, voire blocages réglementaires (jeux d'argent, crypto).

MCCCatégorieParticularités
5411Supermarchés, épiceriesInterchange souvent réduit (programmes grande distribution)
5812 / 5814Restaurants / restauration rapideDistinction utile pour les cartes titres-restaurant
5541 / 5542Stations-service / automates carburant (AFD)5542 : préauth plafond + capture partielle obligatoire
5912PharmaciesProgrammes santé, restrictions cartes prépayées possibles
4111 / 4131Transports urbains / autocarsTransit EMV : agrégation de trajets, no-CVM spécifique
4511 / 3000-3299Compagnies aériennes (générique / codes propres)Chaque grande compagnie a son MCC dédié
7011 / 3501-3999Hôtels (générique / chaînes)Préauth longue durée, incrémentales, no-show
6011Retraits DABHors périmètre interchange commerçant
6051 / 6540Quasi-cash, crypto-actifs / rechargement walletSouvent traités comme avance d'espèces : frais et blocages émetteur
7995Jeux d'argent et parisInterdictions fréquentes, codes réponse 57 massifs
4814TélécomsFort taux de récurrence (abonnements)
5999Commerce de détail diversMCC « fourre-tout », scruté par les acquéreurs
MCC courants
⚠️
Le mauvais MCC coûte cher
Un MCC inexact produit trois effets distincts : interchange inadapté et payé en trop, refus émetteur injustifiés quand le MCC est bloqué par le porteur ou l'émetteur, et surtout risque de requalification par le scheme, assorti d'amendes. La dissimulation d'activité sous un MCC banal (transaction laundering) constitue une infraction aux règles réseaux. Certains MCC ouvrent à l'inverse des grilles d'interchange réduites, ce qui donne un intérêt direct à la vérification du MCC porté au contrat d'acceptation.
  • Le MCC est attribué par contrat d'acceptation : un commerçant multi-activités peut avoir plusieurs contrats/MID avec des MCC différents.
  • Les émetteurs s'appuient sur le MCC pour le contrôle parental, les cartes affaires (catégories autorisées) et les programmes de cashback.
  • En reporting, croiser MCC et taux d'acceptation révèle des poches de refus spécifiques (ex. MCC 6051 sur-refusé par certains émetteurs).

BIN / IIN : identifier l'émetteur

Les premiers chiffres du PAN forment l'IIN (Issuer Identification Number, ISO/IEC 7812), usuellement appelé BIN. Historiquement sur 6 chiffres, la norme est passée à 8 chiffres en avril 2022 pour faire face à la pénurie. Le premier chiffre (MII) indique la famille : 4 = Visa, 5 (et 2221-2720) = Mastercard, 3 = Amex/Diners/JCB, 6 = Discover/UnionPay... Le BIN pilote le routage, c'est-à-dire le choix de l'émetteur vers lequel envoyer l'autorisation. Il alimente aussi les tables BIN utilisées par les PSP pour détecter pays d'émission, type de carte (débit/crédit, consommateur/commercial) et marques co-badgées.

PréfixeMarqueLongueur PAN
4xxxxxVisa16 (parfois 13/19)
51-55, 2221-2720Mastercard16
34, 37American Express15
6011, 644-649, 65Discover16-19
35 (3528-3589)JCB16-19
62UnionPay16-19
–CBPas de plage propre : cartes co-badgées sur plages Visa/Mastercard ; l'appartenance CB se lit dans les tables BIN
Plages de numérotation usuelles
Anatomie d'un PAN (numéro fictif)
PAN : 4 9 7 0 1 0 1 2 3 4 5 6 7 8 9 0
      |_____________|                     IIN/BIN 8 chiffres : 49701012
      |                                   MII : 4 = Visa
                      |___________|       identifiant de compte individuel
                                    |     cle de Luhn (controle modulo 10)

Verification de Luhn (droite -> gauche) :
  doubler un chiffre sur deux, soustraire 9 si > 9,
  sommer le tout : total % 10 == 0  =>  PAN structurellement valide.
Attention : Luhn valide la FORME, pas l'existence du compte
(le code reponse 14 "carte invalide" reste possible).
ℹ️
Le BIN 8 et ses effets de bord
La migration BIN 6 → BIN 8 a mis en défaut quantité de systèmes sans produire d'erreur visible : règles de fraude par préfixe, troncatures PCI, tables de routage locales. L'historique « 6 premiers + 4 derniers » n'identifie plus l'émetteur. Le PCI SSC autorise désormais « 8 premiers + 4 derniers » pour les PAN d'au moins 16 chiffres. Les logiques métier fondées sur « les 6 premiers chiffres » restent donc à réviser dans les systèmes existants.

ARN, RRN, STAN : tracer une transaction

Une même transaction porte plusieurs identifiants distincts, qui varient selon l'étape du traitement et selon l'acteur qui les produit. Chacun a une portée propre, certains ne valant que le temps d'une session d'autorisation, d'autres subsistant jusqu'à l'arbitrage d'un litige. Leur distinction conditionne la réconciliation et la gestion des litiges. Une référence citée à la place d'une autre ne trouve aucune correspondance chez le destinataire.

IdentifiantFormatGénéré parSert à
STAN (DE11)6 chiffres, cycle par terminal/sessionTerminal ou hôte acquéreurApparier demande/réponse/reversal dans la session d'autorisation
RRN (DE37)12 caractères (souvent AJJJ + heure + STAN)Acquéreur/switchRéférence de recherche commune autorisation ↔ compensation
Code d'autorisation (DE38)6 caractères alphanumériquesÉmetteur (ou stand-in)Preuve de l'autorisation ; figure sur le ticket
ARN23 chiffresAcquéreur, à la présentation en compensationLA référence de bout en bout : règlement, chargebacks, arbitrage
TID (DE41) / MID (DE42)8 / 15 caractèresAcquéreur (contrat)Identifier le terminal et le contrat commerçant
Transaction ID schemeSelon réseau (ex. Banknet ref + date)SchemeRéférences internes réseau, tokenisation, MIT (transactions initiées par le commerçant)
Identifiants de transaction
Décomposition d'un ARN (Acquirer Reference Number, 23 chiffres)
ARN : 2 433261 6192 00000123456 7
      |                              format : 2 = presentation acquereur
        |____|                       BIN acquereur (6 chiffres)
               |__|                  date julienne AJJJ : 6192
                                     = annee ...6, 192e jour = 11/07/2026
                    |_________|      numero de sequence / film locator
                                |    cle de controle (Luhn)

Usage : c'est l'ARN que l'emetteur et l'acquereur citent dans
un chargeback ou une demande de justificatif. Sans ARN, pas
d'arbitrage possible aupres du scheme.
🔑
Quelle référence donner à qui ?
Le porteur qui conteste reçoit la date, le montant, les 4 derniers chiffres et le libellé. L'acquéreur demande de son côté le RRN, le code d'autorisation et le TID/MID. Le scheme (litige, arbitrage) exige l'ARN, seule référence stable après compensation. En interne, l'ID d'ordre du système est mappé vers tous les précédents. Cette table de correspondance conditionne toute réconciliation automatisée.

ECI : l'indicateur d'authentification e-commerce

L'ECI (Electronic Commerce Indicator) qualifie le niveau d'authentification d'une transaction à distance : 3-D Secure complet, tentative, ou aucune authentification. Il détermine le transfert de responsabilité (liability shift). Sur une transaction correctement authentifiée, la fraude « carte volée/usurpée » pèse sur l'émetteur, pas sur le commerçant. Chaque scheme emploie sa propre échelle de valeurs, si bien qu'une même situation d'authentification porte un code différent chez Visa et chez Mastercard.

Navigateurdevice data (~130 champs)3DS Servercôté marchand / PSPDSdirectory server schemeACSbanque émettricecollecteAReqAReqFrictionless≈ 90-95 % des transactionsChallengeOTP, app bancaire, biométrieARes = Y (risque faible)ARes = CCReq / CResLe client s'authentifievia sa banqueAuthentification réussieliability shift → l'émetteur porte la fraudeDonnées riches et cohérentes= plus de frictionless
SituationVisa / CBMastercardResponsabilité fraude
Authentification 3DS réussie (frictionless ou challenge)0502Émetteur (liability shift acquis)
Tentative : porteur/émetteur non participant, ACS indisponible (attempt)0601Émetteur (selon règles schemes)
Pas d'authentification (ou 3DS échoué, transaction poursuivie)0700Commerçant
Exemption SCA demandée par l'acquéreur (TRA, faible montant...)07 + indicateur d'exemption00/06 + indicateurCommerçant (l'exemption ne transfère pas la responsabilité)
MIT / transaction hors périmètre SCA (MOTO, one-leg-out)07 + flags MIT00 + flags MITCommerçant, sauf cas particuliers
Valeurs ECI en e-commerce
⚠️
Exemption ≠ liability shift
Une transaction exemptée de SCA (TRA acquéreur, petit montant) passe sans friction, alors que son ECI reste 07/00. En cas de fraude, le commerçant paie. L'arbitrage entre exemption et authentification met donc en balance le gain de conversion et le coût attendu de la fraude et des chargebacks. Certains PSP conduisent cet arbitrage transaction par transaction, en fonction du score de risque et du comportement observé de chaque émetteur.

Transaction codes : le langage de la compensation

En compensation, chaque enregistrement porte un code de transaction qui indique sa nature. Chez Visa (format Base II), ce sont les TC, là où chez Mastercard (IPM) la combinaison MTI + function code joue le même rôle. Ces codes structurent l'ensemble des fichiers de compensation et des rapports acquéreur, dont la lecture suppose donc de les identifier.

MTI 0100bitmap : quels DE sont présentsData Elements présentsAcquéreurÉmetteur0100 : demande d’autorisationréservation de provision, aucun mouvement de fonds0110 : réponse (DE39 + DE38)00 accord · 05 refus · 51 provision insuffisante0420 : reversal adviceneutralise l’autorisation fantôme0430 : réponse au reversalsans acquittement : répéter en 0421 (store-and-forward)0200 / 0210 : demande financièreautorisation + capture en un seul message (retrait DAB)0100 restée sans réponsetimeout : 30 à 60 s côté terminalne JAMAIS supposer le refus0400/0410 · annulation en ligne0800/0810 · sign-on, echo testLa plupart des « doubles débits » sont une autorisation fantôme non reversée, suivie d’une tentative aboutie.Un champ n’existe que si son bit est levé dans le bitmap ; une relance porte un nouveau STAN.
TCNatureSens des fonds
TC05Vente (sales draft)Émetteur → acquéreur
TC06Crédit / remboursement (credit voucher)Acquéreur → émetteur
TC07Avance d'espèces (cash disbursement)Émetteur → acquéreur
TC15 / 16 / 17Chargeback d'un TC05 / TC06 / TC07Inverse de l'original
TC25 / 26 / 27Annulation de présentation (reversal) d'un TC05 / 06 / 07Neutralise l'original
TC40Déclaration de fraude émetteur (fraud advice)Informationnel, alimente les scores et programmes de monitoring
TC10 / TC20Collecte de frais / versement de fonds (fee collection / funds disbursement)Variable
Transaction codes Visa Base II essentiels

Mastercard emploie les équivalences IPM suivantes. 1240 avec function code 200 = première présentation, l'équivalent du TC05 Visa. Puis 1240/205 = re-présentation, 1442/450-453 = chargeback et cycles suivants, 1740 = frais divers (fee collection), 1644/603 = demande de justificatif (retrieval request). Les rapports de l'acquéreur agrègent ces enregistrements, dont la restitution au niveau unitaire donne le détail des opérations sous-jacentes.

ℹ️
Le TC40 / SAFE, radar de la fraude
Chaque fraude déclarée par un porteur génère un TC40 (Visa) ou un enregistrement SAFE (Mastercard), même sans chargeback. Les schemes s'en servent pour leurs programmes de surveillance : VAMP chez Visa, qui a remplacé VFMP et VDMP en 2025 ; ECP et EFM chez Mastercard. Un commerçant peut donc être sanctionné pour excès de fraude déclarée alors que son taux de chargeback reste dans les seuils. Le TC40 et le chargeback ne comptent pas les mêmes événements.

Lire un ticket et un relevé monétique

Les nomenclatures décrites plus haut apparaissent sur deux documents d'usage courant : le ticket (facturette) imprimé ou dématérialisé, et le relevé monétique mensuel de l'acquéreur. Le premier documente une transaction unitaire. Le second couvre l'ensemble de l'activité d'un mois et la facturation qui s'y rapporte.

Entité juridiqueSIREN : une ou plusieurs conventionsContrat proximitéAcquéreur AContrat VADAcquéreur B, via PSPMID 4571120001Paris Rivoli · MCC 5651TID 00000001 · caisse 1TID 00000002 · caisse 2MID 4571120002Lyon Part-Dieu · MCC 5651TID 00000001 · caisse 1MID 8890455001site FR · règlement EURTID 01 · site webMID 8890455002site UK · règlement GBPTID 01 · app mobile1 MID = 1 unité de reportingseuils schemes comptés par MIDMCC déclaré au niveau du MIDTrop peu de MID = pilotage aveugle ; trop de MID = frais fixes et gestion multipliés.
Ticket CB commerçant, annoté ligne à ligne
        CARTE BANCAIRE
       CB SANS CONTACT            technologie utilisee (contact/sans contact)
LE 11/07/26 A 12:34:56            date et heure de la transaction
BOULANGERIE DUPONT                enseigne (DE43)
75011 PARIS
1234567                           numero de contrat commercant (MID)
00012345                          numero de terminal (TID)
############1234                  PAN masque (4 derniers chiffres seulement)
A0000000421010  CB                AID : application selectionnee (ici CB)
                                  -> sur carte co-badgee, "VISA DEBIT" ici
                                     signalerait un routage marque internationale
NO AUTO : 123456                  code d'autorisation emetteur (DE38)
001234  000012                    numero de remise / numero de transaction (STAN)
MONTANT REEL =
              12,50 EUR
DEBIT                             sens de l'operation (DEBIT/CREDIT)
      TICKET COMMERCANT           exemplaire (commercant / client)
   A CONSERVER 13 MOIS            duree de conservation recommandee (litiges)
  • L'AID trahit le routage : A0000000421010 = CB, A0000000031010 = Visa, A0000000041010 = Mastercard. Sur carte co-badgée, c'est ici que se lit la marque réellement utilisée, et donc le coût (cf. topic interchange).
  • Le code d'autorisation figure sur le ticket : c'est lui qu'on rapproche du relevé bancaire du porteur en cas de contestation « je ne reconnais pas ce paiement ».
  • PAN masqué : un ticket commerçant affichant plus que les 4 derniers chiffres (ou une date d'expiration) signale un terminal non conforme, à remonter immédiatement.
  • Sans contact + absence de ligne PIN : transaction no-CVM, contestable plus facilement ; les tickets des transactions PIN mentionnent la vérification.
Ligne du relevéCe que c'estContrôle à faire
Volume et nombre par marque (CB / Visa / MC)Mix de routage réelPart CB anormalement basse = fuite de coûts co-badge
Commissions par catégorie de carteMSC détaillée (si unblending demandé)Cohérence avec la grille contractuelle, dérive des cartes commerciales
Frais de scheme refacturésLignes réseaux (autorisation, clearing, marque)Comparer mois par mois : les hausses silencieuses sont fréquentes
Impayés / chargebacksLitiges débités avec frais de dossierRapprocher chaque ARN avec le litige correspondant
Location TPE, frais fixes, télécollecteCoûts d'infrastructureFacturation de terminaux rendus, doublons
Relevé monétique mensuel : les lignes à contrôler
🔑
L'audit du pauvre (et du malin)
Le ticket, le journal de remise et le relevé monétique couvrent à eux trois 90 % de l'audit d'une monétique de commerçant. On y lit le routage des cartes co-badgées (AID sur tickets), le coût réel par transaction (relevé ÷ volume), les délais de crédit (remise → virement) et les litiges (ARN). Ces vérifications reposent sur la grille de lecture que donnent les nomenclatures décrites plus haut, sans recours à un outillage coûteux.