Dalla frammentazione alla faglia: lo standard API mancante del corporate banking nell'era agentica

Il retail banking ha avuto il suo standard API un decennio fa. Il corporate banking mai — e nel 2026 quell'omissione ha smesso di essere un fastidio ed è diventata una faglia. ISO 20022 ha dato al settore una grammatica comune; non gli ha mai dato una superficie comune, pronta per gli agenti. Ora il chiamante è cambiato. Non è più uno sviluppatore con un trimestre da bruciare sull'integrazione, ma un modello che scopre gli strumenti a runtime e muove denaro entro fasce di policy. L'ambiguità che i tesorieri corporate hanno assorbito in silenzio per vent'anni sta per essere consegnata a un software che non può assorbirla — mentre il layer dati sottostante viene forzato in forma strutturata che le banche lo vogliano o no. Questo è ciò che costa la direzione mancante, perché gli agenti rendono l'attuale frammentazione non sicura anziché meramente inefficiente e ciò che uno standard API per il corporate banking deve rendere obbligatorio prima che la tesoreria autonoma possa scalare.

Sintesi per la dirigenza

Il corporate banking ha la grammatica, non la superficie. ISO 20022 ha standardizzato i dati; nessuno ha standardizzato l'API. Era sostenibile finché un integratore umano assorbiva l'ambiguità — un modello a runtime non può.

Il chiamante è cambiato. MCP ha reso la scoperta degli strumenti una decisione a runtime. Un agente pensato per abolire il problema di integrazione M×N lo incontra di nuovo al confine della banca, dove ogni istituzione è un server su misura con la propria semantica.

La frammentazione ora muove denaro in modo errato, a velocità di macchina. Un timeout, tre banche, tre verità contraddittorie — un duplicato in A, un'istruzione bloccata in B, un guasto silenzioso in C. Idempotenza e una grammatica deterministica degli errori diventano portanti.

Avvolgere ogni banca in un server MCP sposta la palude. Quaranta server, quaranta semantiche, nessun pavimento non funzionale condiviso — e un modello non deterministico con accesso in scrittura ai canali di pagamento, in pieno un problema SR 11-7 / DORA / EU AI Act.

Standardizza la tua superficie, o diventa la commodity. Le banche che pubblicano ora un'API ISO 20022-native e pronta per gli agenti diventano le controparti predefinite per la tesoreria autonoma; le altre affittano la relazione con il cliente a chi possiede l'adattatore.

Due mondi bancari, uno solo standardizzato

Si guardi il retail e il quadro è disordinato ma navigabile. L'Europa ha UK Open Banking e la NextGenPSD2 del Berlin Group, quest'ultima adottata da oltre tre quarti delle banche europee e trattata in pratica come uno standard de facto. Gli Stati Uniti hanno il Financial Data Exchange, che oggi copre oltre sessanta milioni di conti dei consumatori. L'Australia ha il Consumer Data Right. Nessuno di questi è globale, e nessuno è destinato a diventarlo — ma ciascuno è un contratto reale, versionato, testabile dalla macchina, e dove i contratti finiscono, gli aggregatori (Plaid, Tink, TrueLayer, Salt Edge) assorbono la differenza dietro un'unica interfaccia. La frammentazione retail è una tassa. Non è un muro.

Il corporate e wholesale banking non ha un equivalente. Una tesoreria multinazionale raggiunge le proprie banche attraverso pipe di file host-to-host, una dozzina di portali su misura, un sistema di gestione della tesoreria o un aggregatore — di solito tutti e quattro insieme. Non è un uomo di paglia: la stessa ricerca di McKinsey sul transaction banking cataloga da anni questa eredità, descrivendo come le banche si appoggino al trasferimento di file host-to-host e SFTP, elencando le note modalità di guasto dell'integrazione basata su file — formati ERP ingombranti da personalizzare per ogni corporate, un'incapacità di gestire l'instradamento condizionale — e riportando che oltre l'85% dei dirigenti del transaction banking intende investire in API di cash management. L'appetito per le API non è in dubbio. Ciò che manca è il contratto comune a cui puntano.

