Aurélien Bonnel, CTO og grunnlegger av N3XT – Intervjuserie

Aurélien Bonnel, Chief Technical Officer og grunnlegger av N3XT, er en finansteknologileder og ingeniør med mer enn 14 års erfaring med å bygge sikker, sanntids bank-, betalings- og kapitalmarkedsinfrastruktur. Før han grunnla N3XT, hadde han senior ingeniørroller i Deutsche Bank (DB ), Nimbla, Symbiont og SADA, og bidro til å utvikle blokkjedebetalingsinfrastrukturen som brukes av Signature Bank sin Signet-plattform. Karrieren hans har fokusert på å modernisere finansielle systemer gjennom sky‑native arkitektur, blokkjedeteknologi, automatisering og skalerbar betalingsteknologi.

N3XT er en fullreservebank bygget rundt moderne infrastruktur for øyeblikkelige, programmerbare business‑to‑business‑betalinger i amerikanske dollar. I motsetning til konvensjonelle banker låner N3XT ikke kundens innskudd, og innskuddene er støttet av kontanter eller kortsiktige amerikanske statsobligasjoner. Selskapet utvider også inn i skjæringspunktet mellom bankvirksomhet og AI gjennom N3XT MCP, et basert på Model Context Protocol-system designet for å koble AI‑agenter og assistenter med levende bankdata samtidig som eksisterende tillatelser og etterlevelseskontroller opprettholdes. Dette kan muliggjøre AI‑drevne arbeidsflyter for betalingsforberedelse, rapportering, finansiell overvåking og andre oppgaver innen bedriftsfinans.

Din karriere har tatt deg fra prisfastsettelse og høyfrekvent handels‑teknologi i Deutsche Bank til å bygge blokkjedebetalingsinfrastruktur, lede ingeniørarbeidet i Symbiont og til slutt medgrunnelegge N3XT. Hvilke problemer dukket stadig opp i disse rollene og overbeviste deg om at en ny type bank måtte bygges fra bunnen av?

Uavhengig av min personlige historie kan alle se problemene som førte til opprettelsen av N3XT. Vi kjenner alle til problemet med at betalinger blir gjort på en fredag, men først lander på mottakerens bankkonto tirsdagen etter. Den «tilgjengelige saldoen» på den kontoen er forskjellig fra den viste saldoen fordi de «mottatte» betalingene ikke er avregnet og dermed ikke kan brukes.

Jeg lurte på hvorfor. Hvem drar nytte av alle disse forsinkelsene? Det viser seg at bankene gjør det. Hver dag med forsinkelse er rente de tjener på sine kunders bekostning. Bankene har hatt tilgang til den samme teknologien som N3XT bruker i flere år, men har ikke tatt den i bruk – kanskje fordi den ville avsløre forretningsmodellen deres.

Alt dette gjorde det tydelig for meg at den eneste måten å fikse dette systemet på er å komme opp med en radikalt ny modell, bygget fra bunnen av, med nye ideer: Et smalt fundament, hvor en bank ikke låner og avregner betalinger umiddelbart.

N3XT MCP er designet for å koble AI‑assistenter direkte til levende bankdata og arbeidsflyter. Hva gjør Model Context Protocol mulig som ikke kan oppnås like effektivt gjennom konvensjonelle bank‑API‑er, bedriftsintegrasjoner eller robotisk prosess‑automatisering?

Først er det verdt å merke seg at N3XT MCP ikke erstatter vår eksisterende API‑infrastruktur, men er avhengig av den. Vi trengte en moden og robust API‑infrastruktur på plass før vi kunne lage N3XT MCP. Våre API‑er (som du kan lese om her) forblir kjernen i å håndtere tilgang til levende kontodata og arbeidsflyter.

Det Model Context Protocol (MCP) endrer, er hvordan AI‑modeller samhandler med dette.

Først krever API‑er utvikler‑skrevne, hardkodede integrasjoner for hvert brukstilfelle. MCP fungerer derimot som et standardgrensesnitt som lar AI‑modeller oppdage og bruke våre bankverktøy og data i sanntid. På denne måten fjerner AI‑assistenter friksjon fordi de har muligheten til å spørre systemet og starte godkjente arbeidsflyter enklere.

For det andre automatiserer Robotic Process Automation (RPA) repeterende oppgaver gjennom definerte regler, men svikter så snart den møter noe uventet. Bankinteraksjoner med MCP gir derimot sanntidskontekst slik at modellen kan resonere gjennom komplekse oppgaver uten å stole på fast logikk. En bruker kan stille et flerstegs spørsmål, eller be AI‑assistenten om å vurdere bankdata i sammenheng med et annet datasett som vanligvis ligger utenfor bankens syn.

