Cartographier le patrimoine de données bancaires : core, canaux et bureaux de crédit

Un client appelle pour contester un débit de 47 $ passé mardi dernier. Où se trouve la « vérité » de cette transaction ? Pas à un seul endroit. Le réseau de cartes l'a vue en premier, le système core bancaire l'a comptabilisée, l'application mobile l'a affichée, et un moteur antifraude l'a scorée. Cinq systèmes, cinq horodatages, cinq versions légèrement différentes du même événement.

Savoir quel système fait autorité pour quelle question est la compétence la plus utile dans le travail sur les données bancaires. Cette leçon cartographie le patrimoine pour que vous puissiez toujours nommer la source de référence.

Le système core bancaire : le registre de référence

Le système core bancaire (souvent appelé simplement « le core ») est le grand livre mamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète →ître. Il contient les comptes, les soldes et les transactions comptabilisées qui déplacent l'argent. Voyez-le comme le grand livre de chaque relation client.

Parmi les principaux cores en 2026 : FIS, Fiserv, Temenos et Jack Henry, plus des acteurs plus récents nés dans le cloud comme Thought Machine et Mambu. Les grandes banques exploitent souvent plusieurs cores rapiécés après des décennies de fusions, raison pour laquelle un même client peut exister sous trois identifiants différents.

Ce pour quoi le core fait autorité :

• Les soldes comptabilisés (fin de journée, réglés)
• La propriété et le statut du compte (ouvert, dormant, clôturé)
• Le registre officiel des transactions après règlement

Ce que le core fait mal : les vues en temps réel. Les cores fonctionnent traditionnellement en batch processing, c'est-à-dire que les transactions sont collectées et comptabilisées lors de traitements planifiés (souvent la nuit). Le solde affiché dans le core à 14h peut donc ne pas refléter le café acheté à 13h55.

