Core Banking Radar

De Modularbank à Tuum - un système bancaire central, pas uniquement pour les banques

Développé par des spécialistes de la banque et de l’informatique en Estonie s’occupant de concert des systèmes bancaires centraux depuis déjà des années, Tuum combine l’approche API-First avec l’objectif de proposer non seulement le cœur du système mais aussi les fonctionnalités bancaires les plus complètes possible. Ses fonctionnalités financières en particulier sont aussi utilisées par d’autres industries que les banques.

Texte: Christine Popp, Images: Wendy Buck, Zense GmbH, 09

Le Core Banking Radar de Swisscom observe depuis 2017, en collaboration avec le Business Engineering Institute de Saint-Gall (BEI), le support système des banques. Il analyse les systèmes les plus pertinents pour le marché suisse en s’appuyant sur un modèle d’évaluation complet.


Après Leveris, SolitX et Mambu, cet article décrit avec Tuum un quatrième néosystème bancaire central qui cherche et examine sur le marché la manière dont il stipule ce faisant la standardisation, la modularité et l’internationalisation.

Introduction - des solutions de licence conventionnelles vers le Cloud

Des systèmes bancaires centraux établis fonctionnent et proposent une stabilité. L’introduction de nouveaux produits et de nouvelles fonctionnalités peut néanmoins être très longue. Cela conduit les banques désireuses de proposer rapidement de nouveaux services à leur clientèle à considérer des néosystèmes bancaires centraux qui permettent une introduction des produits nettement plus rapide. Les néosystèmes bancaires centraux fixent remarquablement souvent sur le cloud une structure modulaire jusqu’aux microservices, ainsi qu’une stratégie internationale SaaS.

 

Le fait que les fournisseurs SaaS doivent prévoir une standardisation élevée pour pouvoir atteindre les économies d’échelle souhaitées et ainsi des prix très compétitifs constitue une zone tension qui apparaît dans le cloud en cas de solutions SaaS pures (Software as a Service).

 

Contrairement aux solutions individualisées, cela signifie pour la clientèle SaaS qu’elle peut à peine influencer la roadmap des produits à développer du producteur de systèmes bancaires centraux. La clientèle SaaS doit par conséquent solutionner les besoins spécifiques en particulier, par exemple issus de l’helvétisation (comme des spécificités procédurales dans les finances, les paiements ou les produits de placement) grâce à des systèmes périphériques ou à un paramétrage restreint, basé sur des standards.

 

Les concepts d’interface vers des architectures ouvertes se modifient certes pour permettre un équipement flexible sur les besoins bancaires. La complexité augmente cependant avec l’intégration.

 

Dans ce contexte, la question se pose pour les néosystèmes bancaires centraux: Peuvent-ils réellement constituer une solution pour les banques en Suisse? À partir de l’exemple concret de Tuum, nous aimerions aborder les réponses possibles à cette question.

Origine et création de Tuum

L’Estonie, indépendante depuis 1991 avant une période de reconstruction en profondeur, est aujourd’hui une société numérique grâce à l’absence de charges héritées du passé. La plupart des transactions, des signatures et des déclarations fiscales se déroulent en ligne.

 

L’équipe fondatrice de Tuum composée de cinq personnes comprenant des spécialistes du secteur de la banque et de l’informatique, ainsi que des entrepreneuses et entrepreneurs, travaillait déjà avant la création de Tuum (autrefois Modularbank) depuis huit ans côte à côte avec la Management Team d’Icefire. Cette dernière était une entreprise de consulting et de développement nordique cofondée par Vilve Vene, l’actuelle CEO de Tuum. Elle a construit depuis 2002 des infrastructures bancaires centrales pour 15 banques et ses fondateurs et fondatrices l’ont vendue en janvier 2021 à Checkout.com.

 

À l’été 2018, influencée également par l’impulsion de la clientèle, l’équipe fondatrice a décidé de placer son savoir dans sa propre plateforme et a commencé les premiers entretiens commerciaux. En janvier 2019, elle a immatriculé l’entreprise de Modularbank et a attiré son premier client, un établissement de prêts actif dans 23 pays.

 

