Core Banking Radar
Les systèmes Neo Core Banking et leur contribution à l'architecture IT du futur
Depuis 2017, le Core Banking Radar de Swisscom observe en collaboration avec le Business Engineering Institute de Saint-Gall (BEI) de quel support système les banques disposent et ce qui s’offrirait potentiellement à elles. Il analyse les systèmes les plus pertinents pour le marché suisse en s’appuyant sur un modèle d’évaluation complet. Dans ce cadre, 13 systèmes Core Banking ont déjà été passés à la loupe.
Text: Christine Popp, BEI, Images: Wendy Buck, Zense GmbH,
Le paysage bancaire suisse se compose actuellement de 243 banques (source : Statista, 2022), qui reposent en grande majorité sur un système Core Banking d’un fournisseur connu. Les systèmes couvrent les besoins des banques et présentent différents avantages sur les plans fonctionnel et architectural. Quelques banques, comme les deux banques principales, disposent de leur propre système Core Banking.
La banque de demain sera marquée par diverses tendances, comme la mise en réseau croissante dans des écosystèmes ou encore dans l’Embedded Banking. Afin de proposer des services adaptés tout au long d’une «Expérience Client» (le processus suivi par la clientèle), les banques doivent faire face aux défis en constante évolution en matière de Core IT. Pour être capable de constamment anticiper les changements à venir, les banques doivent faire preuve d’une grande flexibilité et investir continuellement dans l’architecture bancaire.
Cet article porte sur le support que les systèmes peuvent apporter aux banques les banques et leur organisation à l’avenir dans un monde de plus en plus interconnecté.
Tendance : mise en réseau bancaire
Monsieur et Madame Suisse sont de plus en plus inquiets au sujet de leur prévoyance et en font part lors de leur entretien bancaire. Leur conseillère à la clientèle leur présente alors les avantages d’une assurance vie et en explique les modalités, en cas d’invalidité d’une des deux parties. Les clients signent leur contrat dans la foulée, à la banque.
Voici à quoi pourrait ressembler une Expérience Client dans le secteur de la prévoyance.
Dans un contexte d’incertitudes grandissantes, les consommateurs et les consommatrices souhaitent aussi disposer de manière digitalisée d’une vue d’ensemble de leur couverture financière. Certaines initiatives, comme le Swiss Pension Cockpit, offrent déjà cette possibilité aux clients en proposant une vue globale des trois piliers de prévoyance.
En outre, l’IoT, et donc la mise en réseau de biens physiques, gagnent en importance auprès des consommateurs. Ces derniers souhaitent à présent pouvoir payer leurs courses avec leur montre connectée, obtenir un rabais sur leur assurance automobile grâce à l’analyse de leurs comportements de conduite mesuré par leur smartphone, ou encore voir leurs trajets parcourus en train directement débités auprès de leur banque. La majorité de la clientèle n’accorde aucune importance aux prestataires ou aux conditions techniques requises, tant que tout fonctionne de manière simple et rapide.
L’Expérience Client classique ne se limite depuis bien longtemps plus à la relation des clients avec leur banque ; il prend désormais la direction d’interactions-clients, basées sur des événements. Les banques essaient de générer une plus-value complémentaire pour la clientèle grâce à leur positionnement dans des écosystèmes, par exemple en proposant des assurances adaptées aux situations. Il est ainsi envisageable de créer une Expérience Client «Vacances»: Madame Suisse se connecterait à son e-Banking depuis l’étranger et se verrait alors proposer une assurance voyage avec une couverture immédiate. Pour y parvenir, un traitement des données extérieures (par exemple, la localisation) est nécessaire . L’importance de l’Analytics, du Machine Learning et de l’Artificial Intelligence prend de l’ampleur. En parallèle, la prise de conscience et le savoir-faire en matière de gestion des données dans l’industrie financière augmentent.
Face aux développements actuels, tels que l’Embedded Banking et l’Open Banking, les banques sont contraintes de se rapprocher d’autres industries. L’établissement de partenariats dans l’écosystème ne s’accompagne pas seulement d’un développement des canaux de communication digitaux; il va également de pair avec la promotion des capacités d’intégration via les API, etc. et un niveau de standardisation élevé. Dans le même temps, la personnalisation d’une Expérience Client d’un point de vue architectural est un atout majeur pour les micro-services.
Les systèmes informatiques des banques devront répondre à de nombreuses exigences à l’avenir. L’architecture informatique bancaire de demain est notamment influencée par quatre facteurs :
- Les FinTechs, qui proposaient à leurs débuts des fonctionnalités complémentaires (par exemple, le Personal Finance Management), sont aujourd’hui partie intégrante de l’environnement bancaire (voir aussi la Swisscom FinTech Map).
- La numérisation crée un dilemme permanent entre la personnalisation et la standardisation. Les besoins personnels des consommateurs doivent être satisfaits dans l’univers numérique au moyen d’applications standardisées.
- On assiste à un découplage croissant des fonctionnalités du front office et du back office. Tandis que les fonctionnalités de back office ont toujours des cycles de vie longs (15-30 ans), les fonctionnalités de front office ont des cycles de vie très variables, qui s’étendent de quelques mois à plusieurs années.
- L’organisation centrale traditionnelle des banques, dont le but est d’orchestrer l’interaction avec la clientèle, tend à être remplacée par des formes d’organisation décentralisées. Pour ce faire, différentes technologies sont utilisées (par exemple la blockchain) afin d’intégrer des structures décentralisées et inter-entreprises. Un autre exemple est l’intégration de la communauté à l’aide de tests ou de sondages.
Pour la mise en œuvre de toutes ces évolutions, l’orientation de l’informatique bancaire représente une force motrice et une caractéristique distinctive qui doit évoluer en continu en tenant compte de l’orientation stratégique choisie et de la réglementation à venir. Il faut s’attendre à l’avenir à observer des architectures informatiques qui améliorent l’agilité, accélèrent les capacités d’adaptation des technologies, augmentent la disponibilité des interfaces et favorisent l’évolutivité et l’ouverture.
Défis pour le support système dans les banques
Dans l’environnement informatique de demain, l’interaction avec la clientèle joue un rôle central. Il convient alors de définir quel support les systèmes de demain offriront pour la fourniture de services dans cet écosystème. Afin de structurer les défis à relever, il est possible de distinguer les trois domaines suivants : gestion de la clientèle, gestion des services et gestion des systèmes.
- Gestion des clients
Si l’Expérience Client est orchestré au sein de la banque, la banque regroupe elle-même des services en intégrant des services externes (et a ainsi une vue globale du conseil et des interactions avec la clientèle). Ou bien, elle intègre ses services dans l’Expérience Client d’autres prestataires (voir Illustration 1).
Pour ce faire, la Banque doit définir les écosystèmes dans lesquels elle souhaite évoluer et les Expériences Clients qu’elle souhaite prendre en charge, ainsi que les services qu’elle souhaite fournir elle-même, et celles qu’elle externalise. La plupart des banques veulent par exemple conseiller leur client elles-mêmes, et intégrer de plus en plus les services des partenaires en complément de leurs propres services.
Trois niveaux de défis: gestion de la clientèle, gestion des services et gestion des systèmes
- Gestion des services
Afin d’orchestrer les services pour la clientèle bancaire, il est nécessaire d’avoir une vision technique et métier de l’intégration avec les partenaires.
L’intégration technique doit représenter l’ensemble des services que la banque propose à la clientèle dans une nomenclature uniforme pour tous les partenaires. Une Expérience Client permet ainsi de traduire les besoins en services et de les regrouper dans un catalogue, par exemple, et ce indépendamment du fait que la banque propose elle-même ces services, ou qu’ils soient fournis par des partenaires, comme c’était le cas dans notre exemple. Tous les partenaires impliqués doivent disposer des informations sur les produits. C’est en effet le seul moyen de coordonner les prestataires à chaque étape et de définir leurs responsabilités dans chaque situation, par exemple en cas d’invalidité dans le cadre de l’assurance-vie vendue par la banque.
Sur le plan de l’architecture, cela conduit à une conservation redondante de données, du côté de la banque et de l’assurance, ce qui exige un haut degré de compétence en gestion des données, tout comme l’intégration des données publiques disponibles dans les services.
L’intégration technique doit permettre, et ce quel que soit le canal utilisé, de fournir toute forme d’informations nécessaires aux clients, de retracer les interactions à l’aide d’un suivi adéquat, de gérer les transactions réalisées, que ce soit pour les services de la banque (achat d’une action, par exemple) ou du partenaire (modification d’une assurance-vie, par exemple). L’ensemble des données nécessaires à l’établissement des évaluations et des analyses, et notamment pour les reportings réglementaires, doivent être consignées dans une archive ou un Data Hub.
Pour ce faire, une plateforme d’intégration solide, également orchestrée à l’aide d’API ouvertes, est nécessaire. La gestion des services doit alors disposer de conventions claires sur les plans organisationnel et technique (SLA, par exemple) entre les acteurs. C’est la seule manière d’organiser efficacement la fourniture des différents services parfois complexe et de réagir rapidement en cas de problèmes. Pour fournir des services au client final, il est indispensable d’avoir une compréhension commune de la gouvernance dans l’écosystème.
- Gestion des systèmes
Dans le cadre de la gestion des systèmes, le service à la clientèle finale dans l’écosystème nécessite de plus en plus l’intégration de FinTechs ou d’autres fournisseurs en complément de l’exploitation du système Core Banking et des systèmes périphériques intégrés correspondants. Pour la banque et pour les fournisseurs du e système Core Banking, la question se pose donc de savoir, si et dans quelle mesure, les fonctionnalités doivent être reproduites dans le système Core ou acquises auprès de partenaires. Avec son moteur de comptabilisation, le système Core Banking de la banque couvre certainement tous les aspects liés au déclenchement d’une transaction l Cependant, la vue complète des transactions côté client se trouvera à l’avenir dans le Service Layer.
Les défis que nous venons de décrire entraînent une mise en réseau croissante dans l’écosystème. Pour une collaboration efficace au sein de l’écosystème, des API (ouvertes) compatibles avec les releases sont indispensables. La conception future des éléments architecturaux et la flexibilité dans l’écosystème exigent un système ouvert adéquat, ce qui n’existe pas encore dans la plupart des banques en Suisse. Les adaptations permettant de mettre à disposition et d’enregistrer librement des données à partir du système Core sont coûteuses et génèrent souvent une complexité croissante ainsi que des frais supplémentaires dans les environnements système développés.
Éléments de l’architecture informatique de demain
Dans la future architecture informatique des banques, on pourra à nouveau distinguer les trois niveaux de défis Gestion des clients, Gestion des services et Gestion des systèmes. Ils seront complétés par des éléments de l’architecture informatique de demain.
Éléments de l’architecture-système de demain répartis à trois niveaux
- Les éléments architecturaux concernant la gestion des clients comprennent tous les systèmes front ainsi que le Data Hub qui permet de gérer les données issues de l’ensemble des sources et des systèmes et qui permet de réaliser des analyses portant sur l’ensemble des données. Bien souvent, la gestion globale des données en est à ses prémices ;
- Les éléments architecturaux concernant la gestion des services comprennent le Service Integration Layer avec sa logique de collaboration avec les partenaires, tandis que l’API Layer de la banque permet d’obtenir des informations issues des applications via les API. L’utilisation d’interfaces ouvertes au sens de l’Open Banking n’est pas encore répandue en Suisse;
- Les éléments architecturaux de la gestion des systèmes comprennent le système Core Banking et son outil de comptabilisation qui enregistre toutes les transactions côté client, ainsi que des systèmes périphériques souvent étroitement intégrés (par exemple pour le Credit Rating, le SNB Reporting ou la gestion des portefeuilles) et des partenaires tels que les FinTechs ou les assureurs à différents niveaux d’intégration.
En raison notamment de l’attention accrue portée à l’interaction avec la clientèle, il semble que le front end de l’architecture bancaire devra à l’avenir intégrer les prestations de services non seulement de la banque elle-même, mais aussi de ses partenaires dans le réseau. Il devra donc gérer dans le Service Layer une gamme de services beaucoup plus large que celle de son propre système de Core Banking. Dans le même temps, la tendance est à la réduction progressive de la taille du back end de la banque, accélérée par la pression croissante de la standardisation inter-entreprises.
Les trois stratégies fondamentales (comme précisé dans un article précéden) sont sources d’opportunités et des risques.
Aperçu simplifié de l’architecture sur la base de trois stratégies fondamentales
Stratégie Core (Best of Suite):
Dans la mesure du possible, toutes les fonctionnalités de la banque sont disponibles via le système bancaire central. Ce dernier couvre donc également les systèmes front et l’API Layer.
Ainsi, la banque se repose sur son fournisseur de système Core Banking et a tout intérêt à développer un partenariat étroit avec ce dernier pour de futures optimisations communes. L’intégration de services complémentaires (assurances, par exemple) dans l’écosystème tout au long de l’Expérience Client est effectuée en collaboration avec le fournisseur système.
Stratégie Front to Back:
L’interaction avec la clientèle est davantage couverte par les systèmes de la banque. Pour ce faire, la banque dispose souvent de sa propre plateforme d’intégration. Alors qu’elle a généralement recours au système Core Banking pour les fonctionnalités back end, la banque se détache de plus en plus du système Core pour les services. Les données sont généralement traitées par le système CRM, qui est d’ailleurs une solution front. Les anciens systèmes CRM deviennent petit à petit des plateformes qui vont bien au-delà du système Core Banking et des processus bancaires clés.
Stratégie modulaire (Best of Breed):
En fonction des exigences de la banque, les fonctionnalités sont structurées de manière modulaire par différents fournisseurs. Cette approche nécessite des compétences d’intégration élevées et des connaissances technologiques qui doivent être disponibles au sein même de la banque.
Les banques optant pour une stratégie modulaire doivent en priorité développer le Service Integration Layer et l’API Layer. À l’avenir, les neo-systèmes devraient également jouer un rôle d’outil de comptabilisation dans le cadre de la stratégie modulaire étant donné qu’ils soutiennent la stratégie Best of Breed avec leur Core réduit et performant.
Les neo-systèmes Core Banking prennent de l’ampleur, gagnent des parts de marché et sont d’ores et déjà utilisés par des acteurs majeurs tels que N26. Les nouvelles approches axées sur les plateformes offrent un haut degré de standardisation, une gestion flexible des données et une architecture modulaire orientée sur les services. Elles offrent un terrain vierge, permettant ainsi de mettre en œuvre des offres purement SaaS de manière beaucoup plus cohérente par exemple. Dans le même temps, on constate une fonctionnalité limitée par rapport aux systèmes bancaires centraux connus qui reposent sur l’intégration dans un écosystème composé d’autres systèmes. Les explications ci-après caractérisent les systèmes pertinents pour la Suisse de ce point de vue.
Aperçu des neo-systèmes Core Banking pertinents pour le marché suisse
Contrairement aux systèmes traditionnels, les neo-systèmes Core Banking proposent davantage de flexibilité en termes d’architecture, mais les fonctionnalités sont moins centralisées. Tous les neo-systèmes sont (pour certains exclusivement) compatibles avec le cloud, reposent sur des micro-services et nécessitent de larges connaissances informatiques au sein de la banque.
Dans leurs fonctionnalités de base, tous les neo-systèmes se ressemblent: dans le secteur de la banque de détail, ils couvrent entièrement le noyau (comptabilisation des transactions côté client), les paiements et quelques fonctionnalités de prêt comme les hypothèques et les crédits. Deux systèmes couvrent également des fonctionnalités pour la clientèle entreprise, comme les crédits d’exploitation. Seul un neo-système a développé un service pour les titres. Les neo-systèmes Core Banking ne sont pour l’instant pas helvétisés, à l’exception d’un système qui a été développé en Suisse. Les fonctionnalités spécifiques à la Suisse, comme la QR-facture ou les prescriptions réglementaires relatives au calcul de la capacité financière pour l’octroi d’hypothèques doivent encore être développées, ou intégrées via des systèmes tiers. Les neo-systèmes Core Banking ont choisi de renoncer à la gestion du grand livre comptable (General Ledger), car elles estiment, à titre d’exemple, que la comptabilité des salaires dépasse leur domaine de compétences. L’interface pour la clientèle finale (e-Banking, Mobile Banking) est également mise à disposition par les partenaires des neo-systèmes.
La couverture des fonctionnalités de base est similaire pour tous les neo-systèmes
Malgré une couverture en apparence similaire, chaque système a ses propres caractéristiques et une approche qui lui est propre.
Mambu est un système Software-as-a-Service (SaaS) disponible uniquement via le cloud. Il se concentre sur le moteur de comptabilisation, les services de financement et les placements. Son haut niveau de standardisation permet à la société berlinoise de se développer à l’international. En d’autres termes, Mambu offre à toutes les banques une version identique avec la possibilité de personnaliser les produits à leur convenance selon la devise «Configuration over Customization».
L’architecture API permet à Mambu d’obtenir facilement des données externes ou d’intégrer des systèmes tiers. Le noyau de Mambu comprend les données, y compris le modèle de données configurable pour l’archivage et la connexion avec les données structurées ou non structurées. Afin de traiter les données, Mambu recommande de les transférer vers un Data Warehouse ou Data Lake.
Le Mambu Marketplace aide les banques à développer leur propre écosystème et à composer leur solution Best of Breed. Les coopérations nécessaires à l’échelle nationale avec des entreprises partenaires exigent des compétences d’intégration poussées (au sein de la banque ou à l’aide du réseau d’intégrateurs système de Mambu); plus de 160 installations de référence ont toutefois montré qu’il ne s’agissait pas d’un obstacle insurmontable. La possibilité d’acquérir par le biais de Mambu une solution prête à l’emploi (URL qui peut être démarrée immédiatement, avec des points d’intégration API) répond à un réel besoin sur le marché.
SolitX est un système de transaction de l’entreprise suisse Ariadne Business Analytics, qui se concentre uniquement sur le traitement des transactions dans un système Core Banking restreint, et dont le développement repose sur l’association de ce dernier à des produits financiers spécifiques aux clients.
Il se repose sur le standard ACTUS pour les Smart Contracts, qui couvre plus de 99% des contrats financiers dans le monde. Outre la possibilité de personnaliser la configuration de ces Smart Contracts, SolitX couvre la fonctionnalité de l’ensemble du Core, de la comptabilité ainsi que de tous les produits bancaires, même helvétisés.
SolitX intègre des produits de placement, des services de financement et de paiement.
Ariadne compte par exemple parmi ses clients l’entreprise suisse de développement d’une plateforme permettant le développement rapide d’une application pour des services tels que la microfinance ou le peer-to-peer lending. La gestion des produits financiers est assurée par SolitX.
Pour l’intégration des systèmes périphériques, un API Layer technique et un adaptateur DLT (Blockchain) sont à disposition.
Tuum (Estonie) vise la couverture la plus complète possible des fonctionnalités bancaires, et essaie d’intégrer les fonctionnalités manquantes en impliquant le moins de partenaires possible. Il laisse la plateforme aussi ouverte que possible, afin de pouvoir raccorder d’autres systèmes, si besoin. Tuum combine ainsi les avantages d’une stratégie modulaire et d’une stratégie Core (solution Best of Suite).
Tuum, qui peut, en fonction des besoins, être installé en local ou sur le cloud, regroupe ses services dans des modules indépendants (par exemple le module Core avec les comptes et les transactions, le module de cartes, …) disposant de leur propre base de données. Cela permet de découpler ces modules et de les lier à d’autres systèmes Core. Ainsi, la majeure partie des clients de Tuum commence avec des modules individuels.
Les produits prédéfinis, comme la saisie électronique des signatures des clients, nécessitent moins de connaissances en programmation mais l’adaptation des processus bancaires au standard de Tuum est indispensable. Tuum prend en charge le secteur Retail, mais également les opérations avec la clientèle entreprises et notamment les crédits d’exploitation. En outre, Tuum ouvre l’utilisation de ses fonctionnalités aux industries non bancaires sous la forme d’«Embedded Banking Use Case» au long du Expérience Client et compte déjà des clients non bancaires au sein de sa clientèle (dans le secteur du commerce).
Vault Platform (comprenant Vault Core et Vault Payments) de la société de technologie bancaire britannique Thought Machine repose a pour principe fondateur l’utilisation des nouvelles technologies pour optimiser les performances et les possibilités de configuration. Les fonctionnalités clés sont la comptabilisation des transactions, la gestion de compte, le développement produit (Vault Core) et, depuis cet été, la gestion des cartes et des paiements (Vault Payments). Chaque produit financier est représenté via des Smart Contracts, ce qui favorise l’introduction rapide de nouveaux produits (programmation via Python ou depuis la Product Library) et les adaptations pour répondre aux besoins individuels des clients. L’architecture de ce système est basée sur des microservices aussi granulaires que possible, chacun disposant de sa propre base de données.
L’idée sous-jacente de Vault Core est d’intégrer des fonctionnalités et des services selon les besoins via des interfaces ouvertes. À des fins d’efficacité, Vault renonce au General Ledger et à l’offre de gestion du grand livre; néanmoins, la comptabilité auxiliaire transfère en tant que «single source of truth» les transactions de tous les produits liés à la banque en temps réel dans l’entrepôt de données de la banque via le General Ledger.
La Vault Platform laisse la porte ouverte aux futurs développements architecturaux des banques et peut être relié aux systèmes existants par des banques ayant une grande affinité avec la technologie.
Leveris était une plateforme intégrative avec une architecture modulaire et évolutive qui misait sur l’analyse et l’utilisation des données en temps réel. Elle mélangeait à la fois des microservices, un Open API et un Data Lake avec des approches traditionnelles comme Oracle et les technologies PLSQL. En juillet 2021, Leveris a mis fin à ses activités en raison du ralentissement du marché des investissements dû au Covid-19 et de l’échec d’une opération financière importante.
Le tableau suivant compare les principales caractéristiques des neo-systèmes de Core Banking observés.
Caractéristiques des neo-systèmes étudiés jusqu'à présent dans le Core Banking Radar
La dynamique du marché des neo-systèmes bancaires est particulièrement élevée. Le radar central des banques observe cette évolution du point de vue suisse et a déjà pris contact avec des fournisseurs tels que 10X ou SaaScada.
Aussi bien pour les banques que pour les fournisseurs de systèmes bancaires clés, la coopération et l’utilisation de ces plateformes agiles et abordables du fait de leur faible complexité peuvent présenter, à court terme ou à long terme, une alternative intéressante pour la transformation et le développement de leurs environnement technique. Cela vaut pour chacune des stratégies fondamentales de développement (voir ci-dessus) et cette approche évite en principe un big bang qui mobiliserait des ressources importantes sur une longue période.
Conclusion
Face à l’accélération de la digitalisation, de l’Embedded Banking et de l’Open Finance, les banques doivent intensifier leurs collaborations en s’appuyant sur des logiciels. Elles doivent également davantage s’intégrer dans des écosystèmes, afin d’offrir à leur clientèle des services adaptés à leurs besoins tout au long de l'Expérience Client individuel. Pour ce faire, les banques intègre dans leur système des services issus de l’écosystème d’autres partenaires, ou se positionnent dans d’autres écosystèmes avec certains de leurs services.
Les banques et les fournisseurs doivent alors répondre à de nouvelles exigences système. L’architecture système de demain des banques peut être décrite par des éléments architecturaux à trois niveaux : la gestion des clients, la gestion des services et la gestion des systèmes.
Les caractéristiques des éléments varient en fonction de l’orientation stratégique quant au support offert par les systèmes. Les neo-systèmes Core Banking peuvent également jouer un rôle dans la mise en œuvre de la stratégie choisie. En effet, ils présentent différentes caractéristiques, une architecture moderne et un développement rapide.
Un changement ne devrait être envisagé qu’à moyen ou long terme. Pour l’instant, aucun neo-système Core Banking n’a été mis en œuvre avec succès en Suisse. De plus, l’adaptation au marché suisse nécessite encore des efforts. Le tableau ci-dessous illustre les différentes caractéristiques des neo-système Core Banking et des systèmes Core Banking établis. La caractéristique principale est certainement la couverture fonctionnelle ciblée des neo-système de Core Banking contrairement aux systèmes Core Banking établis.
Différences entre les neo-systèmes et les systèmes Core Banking établis
Les banques ont en principe deux options pour développer leur architecture système :
- Collaborer avec leur fournisseur de système de Core Banking pour mettre à disposition des éléments architecturaux permettant l’ouverture des systèmes (stratégie Core), car même les fournisseurs de systèmes de Core Banking établis doivent se pencher sur les questions de mise en réseau et de coopération;
- Chercher à collaborer avec des neo-système Core Banking, à un ou plusieurs des trois éléments architecturaux décrits, et, à partir d’une certaine taille, mettre tous ses efforts en œuvre pour développer une couche d’intégration solide à des fins d’ouverture (stratégies Front to Back et modulaire).
Dans les deux cas, il vaut la peine d’observer les évolutions et d’acquérir de l’expérience par le biais de partenariats et de gestion de services inter-entreprises. En outre, il est recommandé de formuler systématiquement des stratégies partielles en matière de gestion des données, d’analyse et d’IA afin d’absorber la redondance croissante des données.
L’un des prochains articles du Core Banking Radar sera consacré à l’élaboration de scénarios de transformation viables pour l’architecture de demain (en termes de ressources, d’argent et de temps).
En savoir plus sur ce thème:
