Quels enjeux technologiques pour le secteur bancaire en 2024 ?

Le Bank Tech Day 2024 est un événement incontournable pour les acteurs du secteur bancaire, réunissant experts, décideurs et innovateurs autour des défis et des opportunités technologiques qui façonnent l’avenir de la finance. Si vous l’avez manqué, voici les principaux enseignements et enjeux technologiques que nous avons retenus : IA !

Bank Tech Day 2024, représentation d'un conseiller bancaire dans un univers fututiste.

L’intelligence artificielle en passe de révolutionner l’expérience client

L’intelligence artificielle (IA) a été au cœur des discussions, notamment pour améliorer l’expérience client. Les banques et les institutions financières investissent en priorité dans l’optimisation des processus KYC (Know Your Customer) et KYB (Know Your Business), ce qui non seulement permet de prévenir les fraudes potentielles mais aussi de se conformer aux lois et réglementations nationales et internationales.

C’est dans ce contexte que des solutions IA sont de plus en plus utilisées pour créer des scénarios prédictifs, et assurer une maintenance continue des données KYC et KYB​ dans le but de mettre en place des dispositifs pour améliorer la satisfaction client

Cependant une grande importance doit être donnée à la qualité des données pour entraîner les différents modèles d’IA afin d’obtenir des résultats pertinents et proposer des services satisfaisants.

Dans une ère où le client peut changer rapidement de banque, intégrer des outils IA permet aussi d’augmenter le conseiller bancaire. Ce n’est pas le futur mais on y est presque :

Traitement et analyse des demandes des clients au téléphone

Au téléphone, une analyse des échanges permettrait de suggérer plus rapidement des solutions en les proposant aux conseillers bancaires. 

Par exemple : suite à la discussion, l’IA propose de noter un RDV dans l’agenda du conseiller bancaire du client, ou il suggère d’envoyer un email au client avec des solutions de financement… 

A la clé : une plus grande efficacité du conseiller, une réduction des temps de formation…

Utilisation de chatbot reposant sur l’IA dans l’espace client

L’IA peut désormais traiter des demandes d’informations très variées tout en proposant une expérience utilisateur d’une grande qualité. Ainsi, le client pourra en une seule question demander une analyse de ses dépenses, poser des questions de facturation où accéder aux informations des produits. Il faut néanmoins rester vigilant sur la fiabilité de l’information et le respect des normes réglementaires. Le chatbot vient ainsi en complément des échanges téléphoniques afin de répondre à une partie des demandes et gagner en efficacité opérationnelle.

Proposer une transcription automatique des réunions

Pour continuer dans la même veine, lors des réunions client, il est possible d’effectuer une retranscription automatique des échanges afin de les synthétiser dans le CRM. Il serait même possible de simplifier les saisies avec les échanges (montant du financement par exemple) voire d’analyser les sentiments des clients pour avoir des indicateurs sur la qualité du service (“big brother is watching you”).

Bank Tech Day 2024 – La DSP3 arrive !

La DSP3, ou Directive sur les services de paiement 3, est un ensemble de nouvelles règles européennes qui visent à rendre les paiements plus sûrs, plus innovants et plus centrés sur le client.

Quels sont les objectifs de la DSP3 ?

  • Sécurité renforcée pour mieux protéger les consommateurs contre la fraude
  • APIs Open banking boosté : L’expérimentation, l’exploitation et l’optimisation des APIs d’Open Bankin pour atteindre la maturité technologique permettant leur ouverture et accessibilité mais aussi leur sécurité.  
  • Lutte contre la fraude optimisée : les acteurs peuvent partager des infos sur les transactions frauduleuses pour mieux les identifier et les bloquer.
  • Protection des consommateurs accrue : plus de contrôle sur leurs données et plus de transparence dans les services de paiement.

Comment s’adapter ? ️

Suite au Bank Tech Day 2024, les acteurs du secteur devront s’appuyer sur des solutions technologiques innovantes telles que l’authentification forte, les plateformes d’open banking sécurisées, les systèmes de détection de fraude basés sur l’IA, et puis surtout des outils de gestion des données robustes. ️

Banking As a Service : les API au coeurs des partenariats entre banque et Fintech

L’ère des APIs permet le développement de nouveaux business models, tels que la Banking-as-a-Service (BaaS) ou Open Banking. Ces modèles favorisent la co-création de valeur avec des partenaires, offrant de nouveaux services aux clients. 

Les APIs facilitent la collaboration entre les grandes banques et les fintechs, permettant une intégration rapide et efficace des nouvelles technologies ou offres. Les API sont aussi la clé de l’utilisation de l’IA à partir des données clients pour proposer des solutions plus pertinentes et adaptées. Évidemment, la mise en œuvre de ces APIs doit respecter les réglementations en vigueur pour garantir la sécurité et la confidentialité des données clients. 

Ce sujet, nous le connaissons bien chez TheCodingMachine. Nous avons eu l’opportunité de mettre en place techniquement de telles solutions notamment en intégrant des solutions comme Bridge ou Ubble au sein des parcours utilisateurs de nos clients.

Quelle banque pour demain ?

Le client est au cœur de la stratégie : l’avenir du secteur se jouera avec les banques qui développent un fort relationnel avec leur client, qui misent sur un accompagnement proactif. Il faut être facilement joignable et offrir un accompagnement à la fois expert et personnalisé à tout moment. Il est estimé que 30% des ventes passeront en 2025 par des leviers digitaux.

Alors, comment faire ? Il faut prioriser la satisfaction client au niveau des innovations et garantir le plus possible une expérience fluide, sécurisée et personnalisée. 

L’avenir de la banque appartiendra certainement à ceux qui sauront placer l’expertise et la confiance au cœur de leur relation client notamment en exploitant à bon escient leurs données à travers les API.

À retenir du Bank Tech Day 2024

Le Bank Tech Day 2024 a mis en lumière les nombreux défis et opportunités technologiques auxquels le secteur bancaire doit faire face : L’IA, la DSP3, la prévention contre la fraude, les business models digitaux, la collaboration avec les fintechs et la confiance client sont les clés pour construire la banque de demain.

Évidemment, si vous souhaitez parler de projets IA, API, relation client et même DSP3, on se tient à votre disposition !

Si ce sujet vous intéresse, lisez également notre article : L’Intelligence Artificielle Générative, quelles applications pour l’entreprise ?

Comprendre en 5 minutes les API

Une API (Application Programming Interface) est un ensemble normalisé de classes, de méthodes, de fonctions et de constantes qui sert de façade par laquelle un logiciel offre des services à d’autres logiciels, afin d’échanger des données et des fonctionnalités.

Types d’API

Il existe quatre principaux types d’API couramment employés.

  • API publiques :

Une API publique (ou API externe), est une API ouverte pour tous les développeurs, qui propose l’accès à ses données et ses services sous forme de libre-service. Cela suppose généralement une authentification et une autorisation modérées.

  • API privées :

Une API privée (ou API interne), est une API créée et utilisée uniquement au sein de l’entreprise. Ce type d’API n’est pas accessible pour des développeurs externes.

  • API partenaires :

Une API partenaire est une API qui est partagée uniquement à une liste de développeurs ou d’entreprises bien définie. Les droits d’accès à l’API sont de fait plus restrictifs que ceux d’une API publique.

  • API composites :

Une API composite est une combinaison de plusieurs API. Cela permet de grouper plusieurs requêtes en un seul appel API. Cette réduction du nombre d’appels améliore la vitesse et les performances de l’API. Ce type d’API est généralement utilisé dans les micro services.

Protocoles et architectures d’API

Il existe plusieurs protocoles et architectures d’API pour permettre cet échange de données et de fonctionnalités. Ils sont régis par des règles, des structures, et des contraintes différentes.

REST