I stedet for å bygge tilpassede integrasjoner for hver ny AI‑assistent eller verktøy i bedriftsstakken, gir MCP en samlet standard. Du eksponerer funksjonaliteten én gang gjennom MCP, og enhver kompatibel AI‑modell kan trygt samhandle med den.

Til syvende og sist gir våre API‑er utførelsesmotoren, men MCP gir språket som lar AI‑assistenter trygt og nøyaktig operere med miljøet i sanntid.

Plattformen gir styrte lese‑ og skrive‑muligheter, slik at AI‑assistenter kan analysere transaksjoner, avstemme aktivitet og forberede betalinger. Hva kan en AI‑agent gjøre selvstendig i dag, og hvilke handlinger må fortsatt gå gjennom menneskelig godkjenning?

For treasury‑styring og bankvirksomhet er hastighet viktig, men sikkerhet og etterlevelse er ufravikelige. N3XT MCP fungerer som en styrt rekkverk, og sikrer at de samme beskyttelsene designet for mennesker hindrer en AI‑agent i å utføre uautoriserte handlinger.

Slik fungerer denne balansen i praksis:

AI‑agenter arver tilgangstillatelsene til brukeren sin. Hvis du kun har innsikt i en liten gruppe lommebøker, vil agentene du bygger ha samme innsikt. Så agenten kan operere og utføre analyser kun innenfor sitt tilgangsområde.

Mer spesifikt kan en agent overvåke og analysere levende kontostrømmer for å vurdere kontantposisjoner og forstå kontekst på tvers av ulike datakilder, samt automatisk matche innkommende betalinger mot fakturaer, flagge feil og identifisere avvik. Dette er alle ting en AI‑agent kan gjøre selvstendig i dag.

Men når handlingen går fra forberedelse av data til gjennomføring av betalinger, sikrer et ekstra lag av styring og tillatelser at agentens handlinger er i samsvar med eksisterende maker/checker‑arbeidsflyter. På denne måten kan betalinger som er satt til å kreve sekundær godkjenning initieres av en agent, men de må gå til den sekundære menneskelige godkjenneren for endelig autorisasjon før noen penger flyttes. Det er også verdt å påpeke at ingen agent kan endre godkjenningspolicyer eller styringsveier. Det ligger utenfor deres ansvarsområde.

Dermed tillater vi maksimal autonomi og analyse uten risiko for å kompromittere eksisterende styrings‑ og etterlevelsesarbeidsflyter.

Kort sagt kan AI gi deg 100 % av innsikten du søker, og nesten hele veien til dine betalingsbehov, men når det gjelder å faktisk utføre betalinger, overføringer og flytte midler, er maker/checker‑arbeidsflyter fortsatt til stede for å sikre at hver transaksjon blir kontrollert og godkjent av et menneske før en handling utføres.

Å la et AI‑system samhandle med en bedriftsbankkonto introduserer betydelige sikkerhets‑ og driftsrisikoer. Hvordan sikrer N3XT at en agent ikke kan overskride en brukers tillatelser, få tilgang til en uautorisert lommebok eller initiere en feilaktig transaksjon?

Sikkerhet i AI handler ikke om å stole på at modellen oppfører seg, men om å arkitektere systemer slik at selv om modeller gjør feil, hindrer systemarkitekturen en uautorisert handling fra å bli utført.

Vi bygde N3XT MCP med en Zero Trust‑filosofi av den grunn, slik at en AI‑agent aldri kan ha en «super‑bruker»-nøkkel eller uavhengige tilgangsrettigheter. Når en person kobler seg til N3XT MCP, arver AI‑agenten den brukerens tilgangstillatelser. Hvis en bruker ikke har tillatelse til å se en spesifikk lommebok, eller utarbeide betalinger over en viss dollargrense, har agenten de samme begrensningene. Punkt.

N3XT MCP tilbyr også et begrenset sett med funksjoner til AI‑agenter. Endring av tillatelser er ikke en av disse funksjonene. Faktisk er det ikke engang mulig via API å endre tillatelser og arbeidsflyter. Dette gjør det umulig for en agent å noen gang foreta en endring på dette området.

Til slutt håndheves regler som maker/checker‑arbeidsflyter på lommeboknivå, ikke på brukernivå. Dette betyr at en agent aldri kan omgå nødvendige sekundære menneskelige godkjenninger.

N3XT sier at deres eksisterende maker‑og‑godkjenner‑arbeidsflyter forblir på plass når kunder bruker AI‑assistenter. Hvordan opprettholder du ansvarlighet og en klar revisjonsspor når en finanshandling kan involvere en ansatt, en AI‑modell og flere automatiserte systemer?

