Aurélien Bonnel, CTO et fondateur de N3XT – Série d’interviews

Aurélien Bonnel, directeur technique et fondateur de N3XT, est un dirigeant et ingénieur en technologie financière avec plus de 14 ans d’expérience dans la construction d’infrastructures bancaires, de paiements et de marchés de capitaux sécurisées et en temps réel. Avant de fonder N3XT, il a occupé des postes d’ingénierie senior chez Deutsche Bank, Nimbla, Symbiont et SADA, et a contribué au développement de l’infrastructure de paiements blockchain utilisée par la plateforme Signet de Signature Bank. Sa carrière s’est concentrée sur la modernisation des systèmes financiers grâce à l’architecture cloud‑native, la blockchain, l’automatisation et les technologies de paiement évolutives.

N3XT est une banque à réserves intégrales construite autour d’une infrastructure moderne pour des paiements inter‑entreprises instantanés et programmables en dollars américains. Contrairement aux banques traditionnelles, N3XT ne prête pas les dépôts des clients, les dépôts étant garantis par des liquidités ou des bons du Trésor américain à court terme. L’entreprise se développe également à l’intersection de la banque et de l’IA grâce à N3XT MCP, un système basé sur le Model Context Protocol conçu pour connecter les agents et assistants IA aux données bancaires en direct tout en conservant les autorisations et contrôles de conformité existants. Cela pourrait permettre des flux de travail pilotés par l’IA pour la préparation de paiements, les rapports, la surveillance financière et d’autres tâches de finance d’entreprise.

Votre carrière vous a conduit de la tarification et de la technologie de trading à haute fréquence chez Deutsche Bank à la construction d’infrastructures de paiement blockchain, en passant par la direction de l’ingénierie chez Symbiont et finalement la co‑fondation de N3XT. Quels problèmes sont apparus de façon récurrente dans ces rôles et vous ont convaincu qu’un nouveau type de banque devait être créé à partir de zéro ?

Quel que soit mon parcours personnel, tout le monde peut voir les problèmes qui ont conduit à la création de N3XT. Nous connaissons tous le problème des paiements effectués un vendredi, qui n’arrivent sur le compte bancaire du destinataire que le mardi suivant. Le « solde disponible » de ce compte diffère du solde affiché parce que les paiements « reçus » ne sont pas encore réglés et ne sont pas utilisables.

Je me suis demandé pourquoi. Qui profite de tous ces délais ? Il s’avère que ce sont les banques. Chaque jour de retard représente des intérêts qu’elles gagnent aux dépens de leurs clients. Les banques ont eu accès à la même technologie que N3XT utilise depuis des années, mais ne l’ont pas adoptée — peut‑être parce que cela exposerait leur modèle économique.

Tout cela m’a clairement montré que la seule façon de réparer ce système est d’inventer un modèle radicalement nouveau, construit de zéro, avec de nouvelles idées : une base étroite, où une banque ne prête pas et règle les paiements instantanément.

N3XT MCP est conçu pour connecter directement les assistants IA aux données bancaires en direct et aux flux de travail. Qu’est‑ce que le Model Context Protocol rend possible qui ne pouvait pas être réalisé aussi efficacement via les API bancaires conventionnelles, les intégrations d’entreprise ou l’automatisation robotisée des processus ?

Tout d’abord, il convient de noter que N3XT MCP ne remplace pas notre infrastructure API existante, mais en dépend. Nous avions besoin d’une infrastructure API mature et robuste déjà en place avant de pouvoir créer N3XT MCP. Nos API (que vous pouvez consulter ici) restent essentielles pour gérer l’accès aux données de compte en temps réel et aux flux de travail.

Là où le Model Context Protocol (MCP) change les choses, c’est dans la façon dont les modèles d’IA interagissent avec cela.

Premièrement, les API nécessitent des intégrations écrites par les développeurs et codées en dur pour chaque cas d’utilisation. MCP, en revanche, agit comme une interface standard qui permet aux modèles d’IA de découvrir et d’utiliser nos outils bancaires et nos données en temps réel. De cette façon, les assistants IA réduisent les frictions car ils peuvent interroger le système et lancer des flux de travail approuvés plus facilement.

Deuxièmement, l’automatisation robotisée des processus (RPA) automatise les tâches répétitives via des règles définies, mais échoue dès qu’elle rencontre quelque chose d’inattendu. Les interactions bancaires avec MCP, quant à elles, offrent un contexte en temps réel afin que le modèle puisse raisonner sur des tâches complexes sans dépendre d’une logique fixe. Un utilisateur peut poser une question à plusieurs étapes, ou demander à l’assistant IA de prendre en compte les données bancaires dans le contexte d’un autre jeu de données qui se situerait normalement hors de la vue de la banque.

Au lieu de créer des intégrations personnalisées pour chaque nouvel assistant IA ou outil dans l’écosystème d’entreprise, MCP fournit une norme unifiée. Vous exposez la capacité une fois via MCP, et tout modèle IA compatible peut interagir avec elle de manière sécurisée.

En fin de compte, nos API fournissent le moteur d’exécution, mais MCP fournit le langage qui permet aux assistants IA d’opérer en toute sécurité et avec précision dans l’environnement en temps réel.

La plateforme offre des capacités de lecture‑écriture gouvernées, permettant aux assistants IA d’analyser les transactions, de rapprocher l’activité et de préparer les paiements. Que peut faire aujourd’hui un agent IA de façon autonome, et quelles actions doivent encore passer par une approbation humaine ?

Pour la gestion de trésorerie et la banque, la rapidité compte, mais la sécurité et la conformité sont non négociables. N3XT MCP agit comme une barrière de gouvernance, garantissant que les mêmes protections conçues pour les humains empêchent un agent IA de prendre des actions non approuvées.

Voici comment cet équilibre fonctionne en pratique :

Les agents IA héritent des autorisations d’accès de leur utilisateur. Si vous n’avez accès qu’à un petit groupe de portefeuilles, les agents que vous créez auront la même visibilité. Ainsi, l’agent ne peut fonctionner et analyser que dans son périmètre d’accès.

Plus précisément, un agent peut surveiller et analyser les flux de compte en direct pour évaluer les positions de trésorerie et comprendre le contexte entre différentes sources de données, et associer automatiquement les paiements entrants aux factures, signaler les erreurs et identifier les écarts. Ce sont toutes des tâches qu’un agent IA peut accomplir de façon autonome aujourd’hui.

Cependant, lorsque l’action passe de la préparation des données à la réalisation des paiements, une couche supplémentaire de gouvernance et d’autorisations garantit que les actions de l’agent respectent les flux de travail maker/checker existants. Ainsi, les paiements qui nécessitent une approbation secondaire peuvent être initiés par un agent, mais ils doivent être transmis à l’approbateur humain secondaire pour autorisation finale avant tout mouvement de fonds. Il convient également de préciser qu’aucun agent ne peut modifier les politiques d’approbation ou les voies de gouvernance. Cela dépasse son champ d’action.

Nous autorisons donc une autonomie et une analyse maximales sans le risque de compromettre les flux de gouvernance et de conformité existants.

En bref, l’IA peut vous fournir 100 % des informations que vous recherchez et la plupart des besoins de paiement, mais lorsqu’il s’agit de réellement effectuer des paiements, des virements et de déplacer des fonds, les flux de travail maker/checker restent en place pour garantir que chaque transaction est vérifiée et approuvée par un humain avant toute action.

Permettre à un système IA d’interagir avec un compte bancaire d’entreprise introduit des risques importants de sécurité et opérationnels. Comment N3XT garantit‑il qu’un agent ne puisse pas dépasser les autorisations d’un utilisateur, accéder à un portefeuille non autorisé ou initier une transaction inappropriée ?

La sécurité en IA ne consiste pas à faire confiance au modèle pour se comporter correctement, mais à concevoir les systèmes de façon à ce que, même si les modèles commettent des erreurs, l’architecture du système empêche l’exécution d’une action non autorisée.

Nous avons construit N3XT MCP avec une philosophie Zero Trust pour cette raison, de sorte qu’un agent IA ne puisse jamais disposer d’une clé « super‑utilisateur » ou de droits d’accès indépendants. Lorsqu’une personne se connecte à N3XT MCP, l’agent IA hérite des autorisations d’accès de cet utilisateur. Si un utilisateur n’a pas la permission de voir un portefeuille spécifique, ou de préparer des paiements au‑delà d’un certain seuil en dollars, l’agent a les mêmes restrictions. Point final.

N3XT MCP offre également un ensemble limité de capacités aux agents IA. Modifier les autorisations ne fait pas partie de ces capacités. En fait, il n’est même pas possible via l’API de changer les autorisations et les flux de travail. Cela rend impossible pour un agent d’apporter une modification dans ce domaine.

Enfin, des règles comme les flux de travail maker/checker sont appliquées au niveau du portefeuille, pas au niveau de l’utilisateur. Cela signifie qu’un agent ne peut jamais contourner les validations humaines secondaires requises.

N3XT affirme que ses flux de travail maker‑approver existants restent en place lorsque les clients utilisent des assistants IA. Comment préservez‑vous la responsabilité et une traçabilité claire lorsqu’une action financière peut impliquer un employé, un modèle IA et plusieurs systèmes automatisés ?

