Comment ont évolué les systèmes bancaires centraux et quelle est la prochaine étape ?

Par : Niloy Sengupta

Les systèmes bancaires centraux ne font pas l'objet de campagnes publicitaires éclatantes.

Souvent qualifiées d'anciennes technologies, ces applications essentielles traitent les transactions quotidiennes, les mises à jour de comptes, etc. Les banques attirent les clients avec des promesses de praticité et de sécurité financière, mais ce sont les systèmes centraux qui font le gros du travail.

Ces systèmes ont également tendance à constituer des obstacles lorsque les dirigeants des banques cherchent à se moderniser.

Si la transformation du secteur bancaire est un sujet d'actualité, rappelons que les systèmes centraux sont devenus un sujet de discorde pour les chefs d'entreprise. Dans cet article, je vous invite à découvrir comment les banques peuvent moderniser leurs applications les plus critiques. 

La naissance des systèmes bancaires centraux

Les premiers systèmes bancaires centraux ont fait leur apparition dans les années 1980, ce qui a permis aux banques d'abandonner les journaux et les grands livres manuscrits utilisés depuis des siècles.

Les banques devaient être en mesure de gérer de gros volumes de transactions de manière rapide, fiable et efficace. Les systèmes bancaires centraux de première génération¹ ont donc évolué afin d'offrir centralisation, vitesse, évolutivité et fiabilité. Écrits en COBOL, Assembler, PL/I et JCL, ils étaient monolithiques et associaient étroitement des modules commerciaux interdépendants sous-jacents tels que les clients, les transactions et les produits.

Ils prenaient uniquement en charge le traitement par lots et la comptabilisation s'effectuait en fin de journée.Les soldes intrajournaliers étaient mis à disposition grâce à des solutions de contournement telles que l'enregistrement de mémos. La logique métier et la logique d’accès aux données étaient étroitement liées² et il était devenu difficile de les séparer.

La deuxième génération de systèmes bancaires centraux

À la fin des années 1980 et au début des années 1990, les systèmes bancaires de deuxième génération ont étendu le marché aux banques régionales et aux petites banques. Les nouveaux systèmes centraux ont introduit des architectures N-tier moins coûteuses qui prenaient en charge le traitement en temps réel et permettaient de séparer la logique métier front-end de la logique métier intermédiaire et de la logique d'accès aux données.

L'architecture de ces applications était généralement centrée sur les produits. Ces derniers étaient plus faciles à créer et à configurer, et de nombreuses méthodologies d'intégration ont été adoptées. Comme les applications étaient plus simples et davantage guidées par des paramètres, les banques ont pu déployer de nouveaux produits, de nouvelles fonctionnalités et proposer de nouveaux tarifs plus rapidement^.3

L'essor d'Internet dans les années 1990 a stimulé la croissance des guichets, des agences bancaires et des applications bancaires en ligne. Les investissements dans les applications bancaires centrales ont considérablement ralenti, et les problèmes d'intégration entre les systèmes front-end et les systèmes centraux sont rapidement apparus.

Pour contourner ces difficultés, les banques ont créé ou acheté des middlewares orientés services pilotés par des messages, qui ont permis une intégration plus facile et plus souple entre les applications front-end et back-end. Les cadres industriels tels que IFX, FIX et FpML ont tenté d'assurer la normalisation et l'interopérabilité entre les institutions.

La troisième génération de systèmes bancaires centraux

Dans les années 2010, les banques ont accéléré leur adoption de la banque numérique grâce aux technologies cloud. Les API REST et JSON étaient très plébiscitées pour l'échange et l'intégration de données.

Compte tenu du nombre croissant de fintechs offrant des solutions de niche et ponctuelles qui améliorent l'expérience client, les banques ont dû s'associer à ces dernières et permettre l'intégration. Les API et l'informatique dématérialisée ont favorisé l'évolution des systèmes bancaires centraux de première et de deuxième génération.

Les banques traditionnelles ont personnalisé leurs systèmes centraux à tel point que le « cap currency », la pratique qui consiste à maintenir le logiciel dans sa version la plus récente, n'est plus pratique. Pressentant une nouvelle opportunité, les fournisseurs de plateformes ont commencé à repenser leurs plateformes pour le cloud en combinant de nouveaux modèles architecturaux et en repensant les systèmes bancaires centraux de deuxième génération^4.

La plupart de ces applications centrales de troisième génération sont conçues comme des microservices. Conteneurisés, elles peuvent fonctionner sur un ou plusieurs environnement(s) de cloud public et sont pensées pour traiter les transactions en temps réel. Leur architecture découple les fonctionnalités commerciales telles que la gestion des clients et des comptes, le traitement des transactions, les relevés et les rapports.

Bien évidemment, les API sont la méthode d'intégration privilégiée pour ces nouveaux systèmes. De plus, la plupart des fournisseurs proposent également leurs propres applications de passerelle API packagées qui fournissent des pré-intégrations avec des applications internes et certaines applications tierces pour prendre en charge le large éventail de services bancaires tels que l'accueil des clients, le service client, les transferts de fonds, la gestion des cartes et d'autres services annexes^.5

La nouvelle génération : les systèmes bancaires centraux composables

Plusieurs nouveaux fournisseurs de services bancaires centraux ont pénétré le marché ces dernières années. Ils proposent la prochaine génération d'applications centrales qui présentent de nombreuses similitudes de conception avec les systèmes centraux de troisième génération, à quelques différences près. Les systèmes centraux de nouvelle génération sont véritablement « cloud native » et ont été intégralement repensés à l'aide de microservices sans aucun code remanié^.6

Certaines de ces applications utilisent des langages de programmation de pointe tels que Golang et RUST et adoptent des bases de données plus récentes telles que PostgreSQL. En outre, elles sont proposées sous la forme d'un ensemble d'API «
sans interface graphique » qui permettent des choix d'intégration flexibles sans tenter de limiter la banque à quelques fournisseurs. Ces modèles de conception rendent les systèmes centraux « composables » en ouvrant le canevas architectural et en offrant aux banques la possibilité de les tester parallèlement à leurs systèmes existants sans migrer complètement les anciens^.7

Quelques fournisseurs proposent des solutions ponctuelles de niche telles que les moteurs de produits, de tarification et de facturation, ainsi que des applications de service client conçues pour le cloud. Bien que ces applications ne remplacent pas entièrement un système bancaire central, elles sont conçues pour fonctionner en partenariat avec d'autres systèmes centraux basés sur le cloud et peuvent devenir un élément essentiel de l'écosystème des systèmes centraux composables⁸.

Ces récentes avancées dans les systèmes bancaires centraux stimulent l'innovation et permettent aux banques d'expérimenter de nouvelles piles d'applications et de nouveaux modèles de migration.

Plusieurs solutions pour moderniser les systèmes centraux

Les systèmes centraux d'ancienne génération étaient conçus pour traiter efficacement et de manière fiable de gros volumes de transactions. Bien que les nouveaux systèmes soient agiles, flexibles et offrent de nombreux avantages aux entreprises, ils restent en deça des anciennes versions sur ce point. Cela explique pourquoi les systèmes centraux d'origine persistent. Autrefois, la modernisation des systèmes bancaires centraux présentait de nombreux risques et était très coûteuse. C'est pourquoi un changement radical était la seule solution envisageable.

Il existe aujourd’hui de nombreuses solutions pour moderniser les systèmes centraux afin d'optimiser les risques, les coûts et les efforts. Les banques peuvent suivre une approche itérative et progressive. Voici quelques exemples :

• Système central « cloud-native » : mettez-les en place pour les services les plus simples, comme les canaux exclusivement numériques, et faites évoluer ces applications de manière régulière, en transférant progressivement d'autres services à partir du système existant.
• Approche transitoire : variante du système « cloud-native », mais ici, les banques peuvent envisager de transférer des produits plus simples comme les comptes épargne et les certificats de dépôt vers les nouveaux systèmes, avant de transférer les comptes chèques ou les prêts. Une banque peut également déplacer quelques segments de clientèle en fonction de leur localisation ou du comportement d'achat vers le nouveau système et l'itérer ensuite.
• Éliminer le système existant : déplacez les fonctionnalités commerciales telles que la gestion des produits et des prix, la gestion des clients, les relevés et la gestion des documents hors du système existant. Cette approche réduira le système à un simple registre de transactions afin que les banques puissent créer ou acheter des microservices pour remplacer les modules éliminés.
• Approche hybride : combinez les avantages du mainframe et du cloud en déplaçant le système du mainframe sur site vers un environnement zCloud. Ce transfert peut être une solution provisoire ou une solution cible. Cette approche offre à la banque une certaine flexibilité pour prendre la décision d'abandonner le mainframe sans perdre les avantages du cloud.

Quelle que soit la solution choisie par les banques, la modernisation des systèmes bancaires centraux ne doit pas être considérée comme un simple exercice de transformation technologique. Les changements de modèle opérationnel, en particulier la réorganisation des processus métier et la gestion des changements de personnel, doivent compléter les changements technologiques.

L'évolution des systèmes bancaires centraux se poursuit

L’évolution des systèmes bancaires centraux explique pourquoi et comment ces systèmes ont été conçus et développés pour répondre aux précédents besoins des entreprises. À mesure de l'évolution des besoins des entreprises, cette vision nous guide concernant les changements nécessaires à apporter. En tirant les leçons des erreurs passées, nous pouvons identifier de nouvelles opportunités d’innovation.

Niloy Sengupta est consultant en services financiers chez Kyndryl

¹Exemples de systèmes bancaires centraux aux États-Unis : Systematics (FIS), Hogan (DXC) et Trisyn
²Exemple : l'utilisation des données de contrôle de processus dans Hogan
³Les exemples sont légion : Profile (FIS), DNA et Premier (Fiserv), Silverlake, CoreDirector, CIF 20/20 (Jack Henry), Bancs (TCS), Finacle (Infosys), Flexcube (Oracle) et T24 (Temenos)
⁴Ils n'ont pas de code remanié provenant des systèmes antérieurs.Cela a donné lieu à des innovations, telles que l’utilisation de langages de programmation de nouvelle génération comme GoLang dans Finxact.
⁵FIS a introduit la plateforme bancaire moderne (MBP) et Temenos a transformé T24 en Transact. Fiserv, Jack Henry, Infosys, TCS, Oracle et Finastra ont tous développé des versions cloud de leurs applications centrales les plus populaires.
⁶Deux solutions pour parvenir à cette intégration sont envisageables. Des sociétés comme FIS, Fiserv et Oracle pré-intègrent les applications de leur portefeuille de produits, en essayant d'enfermer leurs clients dans leurs propres écosystèmes autant que possible. D’autre part, TCS, Infosys, Temenos et d’autres sociétés proposent une approche de place de marché où plusieurs applications tierces sont réputées interopérables avec les systèmes centraux via des API.
⁷Ces principaux fournisseurs disposent également d’un vaste marché d’applications tierces dont l’interopérabilité est certifiée et conforme aux normes du secteur bancaire ouvert telles qu'ISO 20022 et BIAN.
⁸Certaines de ces applications sont des moteurs de produits, de tarification et de facturation tels que ceux proposés par Zafin, SunTec ou Oracle RMB. Les applications de service client et d’intégration telles que Savana font également partie de cette catégorie.