L’architecture REST (Representational State Transfer) est un style d’architecture qui suit plusieurs principes fondamentaux:

  • Client-Serveur : les responsabilités sont séparées entre le client et le serveur. Le client envoie les requêtes au serveur, et le serveur retourne les réponses au client. Ils doivent être indépendants : un changement sur l’un ne doit pas impacter l’autre.
  • Stateless : (Sans état) Chaque interaction client-serveur est indépendante. Le serveur ne stocke pas les données des requêtes précédentes.
  • Cache : Les réponses du serveur peuvent être mises en cache, pour améliorer les performances et éviter d’appeler le serveur pour récupérer des données qui n’évoluent pas ou peu.
  • Layered : (Système multicouche) Architecture qui permet d’avoir plusieurs serveurs intermédiaires qui peuvent améliorer l’extensibilité du système en mettant en place une répartition de charge et un cache partagé.
  • Interface uniforme : Le client et le serveur communiquent avec le protocole HTTP, qui possède plusieurs méthodes de communication (GET, POST, PUT, DELETE, …). Chaque requête possède un URI (Uniform Resource Identifier), et renvoie des données sous une forme prédéfinie (JSON, XML, …).

Les API REST sont majoritairement utilisées pour les sites web accessibles au public. Elles permettent d’avoir une communication relativement simple entre le client et le serveur.

Ce sont des API flexibles, qui peuvent s’adapter à différents types de données (même si le JSON est le plus répandu).

SOAP

SOAP (Simple Object Access Protocol) est un protocole d’échange d’informations utilisant le XML (Extensible Markup Language).

Ce protocole définit de façon stricte comment les messages doivent être envoyés, et ce qui doit être inclus dedans. Cela fait de SOAP un protocole plus sécurisé que REST, mais qui le rend en contrepartie plus lourd au niveau du code, et plus compliqué à implémenter de façon générale.

SOAP utilise généralement le protocole HTTP, mais contrairement au REST, il n’est pas restreint à celui-ci, et peut utiliser le SMTP par exemple.

Il est généralement utilisé pour les applications liées au paiement, qui demandent une haute sécurité, ou pour des API internes.

RPC

RPC (Remote Procedural Call) est un protocole qui invoque des actions ou des processus exécutables sur un serveur.

Il peut aussi bien utiliser du JSON (avec le protocole JSON-RPC) ainsi que du XML (avec XML-RPC).

Contrairement aux API REST, le RPC n’accepte que les requêtes de type GET ou POST.

Le RPC se démarque par des payloads plus légers, ce qui améliore nettement les performances des requêtes client-serveur.

Dernièrement, c’est le framework gRPC, développé par Google qui s’est démarqué grâce à toutes ses améliorations apportées au protocole RPC. Il utilise HTTP/2 pour le transport des données, Protobuf (Protocol Buffers) comme format de sérialisation, qui encode les données envoyées et reçues pour minimiser le poids des requêtes, et encore améliorer les performances.

GraphQL

GraphQL est un langage de requête créé par Facebook, qui propose une alternative à REST. Il utilise une architecture basée sur un système de schéma de requêtes typé qui permet d’éviter les problèmes d’over/under-fetching, c’est à dire que le client récupère exactement ce qu’il demande au serveur, sans surplus de données inutiles.

Contrairement aux autres protocoles et architectures d’API, c’est le client qui définit les données à récupérer, et non pas le serveur qui décide quelles données à renvoyer.

Cela permet d’améliorer les performances sur les requêtes faites au serveur en s’assurant qu’il n’y aura pas de surplus d’informations, mais également de s’assurer que les données demandées sont bien existantes, et dans le bon type demandé.

Ce langage possède cependant quelques limitations, comme le fait de ne pas pouvoir gérer facilement l’upload & le download de fichiers. Néanmoins, chez TheCodingMachine nous sommes fans et avons développé notre propre librairie PHP pour aller avec GraphQL : GraphQLite.

Si vous souhaitez aller plus loin dans votre compréhension du secteur et du vocabulaire tech, n’hésitez pas à lire notre : livre blanc « Do you speak technique ? »