En 2019, lorsque j'ai plongé pour la première fois dans le domaine des intégrations bancaires, mes premières recherches n'ont pas donné grand-chose en dehors de la documentation officielle. Quatre ans plus tard, une quête similaire autour d'un verre dans un bar local n'a toujours pas donné de résultats fructueux. C'est à ce moment-là que l'idée m'est venue de me lancer dans une série d'articles détaillant nos expériences d'intégration avec les banques chez Circit - partageant nos scénarios d'utilisation, nos connaissances et notre savoir.
Ces articles porteront d'abord sur notre utilisation des intégrations bancaires, en élucidant les défis que nous avons rencontrés, l'évolution de nos produits et nos rencontres directes. Les publications suivantes approfondiront des aspects pratiques tels que la gestion des certificats, la validation des signatures, les procédures d'autorisation, les protocoles d'intégration et les subtilités de la conformité réglementaire.
Au sein de notre société, nous disposons de plusieurs produits exploitant les données des transactions bancaires, dont l'un est Transactions vérifiées. Essentiellement, nous offrons un accès accéléré aux données bancaires des clients lors des audits. Avec plus de 2 300 intégrations actives couvrant les banques traditionnelles, les startups fintech, les crypto-portefeuilles, et plus encore, Circit opère sous la surveillance réglementaire de la FCA au Royaume-Uni et de la CBI en Irlande. En tant que fournisseur de services d'information sur les comptes (AIS), nos opérations impliquent uniquement un accès en lecture seule sans aucune transaction financière.
L'un des aspects les plus ardus du développement de nos solutions réside sans aucun doute dans le processus d'intégration.
Bien que le monde de la technologie soit sur la voie de l'unification, nous en sommes encore loin, et voici pourquoi :
Il existe plusieurs cadres disponibles : CDR, PSD2, SX2A, STET et bien d'autres, chaque banque, et parfois même des succursales individuelles, choisissent indépendamment quel cadre utiliser et s'ils l'utilisent ou non.
Les régulateurs locaux ont souvent leurs propres exigences pour les bureaux bancaires locaux, ce qui peut avoir de nombreuses implications, des restrictions sur les données fournies aux méthodes d'autorisation et d'authentification.
Les banques n'en sont pas toutes au même stade de mise en œuvre de l'innovation, elles ont souvent d'anciens systèmes derrière une interface fantaisiste, ou toutes sortes de systèmes Frankenstein, ne soyez pas surpris si le même point d'accès peut renvoyer du json ou du xml selon le scénario.
Alors que le monde de la technologie vise à l'unification, plusieurs facteurs entravent ce progrès :
- Des cadres multiples : Il existe de nombreux cadres, tels que CDR, PSD2, SX2A, STET, chacun étant choisi indépendamment par les banques ou même les succursales individuelles. Cela entraîne une fragmentation et un manque de cohérence dans les approches du traitement des données et des mesures de sécurité.
- Diversité réglementaire : Les régulateurs locaux imposent des exigences variables aux bureaux bancaires, depuis les restrictions sur les données jusqu'aux méthodes d'autorisation et d'authentification. Cela ajoute de la complexité et des pratiques divergentes d'une région à l'autre.
- Diversité de l'infrastructure bancaire : Les banques fonctionnent avec des infrastructures diverses, allant de systèmes obsolètes masqués par des interfaces modernes à des configurations hybrides complexes. Par conséquent, les points d'accès peuvent renvoyer des données dans des formats différents (par exemple, JSON ou XML), ce qui complique les efforts d'intégration.
Ces défis soulignent la nécessité de pratiques normalisées et d'interopérabilité au sein du secteur bancaire afin de faciliter les opérations et de renforcer les mesures de sécurité.
L'absence de normes mondiales dans le secteur bancaire conduit les banques à prendre des décisions indépendantes, qui s'écartent souvent des tendances du secteur. Ce manque d'uniformité nous a posé des défis importants, en particulier au début, lorsque nos connaissances et notre expérience étaient limitées. Voici quelques-unes des hypothèses que nous avons formulées et les leçons que nous en avons tirées :
- Interprétation britannique de la DSP2 : nous avons supposé que les intégrations avec les banques s'aligneraient sur l'interprétation britannique de la DSP2. Cependant, cela a conduit à une intégration incorrecte de nombreux états du domaine, à un mauvais alignement de la terminologie et à un modèle de domaine basé sur une mise en œuvre imparfaite de la directive.
- Mise en œuvre uniforme du cadre : Nous pensions que toutes les banques utilisant un cadre particulier le mettraient en œuvre de la même manière. En réalité, la flexibilité des cadres a donné lieu à diverses options de mise en œuvre, ce qui a entraîné d'importants efforts de remaniement après les intégrations initiales.
- Fourniture de données cohérentes : Nous nous attendions à ce que toutes les banques fournissent les mêmes données conformément aux contrats. Cependant, des divergences sont apparues en raison de contraintes réglementaires, de motivations commerciales ou d'incitations à utiliser des API payantes, ce qui a compliqué nos efforts d'intégration.
- Terminologie uniforme des domaines : Nous avons supposé que la terminologie du domaine serait interprétée de manière uniforme par les banques. Cependant, des incohérences sont apparues, telles que des interprétations différentes des types de bilans.
- Complexité de l'autorisation : L'autorisation s'est avérée être un aspect difficile de l'intégration, nécessitant des paramètres client supplémentaires qui manquaient souvent d'intuitivité. Nous nous sommes d'abord concentrés sur l'autorisation OAuth2, puis nous avons découvert plus de 20 méthodes d'autorisation différentes.
- Échelle des transactions : Nous avons sous-estimé l'ampleur des transactions, ce qui a conduit à des choix sous-optimaux en matière de stockage des données. Ce que nous pensions initialement être plusieurs milliers de transactions par compte avec des montants de 14 caractères s'est avéré être des millions de transactions avec des montants beaucoup plus importants.
- Solutions bancaires sur mesure : Contrairement à nos attentes, plus de 50 % des intégrations ont impliqué des solutions propres aux institutions financières plutôt que des cadres standardisés.
Chacune de ces hypothèses a entraîné des défis que nous avons relevés avec succès. Une approche évolutive du développement de solutions et une architecture adaptable ont permis de surmonter ces obstacles.
En conclusion, naviguer dans le paysage complexe des intégrations bancaires a été un voyage semé d'embûches, d'enseignements et d'évolution. En réfléchissant à nos expériences, il est évident que la route vers l'unification du secteur bancaire est longue et sinueuse, mais qu'elle n'est pas dépourvue de récompenses. En adoptant une approche évolutive du développement de solutions, nous avons transformé les revers en opportunités de croissance et d'innovation.
Pour l'avenir, nous restons déterminés à partager nos idées, nos expériences et nos connaissances techniques avec l'ensemble de la communauté. Grâce à la collaboration, à l'adaptabilité et à un engagement commun en faveur de l'excellence, nous pouvons surmonter les obstacles qui se dressent devant nous et continuer à ouvrir la voie à un écosystème bancaire plus unifié et plus efficace.
Nous vous remercions de nous avoir accompagnés dans cette aventure et nous nous réjouissons d'entamer ensemble le prochain chapitre.