Au cours des deux premières années, elle a financé l’entreprise et les produits avec son propre flux de trésorerie. Un premier tour de financement late seed a pris place en novembre 2020.

 

Le nom Modularbank s’est bientôt avéré trompeur, puisque de nombreuses parties intéressées ne sont pas des banques, mais par exemple des entreprises du monde du commerce ou de l’approvisionnement énergétique qui aimeraient proposer des crédits à leur clientèle. Pour cette raison, la jeune entreprise a modifié son nom en Tuum fin septembre 2021, ce qui signifie plus ou moins «cœur» en estonien. L’entreprise souligne ainsi son désir d’être considérée comme un système (bancaire) central polyvalent.

 

Tuum compte aujourd’hui environ 70 collaborateurs sur les sites de Tallinn, Berlin, Londres et Malaga. La tendance augmente rapidement.

 

Comme le nom originel le laissait entendre, Tuum propose des modules de fonctionnalités, interconnectés de manière flexible. Ceux-ci peuvent être mis en place individuellement ou combinés entre eux, selon le besoin de la clientèle (par ex. module de paiement, gestion de cartes, Credit Suite, etc.). Tuum aspire ainsi à proposer à sa clientèle une solution aussi complète que possible avec de nombreuses fonctionnalités bancaires, sur une interface utilisateur intuitive. Des connaissances de programmation de la part de la clientèle ne sont demandées que pour l’intégration d’autres fonctionnalités non spécifiques à la banque (par ex. CRM) sur les interfaces API ouvertes.
Le système basé sur les microservices peut fonctionner aussi bien sur le cloud que sur site.

 

Un principe clé de Tuum est sa stratégie architectonique consistant à laisser la plateforme ouverte et aussi extensible que possible afin de raccorder chaque type de partenaire nécessaire par Plug and Play et de soutenir les cas d’applications futures les plus divers.

 

Ce qui fait la différence pour Tuum en tant que néosystème bancaire central, c’est sa couverture planifiée de toutes les fonctionnalités bancaires dans la mesure du possible, ainsi que sa position sur le marché pour les non-banques sous forme d’«embedded finance use cases».

caractéristiques saillantes de Tuum

caractéristiques saillantes de Tuum

Structure client et positionnement sur le marché

Tuum compte actuellement jusqu’à 200 utilisatrices et utilisateurs sous forme de différentes entreprises: banques universelles, établissements de prêts globaux, Fintechs, néobanques, fournisseurs de plateforme comme Nets mais aussi PME d’autres industries.

 

Un des plus grands processeurs de cartes en Europe, le Danois Nets, qui a fusionné il y a peu avec l’Italien Nexi, mise sur le système de gestion de cartes de Tuum et fournit ainsi des cartes aussi bien physiques que virtuelles.

 

La plus grande banque universelle de Finlande traite son déroulement complet de financement via Tuum, pendant que d’autres secteurs de service continuent à fonctionner sur le système bancaire central Legacy. L’implantation réussie du néosystème moderne dans l’architecture existante a exigé selon Tuum environ 150 intégrations (moteur de comptabilisation, trésorerie, systèmes de scoring, passerelles de paiement, …).

 

Grâce à ses cas d’application embedded finance pour lesquels des outils ou des services financiers des fournisseurs non financiers sont utilisés, Tuum se positionne aussi dans d’autres industries. Le module Banking Core de Tuum traite par exemple les transactions des 700’000 utilisateurs de cartes de fidélité enregistrés d’un groupe de distribution nordique et permet l’attribution d’une limite de découvert que la clientèle peut rembourser au début du mois par facture. Il y a peu de temps, Tuum a signé un contrat avec un institut de paiement situé à Genève qui, grâce au Banking Core de Tuum, au module de paiement, au Banking Circle et au Currency Cloud Connector, aimerait soutenir des opérations transfrontalières avec des bourses multi-monnaies, des paiements et des devises.

 

Du point de vue suisse, Tuum est servie par des ressources provenant de l’espace DACH. Aucun module helvétisant ou spécifique à la Suisse n’a été implémenté jusqu’ici.

utilisation des modules de Tuum par les non-banques (embedded finance use cases)

utilisation des modules de Tuum par les non-banques (embedded finance use cases)

Fonctionnalité de Tuum