Lorsque plusieurs entités – un humain, un modèle IA et des systèmes back‑end – interviennent sur une transaction financière, la journalisation standard des API ne suffit pas. Pour l’auditabilité, nous devons savoir non seulement ce qui s’est passé, mais qui l’a initié, quel raisonnement l’IA a eu, et qui l’a autorisé.

Nous maintenons une responsabilité absolue en veillant à ce que chaque requête provenant de N3XT MCP inclue une balise qui relie la session de l’utilisateur humain, l’ID d’interaction IA spécifique et l’appel à l’outil back‑end. Si un agent IA prépare un paiement, nous enregistrons quel employé a émis la requête, la session, et les outils utilisés par le modèle IA. Il n’y a aucune action anonyme dans nos journaux.

Lorsqu’un agent IA agit comme le « maker » en préparant un paiement, il ne peut pas s’auto‑autoriser pour l’exécution. La transaction préparée est placée dans la file d’attente standard maker/checker de la banque. Lorsque le « checker » humain examine et approuve le paiement, son jeton d’authentification personnel signe l’action finale. La responsabilité est ainsi préservée.

Quels cas d’usage initiaux suscitent le plus d’intérêt de la part des équipes de trésorerie d’entreprise et des organisations de trading : rapprochement, suivi de liquidité, détection d’écarts, préparation de paiements, reporting ou autre ?

Toute équipe financière souhaite une automatisation de bout en bout, mais malgré cela, les trésoriers d’entreprise et les desks de trading sont assez pragmatiques. Personne ne veut commencer par les flux de travail complexes et risqués ; ils commencent là où la douleur opérationnelle est la plus forte et le risque le plus faible.

Actuellement, la demande la plus forte porte sur le reporting. Les équipes de trésorerie sont déjà submergées de données, qui sont fragmentées entre plusieurs banques et partenaires, ce qui rend la rationalisation difficile. Elles utilisent déjà des assistants IA pour les aider à voir la vue d’ensemble, mais pour l’instant, elles doivent se connecter à différents portails pour télécharger les positions et les relevés. Avec N3XT MCP, aucune connexion n’est nécessaire pour N3XT et elles peuvent plutôt dialoguer avec leurs positions.

Nous prévoyons que la préparation de paiements sera le prochain cas d’usage. Nous constatons déjà un engouement initial à ce sujet, et je m’attends à voir de nombreuses créations de flux de paiement à court terme.

N3XT fonctionne comme une banque à réserves intégrales et à modèle étroit qui ne prête pas et garantit les dépôts un pour un avec des liquidités ou des bons du Trésor américain à court terme. Pourquoi ce modèle est‑il particulièrement adapté aux paiements programmables et aux opérations financières pilotées par l’IA, et comment les clients doivent‑ils évaluer ses protections par rapport à la banque conventionnelle assurée par la FDIC ?

L’IA est un accélérateur pour la finance, mais la réponse à cette question ne porte pas uniquement sur l’IA, elle concerne le règlement. Les banques traditionnelles ont été conçues pour un monde qui évoluait lentement. Elles s’appuient sur un flottement de plusieurs jours pour gérer et tirer profit des différences entre les dépôts opérationnels et les prêts commerciaux de la banque.

L’introduction d’exigences de règlement en temps réel, 24 h/24 et 7 j/7, qu’elles soient introduites par une personne ou un agent IA, expose une faille du système de réserve fractionnaire : pour régler les fonds instantanément, il faut disposer des fonds disponibles. Dans un monde où la vitesse des paiements augmente, les banques ont besoin d’une augmentation égale ou supérieure de leurs réserves pour s’assurer que ces fonds sont disponibles.

Nous pensons que le règlement 24 h/24 et 7 j/7 ne peut pas coexister en toute sécurité avec l’émission de dette à long terme sur un même bilan. Notre modèle de banque étroite sépare les deux et garantit que nous restons liquides, entièrement garantis et isolés des risques de crédit d’un desk de prêt.

Lorsque les trésoriers d’entreprise comparent notre modèle de banque étroite à réserves intégrales à l’assurance FDIC, ils doivent considérer comment la « sécurité » est assurée. L’assurance FDIC plafonne à 250 000 $. Pour les entreprises qui déplacent des millions, cela laisse presque tout leur capital opérationnel exposé aux risques de prêt et de bilan sous‑jacents de la banque.

La banque à réserves intégrales et modèle étroit ne dépend pas du tout de l’assurance car nous ne prêtons pas. Que votre solde soit de 100 000 $ ou de 100 millions de $, nous ne prêtons jamais votre capital, vous savez donc qu’il sera disponible pour soutenir vos opérations et vos besoins de paiement. Nous pensons que c’est ce qui est nécessaire pour une économie de règlement instantané 24 h/24 et 7 j/7.