Når flere enheter – et menneske, en AI‑modell og backend‑systemer – berører en finansiell transaksjon, er standard API‑logging ikke nok. For revisjonsspor må vi vite ikke bare hva som skjedde, men hvem som initierte det, hva AI‑en resonnerte, og hvem som autoriserte det.

Vi opprettholder absolutt ansvarlighet ved å sikre at hver forespørsel fra N3XT MCP inkluderer en tagg som knytter den menneskelige brukerens økt, den spesifikke AI‑interaksjons‑ID‑en og backend‑verktøykallet. Hvis en AI‑agent utarbeider en betaling, logger vi hvilken ansatt som ga kommandoen, økten og verktøyene som AI‑modellen brukte. Det finnes ingen anonyme handlinger i loggene våre.

Når en AI‑agent fungerer som «maker» ved å forberede en betaling, kan den ikke selv autorisere utførelsen. Den forberedte transaksjonen blir sendt inn i bankens standard maker/checker‑kø. Når den menneskelige «checker» gjennomgår og godkjenner utbetalingen, signerer deres personlige autentiseringstoken den endelige handlingen. Ansvarlighet opprettholdes.

Hvilke innledende bruksområder genererer den sterkeste interessen fra bedrifts‑treasury‑team og handelsorganisasjoner: avstemming, likviditets‑overvåking, avviks‑deteksjon, betalingsforberedelse, rapportering eller noe annet?

Alle finans‑team ønsker ende‑til‑ende‑automatisering, men til tross for det er bedrifts‑treasurere og handelsdeskene ganske pragmatiske. Ingen vil starte med komplekse og risikable arbeidsflyter; de starter der deres operative smerte er størst og risikoen lavest.

Akkurat nå er den største etterspørselen rapportering. Treasury‑teamene er allerede overveldet av data, og de er fragmentert på tvers av flere banker og partnere, noe som gjør det vanskelig å rationalisere. De bruker allerede AI‑assistenter for å få oversikt, men nå må de logge inn på ulike portaler for å laste ned posisjoner og uttalelser. Med N3XT MCP er det ingen pålogging nødvendig for N3XT, og de kan i stedet ha en samtale om sine posisjoner.

Vi forventer at betalingsforberedelse blir det neste bruksområdet. Vi ser allerede en innledende entusiasme for dette, og jeg forventer at vi vil se mye opprettelse av betalingsflyt på kort sikt.

N3XT opererer som en fullreserve‑smalbank som ikke låner og støtter innskudd én‑til‑én med kontanter eller kortsiktige amerikanske statsobligasjoner. Hvorfor er denne modellen spesielt egnet for programmerbare betalinger og AI‑drevne finansoperasjoner, og hvordan bør kunder vurdere beskyttelsen sammenlignet med konvensjonell FDIC‑forsikret bankvirksomhet?

AI er en akselerator for finans, men svaret på dette spørsmålet handler ikke bare om AI, men om avregning. Tradisjonelle banker ble bygget for en verden som beveget seg sakte. De er avhengige av en fler‑dagers flyt for å håndtere og tjene på forskjellene mellom driftsinnskudd og bankens kommersielle lån.

Innføring av sanntids‑, 24/7‑avregningskrav, enten det introduseres av en person eller en AI‑agent, avdekker en svakhet i det fraksjonelle reserve‑systemet: for å avregne midler umiddelbart må du ha midlene tilgjengelige. I en verden hvor betalingshastigheten øker, trenger bankene en like stor eller større økning i reserver for å sikre at midlene er tilgjengelige.

Vi tror at 24/7‑avregning ikke trygt kan sameksistere med langsiktig gjeldsutstedelse på ett enkelt balanseark. Vår smalbank‑modell skiller de to og sikrer at vi forblir likvide, fullt støttet og isolert fra kredittrisikoen til en utlånsavdeling.

Når bedrifts‑treasurere sammenligner vår smalbank‑fullreserve‑modell med FDIC‑forsikring, bør de vurdere hvordan «sikkerheten» leveres. FDIC‑forsikring har en grense på $250 000. For foretak som flytter millioner, etterlater det nesten all deres operative kapital eksponert for bankens underliggende utlåns‑ og balanse‑risiko.

Full‑reserve‑smalbankering er ikke avhengig av forsikring i det hele tatt fordi vi ikke låner. Enten balansen din er $100 000 eller $100 millioner, låner vi aldri ut kapitalen din, så du vet at den vil være tilgjengelig for å støtte driften og betalingsbehovene dine. Vi tror dette er nødvendig for en 24/7‑umiddelbar avregningsøkonomi.

