Qu'est-ce que le core banking ?
Il n'existe aucune définition normative du core banking. Ni le règlement européen sur la résilience opérationnelle numérique, ni les orientations de l'Autorité bancaire européenne, ni les principes du Comité de Bâle, ni la norme ISO 20022, ni les publications des superviseurs allemand, français et européen ne définissent le terme.
Le concept réglementaire le plus proche est celui de fonction critique ou importante, employé par DORA. Il est fonctionnel et non applicatif : il qualifie ce dont la défaillance compromettrait l'activité, sans désigner un logiciel particulier.
Les définitions disponibles sont donc des définitions d'éditeurs, et elles doivent être attribuées comme telles. Temenos décrit son core banking comme le cœur battant de la banque et met en avant des capacités centrales modulaires ; Oracle insiste sur la configuration rapide de nouveaux produits et le traitement transactionnel ; Mambu présente un noyau réunissant core banking, paiements et agents d'IA. Ce sont des descriptions d'offre, pas des définitions de concept.
Ce que le core banking recouvre
En recoupant les périmètres annoncés par les éditeurs, l'ossature est stable. Quatre blocs reviennent :
- la tenue de compte — ouverture, arrêtés, positions, mouvements, intérêts ;
- les produits — dépôts, crédits, échéanciers, conditions tarifaires, et le paramétrage qui permet d'en créer de nouveaux ;
- le traitement des opérations — enregistrement, comptabilisation, traitements de fin de journée ;
- le grand livre — l'alimentation de la comptabilité et des restitutions réglementaires.
L'illustration la plus nette de ce découpage ne vient pas d'un éditeur mais d'un opérateur. Finanz Informatik, le prestataire informatique des caisses d'épargne allemandes, décrit sa plateforme OSPlus en trois blocs : le Kernbanksystem comme composant central, complété par un ensemble d'applications ; OSPlus_neo comme frontal de distribution ; et l'OSPlus-Banksteuerung pour le pilotage de l'établissement.
Cette architecture dit en creux ce que le noyau n'est pas : ni le canal par lequel le client ou le conseiller y accède, ni l'outil de pilotage qui l'exploite. La même séparation se lit chez les éditeurs, qui présentent les expériences digitales, la lutte contre la fraude, la gestion de fortune ou l'analytique comme des ensembles distincts, intégrés avec le noyau.
La frontière est déduite de l'organisation des offres et des plateformes, pas d'une définition.
Le cadre réglementaire qui pèse sur ces systèmes
Si le terme n'est pas défini, les obligations qui s'appliquent au système le sont précisément.
DORA — le règlement (UE) 2022/2554 du 14 décembre 2022 sur la résilience opérationnelle numérique du secteur financier — est applicable depuis le 17 janvier 2025. Il pose un cadre de gestion du risque lié aux technologies de l'information, encadre le risque lié aux prestataires tiers et leurs clauses contractuelles, et institue une supervision directe des prestataires désignés comme critiques par les autorités européennes de surveillance. Il harmonise ces exigences sur vingt et un types d'entités financières (ESMA).
La portée pour un système bancaire central est directe. Le règlement ne prononce jamais les mots « core banking », mais un système qui tient les comptes relève sans ambiguïté de la fonction critique ou importante, et son éditeur ou son hébergeur entre dans la catégorie des prestataires tiers de services TIC — services définis par le règlement comme des services numériques et de données fournis de manière continue via des systèmes informatiques.
Les orientations de l'ABE sur le risque TIC et de sécurité (EBA/GL/2019/04, amendées par EBA/GL/2025/02, applicables depuis le 20 mai 2025) s'adressent aux établissements de crédit, aux entreprises d'investissement et aux prestataires de services de paiement. L'amendement de 2025 a restreint leur périmètre, précisément du fait de l'entrée en application de DORA, dans un objectif de clarté juridique.
S'y ajoutent, au niveau international, les principes de résilience opérationnelle publiés par le Comité de Bâle le 31 mars 2021, et les principes d'agrégation des données de risque de janvier 2013, connus sous le nom de BCBS 239, qui portent sur la capacité d'un établissement à consolider ses données de risque et à en rendre compte.
ISO 20022, la contrainte d'interopérabilité
Un système bancaire central ne vit pas isolé : il échange avec les infrastructures de paiement, et le format de ces échanges est normalisé. ISO 20022 est une norme internationale en plusieurs parties, préparée par le comité technique ISO/TC 68 « services financiers », qui fournit une plateforme commune pour le développement des messages. Elle couvre cinq domaines — paiements, titres, financement du commerce, cartes et change — et identifie chaque message par un code à quatre lettres suivi d'un numéro : pacs pour la compensation et le règlement, pain pour l'initiation, camt pour la gestion de trésorerie.
La bascule est faite. Swift situe en novembre 2025 la fin de la période de coexistence entre le format MT et ISO 20022 pour les paiements transfrontaliers, et indiquait le 27 août 2026 que plus de 98 % des instructions de paiement sont désormais émises au format ISO 20022 (Swift). Côté infrastructure européenne, la Banque centrale européenne indique que T2, lancé en mars 2023 en remplacement de TARGET2, utilise la norme ISO 20022, comme T2S, TIPS et ECMS.
Une échéance reste ouverte, et elle vient de bouger. L'obligation de n'accepter que des adresses postales structurées ou hybrides, prévue pour le 14 novembre 2026, a été reportée : Swift a annoncé le 27 août 2026 accepter la demande de sa communauté, la nouvelle date devant être arrêtée d'ici décembre 2026. Le motif invoqué est l'inégalité d'avancement entre acteurs — en avril 2026, 61,2 % des paiements comportaient encore une adresse de débiteur non structurée. Situation au 27 août 2026.
Trois modèles d'organisation, et un cas allemand instructif
La question qui structure les projets n'est pas le choix d'un éditeur mais celui d'un modèle : développement interne, progiciel d'éditeur déployé pour l'établissement, ou plateforme mutualisée exploitée pour un réseau. Le marché allemand offre l'illustration la plus documentée du troisième modèle, parce que ses opérateurs publient leurs chiffres.
Finanz Informatik se présente comme le prestataire informatique central du groupe des caisses d'épargne allemandes. Au 30 juin 2026, l'entreprise déclare servir 338 caisses d'épargne, gérer 112 millions de comptes et compter 7 761 postes équivalent temps plein. Sur l'exercice, elle déclare traiter 219 milliards de transactions techniques pour un chiffre d'affaires de 2,6 milliards d'euros.
Atruvia, son équivalent pour les banques coopératives, déclare pour l'exercice 2025 plus de 900 clients, 97 millions de comptes, 10 milliards d'écritures et 1,9 milliard d'euros de chiffre d'affaires. Ces clients comprennent l'ensemble des Volksbanken et Raiffeisenbanken allemandes, soit environ 650 établissements.
Ces chiffres sont déclarés par les entreprises elles-mêmes et mesurent un volume géré, non une part de marché ni une performance. Ils sont cités pour une raison précise : ils donnent l'ordre de grandeur d'un système bancaire central mutualisé, et ils expliquent pourquoi le calendrier de ces plateformes s'impose aux établissements plutôt que l'inverse.
Le remplacement d'un core banking est un sujet d'usage
Un changement de système bancaire central touche des populations très différentes : conseillers en agence, gestionnaires de back-office, opérateurs de middle-office, contrôle et conformité. Leurs points de contact avec le système n'ont rien de commun, et leur tolérance à l'erreur non plus.
Trois caractéristiques distinguent ces projets :
- la bascule est rarement progressive sur le périmètre comptable : les comptes et les positions changent de système à une date donnée, ce qui fait du cutover et de l'hypercare des moments critiques ;
- l'erreur est visible par le client — un libellé d'opération erroné, un solde affiché avec retard, un prélèvement rejeté remontent immédiatement au conseiller ;
- les gestes sont nombreux et peu fréquents : un gestionnaire exécute des dizaines d'opérations différentes, dont certaines quelques fois par an, ce qui rend la mémorisation par la formation initiale illusoire.
L'accompagnement se joue donc moins sur le volume de formation dispensée avant la bascule que sur l'aide disponible dans l'application au moment de l'opération, et sur la mesure de ce qui bloque réellement, écran par écran et profil par profil. C'est le terrain de l'adoption digitale.