Perché i candidati abituali non lo sono. ISO 20022 viene regolarmente scambiato per lo standard mancante, ma è una grammatica dati, non un contratto API: pain.001 ti dice come esprimere un bonifico, non quale endpoint ne crei uno, come si autentica, come pagina o come ti comunica di aver fallito. BIAN dà al settore un modello di riferimento semantico condiviso, non un'interfaccia imposta. Le API Payment Initiation e Instant Cash Reporting di Swift sono un vero passo verso la standardizzazione, ma sono network-centric e ancora emergenti, non una superficie universale. Il framework openFinance del Berlin Group si sta protendendo verso i casi d'uso corporate — apertura di conti, trade finance, pagamenti ricorrenti dinamici — ma è europeo, precoce e premium per accordo. Assembla tutto questo e ancora non hai uno standard API per il corporate banking vincolante e globale. Hai materiali da costruzione e nessun progetto.

Perché la frammentazione è sopravvissuta — e perché sta finendo

Per vent'anni questo è stato tollerabile, perché l'integratore era umano e paziente. Un corporate attivava una manciata di connessioni bancarie in mesi, a volte trimestri. Ciascuna era un progetto: certificati scambiati, un penny test eseguito, un documento di mappatura discusso. Il costo era reale ma pagato una volta per relazione e ammortizzato su anni di pagamenti successivi. Quando l'API di una banca era sotto-specificata — quando uno standard "lasciava il resto all'istituzione implementante", come le banche stesse lamentano che faccia — un ingegnere umano leggeva il portale, deduceva l'intento e tappava la falla. L'ambiguità era sostenibile perché c'era una persona a risolverla.

È sopravvissuta anche per ragioni dette meno spesso ad alta voce. L'idraulica sottostante è genuinamente difficile da cambiare: finestre di regolamento batch, cicli notturni e core mainframe mai progettati per rispondere a una domanda in tempo reale. E la frammentazione non è solo un incidente — è, silenziosamente, una forma di lock-in. Ogni pipe host-to-host su misura che un tesoriere costruisce è un costo di switching che si accumula a favore dell'incumbent. Una banca difficile da integrare è, al margine, una banca difficile da lasciare. Nulla di tutto ciò è cospirativo; è ordinario incentivo. Ma spiega perché un settore che ha concordato una grammatica dati non ha mai concordato una superficie — e perché la superficie è l'ultimo layer non standardizzato rimasto. La ragione per cui non può più reggere è che il layer sottostante viene forzato in forma strutturata entro una scadenza, e il layer soprastante ha appena acquisito un nuovo utente impaziente.

Il chiamante è cambiato

Quell'utente è arrivato in diciotto mesi. Il Model Context Protocol, che Anthropic ha reso open source a novembre 2024 e donato all'Agentic AI Foundation della Linux Foundation a dicembre 2025 insieme a Block e OpenAI, è diventato il modo predefinito con cui i sistemi AI raggiungono strumenti e dati. All'inizio del 2026 registrava circa novantasette milioni di download di SDK al mese; a metà anno, secondo una lettura direzionale del settore, circa il settantotto per cento dei team AI aziendali eseguiva agenti basati su MCP in produzione e oltre un quarto delle Fortune 500 operava server MCP, protetti attraverso un layer di autorizzazione OAuth 2.1 standard. Viene abitualmente, e accuratamente, descritto come l'USB-C per l'AI: fa collassare l'incubo di integrazione M×N — ogni modello cablato a mano a ogni strumento — in M+N. La sua stessa autodescrizione è la frase che conta per le banche: le API sono per i programmi; MCP è per gli agenti. Un'API REST si aspetta che il chiamante sappia in anticipo quale endpoint colpire e con quali parametri. Un agente si aspetta di scoprire gli strumenti disponibili a runtime e di decidere, da sé, come e quando usarli.

Questo non è ipotetico per la tesoreria. Il pattern è già coerente nelle tesorerie delle corporate-and-investment-bank nel 2026: un agente legge i dati di cassa ISO 20022, chiama un insieme delimitato di strumenti e riequilibra la liquidità entro fasce di policy, con controlli SR 11-7, DORA ed EU AI Act che lo avvolgono. La grammatica dati è pronta per questo. La superficie API no.