Distinction clé pour tout analyste : la date de comptabilisation (quand le core l'a enregistrée) par opposition à la date de transaction (quand elle a eu lieu). Les confondre casse la réconciliation et l'analyse de fraude.

Switchs cartes et rails de paiement : la couche argent en mouvement

Avant d'atteindre le core, une transaction traverse des réseaux.

Un switch cartes est le système qui route et autorise les transactions cartes en temps réel. Quand vous payez sans contact, le switch vérifie les fonds, applique les plafonds et renvoie une autorisation ou un refus en moins de deux secondes. Le switch dialogue avec les réseaux : Visa, Mastercard, et aux États-Unis le routage débit domestique encadré par la Regulation II (les règles de l'amendement Durbin sur l'interchange débit et le choix du réseau).

Les rails de paiement sont les tuyaux dans lesquels circule l'argent. Les principaux en 2026 :

• ACH (Automated Clearing House) : virements interbancaires en batch aux États-Unis, paie et factures.
• Fedwire et CHIPS : virements américains de gros montants.
• FedNow et RTP : paiements instantanés américains, réglés en quelques secondes, 24/7.
• SEPA dans la zone euro, et TARGET2 / T2 pour le règlement de gros montants en euros.
• SWIFT : le standard de messagerie pour les paiements transfrontaliers.

Pourquoi cela compte côté données : les données d'autorisation (issues du switch) et les données de règlement (issues du rail et du core) sont des jeux de données distincts avec des horodatages distincts. Une autorisation carte peut être approuvée puis ne jamais être réglée. Si vous comptez les autorisations comme du chiffre d'affaires, vous le surestimez.

Le secteur standardise sa messagerie sur ISO 20022, un format structuré qui transporte des données de paiement bien plus riches (détails de remise complets, adresses structurées) que les formats historiques. Pour les équipes data, c'est un cadeau : des enregistrements de paiement plus propres et plus lisibles par machine. Le centre de ressources ISO 20022 propose les spécifications gratuitement.

Logs des canaux digitaux : du comportement, pas des soldes

Chaque tap dans l'application mobile et chaque clic dans la banque en ligne génère des logs de canal ou des flux d'événements. Ce sont des données de clickstream : connexions, pages vues, tentatives de virement, échecs d'authentification, empreintes d'appareil.

Les données de canal répondent à des questions comportementales que le core ne peut pas traiter :

• Combien de clients ont abandonné le formulaire de virement ?
• De quel appareil venait la connexion ?
• Le client a-t-il consulté l'information tarifaire avant de se plaindre ?

Ces données arrivent généralement dans un pipelinepipelineL'ensemble des opportunités commerciales actives réparties selon les étapes du processus de vente, avec leur valeur potentielle cumulée et leur probabilité de conclusion.Voir la définition complète → d'événements (Kafka est courant) puis dans un data lakedata lakeUn data lake est un référentiel centralisé qui stocke de grands volumes de données brutes dans leur format d'origine, des tables structurées aux fichiers non structurés, jusqu'à ce qu'on en ait besoin.Voir la définition complète → ou un entrepôt (Snowflake, Databricks, BigQuery). Elles sont volumineuses, semi-structurées et souvent dépourvues d'une clé de compte propre, donc les joindre au core exige une couche de résolution d'identité.

Les logs de canal sont aussi centraux pour la fraude et la sécurité. Une connexion depuis un nouvel appareil dans un nouveau pays, suivie d'un changement de bénéficiaire et d'un virement important, est un schéma classique de prise de contrôle de compte, visible uniquement dans les données de canal.

Bureaux de crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →édit : la vue externe

Les bureaux de crédit détiennent les données sur la façon dont les consommateurs empruntent et remboursent auprès de l'ensemble de leurs prêteurs. Aux États-Unis, les trois grands sont Equifax, Experian et TransUnion. Au Royaume-Uni, ce sont Experian, Equifax et de nouveau TransUnion ; d'autres marchés européens ont des bureaux nationaux (par exemple SCHUFA en Allemagne).

Les données de bureau sont externes et font autorité sur un point : le comportement d'emprunt d'un client auprès d'autres établissements. Elles alimentent le scoring de crédit (les modèles américains FICO et VantageScore s'appuient sur les fichiers de bureau).

Deux réalités de données à respecter :

1. Les bureaux ne sont pas en temps réel. Les prêteurs déclarent généralement une fois par mois, un fichier de bureau peut donc avoir plusieurs semaines de retard sur le comportement réel.
2. Les données de bureau sont fortement réglementées. Aux États-Unis, le Fair Credit Reporting Act (FCRA), appliqué par le Consumer Financial Protection Bureau (CFPB) et la FTC, encadre l'exactitude, les droits de contestation et la finalité autorisée. Vous ne pouvez pas tirer un rapport de bureau sans motif légal. Dans l'UE, le RGPDRGPDRèglement de l'UE encadrant la collecte, le stockage et l'usage des données personnelles, avec des amendes indexées sur le chiffre d'affaires mondial.Voir la définition complète → et les règles nationales s'appliquent.

Synthèse : la carte des sources faisant autorité

La compétence clé : pour chaque question, nommer le système de référence.

Quand deux systèmes se contredisent, cette carte vous dit auquel faire confiance pour ce champ précis. C'est tout l'enjeu du data lineagedata lineageLe data lineage cartographie les déplacements et transformations de la donnée à travers les systèmes, de l'origine à la consommation : d'où elle vient, ce qui l'a modifiée, et où elle va.Voir la définition complète → : remonter une donnée jusqu'à son système d'origine.

Un exemple de réconciliation chiffré

La réconciliation consiste à comparer deux jeux de données censés concorder. Voici le cas le plus courant : autorisations cartes contre comptabilisations dans le core.

Supposons, pour une seule journée (chiffres illustratifs, pas des données bancaires réelles) :

• Le switch cartes déclare 10 000 autorisations pour 430 000 $
• Le core comptabilise 9 850 transactions réglées pour 421 000 $

L'écart :

Auth count 10,000 - Posted count 9,850 = 150 unposted items
Auth value $430,000 - Posted value $421,000 = $9,000 unsettled
Settlement rate = 9,850 / 10,000 = 98.5%

Un taux de règlement à J de 98,5 % est normal : certaines autorisations disparaissent (une caution d'hôtel libérée, une capture refusée, un commerçant qui n'a jamais présenté l'opération). Le travail consiste à expliquer les 1,5 %, pas à paniquer. Si le taux tombait soudainement à 90 %, cela signalerait une défaillance de flux entre le switch et le core, un véritable incident de qualité de données.

Qualité des données à travers le patrimoine

Chaque couche tombe en panne à sa manière. Connaissez les défauts courants :

• Core : identifiants clients dupliqués après des fusions, soldes batch périmés pris pour du temps réel.
• Switch cartes : autorisations sans règlement correspondant (enregistrements orphelins).
• Logs de canal : événements sans clé de compte résoluble, trafic de bots gonflant les volumes.
• Bureau : fichiers périmés, identités mal appariées (dossiers peu fournis ou rapprochements de noms approximatifs).

Une métrique de qualité de données à suivre par flux est la complétude : la part des enregistrements attendus qui sont effectivement arrivés. Si le core reçoit normalement environ 500 000 enregistrements de transaction par jour depuis le switch et qu'un matin il n'en reçoit que 400 000, la complétude est de 80 % et vous avez un flux cassé avant la première réclamation client.

Les principes BCBS 239BCBS 239Principe du Basel Committee on Banking Supervision imposant aux grandes banques une traçabilité stricte des données de risque, ayant catalysé la création de nombreux postes de CDO dans le secteur bancaire. (un standard du Comité de Bâle sur l'agrégation des données de risque pour les grandes banques) poussent exactement cette discipline : exactitude, complétude et actualité, avec un lineage clair. Ils s'appliquent aux grandes banques, mais leur check-list est une bonne pratique partout.

Où les données résident physiquement en 2026

La plupart des grandes banques fonctionnent aujourd'hui en modèle hybride : cores et systèmes de paiement on-premises ou en cloud privé (la latence et la réglementation l'imposent), avec les logs de canal, les extractions de bureau et l'analytique dans un lakehouselakehouseUne architecture hybride qui combine la flexibilité d'un data lake et les capacités analytiques d'un data warehouse, sur une seule couche de stockage.Voir la définition complète → cloud. La couche customer data platform ou golden record se place au-dessus et résout les identités entre les cores, pour que « Jane Smith » présente dans trois systèmes ne devienne qu'un seul client.

Ce golden record n'est pas lui-même une source de vérité. C'est une vue recousue. Quand vous avez besoin de la réponse qui fait autorité, vous remontez encore au système d'origine.

Points clés à retenir

• Nommez le système de référence pour chaque question. Les soldes vivent dans le core, les autorisations dans le switch, le règlement dans le rail, le comportement dans les logs de canal, l'endettement externe dans le bureau.
• Les horodatages ne sont pas interchangeables. Date de transaction, date de comptabilisation, heure d'autorisation et heure de règlement sont des champs différents issus de systèmes différents. Les confondre casse la réconciliation.
• Réconciliez entre les couches. Un taux de règlement autorisation-vers-comptabilisation à J d'environ 98 % ou plus est typique ; une chute soudaine signale une défaillance de flux de données, pas un événement business.
• Les données de bureau sont décalées et juridiquement encadrées. Elles sont déclarées mensuellement et exigent une finalité autorisée au titre du FCRA (États-Unis) ou du RGPD (UE).
• Le golden record est une vue recousue, pas la vérité. Pour des réponses qui font autorité, remontez toujours le lineage jusqu'au système d'origine.