La donnée et sa fiabilité ont toujours été au cœur des métiers de la banque. Gérer les dépôts tout en optimisant les couples rendement-risque des produits nécessite de collecter et de traiter une donnée de qualité. Avec la diminution des coûts de stockage et l’avènement du Big Data, la collecte et le traitement des données ont atteint une nouvelle dimension. En plus du patrimoine de données extrêmement riche qu’elles possèdent en propre – données client, données transactionnelles, etc. –, les banques sont désormais à l’affût de la valeur contenue dans les différents types de données externes. Mais comment les collecter ? Comment les utiliser pour créer de nouveaux cas d’usage business ?
Données externes et algorithmes
Il existe divers processus de collecte de données externes :
- de façon ad hoc et ponctuelle, sur les sites d’information ou en téléchargement simple, par exemple ;
- via des flux à fréquence définie : appels à une API (Application Programming Interface), scrapping web, ou encore, abonnement à une source de données externe.
Aujourd’hui, l’utilisation qui est faite par les banques des données externes est directement dépendante des différentes entités de celle-ci ; elle peut être nulle car interdite, ou potentiellement illimitée.
Certaines activités Risque des banques ont un accès limité, voire nul, aux données externes. En effet, les modèles de risque de crédit réglementaires, parmi les plus importants d’une banque puisqu’ils contribuent à sa comptabilité, sont soumis à la validation du régulateur. Ces modèles, qui cherchent par exemple à estimer des probabilités de défaut, ou à estimer la perte de la banque en cas de défaut, sont contraints de respecter, entre autres, la norme Bâle II. Cette réglementation proscrit strictement l’usage de données externes, à l’exception des ratings des agences de notation, ou des taux standard mis à disposition par le régulateur. Ainsi, à l’exception de périmètres restreints ne dépendant pas de l’approbation du régulateur, les activités Risque ont un intérêt limité à investir dans les données externes.
À l’inverse, la plupart des activités Marché des banques n’ont pas attendu l’avènement du Big Data pour structurer leur activité autour de la donnée externe. La majorité des modèles de trading et de pricing d’actifs développés par les banques, en propre, reposent sur de l’information qui n’est pas directement produite par elles. Toutes les salles de marché disposent depuis longtemps d’abonnements à Bloomberg ou Datastream, qui constituent des agrégateurs d’informations de référence (séries financières, rapports investisseurs, etc.), « ingrédients de base » de la plupart des stratégies d’investissement.
Si les deux activités précédentes illustrent un rapport plutôt mature et établi des banques à la donnée externe – non-utilisation dans le premier cas, exploitation totale dans le second –, il existe d’autres opportunités d’utilisation des données externes dont l’intérêt et la pérennité sont en cours d’exploration. Nous en donnerons deux exemples ici. Sur des problématiques de fraude à la carte, par exemple, le cadre du nouveau protocole 3D Secure 2.0 permet d’adjoindre aux modèles de détection de fraude, développés en propre par les banques, un nombre important de données externes. Au moment d’une transaction, les marchands sont désormais tenus d’envoyer à la banque des données telles que les caractéristiques du « device » au moment du paiement (localisation, SSID wifi du client, etc.), ou encore des informations sur le consommateur, telles que son adresse de livraison. Le volume de ces données peut aller jusqu’à une centaine de champs. Cette source additionnelle d'information apporte une vision complémentaire de celle de la banque, permettant de contextualiser la transaction et d’approfondir la connaissance des clients. Banques comme marchands ont un intérêt certain à fournir des données de qualité : si elles sont suffisamment complètes, elles permettront d’avoir un niveau de confiance élevé dans la transaction. Ainsi, la friction du 3DS – qui est géré par la banque et qui introduit un intermédiaire supplémentaire au moment du paiement (par exemple via confirmation SMS) – sera évitée pour le client. La complémentarité des données internes et externes favorise donc la reconstitution de « l’écosystème du paiement », facilitant ainsi la détection des comportements à risque.
Un autre exemple d’utilisation des données externes par les banques, en marketing cette fois-ci, est la surveillance de la réputation. Ce cas d’usage est d’autant plus important depuis le vote de la loi Macron-Hamon sur la mobilité bancaire, qui facilite les démarches de changement de banque. Google Analytics, Glassdoor, ou encore l’exploitation de flux Twitter, combinés à des outils de traitement du langage naturel (natural language processing), sont autant de sources d’information externes qui permettent de monitorer, en temps réel, et à une maille quasiment locale, la popularité de la banque et/ou des services qu’elle propose auprès du grand public. Le suivi de réputation s’effectue, en plus des outils SEO (Search Engine Optimization), grâce à des méthodes d’intelligence artificielle (IA) comme l’analyse de sentiments – catégorisation d’un verbatim comme positif, neutre, ou négatif –, la détection d’intention – de quoi parle le verbatim ? –, ou encore la détection d’entités nommées – y a-t-il des personnes, lieux, organisations dans le verbatim ?
Open banking et partage de données : de la création de valeur pour les banques
Depuis le début de l’année 2018, la directive européenne sur les services de paiement 2e version (DSP2) a été transposée dans le droit français. Il s’agit d’une directive proposant un cadre légal aux nouveaux acteurs intervenant sur le marché des paiements, aussi appelés tiers de paiement (TPP). Ceux-ci peuvent désormais proposer deux types de services : agréger les informations bancaires d’un utilisateur (vision consolidée de l’ensemble des comptes) ou initier un ordre de paiement. Cette directive impose par ailleurs aux banques de rendre accessibles ces informations aux TPP, gratuitement, via des API, en cas de demande du client.
Les banques ne sont donc plus uniquement consommatrices de données externes, mais bien productrices de données utilisées par des tiers. Si cette directive est redoutée par les acteurs bancaires à cause du risque de désintermédiation qu’elle génère, elle doit en réalité être perçue comme l’opportunité d’une collaboration entre acteurs différents ; opportunité qui favorisera un recentrage de l’industrie financière sur le service rendu au client. Un exemple illustrant l’intérêt d’une telle démarche est celui des offres Blablacar qui figurent désormais sur le site de la SNCF, ce qui contribue à fluidifier l’expérience utilisateur.
Comment les banques peuvent-elles se positionner dans ce nouvel écosystème ? D’un côté, les banques mettent des données à disposition des TPP, gratuitement pour les services régis par la DSP2, et de manière non gratuite pour tous les autres, ce qui fait d’ailleurs naître de nouveaux business models, centrés sur la donnée. D’autre part, plusieurs alternatives s'offrent aux banques afin de se démarquer de la concurrence et, en premier lieu, concevoir leurs propres services innovants (modèle interne). Elles gardent ainsi le contrôle de la chaîne de valeur, mais cela nécessite de la ressource de développement (temps/personne).
Elles peuvent aussi décider de s’appuyer sur les TPP via des partenariats ou acquisitions pour améliorer leur offre de services, et leur time to market (modèle mixte). Une illustration de ce changement de paradigme est incarnée par la banque allemande Solaris Bank. Celle-ci met à la disposition de ses utilisateurs un ensemble de services intégralement à la carte (compte courant, prêt, paiement, etc.), lesdits services étant fournis par des FinTechs partenaires, via API. On s'approche dans ce cas d’un dernier modèle, dit de rupture, de « bank as a platform ». Dans ce modèle, l’activité de la banque se « réduit » à celle d’une marketplace de services financiers, exploitant intégralement un écosystème de services fournis par des entités tierces et veillant à la protection des données de ses clients.
Ainsi, la crainte de certains acteurs d’être privés de la relation client génératrice de valeur n’est pas totalement justifiée, car un business model de type plateforme - et non back office - permettrait de collecter une part de la valeur générée par des tiers, à l’image d’Apple avec son AppStore. L’exemple de Solaris Bank, qui n’est plus isolé aujourd’hui, montre que des modèles vertueux émergent d’une politique de partage de données, à la fois pour les utilisateurs qui bénéficient de meilleurs services (interfaces, personnalisation), et pour les banques qui peuvent accélérer leur innovation et améliorer leur rentabilité.
Blockchain et décentralisation des services bancaires
Prolongement naturel de l’open banking, la question de l’automatisation et de la décentralisation de certains services bancaires s'impose. La blockchain remplit le cahier des charges en matière de sécurité et de fiabilité grâce à son architecture naturellement distribuée – même si des progrès sur la scalabilité restent à faire –, ouvrant ainsi la voie à la création d’une nouvelle catégorie de produits : les smart contracts.
Un smart contract est un protocole informatique qui facilite, vérifie, et exécute un contrat sans tiers de confiance. Une spécificité des smart contracts est de ne pouvoir recevoir de données que d’une seule source : la blockchain sous-jacente. Il est alors impératif de disposer d’un mécanisme d’ingestion des données issues du monde réel, capable par la suite d’alimenter le smart contract. Utiliser les nœuds d’un système décentralisé pour intégrer ces données issues du monde réel à la blockchain est théoriquement possible. Néanmoins, cette alternative serait trop coûteuse, puisque tous les nœuds du réseau seraient tenus d’effectuer tous les calculs : c’est le principe de la blockchain pour valider de manière décentralisée une « transaction ». Une solution pour dépasser cette difficulté passe par l’utilisation de ce que l’on nomme des « oracles ». Un oracle est un tiers de confiance, en dehors de la blockchain, qui assure la liaison entre les données issues du monde réel et ladite blockchain, en vérifiant des conditions liées à ces données, et en communiquant le résultat de cette vérification à la blockchain. Ainsi, un oracle peut fournir le résultat de n’importe quelle requête sur les données à n’importe quel contrat de la blockchain.
La banque, historiquement dépositaire de la confiance de ses clients pour toute opération financière, verra donc une partie de ses services déportée vers des blockchains dont elle ne maîtrise pas l’infrastructure, mais vis-à-vis desquelles elle peut continuer à jouer le rôle de tiers de confiance en fournissant des données vérifiées et de qualité. Komgo SA propose par exemple de digitaliser le commerce de matières premières grâce à cette technologie et a lancé un partenariat avec quinze entreprises, dont sept banques. AXA a lancé le service Fizzy, une assurance « retard d’avion » s'exécutant automatiquement sur la blockchain publique Ethereum lorsque le déclencheur (retard) est détecté, grâce à un branchement sur la base du trafic aérien mondial.
Les banques sont donc aujourd'hui bousculées par trois pressions de natures différentes, toutes orientées vers une ouverture plus forte à l’extérieur :
- une pression « dataïste » issue de l’explosion des données externes : l’investissement dans la collecte et le traitement de ces données doit se faire de manière judicieuse ;
- une pression juridique à travers l’open banking, qui oblige les banques à se repositionner devant un risque de désintermédiation de la relation client ;
- une pression technologique avec la blockchain qui permet de délocaliser une partie de la confiance placée en les banques vers des plateformes techniques distribuées.