N3XT a également lancé le N3XT Digital Dollar, un dépôt tokenisé émis par la banque conçu pour le règlement 24 h/24. Comment N3XT MCP interagira‑t‑il avec les dépôts tokenisés, les stablecoins et les rails de paiement traditionnels en dollars américains au sein du même flux de travail de trésorerie ?

Tout d’abord, il convient de préciser un point concernant notre modèle. N3XT est spécialement conçu pour prendre en charge les paiements B2B 24 h/24 avec un règlement atomique. Les rails hérités n’étaient pas conçus pour un règlement atomique, ils n’interagissent donc pas à ce niveau. C’était un choix délibéré.

Nous avons passé deux ans à construire un système bancaire central moderne basé sur la blockchain. Cela comprend une chaîne privée autorisée où les clients effectuent des transactions en dollars pour payer d’autres clients N3XT sur le réseau, ainsi qu’un accès à une chaîne publique où de nombreux clients effectuent déjà des transactions. La chaîne publique est celle où ils peuvent transiger en utilisant le N3XT Digital Dollar (NDD).

MCP permet aux assistants IA d’orchestrer des flux de travail entre ces deux environnements. Par exemple, vérifier les soldes NDD dans les portefeuilles publics d’un client, puis effectuer un transfert entre les portefeuilles si nécessaire, ou transférer des fonds d’un portefeuille privé vers un portefeuille NDD public — tout en respectant les flux de gouvernance.

Ainsi, MCP fournit une interface gouvernée pour opérer à travers l’architecture numérique 24 h/24 de N3XT, tant pour l’USD que pour le NDD.

Une grande partie de la valeur d’une norme ouverte repose sur l’interopérabilité. Quels assistants IA, systèmes d’entreprise et plateformes de trésorerie peuvent actuellement se connecter à N3XT MCP, et comment empêchez‑vous les clients de devenir dépendants d’un seul fournisseur de modèle ou d’une interface propriétaire ?

La raison pour laquelle nous avons construit sur le Model Context Protocol (MCP) plutôt que de publier notre propre SDK était de permettre l’interopérabilité. Nos clients utilisent les outils qu’ils utilisent, et à l’ère de l’IA, ils pourraient même changer plus souvent qu’auparavant.

Parce que MCP est une spécification ouverte, N3XT MCP se branche directement sur l’environnement d’hébergement IA que le client connaît déjà, comme Cursor, Anthropic, OpenAI ou Gemini. Il offre également une compatibilité native avec les cadres d’orchestration tels que LangChain et AutoGen. En ce qui concerne les systèmes d’entreprise comme les ERP, si ces systèmes ont construit des connexions MCP natives, les clients peuvent également travailler entre plateformes depuis leur plateforme IA choisie.

Avec MCP, nous offrons donc plus de liberté aux clients. S’ils décident de changer de fournisseur IA, ou souhaitent passer à des modèles plus récents, ils n’ont pas besoin de reconstruire des connecteurs. Ils pointent simplement le nouveau modèle IA vers le serveur N3XT MCP et ils sont opérationnels.

N3XT décrit ce lancement comme une première étape vers la gestion autonome du capital d’entreprise. Jusqu’où la finance d’entreprise devrait‑elle devenir réellement autonome, et quelles barrières techniques, réglementaires et culturelles doivent être surmontées avant que les entreprises autorisent les agents IA à gérer des montants de capital significatifs ?

L’objectif de la finance autonome n’est pas de créer une boîte noire « set it and forget it » qui déplace de l’argent sans supervision humaine. Une autonomie non surveillée n’est pas de l’innovation ; c’est une responsabilité.

Plus réalistement, la finance d’entreprise devrait évoluer vers une autonomie engagée : les agents IA effectuent l’analyse des données, la surveillance et les flux de travail, tandis que les dirigeants et les équipes financières passent de l’exécution manuelle à la définition de politiques, à la stratégie et aux approbations.

Pour renforcer la confiance des entreprises et donner aux agents IA un accès et un contrôle gouverné sur les paiements et le capital d’exploitation, les questions d’identité et de responsabilité doivent être résolues.

Qui est responsable si un modèle IA interprète mal une facture et déclenche un paiement inapproprié ? Notre modèle maker/checker fonctionne pour empêcher que cela ne se produise.

Culturellement, nous sommes encore au début de la transition vers la finance agentique. À mesure que l’IA assume des rôles opérationnels plus importants, je crois que l’identité agentique deviendra un sujet de plus en plus important et central, car la confiance — envers les personnes ou l’IA — nécessite une responsabilité.

Merci pour cette excellente interview, les lecteurs qui souhaitent en savoir plus devraient visiter N3XT.