L’éventail de fonctions de Tuum s’étend en 2021 aux secteurs de la gestion de compte, de la circulation des paiements, des dépôts et du financement pour l’activité de la clientèle privée et d’entreprise.

 

Dans le secteur des paiements, Tuum met à disposition différents types de procédés de paiement (cartes, SEPA, SWIFT). Elle soutient parallèlement les e-Wallets ainsi que les échanges de supports de données pour une transmission sécurisée des données de paiement entre les entreprises et les banques, directement depuis le système ERP.

 

Tuum encourage aussi les services de financement standard comme les crédits et les hypothèques. Même la comptabilisation des garanties et l’attribution de la garantie à un crédit déterminé, incluant la détermination du pourcentage et de la validité, ainsi que le contrôle des charges héritées du passé sont possibles. Des crédits d’exploitation de Tuum peuvent de plus être perçus. Des crédits d’investissement et des crédits syndiqués devraient encore s’y ajouter avant fin 2022.

 

Des fonctionnalités dans le secteur des placements devraient être introduites au plus tard au T3/2022, potentiellement plus tôt sur demande de la clientèle. Tuum travaille aussi à l’introduction de valeurs de patrimoine digitales, convaincue qu’elles joueront à l’avenir un rôle de plus en plus important.

couverture fonctionnelle et non fonctionnelle de Tuum dans les secteurs de service des paiements et des financements

couverture fonctionnelle et non fonctionnelle de Tuum dans les secteurs de service des paiements et des financements

Tuum permet généralement l’enregistrement, l’approbation et le contrôle des paiements et des ordres relatifs aux devises, ainsi que leur traitement (déclenchement, comptabilisation, détermination des voies de paiements).

 

Dans la gestion de compte (Account Management), le déroulement de la gestion d’ordre est soutenu par le workflow. Tuum met à la disposition de sa clientèle des processus prédéfinis concernant les fonctionnalités licenciées dans son module d’orchestration de processus basé sur la plateforme Open Source Camunda et orchestre aussi des Call-Outs, par exemple pour les systèmes périphériques de vérification, les solutions KYC ou AML (mesures contre le blanchiment d’argent). Dans le management de document (Enterprise Content Management), il est possible de définir des modèles dans le système, d’y intégrer des données de manière dynamique, de les transmettre via un adaptateur aux principaux systèmes output (par ex. e-banking, impression, mobile, etc.) ainsi que de suivre le statut des documents (par ex. «signature client attendue»).

 

La possibilité d’enregistrer électroniquement la signature du client directement lors de l’entretien client ou ultérieurement de manière électronique est un bel exemple de l’ADN digital estonien.

 

Pour introduire de nouveaux produits, quelques produits (priorité basée sur des études de marché) préconfigurés sont à la disposition de la clientèle. Dans le même temps, celle-ci peut elle-même définir et paramétrer ses produits sur l’interface utilisateurs au moyen d’un design basé sur la configuration (Drag & Drop). Une commercialisation rapide est par conséquent possible sans connaissance de la programmation. Il en résulte toutefois une certaine dépendance du fabricant de banques centrales, car l’implémentation de produits très spécifiques en particulier exige le recours à Tuum.

 

Initialement, Tuum voulait aussi accepter des modèles Front-End préfabriqués, mais elle a changé d’avis après qu’il soit ressorti au cours des entretiens clients que les banques désiraient configurer elles-mêmes le Customer Journey. Les fonctionnalités Front sont ainsi mises à la disposition de la clientèle via les API. Les clientes et les clients finaux se servent du Front-End respectif (par ex. app) de la banque, les collaborateurs de celle-ci utilisant l’interface utilisateurs Middle et Back Office de Tuum.

 

Toutes les fonctionnalités, core inclus, étant couvertes aussi bien que possible par différents modules et par leurs extensions, Tuum ne table pas seulement sur une approche Best-of-Breed, contrairement à certains autres néosystèmes bancaires centraux, mais essaie de combiner les avantages d’une stratégie modulaire avec la Core Strategy (solution Best-of-Suite) (voir article sur les stratégies pour le soutien du système futur).
Le core de Tuum avec son moteur de comptabilisation fonctionne également en tant que service et par conséquent comme module interchangeable. Les modules mis en place sur le moteur de comptabilisation peuvent eux aussi tourner indépendamment du core avec d’autres systèmes bancaires centraux.

Assistance non fonctionnelle

Capacité de livraison et écosystème
 

Comme la plupart des néosystèmes bancaires centraux, Tuum a recours de manière ciblée à une utilisation large des nouvelles technologies et dispose de suffisamment de ressources pour développer, intégrer et garder en l’état le système. Différentes évaluations de parties intéressées envisageant d’utiliser un ou plusieurs modules de Tuum sont momentanément en cours. Quatre implémentations de Tuum sont de plus en cours pour fin 2021.

 

Facilité d’exploitation
 

Une maintenance ininterrompue est garantie par l’architecture basée sur le microservice et Tuum a éliminé les tâches par lot pour l’actualisation quotidienne avec le traitement complet en temps réel. Le cycle de mise à jour prévoit une mise à jour toutes les deux semaines. L’exploitation technique est soutenue par une documentation intégrée et une plateforme d’e-learning sur lesquelles les modèles de données et le système sont largement décrits, avec un rythme important d’actualisation.

 

Architecture
 

La stratégie architectonique permet aussi bien le travail avec le cloud que l’installation sur site (on premise). Chaque module de Tuum peut être testé de manière indépendante et utilise sa propre base de données. Il est possible de prévenir la duplication des données grâce au référencement (par ex., pour une cliente disposant d’un compte épargne et d’une hypothèque, les données liées à la personne sont actuellement conservées dans CRM et référencées dans les produits respectifs). Les différents modules alimentent un lac de données centralisé qui tient ainsi les données prêtes à tout moment pour le reporting. La clientèle qui dispose de son propre lac de données ou qui souhaiterait utiliser son propre data warehouse accède aux données de Tuum via les webhooks en temps réel.

 

Grâce au concept Open API entièrement mis en œuvre, les modules individuels sont extensibles au choix et les exigences comme par exemple PSD2 sont simples à remplir.

 

Des utilisations multiples sont garanties par différents mandants, différentes monnaies et différents langages. Plusieurs fuseaux horaires sont automatiquement soutenus.

Modèle commercial

La stratégie de marché de Tuum s’inspire de «Land and Expand», c’est-à-dire du fait de laisser, par petites étapes, des empreintes de pas ayant une grande influence sur les affaires de la clientèle, tout en continuant à se développer petit à petit. Tuum investit plus de 50% du chiffre d’affaires dans le développement pour soutenir la croissance.

 

La fixation des prix intègre la taille de la clientèle et la courbe de croissance. Basées sur le volume des affaires prévu, les catégories préalablement déterminées par module entrent en ligne de compte – par exemple, plus le nombre de prêts est important pour une banque universelle, plus le prix unitaire est faible. Tuum propose une présentation complètement transparente des coûts de processus ainsi qu’une assistance importante de gestion des coûts et crée proactivement le contact entre les parties intéressées et la clientèle actuelle.

 

Tuum estime que ses coûts d’intégration se situent dans la moyenne suisse. L’avantage est que la clientèle ne paie que les modules dont elle a besoin.

Futur support système avec Tuum

Tuum désire proposer une plateforme aussi complète que possible et offre déjà une palette de fonctionnalités relativement large, malgré une existence d’à peine trois ans. D’autres devraient suivre à l’avenir.

 

Ce faisant, elle se différencie des approches étroites des autres néosystèmes bancaires centraux et suit une stratégie produits analogue à Eri Bancaire avec son célèbre système bancaire central Olympic: toutes les fonctions nécessaires pour une banque doivent (peuvent) être perçues par le fabricant lui-même. Tuum développe néanmoins ce système avec une plateforme par principe ouverte API-first.

 

Tuum apporte des fonctionnalités de base (comme l’enregistrement des interactions clients) au besoin élevé de CRM selon une enquête des banques. Concernant les campagnes, Tuum recommande une intégration avec les systèmes CRM comme la plupart des néosystèmes bancaires centraux.

 

Tuum propose une couverture élevée dans le management de documents (Enterprise Content Management), ainsi que pour les cartes et les garanties. Cela lui permet de dépasser le besoin moyen.
Dans le management produit, Tuum soutient la migration d’un produit existant dans un nouveau produit généré (configuration produit comprise), ce qui satisfait un besoin moyen.

couverture des besoins par Tuum en Suisse

couverture des besoins par Tuum en Suisse

Tuum soutient les éléments centraux stratégiques décrits dans l’article Satisfaction des banques vis-à-vis de leur système bancaire central: un thème sujet à tensions?, comme suit:

 

Transparence: La plateforme de Tuum a un concept Open API API-first entièrement mis en œuvre pour permettre une diversité de cas d’application sur la connexion des systèmes tiers. Grâce à la transparence implémentée du système vis-à-vis des partenaires coopérants, tous les raccordements fonctionnent par principe en accédant aux données propres. La banque doit toutefois pouvoir vraiment se reposer sur le standard ouvert et l’accès aux données des différents systèmes doit être garanti à tout moment afin que la liberté de manœuvre de la banque ne soit pas limitée. Lors de l’intégration des systèmes périphériques dans le système bancaire central avec une architecture actuelle, la question se pose de savoir à quel point les systèmes actuels soutiennent l’intégration de chaque module de Tuum puisqu’ils perdent alors les frais de licence.

 

Données: Par l’orientation architectonique de Tuum consistant à couvrir soi-même toutes les fonctionnalités de banking, le système tient lui-même les données correspondantes à disposition et augmente ainsi l’efficacité de l’utilisation des données. Le maintien des données réparties en module permet l’intégration d’Open Data, comme par exemple l’attribution des données du cadastre de biens immobiliers à une hypothèque. Avec la possibilité d’installation sur site, Tuum fait face aux directives réglementaires correspondantes.

 

Fonctions: L’éventail de fonctions de Tuum se focalise à ce stade sur la circulation des paiements (également de manière transfrontalière), les cartes, le management de documents, les crédits (aussi pour les entreprises) et les garanties. Tuum est encore très jeune sur le marché. Elle aspire à croître pour devenir une plateforme aussi autonome que possible qui ne doive accéder aux systèmes périphériques intégrés sur le réseau croissant de Tuum que pour les fonctionnalités satellites (AML, Frontends, décision de crédit, CRM).

 

Processus: Tuum dispose d’un module d’orchestration des processus qui administre tous les processus prédéfinis dans Tuum. Comme Tuum a été développée par des spécialistes disposant de profondes connaissances des processus bancaires, la banque n’a pas besoin de compétences importantes dans ce domaine. Celles-ci sont en revanche d’autant plus sollicitées qu’on dévie des standards de Tuum en ayant recours aux systèmes périphériques.

 

Les facteurs de réussite pour l’utilisation d’un néosystème bancaire central comme Tuum chez une banque sont notamment:

 

  • Intégration et transparence du fabricant de systèmes actuel
    Le rattachement de chaque module exige la mise à disposition d’interfaces ouvertes du côté du système de la banque. Le fabricant de systèmes existant n’est pas toujours motivé par cette situation puisque des pertes pourraient survenir dans les revenus de licence.
     
  • Frontends adaptés au rôle
    Pour la clientèle, les conseillers et conseillères clients et les spécialistes, un Frontend spécifique respectif doit être intégré. Les banques souhaitent souvent continuer à utiliser leur frontend actuel.
     
  • Transition culturelle
    Encourager la disposition des collaborateurs à se confronter à des projets agiles et aux adaptations de projet en cours dans le contexte international.
     
  • Différenciation en matière de possibilité de standardiser
    Distinction entre les éléments qui suivent les standards de Tuum et les éléments qui font la différence sur le marché pour la banque et qui ne peuvent pas être standardisés (voir aussi le point suivant sur l’helvétisation). Pour garder les standards de Tuum aussi élevés que possible et afin que le système reste efficace, lors de l’introduction d’autres produits, les processus de ces derniers doivent être adaptés si possible à ceux de Tuum. Pour cela, la compréhension de la gestion des standards chez les collaborateurs doit être encouragée et défendue.
     
  • Helvétisation aussi faible que possible
    Intégrer les produits nécessaires en Suisse comme QR Bill ou le décompte AVS par les systèmes périphériques, sinon ne pas déformer les modèles fournis et éviter l’helvétisation, afin de conserver le besoin d’intégration faible.

