À chaque fois qu'une carte est utilisée, qu'il s'agisse d'un paiement sans contact, d'un glissement ou d'une saisie en ligne, un flux de données de transaction brutes est généré en arrière-plan. Les banques, les processeurs de paiement et les fintechs reçoivent tous ces données, mais très peu d'entre eux parviennent à les rendre immédiatement exploitables.
Cet article explique ce que sont les données de transaction, d'où elles proviennent et pourquoi elles constituent le point de départ indispensable à la création de tout produit de paiement réellement utile aux utilisateurs.
D'où proviennent les données de transaction
Les données de transaction ne proviennent pas d'une source unique. Elles circulent à travers plusieurs segments de l'écosystème des paiements, chaque source les fournissant dans un format légèrement différent et avec un niveau de détail variable.
Les réseaux de cartes (Visa et Mastercard) sont au cœur de la plupart des flux de paiement des consommateurs. Ils acheminent les messages d'autorisation entre les banques acquéreuses et émettrices tout en transmettant un ensemble standardisé d'identifiants et de métadonnées.
Vous souhaitez en savoir plus ? Lisez notre guide de conformité pour Visa et Mastercard.
Les processeurs de paiement et les passerelles capturent les enregistrements de transaction au point d'acceptation. Leurs données sont généralement plus riches en détails au niveau du terminal, mais leur structure varie en fonction de l'acquéreur, du pays et de la configuration du terminal.
Les banques acquéreuses sont responsables de l'attribution d'identifiants tels que l'identifiant marchand (Merchant ID). Leurs enregistrements incluent des données de règlement en plus des données d'autorisation, ce qui signifie qu'une même transaction peut apparaître différemment selon les étapes du cycle de compensation.
Les fournisseurs d' open banking offrent une quatrième voie. Grâce aux licences AISP, les banques et les fintechs peuvent accéder aux données de transaction provenant d'autres institutions (souvent dans des formats différents et avec certains champs manquants), ce qui rend l'enrichissement des données à la fois plus important et plus complexe.
La conséquence pratique est qu'un même événement de paiement peut apparaître différemment selon la source qui a généré l'enregistrement. L'incohérence est présente dès le départ.
Qu'est-ce que les données de transaction ?
Les données de transaction sont les informations brutes générées automatiquement par un système de paiement ; l'enregistrement est créé lorsqu'un paiement est initié et traité tout au long du processus de règlement. Elles incluent les transactions par carte — qu'il s'agisse de débit, de crédit ou de cartes prépayées —, les virements bancaires entre comptes et, de plus en plus, les données d'open banking circulant via des canaux de partage de données réglementés. Elles sont souvent appelées, de manière interchangeable, données de paiement, bien que ces deux termes puissent avoir des significations légèrement différentes selon le contexte.
Le problème est qu'elles répondent rarement à la question que se pose un utilisateur lorsqu'il ouvre son application bancaire : « Pour quoi ai-je dépensé cet argent, et où ? »
Quelles données sont incluses ?
Lorsqu'une banque ou une fintech reçoit des données de transaction provenant d'un réseau de cartes, elles comprennent généralement un petit ensemble de champs standardisés. Prenons un exemple concret : un achat dans un supermarché Tesco à Prague. Les données brutes que la banque reçoit réellement peuvent ressembler à ceci :
- PosID – 832216
- MerchantID – 180520062
- Descriptor – TESCO PRAHA EDEN
- MCC – 5411
- City – PRAHA
- Country - CZ
C'est à peu près tout. Pas de logo. Pas d'adresse précise. Pas de catégorie confirmée. Pas d'URL. Juste un numéro de terminal, un identifiant de compte, un nom en texte libre, un code à quatre chiffres et une localisation approximative. C'est la matière première avec laquelle les banques et les fintechs doivent travailler. Approfondissons maintenant.
Explication des champs clés
Qu'est-ce qu'un identifiant de point de vente (POS ID) ?
Un identifiant de point de vente (POS ID) est l'identifiant unique d'un terminal de paiement spécifique au sein d'un magasin ; chaque caisse possède le sien. Utile pour le rapprochement bancaire et la détection de la fraude au niveau de l'acquéreur, il ne permet cependant pas d'identifier le lieu où un utilisateur a effectué ses achats.
Qu'est-ce qu'un identifiant de commerçant (Merchant ID) ?
Un identifiant de commerçant (MID) est un identifiant unique attribué à un commerçant par la banque acquéreuse lorsqu'il est autorisé à accepter les paiements par carte. Il peut s'agir d'un MID direct pour les entreprises entièrement souscrites, ou d'un sous-MID via un agrégateur de paiement. Le problème est que les MID ne sont pas stables : un détaillant comme Tesco possède plusieurs MID liés à différentes relations d'acquisition et à différents pays, et les migrations de terminaux peuvent entraîner des correspondances erronées ou des connexions manquées.
Qu'est-ce qu'un code MCC ?
Un MCC (Merchant Category Code) est un numéro à quatre chiffres décrivant le type d'activité principale d'un commerçant, défini par la norme ISO 18245 et initialement développé pour les déclarations fiscales. Il est attribué lorsqu'un commerçant installe un terminal de paiement : Tesco porte le code MCC 5411 (épicerie), une station-service le 5541. Les MCC déterminent les frais d'interchange, signalent les commerçants à haut risque et déclenchent les récompenses liées aux cartes. Le problème est qu'ils sont souvent erronés, obsolètes ou trop vagues, et qu'il n'existe aucune norme universelle.
Découvrez ce que sont les codes MCC et pourquoi ils sont nécessaires pour une catégorisation fiable.
Qu'est-ce qu'un libellé de paiement (Payment Descriptor) ?
Le libellé est le nom du commerçant en texte libre figurant sur le relevé de transaction, défini lors de la configuration du terminal. Le même magasin Tesco peut apparaître sous les noms "TESCO PRAHA EDEN", "TESCO STORES CZ" ou "TESCO SUPERSTORE" selon l'acquéreur, le micrologiciel du terminal et les données d'enregistrement du commerçant. Pour les grandes chaînes, il contient souvent des numéros de magasin ou des noms abrégés.
Qu'est-ce que la ville et le pays ?
La ville et le pays sont les champs de localisation les plus larges dans les données de transaction brutes. Ils sont transmis par le réseau de cartes dans le cadre du message d'autorisation et font partie des champs les plus fiables du flux de données. Leur utilité est limitée : une ville peut contenir des dizaines de succursales du même commerçant, et le pays seul n'apporte rien à l'identification du commerçant. Ces deux éléments sont surtout précieux en tant que signaux complémentaires pour le rapprochement des points de vente lors de l'enrichissement des données, et non en tant qu'identifiants autonomes.
Pourquoi les données de transaction sont-elles défaillantes ?
Les données de transaction ont été conçues pour le traitement des paiements, et non pour l'expérience utilisateur. Les champs qu'elles contiennent (POS ID, Merchant ID, MCC, libellé) sont suffisants pour autoriser, acheminer et régler un paiement. Ils n'ont jamais été pensés pour l'expérience utilisateur, et le résultat est évident :
Le même commerçant apparaît sous de nombreuses entités différentes. Une chaîne de supermarchés présente dans tout le pays peut avoir des dizaines d'identifiants de commerçant (un par relation d'acquisition ou par région), des centaines d'identifiants de point de vente (un par terminal) et de multiples variantes de libellés. Du point de vue des données brutes, tout cela ressemble à autant de commerçants différents.
Les catégories sont erronées ou trop vagues. Un code MCC 5999 (« Commerce de détail divers et spécialisé ») ne vous apprend pratiquement rien. Même un code plus spécifique comme le 5411 (Épicerie) ne permet pas de distinguer une petite épicerie de quartier d'un grand supermarché. Et comme les MCC peuvent être mal attribués et sont rarement mis à jour, ils ne reflètent souvent pas du tout l'activité réelle.
Le contexte est totalement absent. Les données de transaction brutes ne contiennent aucun logo, aucune adresse précise, aucun site web, aucune coordonnée GPS, aucune identité de marque. Pour une banque qui construit un flux de transactions moderne, cela signifie que chaque paiement est une page blanche : un numéro de référence en quête de sens.
Les conséquences en aval sont significatives : une mauvaise catégorisation des dépenses dans les outils de gestion financière personnelle, des historiques de transactions encombrés et illisibles, des analyses peu fiables tant pour la banque que pour l'utilisateur final, et une érosion générale de la confiance envers le produit. Heureusement, il existe une solution.
Rendre les données de transaction exploitables
Pour être utile dans un produit — qu'il s'agisse d'une application bancaire, d'un outil de gestion financière personnelle ou d'une plateforme de prêt — les données brutes de transaction doivent être enrichies. L'enrichissement consiste à prendre les identifiants bruts (posId, merchantId, descripteur, MCC, ville, pays) et à les convertir en un ensemble d'attributs structurés, lisibles par l'humain et exploitables.
Voici ce dont un produit a réellement besoin concernant une transaction :
- Un nom de marque propre et cohérent nom du commerçant - celui que l'utilisateur reconnaît, et non une chaîne de référence interne de l'acquéreur
- Un logo haute résolution logo - prêt à être affiché dans une interface utilisateur, aussi bien en format circulaire que carré
- Un catégorie vérifiée catégorie - pas simplement le code MCC, mais une catégorie sélectionnée (ex. « Alimentation », « Mode », « Transport ») avec des tags supplémentaires pour une plus grande précision
- Des données de localisation du commerçant - adresse postale, coordonnées GPS et, idéalement, un identifiant Google Places pouvant être lié à une carte
C'est là que réside l'écart entre ce que les paiements fournissent et ce que les produits bancaires numériques exigent. Combler cet écart est précisément la raison d'être de l'enrichissement des données de transaction.
Comment fonctionne Tapix
Tapix est un écosystème d'API REST conçu spécifiquement pour effectuer cet enrichissement. Il traite les données brutes données de paiement - transactions par carte, virements bancaires ou données d'open banking - en entrée, et renvoie des informations structurées et enrichies sur le commerçant et le point de vente où le paiement a eu lieu.
Le modèle de données utilisé par Tapix reflète la hiérarchie réelle du monde des paiements :
- Un commerçant est le propriétaire de la marque - Tesco, Shell, Amazon ou un café local. Les commerçants possèdent un ou plusieurs points de vente.
- Un point de vente est un emplacement physique ou en ligne spécifique - une succursale Tesco particulière, par exemple. Chaque point de vente dispose d'une adresse, de coordonnées GPS, d'une URL de site web, d'un identifiant Google Places et d'une catégorie.
- Un terminal de paiement ou une passerelle de paiement est le point d'acceptation spécifique au sein d'un point de vente, identifié par un identifiant de terminal (POS ID) ou une référence de passerelle de paiement.
Lorsqu'une banque envoie à Tapix une transaction brute (incluant n'importe quelle combinaison de posId,merchantId,descripteur,ville, et pays disponible), Tapix le résout en un shop.uid. Cet identifiant de boutique peut ensuite être utilisé pour récupérer l'ensemble des données d'enrichissement : le nom et le logo du commerçant, l'adresse de la boutique, sa localisation GPS, son identifiant Google Places, s'il s'agit d'une boutique physique ou en ligne, ainsi qu'une catégorie principale et des tags détaillés issus d'une taxonomie de plus de 25 catégories et 350 tags.
Même lorsque seules des données partielles sont disponibles - par exemple, juste un posId et merchantId - Tapix tentera de résoudre la boutique, en renvoyant un shop.uid si une correspondance est trouvée ou un identifiant non résolu qui sera traité à mesure que la couverture de Tapix s'étend.
Alors, quelles sont les prochaines étapes ? Tapix prend en charge trois parcours d'enrichissement selon votre source de données : les transactions par carte via Visa ou Mastercard, les virements bancaires via des normes telles que SEPA, BACS/Faster Payments et CERTIS, et les données d'open banking accessibles via les licences PSD2 AISP. Dans les trois cas, le résultat est identique : une identité cohérente et structurée pour chaque paiement, prête à être affichée, catégorisée et analysée.