N3XT har også introdusert N3XT Digital Dollar, et bankutstedt tokenisert innskudd designet for døgnkontinuerlig avregning. Hvordan vil N3XT MCP samhandle med tokeniserte innskudd, stablecoins og tradisjonelle amerikanske dollar‑betalingsnettverk innen samme treasury‑arbeidsflyt?

Først er det verdt å klargjøre et punkt om vår modell. N3XT er spesialbygget for å støtte 24/7 B2B‑betalinger med atomisk avregning. Eldre betalingsnettverk var ikke designet for atomisk avregning, så de interagerer ikke der. Det var et bevisst valg.

Vi brukte to år på å bygge et moderne, blokkjedebasert kjernbankssystem. Dette inkluderer en privat tillatt kjede hvor klienter transakterer i dollar for å foreta betalinger med andre N3XT‑klienter på nettverket, og offentlig kjede‑tilgang hvor mange av våre klienter allerede transakterer. Den offentlige kjeden er hvor de kan transaktere ved hjelp av N3XT Digital Dollar (NDD).

MCP gjør det mulig for AI‑assistenter å orkestrere arbeidsflyter mellom disse to miljøene. For eksempel å sjekke NDD‑saldoer i en klients offentlige lommebøker, og deretter utføre en sweep mellom lommebøkene om nødvendig, eller overføre midler fra en privat lommebok til en offentlig NDD‑lommebok – alt mens man overholder styringsarbeidsflyter.

Dermed gir MCP et styrt grensesnitt for å operere på tvers av N3XT sin 24/7 digitale arkitektur, både for USD og NDD.

Mye av verdien av en åpen standard avhenger av interoperabilitet. Hvilke AI‑assistenter, bedrifts‑systemer og treasury‑plattformer kan for øyeblikket kobles til N3XT MCP, og hvordan forhindrer du at kunder blir avhengige av én modellleverandør eller proprietært grensesnitt?

Grunnen til at vi bygde på Model Context Protocol (MCP) i stedet for å slippe et eget SDK, var for å muliggjøre interoperabilitet. Våre kunder bruker de verktøyene de bruker, og i AI‑alderen kan de kanskje bytte oftere enn før.

Fordi MCP er en åpen spesifikasjon, kobler N3XT MCP seg direkte til hvilken AI‑vertsmiljø en klient allerede stoler på, som Cursor, Anthropic, OpenAI eller Gemini. Den tilbyr også innebygd kompatibilitet med orkestreringsrammeverk som LangChain og AutoGen. Når det gjelder bedrifts‑systemer som ERP‑er, hvis disse systemene har bygget inn native MCP‑tilkoblinger, kan klientene også arbeide på tvers av plattformer fra sin valgte AI‑plattform.

Så med MCP gir vi klientene mer frihet. Hvis de bestemmer seg for å bytte AI‑leverandør, eller de vil bytte modeller til det nyeste og beste, trenger de ikke å bygge om noen koblinger. De peker bare den nye AI‑modellen mot N3XT MCP‑serveren, så er de i gang.

N3XT beskriver denne lanseringen som et tidlig steg mot autonom bedriftskapitalforvaltning. Hvor autonom bør bedriftsfinans realistisk bli, og hvilke tekniske, regulatoriske og kulturelle barrierer må løses før bedrifter tillater AI‑agenter å håndtere betydelige kapitalmengder?

Målet med autonom finans er ikke å skape en «sett‑og‑glem»-svart boks som flytter penger uten menneskelig tilsyn. Uovervåket autonomi er ikke innovasjon; det er en forpliktelse.

Mer realistisk bør bedriftsfinans utvikle seg mot engasjert autonomi: AI‑agenter utfører dataanalyse, overvåking og arbeidsflyter, mens forretningsledere og finans‑team skifter fra manuell utførelse til policy‑setting, strategi og godkjenninger.

For å øke tilliten i virksomheten og gi AI‑agenter tilgang og styrt kontroll over betalinger og driftskapital, må spørsmålene om identitet og ansvarlighet løses.

Hvem er ansvarlig hvis en AI‑modell misforstår en faktura og utløser en feilaktig utbetaling? Vår maker/checker‑modell fungerer for å forhindre at dette skjer.

Kulturelt er vi fortsatt tidlig i overgangen til agentisk finans. Etter hvert som AI tar på seg større operative roller, tror jeg agentisk identitet vil bli et tema av økende betydning og fokus fordi tillit – enten til mennesker eller AI – krever ansvarlighet.

Takk for det flotte intervjuet, lesere som ønsker å lære mer bør besøke N3XT.