Lorsqu'un client utilise sa carte, le système émetteur de la banque reçoit un ensemble de données de transaction du réseau de cartes, très structuré mais étonnamment limité. Les champs sont normalisés, les valeurs sont restreintes, et la plupart des éléments qu'un utilisateur final s'attend à voir dans son application - des noms de commerçants clairs, des logos, des catégories reconnaissables, des lieux de vente précis - sont tout simplement absents du message. Tout, de la clarté du relevé aux décisions de crédit, est construit en aval de ces données brutes, ce qui fait du fossé entre ce qui est reçu et ce dont un client a besoin le problème de données le plus crucial dans la banque de détail.
Comment sont créées les données de transaction des réseaux de cartes
Chaque transaction par carte passe par trois étapes distinctes : l'autorisation, la compensation et le règlement.L'autorisationest la vérification en temps réel qui s'effectue dans les secondes suivant le paiement ou la saisie du code PIN par le titulaire de la carte. Le terminal du commerçant envoie une demande via l'acquéreur au réseau de cartes (Visa, Mastercard, Amex, Discover), qui l'achemine vers la banque émettrice pour une décision d'approbation ou de refus. La plupart de ces messages sont basés sur la norme ISO 8583, le standard qui régit les messages issus des cartes bancaires depuis 1987.
La compensationintervient plus tard, généralement par lots en fin de journée. C'est à ce moment que l'acquéreur soumet formellement la transaction pour le transfert de fonds, et elle peut contenir des données légèrement différentes ou enrichies par rapport au message d'autorisation initial.
La majeure partie des données qu'une banque utilise pour les fonctionnalités en temps réel destinées aux clients (notifications push, flux dans l'application, contrôles de fraude) provient du message d'autorisation. Ce message a été conçu pour la rapidité sur les infrastructures de télécommunications des années 1980, et non pour être lisible par l'humain.
Quelles données contient un message de paiement
Un message d'autorisation de carte bancaire type contient un petit ensemble de champs essentiels pour les produits bancaires en aval.ISO 8583y fait référence par numéro d'élément de données - Visa les appelle « Field x », Mastercard « DE x », avec une numérotation globalement alignée mais non identique.
Les champs qu'un système émetteur bancaire extrait de manière fiable incluent :
- Numéro de compte principal (DE 2)- le numéro de la carte, utilisé pour identifier le compte.
- Montant et devise de la transaction (DE 4 et DE 49)- la valeur débitée et le code devise ISO 4217.
- Date et heure (DE 7 et DE 12)- le moment où la transaction a été initiée, en heure réseau et en heure locale.
- Code de catégorie de commerçant (DE 18)- un code ISO 18245 à quatre chiffres destiné à classer l'activité principale du commerçant.
- Mode de saisie TPE (DE 22)- la manière dont la carte a été lue : puce, sans contact, piste magnétique, saisie manuelle, e-commerce.
- ID de l'acquéreur (DE 32)- identifie la banque acquéreuse qui achemine la transaction.
- ID du terminal d'acceptation de carte (DE 41)- le terminal où le paiement a été effectué.
- ID d'acceptation de carte, également appelé ID commerçant ou MID (DE 42)- identifie le commerçant au sein du système de l'acquéreur.
- Nom et emplacement de l'accepteur de carte (DE 43)- une chaîne de texte libre généralement limitée à environ 40 caractères, contenant le descripteur du commerçant, la ville et le code pays.
- BIN de la carte- les six à huit premiers chiffres du PAN, qui identifient l'institution émettrice et le produit de la carte.
C'est essentiellement ce que contient le flux brut. Cela suffit à l'émetteur pour prendre une décision d'autorisation et enregistrer une ligne dans le grand livre du titulaire de la carte. Cela ne suffit pas pour afficher une transaction claire dans une application bancaire mobile.
DE 43est à l'origine de la plupart des problèmes visibles dans les produits destinés aux clients. L'acquéreur ou le processeur le renseigne sous forme de texte libre contraint -SQ *NOM DU COMMERÇANT LDN, PAYPAL *ABOUTYOUSEC,WWW.SHOP.COM4083334000 CA, ou un simple nom commercial accompagné d'une indication de ville. La plupart des banques affichent cette chaîne de données brute à moins d'investir dans l'enrichissement des données.
Ce qui n'est pas inclus
Ce que le message réseau ne contient pas est tout aussi important. Il n'y a pas de nom de marque commerçante clair, pas de logo, pas d'adresse physique vérifiée, pas de détail des produits achetés, ni de catégorie de dépenses destinée au consommateur. Il n'y a aucune information permettant de savoir si le commerçant est une franchise, une marque au sein d'une place de marché ou un sous-locataire d'un centre commercial. Il y a rarement une URL utilisable, jamais de numéro de téléphone, et presque jamais d'identifiant de lieu structuré comme un Google Place ID.
Le champ MCC donne une indication sur le secteur d'activité du commerçant, mais il a été conçu pour le calcul des commissions d'interchange, et non pour la catégorisation destinée aux consommateurs. Le fossé se creuse en ligne : lorsqu'un client paie via une passerelle comme Stripe, PayPal ou Adyen, le descripteur reflète souvent la passerelle plutôt que l'entreprise sous-jacente, et le MCC peut suivre la classification du processeur.
Ces lacunes ne sont pas des bugs du protocole réseau. ISO 8583a été conçu pour transférer de l'argent, pas pour afficher des achats détaillés à un utilisateur. Combler ce fossé est la responsabilité de la banque.
Pourquoi les données brutes varient selon les réseaux
Au sein ducadre ISO 8583, chaque réseau de cartes maintient ses propres extensions et conventions. Visa, Mastercard, Amex, Discover et JCB publient chacun des spécifications propriétaires définissant les champs optionnels utilisés, les sous-champs renseignés et la manière dont les valeurs sont encodées. Des décennies d'évolution indépendante ont fait que les spécifications des réseaux présentent davantage de différences que de similitudes au niveau des champs.
Les acquéreurs ajoutent une couche supplémentaire de variation. La manière dont le nom du commerçant est formaté dans leDE 43, l'inclusion ou non de la ville, l'utilisation de deux ou trois caractères pour le code pays, et la conservation ou la suppression de préfixes tels que Square SQ* ou PayPal PP* — tout cela est décidé au niveau de l'acquéreur ou du processeur. Une même chaîne de commerçants travaillant avec plusieurs acquéreurs dans différents pays peut apparaître à l'émetteur sous une douzaine de formats de descripteurs différents.
La conséquence est qu'un même achat réel, effectué chez le même détaillant et dans la même devise, peut produire des chaînes de données brutes très différentes dans le système de l'émetteur selon le réseau et l'acquéreur qui l'ont acheminé. Cette incohérence est la cause profonde de la plupart des problèmes de qualité des données en aval.
Pourquoi cela est important pour les produits bancaires numériques
Chaque fonctionnalité destinée aux clients qui interagit avec le flux de transactions hérite de la qualité de ces données brutes. Une liste de transactions claire, des notifications push avec le contexte du commerçant, la recherche intégrée à l'application, les filtres intelligents, les analyses de dépenses, la gestion des abonnements, les outils de gestion financière personnelle (PFM) et de budgétisation, l'évaluation du crédit, ainsi que les flux de travail liés à la fraude et aux litiges — tous dépendent des mêmes champs sous-jacents.
Lorsque le nom du commerçant est une description vague, le client ne peut pas effectuer de recherche ou de filtrage. Lorsque le code MCC est erroné, les analyses de dépenses classent mal la catégorie. Lorsque la passerelle de paiement masque le commerçant sous-jacent, la détection des paiements récurrents ne parvient pas à regrouper les prélèvements répétés. Le coût en aval se traduit par des tickets de support, des litiges pour fraude amicale, des fonctionnalités délaissées et des clients qui migrent discrètement vers des concurrents proposant des applications mieux présentées.
Pour l'octroi de crédit, les enjeux sont encore plus élevés. L'évaluation de la solvabilité dans le cadre de régimes tels quela CCD2dans l'UE dépend de la classification des dépenses des clients en revenus, dépenses essentielles et dépenses discrétionnaires. Si les données de transaction sous-jacentes sont bruitées et incohérentes, chaque couche du modèle de crédit en pâtit. Les modèles de fraude suivent la même logique à l'inverse : ils dépendent de la détection d'écarts par rapport aux habitudes de consommation du client, à sa localisation habituelle ou à une répartition atypique des catégories. Ces trois signaux s'effondrent lorsque les noms des commerçants sont incohérents, que les localisations sont manquantes et que les catégories sont basées uniquement sur le code MCC.
Des champs bruts aux données exploitables
Combler ce fossé nécessite un enrichissement : une couche de traitement délibérée qui transforme les données brutes du réseau en un résultat prêt à l'emploi pour le produit. Elle accomplit quatre tâches que le message réseau ne peut pas réaliser.
Ellerésout l'identité du commerçant, transformant SQ *KAFFEE 12 LDN, KAFFEE 12 LIMITED et KAFFEE12.COM en une entité marchande canonique unique avec un nom commercial clair, un logo haute résolution et une hiérarchie de localisation vérifiée. Ilapplique un modèle de catégorisationqui va plusieurs niveaux plus loin que le MCC - capturant non seulement la catégorie « Alimentation et boissons », mais aussi la distinction entre un service de vente à emporter, un restaurant gastronomique et un abonnement café. Ilcomplète les données de localisationau niveau du point de vente plutôt qu'au niveau du siège social, afin que l'adresse affichée corresponde au lieu réel de l'achat. Et ildétecte des modèles à travers les transactionspour identifier les abonnements, les prélèvements automatiques récurrents et les achats fractionnés couvrant plusieurs événements d'autorisation.
Tapix se situe exactement à ce niveau. L'API reçoit des données de carte brutes - descripteur, MCC, MID, identifiant de terminal, pays, montant, devise - et renvoie un objet structuré contenant un nom de marchand propre, un logo 512x512, une catégorie à quatre niveaux, des coordonnées GPS, une URL, un numéro de téléphone, un identifiant Google Place, un indicateur de passerelle de paiement et des métadonnées CO2. Elle fonctionne avec une précision de 99,99 % et est utilisée par plus de 90 banques et fintechs dans le monde, dont la Société Générale, UniCredit, Erste, Revolut et bunq, traitant plus de 1,5 milliard de transactions par mois.
L'essentiel n'est pas l'API elle-même, mais ce qu'elle représente sur le plan architectural. Les banques qui considèrent les données de transaction brutes du réseau de cartes comme la fin de la chaîne de traitement proposent des produits clients limités par le plafond de qualité imposé par la norme ISO 8583. Celles qui les considèrent comme le début de la chaîne - et qui investissent dans une couche d'enrichissement délibérée entre le réseau et le produit - se dotent d'une base sur laquelle toutes les fonctionnalités en aval peuvent s'appuyer.