Conclusion

Comme décrit au début, les néosystèmes bancaires centraux misent souvent sur la modularité et SaaS. Ce dernier implique généralement une standardisation de l’offre et une internationalisation.

 

Tuum, qui peut être utilisée aussi bien sur le cloud qu’installée sur site, essaie de conserver le besoin d’intégration à un faible niveau malgré la modularisation, tout en visant une large couverture des fonctionnalités bancaires. En outre, Tuum veut pouvoir proposer ses fonctions à toute sa clientèle dans les différents pays. Pour réussir ce grand écart, Tuum a besoin d’un degré élevé de standardisation. Cela signifie que les produits et les processus doivent être déterminés jusqu’à un certain degré. La clientèle peut néanmoins produire elle-même de nouveaux produits (de manière analogue aux produits SaaS très utilisés comme Salesforce ou SAP) sur la base de modèles de produits pouvant être combinés entre eux. La standardisation complique certes l’individualisation, mais elle réduit la complexité des connaissances que les développeurs informatiques doivent posséder au sein de la banque.

 

En matière d’internationalisation, il convient de questionner la quantité d’helvétisation dont une banque a besoin en Suisse. Même les fabricants de systèmes bancaires centraux se détournent de plus en plus de la reproduction individuelle de chaque produit dans le système. Ils proposent en revanche ici aussi différentes formes de crédit (par ex. types de nantissement comme rentes, fermage agricole en Suisse) dans des paquets de fonctionnalités globaux et uniformes (bail, gage). Il convient néanmoins d’illustrer par exemple des fonctionnalités spécifiques à la circulation des paiements en Suisse comme QR Bill.

 

L’usage de Tuum fonctionne si l’enveloppe de Tuum est prise en charge, si seules les fonctionnalités spécifiques à la Suisse réellement obligatoires sont intégrées et si les processus de la banque, dans la mesure du possible, sont adaptés aux standards prédéterminés respectifs de Tuum. Cela suppose que, par exemple, on travaille avec des systèmes périphériques, même pour le reporting réglementaire (Tuum crée ainsi actuellement des intégrations avec Bearing Point Abacus).

 

Des banques universelles qui se décident pour Tuum suivront une stratégie modulaire et relieront tout d’abord à leur système existant un ou plusieurs modules, comme par exemple le module de cartes ou de financement via Open API pour générer Quick Wins sous forme d’un Time to Market rapide de produits innovants. Si les expériences sont positives, l’ajout d’autres modules de Tuum est concevable jusqu’au moteur de comptabilisation, en fonction de l’introduction continue des nouvelles fonctionnalités chez Tuum.

 

Pour les banques privées, un usage des modules individuels pourrait devenir intéressant dès lors que les fonctionnalités correspondantes sont à disposition dans le secteur Wealth.

 

Nous pensons qu’il existe aussi un potentiel pour les non-banques qui aimeraient proposer elles-mêmes des fonctionnalités de financement (par ex. un paiement échelonné), Tuum étant simple d’utilisation avec une interface intuitive.

 

Lors de l’implication des néosystèmes bancaires centraux, les besoins des banques suisses doivent être résolus par des systèmes périphériques, en particulier dans le secteur du placement. C’est le cas actuellement et cela le restera peut-être à l’avenir. Le temps nous montrera si Tuum proposera une couverture intéressante aux banques suisses dans le Wealth Management ou si les priorités seront fixées différemment.

 

Le radar central des banques poursuit les développements sur le marché, même au cours des prochaines années.

Articles 2018/2019/2020 déjà publiés


Business Engineering Institute de Saint-Gall

Swisscom et le Business Engineering Institute de Saint-Gall (BEI) entretiennent un partenariat de longue date dans le cadre du centre de compétences «Ecosystems». Celui-ci se penche sur des thèmes tels que les écosystèmes, la numérisation, la transformation, ainsi que des questions portant sur la conception future du secteur financier. Outre les activités de recherche, le BEI réalise des projets de conception et de mise en œuvre de modèles commerciaux innovants et intersectoriels.

 

La méthodologie du radar des systèmes bancaires centraux