Il disallineamento, con precisione

Riduci l'agente a ciò di cui ha realmente bisogno da una controparte bancaria e la lista è breve e implacabile:

Un contratto scopribile dalla macchina — una descrizione OpenAPI, o un manifest di strumenti, che l'agente possa leggere a runtime anziché un PDF che un umano legge una volta.
Un unico modello di autenticazione — un profilo OAuth2/mTLS di livello finanziario (FAPI è l'ancora ovvia), non un handshake diverso per banca.
L'idempotenza come garanzia — un riferimento di istruzione univoco che rende un pagamento ritentato un no-op, perché un agente ritenterà.
Una grammatica deterministica degli errori — lo stesso guasto che significa la stessa cosa ovunque, così che il modello possa ragionarci sopra.
Versionamento semantico e scoperta delle capacità — così che un agente possa sapere cosa può fare una controparte in questo trimestre senza una release note umana.
Payload ISO 20022 strutturati, consenso ed entitlement, e una traccia di audit a prova di manomissione — la sostanza, il permesso e l'evidenza.

Metti tutto ciò a confronto con il corporate banking così com'è e ogni riga si frantuma in N dialetti — uno per banca. L'agente che avrebbe dovuto abolire il problema M×N lo incontra di nuovo al confine della banca, perché ogni istituzione è, di fatto, un server su misura con la propria grammatica per "saldo", la propria nozione di "stato del pagamento", il proprio balletto di autenticazione e la propria idea di cosa sia un errore. Il protocollo ha standardizzato il lato dell'agente sul filo. Nessuno ha standardizzato quello della banca.

Una modalità di guasto, resa concreta

Rendila specifica, perché è qui che l'astrazione morde. Immagina un agente di liquidità autorizzato a spazzare cassa attraverso tre banche per mantenere ogni conto entro una fascia target. Lancia tre istruzioni quasi identiche e, come fanno le reti, incappa in un timeout su ciascuna.

La Banca A tratta il timeout come sconosciuto — sicuro da ritentare, quindi l'agente ritenta, e anche l'istruzione originale si regola: un pagamento duplicato. La Banca B tratta lo stesso timeout come inviato — non ritentare, ma non fa mai emergere una conferma che l'agente possa interpretare, così l'istruzione resta nel limbo mentre l'agente, non vedendo alcun successo, escala o reinstrada: un pagamento bloccato e una posizione contabilizzata due volte. La Banca C restituisce un allegro HTTP 200 con un rifiuto sepolto nel corpo del payload; l'agente legge il codice di stato, marca lo sweep come concluso e prosegue: un guasto silenzioso che emerge solo la mattina successiva come uno scarto di riconciliazione che nessuno riesce a spiegare.

Tre banche, una condizione, tre verità contraddittorie — fondi duplicati usciti dalla porta in A, un'istruzione congelata in B, un successo fantasma in C. Un tesoriere umano avrebbe telefonato a tre relationship manager e risolto entro pranzo. L'agente non può telefonare a nessuno. È esattamente per questo che "l'idempotenza come garanzia" e "una grammatica deterministica degli errori" non sono accessori architetturali: senza di essi, la stessa frammentazione che prima costava ore umane ora muove denaro reale in modo errato, a velocità di macchina, attraverso ogni controparte contemporaneamente.

Perché "avvolgere ogni banca in un server MCP" non è la soluzione

La risposta riflessa è dare a ogni banca un server MCP e chiudere la questione. Non regge, perché ricolloca la frammentazione anziché rimuoverla. Quaranta banche diventano quaranta server con quaranta semantiche, quaranta flussi di autenticazione e nessun significato condiviso — e, cosa cruciale, nessun pavimento non funzionale condiviso: nessun budget di latenza comune, nessun livello di disponibilità concordato, nessuna garanzia di idempotenza comparabile. La modalità di guasto descritta sopra sopravvive intatta all'involucro. Peggio, il chiamante è ora un modello non deterministico con accesso in scrittura ai canali di pagamento, il che non è solo una questione di integrazione ma di rischio di modello e resilienza operativa che ricade in pieno su SR 11-7, DORA ed EU AI Act. Le primitive human-in-the-loop di MCP — elicitation per la conferma, sampling per il ragionamento — sono necessarie e benvenute, ma una finestra di conferma non sostituisce una controparte che si comporta in modo prevedibile. Non puoi governare su scala ciò che non puoi descrivere in modo uniforme. Un migliaio di server su misura non è uno standard; è la stessa palude con una patina JSON-RPC.

Due futuri, e una scelta strategica

Chi risolve questo determina chi possiederà la relazione corporate per il prossimo decennio, e ci sono solo due candidati.

Nel primo, le banche standardizzano le proprie superfici. Pubblicano API pronte per gli agenti, mantengono la connessione diretta con il tesoriere e restano la controparte che l'agente scopre e chiama. Nel secondo, gli aggregatori la standardizzano per loro. Una manciata di piattaforme definisce il contratto agentico de facto, e le banche diventano endpoint intercambiabili dietro di esso — raggiungibili solo attraverso l'astrazione di qualcun altro. Non è speculazione; è la storia del retail proiettata in avanti di un segmento. Lo stesso lavoro di McKinsey del 2025 sul transaction banking descrive piattaforme di gestione della tesoreria come Kyriba e GTreasury, e piattaforme office-of-the-CFO come Bill.com, che si posizionano tra clienti e banche con una vista unica e agnostica rispetto alla banca della posizione. È esattamente il layer che, nel retail, ha silenziosamente fatto sparire la coda lunga dietro Plaid e Tink. La stessa ricerca nota che i tesorieri corporate oggi tengono le loro banche agli standard delle proprie app consumer, e cambieranno quando onboarding, entitlement e integrazione API deludono.

Il contenuto strategico della scelta è netto. Una banca che diventa un endpoint dietro il contratto agentico di un aggregatore cede tre cose in una volta. Il margine, poiché i suoi servizi vengono ridotti a commodity e confrontati anzitutto sul prezzo attraverso l'interfaccia di qualcun altro. La proprietà del cliente, poiché la relazione, il contesto e il costo di switching migrano verso la piattaforma. E il potere sui dati e sull'analisi, poiché il flusso che un tempo vedeva end-to-end è ora mediato da un intermediario che vede più del cliente di quanto ne veda la banca. Standardizzare la propria superficie non è un progetto di igiene tecnica. È la differenza tra essere la controparte ed essere la commodity.

Cosa deve rendere obbligatorio lo standard

La direzione che manca non è esotica. Ogni componente esiste già in forma aperta — ISO 20022 per i dati, le API Payment Initiation e Instant Cash Reporting di Swift per le operazioni di riferimento, BIAN per la semantica, l'openFinance del Berlin Group per il pattern consenso-e-catalogo, FAPI per l'autenticazione di livello finanziario, MCP per l'esposizione degli strumenti, A2A per l'orchestrazione agent-to-agent. Ciò che è assente è l'atto di assemblarli in un contratto vincolante per lo spazio corporate — e la disciplina di specificare due pavimenti, non uno. La letteratura esistente sulle API B2B, quella di McKinsey inclusa, tratta le API in gran parte come un'opportunità di crescita e di esperienza. Dice poco su determinismo, scoperta delle capacità a runtime o non funzionali standardizzati — esattamente l'omissione che gli agenti non possono tollerare. Perciò lo standard deve essere esplicito sia su cosa è l'interfaccia sia su come si comporta sotto governance.

Il pavimento tecnico

Un contratto OpenAPI-first con un manifest canonico di strumenti MCP generato da esso — non scritto a mano di fianco, così che gli strumenti che un agente vede non possano mai divergere dall'API che la banca esegue.
Autenticazione e consenso di livello FAPI come unico handshake su tutta la superficie.
Idempotenza e una tassonomia deterministica degli errori — codici stabili, un significato per guasto, documentati nel contratto stesso.
Payload ISO 20022-native, strutturati e pronti per l'indirizzo ibrido.
Versionamento semantico con scoperta delle capacità a runtime — un agente può chiedere cosa può fare oggi questa controparte, e ottenere una risposta leggibile dalla macchina.

Il pavimento di governance e resilienza

SLO non funzionali pubblicati e imposti — latenza, disponibilità, throughput, straight-through-processing e sforzo umano — espressi come numeri reali di tempo e movimento, non come linguaggio di marketing.
Entitlement, consenso e una traccia di audit a prova di manomissione vincolati al percorso di esecuzione, non fluttuanti in un portale fuori banda.
Controlli di rischio di modello e di resilienza operativa allineati a SR 11-7, DORA ed EU AI Act, così che le chiamate di un agente siano eventi governati con un proprietario, non casi limite esotici.

C'è una lezione dura sepolta nell'esperienza retail qui. Uno standard che una macchina esegue deve essere più preciso di uno che un integratore umano può riparare silenziosamente; la sotto-specificazione non è più un costo morbido pagato in ore di sviluppo ma una modalità di guasto dura pagata in pagamenti mal inviati. È significativo che lo sforzo di armonizzazione più autorevole del settore — i requisiti dati ISO 20022 armonizzati di CPMI e PMPG, che i sistemi di pagamento di tutto il mondo sono sollecitati ad adottare entro la fine del 2027 nell'ambito del programma G20 sui pagamenti transfrontalieri, per combattere esattamente questa frammentazione — sia, per sua stessa descrizione, né una regolamentazione né uno standard API. Armonizza i dati. L'interfaccia resta compito di nessuno.

Un quadro obiettivo

La costruzione è meno scoraggiante della diagnosi, perché sono tre layer, non un programma. Un'API canonica per il corporate banking espone pagamenti e reporting di cassa su REST e OpenAPI, con payload ISO 20022-native e autenticazione di livello FAPI — un contratto, una grammatica, un handshake. Un bridge MCP si colloca sopra di essa e genera il manifest di strumenti rivolto agli agenti direttamente da quel contratto OpenAPI, così che scoperta, schemi e permessi siano derivati dalla superficie anziché mantenuti in parallelo a essa. E un layer di policy e resilienza avvolge ogni chiamata dell'agente con i controlli che rendono sicura l'autonomia: limiti su transazioni e controparti, segmentazione, trigger human-in-the-loop (elicitation sulle azioni ad alto rischio), monitoraggio SLO in tempo reale e un interruttore di emergenza rigido. Non servono diagrammi per afferrare il punto — lo standard non è un nuovo canale, è una disposizione disciplinata di canali che già esistono, con il percorso dell'agente e il percorso di governance integrati fin dal primo commit anziché innestati dopo l'incidente.

Cosa fanno le banche credibili nei prossimi 24 mesi

Se accetti che il chiamante è cambiato, il lavoro è concreto e si articola in cinque filoni.

Pubblica una superficie ISO 20022-native e OpenAPI-first. Prendi un corridoio ad alto valore — tipicamente pagamenti transfrontalieri e reporting di cassa — ed esponilo attraverso una singola definizione OpenAPI versionata con payload ISO 20022, allineata ai tuoi schemi CBPR+ esistenti anziché a una quinta grammatica inventata. Rendila pubblica per i clienti e gli agenti interni, con una sandbox, e tratta le modifiche come release di prodotto. Il successo del primo anno non è la copertura totale; è dimostrare che un corridoio può essere reso indirizzabile dagli agenti end-to-end.
Standardizza autenticazione e idempotenza su di essa. Adotta un unico profilo di livello FAPI come solo handshake, imponi chiavi di idempotenza su ogni scrittura e rendi "ritenta la stessa istruzione" una garanzia documentata nel contratto — trasformando "gli agenti ritenteranno" da rischio in un'assunzione sicura.
Definisci una grammatica deterministica degli errori e la scoperta delle capacità. Dai a ogni guasto un codice stabile e una semantica coerente, aggiungi il versionamento semantico ed esponi un catalogo di capacità che un agente possa interrogare a runtime, con flag espliciti per supporto parziale, deprecazione e "non ancora disponibile".
Collega entitlement, consenso e audit alla stessa superficie. Sposta i flussi di consenso e approvazione sul percorso API, emetti una traccia a prova di manomissione per ogni istruzione avviata da un agente — chi, cosa, quando, sotto quale fascia di policy — e allineala esplicitamente a SR 11-7, DORA ed EU AI Act così che la seconda linea possa validarla.
Pubblica i pavimenti non funzionali, poi esegui un pilota supervisionato con un agente. Impegnati su obiettivi di latenza, disponibilità, throughput e STP per il corridoio e strumentali; poi metti in piedi un agente supervisionato di liquidità o di cash-sweeping che usi solo questa superficie, con limiti rigidi, checkpoint human-in-the-loop e audit completo, per sei-dodici mesi. È la funzione forzante che controlli tu stesso — dimostra che un agente può muovere denaro in sicurezza entro fasce di policy quando la superficie è prevedibile, e ti dice rapidamente dove il tuo standard è ancora aspirazione anziché fatto.

La funzione forzante

Il settore ha appena dimostrato di sapersi muovere quando qualcosa lo costringe. Il cut-over dell'indirizzo strutturato di Swift di novembre 2026 — dopo il quale gli indirizzi non strutturati nei pagamenti transfrontalieri vengono semplicemente rifiutati, senza conversione di contingenza — ha trascinato un mercato riluttante verso i dati ISO 20022 strutturati entro una data fissa, rafforzato dalla spinta del CPMI di fine 2027 per requisiti dati armonizzati nell'ambito del programma G20 sui pagamenti. Nota cosa standardizzano entrambi gli sforzi: i dati, non l'interfaccia. La grammatica viene forzata pulita. La superficie è stata lasciata alla discrezione di ciascuna banca — che è precisamente la discrezione con cui gli agenti non possono lavorare. Per un agente, questo significa che i payload saranno finalmente coerenti mentre il comportamento dietro di essi resta divergente — un'inversione di ciò di cui una macchina ha davvero bisogno, che è comportamento prevedibile prima e dati puliti poi.

Ecco quindi l'errore evitabile da scongiurare: aspettare che un comitato globale benedica uno standard API per il corporate banking prima di agire. Le banche che pubblicano ora una superficie ISO 20022-native e pronta per gli agenti — un contratto OpenAPI, un manifest MCP generato da esso, autenticazione di livello finanziario e pavimenti non funzionali su cui sapranno davvero rispondere — diventeranno le controparti predefinite per la tesoreria autonoma. I loro strumenti saranno quelli che gli agenti potranno scoprire, di cui potranno fidarsi e che potranno chiamare senza un umano nel mezzo. Le banche che aspettano saranno raggiungibili solo attraverso l'astrazione di un aggregatore, affittando la propria relazione con il cliente a chi possiede l'adattatore.

Grammatica senza direzione non è uno standard. ISO 20022 ha detto al corporate banking come parlare. Non gli ha mai detto dove andare. Gli agenti sono arrivati, fluenti e impazienti, e la mappa ancora non c'è. Disegnarla è ora il pezzo più consequenziale di lavoro infrastrutturale nel transaction banking — e, per una volta, la scadenza non è fissata da un regolatore ma dalle macchine già in attesa all'interfaccia.

Domande frequenti

ISO 20022 non è lo standard mancante? No. ISO 20022 è una grammatica dati, non un contratto API. pain.001 dice a un sistema come esprimere un bonifico; non dice quale endpoint ne crei uno, come si autentica, come pagina o come riporta un guasto. La grammatica è pronta per gli agenti. La superficie — l'interfaccia scopribile dalla macchina, dal comportamento uniforme, che un agente chiama davvero — no.

Perché non avvolgere semplicemente ogni banca in un server MCP? Perché ricolloca la frammentazione invece di rimuoverla. Quaranta banche diventano quaranta server con quaranta semantiche, quaranta flussi di autenticazione e — cosa cruciale — nessun pavimento non funzionale condiviso: nessun budget di latenza comune, nessun livello di disponibilità concordato, nessuna garanzia di idempotenza comparabile. Il chiamante è ora un modello non deterministico con accesso in scrittura ai canali di pagamento, il che è un problema di rischio di modello e di resilienza operativa sotto SR 11-7, DORA ed EU AI Act. Un migliaio di server su misura non è uno standard.

Qual è la prima mossa più utile per una banca? Pubblicare un corridoio ISO 20022-native e OpenAPI-first — tipicamente pagamenti transfrontalieri e reporting di cassa — con un handshake di livello FAPI, l'idempotenza come garanzia documentata e una grammatica deterministica degli errori. Poi eseguire un pilota supervisionato con un agente solo contro quella superficie, con limiti rigidi, checkpoint human-in-the-loop e audit completo. Dimostrare un corridoio end-to-end batte una roadmap che copre tutto e non rende obbligatorio nulla.

Chi risolve questo se le banche non lo fanno? Gli aggregatori. Una manciata di piattaforme di tesoreria e office-of-the-CFO definirà il contratto agentico de facto, e le banche diventeranno endpoint intercambiabili dietro di esso — cedendo margine, proprietà del cliente e dati end-to-end in una volta. È la storia del retail, dove Plaid e Tink hanno assorbito la coda lunga, proiettata in avanti di un segmento nel corporate banking.

Riferimenti

Model Context Protocol — documentazione ufficiale ⧉. [MCP reso open source a novembre 2024 e donato all'Agentic AI Foundation della Linux Foundation a dicembre 2025 insieme a Block e OpenAI; il layer di scoperta degli strumenti a runtime su cui l'analisi si fonda. Le cifre di adozione nel testo sono letture direzionali del settore e come tali segnalate.]
Berlin Group — NextGenPSD2 e openFinance ⧉. [Lo standard API retail europeo de facto e la sua estensione verso i casi d'uso corporate — citato per il pattern consenso-e-catalogo e per il contrasto retail-vs-corporate.]
Financial Data Exchange (FDX) ⧉. [Lo standard USA di condivisione dei dati retail, citato per la scala dei contratti retail standardizzati rispetto ai quali il corporate banking non ha equivalenti.]
McKinsey & Company — Financial Services insights ⧉. [Ricerca sulle API del transaction banking: eredità host-to-host / SFTP, l'intento di investimento in API di cash management di circa l'85% e l'intermediazione delle piattaforme di tesoreria. Citata per la diagnosi di mercato; l'impostazione e le conclusioni qui sono dell'autore.]
Bank for International Settlements (CPMI) — Requisiti dati ISO 20022 armonizzati ⧉. [La spinta di fine 2027 ad armonizzare i dati di pagamento — per sua stessa descrizione né una regolamentazione né uno standard API — citata per il punto "grammatica senza superficie".]
Swift — ISO 20022 per le istituzioni finanziarie ⧉. [CBPR+ e il traguardo dell'indirizzo strutturato di novembre 2026; le API Payment Initiation e Instant Cash Reporting citate come operazioni di riferimento, non una superficie universale.]

Ultima revisione luglio 2026. Analisi originale; le fonti sono citate, non riprodotte. Le cifre di adozione e di mercato sono letture direzionali del settore — da verificare rispetto alle fonti primarie prima della ripubblicazione. Concesso in licenza CC-BY-4.0.

Ultima revisione 2026-07-08.

Ripubblica questo articolo

From Fragmentation to Fault Line: Corporate Banking's Missing API Standard in the Agentic Era — Sebastien Rousseau

Il retail banking ha avuto il suo standard API un decennio fa. Il corporate banking mai — e ora che gli agenti AI e il Model Context Protocol hanno reso l'integrazione una decisione a runtime, il divario è diventato una faglia.

Questo articolo è pubblicato con licenza Creative Commons Attribution 4.0 International. La ripubblicazione richiede l'attribuzione all'URL canonico.

From Fragmentation to Fault Line: Corporate Banking's Missing API Standard in the Agentic Era — Sebastien Rousseau

Il retail banking ha avuto il suo standard API un decennio fa. Il corporate banking mai — e ora che gli agenti AI e il Model Context Protocol hanno reso l'integrazione una decisione a runtime, il divario è diventato una faglia.

Originally published at https://sebastienrousseau.com/it/2026-07-07-corporate-banking-api-standard-agentic-mcp-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER