A széttöredezettségtől a törésvonalig: a vállalati banki szektor hiányzó API-szabványa az ügynöki korszakban

TL;DR. A lakossági banki szektor egy évtizede megkapta az API-szabványát. A vállalati banki szektor sosem, és most, hogy az AI-ügynökök és a Model Context Protocol az integrációt futásidejű döntéssé tették, a rés törésvonallá vált.

Points clés

A széttöredezettségtől a törésvonalig: a vállalati banki szektor hiányzó API-szabványa az ügynöki korszakban. A lakossági banki szektor egy évtizede megkapta az API-szabványát.
Két banki világ, egyikük szabványosítva. Nézzük a lakossági szektort: a kép rendezetlen, de bejárható.
Miért maradt fenn a széttöredezettség, és miért ér ez véget. Húsz éven át ez elviselhető volt, mert az integrátor emberi és türelmes volt.
A hívó fél megváltozott. Ez a felhasználó tizennyolc hónap alatt érkezett meg.

A széttöredezettségtől a törésvonalig: a vállalati banki szektor hiányzó API-szabványa az ügynöki korszakban

A lakossági banki szektor egy évtizede megkapta az API-szabványát. A vállalati banki szektor sosem, és 2026-ra ez a mulasztás megszűnt kellemetlenség lenni, és törésvonallá vált. Az ISO 20022 közös nyelvtant adott az iparágnak; közös, ügynökkész felületet sosem adott. Most azonban a hívó fél megváltozott. Már nem egy fejlesztő, akinek egy negyedéve van az integrációra, hanem egy modell, amely futásidőben fedezi fel az eszközöket, és szabályzati sávokon belül mozgat pénzt. A kétértelműséget, amelyet a vállalati treasurerek húsz éven át csendben elnyeltek, hamarosan olyan szoftverre bízzák, amely nem képes elnyelni azt, miközben az alatta lévő adatréteget strukturálttá kényszerítik, akár tetszik a bankoknak, akár nem. Ez az, amibe a hiányzó irány kerül, ez az oka annak, hogy az ügynökök a mai széttöredezettséget nem pusztán nem hatékonnyá, hanem veszélyessé teszik, és ez az, amit egy vállalati banki API-szabványnak elő kell írnia, mielőtt az autonóm treasury méretezhetővé válhat.

Vezetői összefoglaló

A vállalati banki szektornak megvan a nyelvtana, de nincs meg a felülete. Az ISO 20022 szabványosította az adatokat; az API-t senki sem szabványosította. Ez elviselhető volt, amíg egy emberi integrátor elnyelte a kétértelműséget: egy futásidejű modell nem képes erre.

A hívó fél megváltozott. Az MCP az eszközfelfedezést futásidejű döntéssé tette. Egy ügynök, amelynek az M×N integrációs problémát kellett volna megszüntetnie, a bank határán ismét szembetalálja magát vele, ahol minden intézmény egyedi szerver a maga szemantikájával.

A széttöredezettség immár rosszul mozgatja a pénzt, gépi sebességgel. Egy időtúllépés, három bank, három egymásnak ellentmondó igazság: egy duplikátum A-nál, egy elakadt utasítás B-nél, egy néma hiba C-nél. Az idempotencia és a determinisztikus hibanyelvtan teherhordóvá válik.

Ha minden bankot MCP-szerverbe csomagolunk, az áthelyezi a mocsarat. Negyven szerver, negyven szemantika, közös nem funkcionális alapszint nélkül, és egy nem determinisztikus modell írási hozzáféréssel a fizetési csatornákhoz, ami egyértelműen SR 11-7 / DORA / EU AI Act probléma.

Szabványosítsd a saját felületed, vagy válj árucikké. Azok a bankok, amelyek ISO 20022-natív, ügynökkész API-t tesznek közzé, az autonóm treasury alapértelmezett partnereivé válnak; a többiek az ügyfélkapcsolatukat bérbe adják annak, aki az adaptert birtokolja.

Két banki világ, egyikük szabványosítva

Nézzük a lakossági szektort: a kép rendezetlen, de bejárható. Európának ott van a UK Open Banking és a Berlin Group NextGenPSD2-je, utóbbit az európai bankok több mint háromnegyede vette át, és a gyakorlatban de facto szabványként kezelik. Az Egyesült Államoknak ott a Financial Data Exchange, amely mára több mint hatvanmillió fogyasztói számlát ölel fel. Ausztráliának ott a Consumer Data Right. Ezek egyike sem globális, és egyiküknek sem valószínű, hogy globálissá válik, de mindegyik valódi, verziózott, géppel tesztelhető szerződés, és ahol a szerződések véget érnek, ott az aggregátorok (Plaid, Tink, TrueLayer, Salt Edge) egyetlen felület mögött nyelik el a különbséget. A lakossági széttöredezettség egy adó. Nem fal.

A vállalati és nagykereskedelmi banki szektornak nincs ezzel egyenértékű megoldása. Egy multinacionális treasury host-to-host fájlcsöveken, egy tucat egyedi portálon, egy treasury-menedzsment rendszeren vagy egy aggregátoron keresztül éri el a bankjait, rendszerint mind a négyen egyszerre. Ez nem szalmabáb: a McKinsey saját tranzakciós banki kutatása évek óta katalogizálja ugyanezt az örökséget, leírva, hogyan támaszkodnak a bankok host-to-host és SFTP fájlátvitelre, felsorolva a fájlalapú integráció jól ismert hibamódjait, a terjedelmes ERP-formátumokat, amelyeket vállalatonként testre kell szabni, a feltételes útválasztás kezelésének képtelenségét, és arról számolva be, hogy a tranzakciós banki vezetők több mint 85%-a szándékozik készpénzkezelési API-kba fektetni. Az API-k iránti étvágy nem kérdéses. Ami hiányzik, az a közös szerződés, amelyre mutatnak.

Mert a szokásos jelöltek nem azok. Az ISO 20022-t rendszeresen összetévesztik a hiányzó szabvánnyal, pedig az adatnyelvtan, nem API-szerződés: a pain.001 megmondja, hogyan kell megfogalmazni egy átutalást, de nem azt, melyik végpont hozza létre, hogyan hitelesít, hogyan lapoz, vagy hogyan közli, hogy meghiúsult. A BIAN közös szemantikai referenciamodellt ad az iparágnak, nem kikényszerített felületet. A Swift Payment Initiation és Instant Cash Reporting API-jai valódi elmozdulás a szabványosítás felé, de hálózatközpontúak és még kibontakozóban vannak, nem egyetemes felület. A Berlin Group openFinance keretrendszere a vállalati felhasználási esetek felé nyúl, számlanyitás, kereskedelemfinanszírozás, dinamikus visszatérő fizetések, de európai, korai és megállapodás alapján prémium. Rakd össze az egészet, és még mindig nincs kötelező érvényű, globális vállalati banki API-szabványod. Csak építőanyagaid vannak, tervrajz nélkül.

Miért maradt fenn a széttöredezettség, és miért ér ez véget

Húsz éven át ez elviselhető volt, mert az integrátor emberi és türelmes volt. Egy vállalat hónapok, néha negyedévek alatt kötött be egy maroknyi banki kapcsolatot. Mindegyik projekt volt: tanúsítványok cseréje, egy pennys tesztfutás, egy leképezési dokumentum megvitatása. A költség valós volt, de kapcsolatonként egyszer fizették meg, és évek további fizetéseire amortizálták. Amikor egy bank API-ja alul volt specifikálva, amikor egy szabvány „a többit a megvalósító intézményre bízta", ahogy a bankok maguk panaszkodnak, hogy teszi, egy emberi mérnök elolvasta a portált, kikövetkeztette a szándékot, és áthidalta a rést. A kétértelműség elviselhető volt, mert ott volt egy ember, hogy feloldja.

Fennmaradt olyan okokból is, amelyeket ritkábban mondanak ki hangosan. Az alatta lévő vízvezeték valóban nehezen megváltoztatható: kötegelt elszámolási ablakok, éjszakai ciklusok és mainframe magok, amelyeket sosem terveztek arra, hogy valós idejű kérdésre válaszoljanak. És a széttöredezettség nem csupán baleset: csendben a bezártság egy formája is. Minden egyedi host-to-host cső, amelyet egy treasurer épít, egy váltási költség, amely a piacvezetőnek gyűlik. Egy bank, amelyet nehéz integrálni, a peremen egy olyan bank, amelyet nehéz elhagyni. Ebben semmi összeesküvésszerű nincs; ez közönséges ösztönző. De megmagyarázza, miért nem egyezett meg soha egy felületben egy olyan iparág, amely megegyezett egy adatnyelvtanban, és miért a felület az utolsó nem szabványosított réteg. Az ok, amiért ez tovább nem tartható, az, hogy az alatta lévő réteget határidőre strukturálttá kényszerítik, a fölötte lévő réteg pedig épp most szerzett egy új, türelmetlen felhasználót.

A hívó fél megváltozott

Ez a felhasználó tizennyolc hónap alatt érkezett meg. A Model Context Protocol, amelyet az Anthropic 2024 novemberében nyílt forráskódúvá tett, és 2025 decemberében a Linux Foundation Agentic AI Foundationjének adományozott a Block és az OpenAI mellett, az AI-rendszerek eszközökhöz és adatokhoz való hozzáférésének alapértelmezett módjává vált. 2026 elejére havonta nagyjából kilencvenhétmillió SDK-letöltést produkált; az év közepére, egy irányadó iparági olvasat szerint a vállalati AI-csapatok mintegy hetvennyolc százaléka futtatott MCP-alapú ügynököket éles környezetben, és a Fortune 500 több mint negyede üzemeltetett MCP-szervereket, amelyeket egy szabványos OAuth 2.1 engedélyezési réteg biztosított. Rendszeresen, és pontosan, az AI USB-C-jeként írják le: az M×N integrációs rémálmot, ahol minden modellt kézzel kötnek minden eszközhöz, M+N-re csökkenti. A saját magáról szóló összefoglalója az a mondat, amely a bankok számára számít: az API-k a programoknak valók; az MCP az ügynököknek. Egy REST API elvárja, hogy a hívó fél előre tudja, melyik végpontot kell megcéloznia és milyen paraméterekkel. Egy ügynök elvárja, hogy futásidőben fedezze fel az elérhető eszközöket, és maga döntse el, hogyan és mikor használja őket.

Ez a treasury számára nem elméleti kérdés. A minta 2026-ban már következetes a vállalati és befektetési banki treasuryk körében: egy ügynök beolvassa az ISO 20022 készpénzadatokat, meghív egy korlátozott eszközkészletet, és szabályzati sávokon belül újraegyensúlyozza a likviditást, SR 11-7, DORA és EU AI Act kontrollokkal körülvéve. Az adatnyelvtan készen áll erre. Az API-felület nem.

A meg nem felelés, pontosan

Csupaszítsd le az ügynököt arra, amire valójában szüksége van egy banki partnertől, és a lista rövid és kérlelhetetlen:

Egy géppel felfedezhető szerződés, egy OpenAPI-leírás vagy egy eszközmanifeszt, amelyet az ügynök futásidőben olvashat, nem pedig egy PDF, amelyet egy ember egyszer olvas el.
Egyetlen hitelesítési modell, egy pénzügyi szintű OAuth2/mTLS profil (a FAPI a kézenfekvő horgony), nem bankonként eltérő kézfogás.
Az idempotencia mint garancia, egy egyedi utasítás-hivatkozás, amely egy újrapróbált fizetést műveletnélkülivé tesz, mert egy ügynök fog újrapróbálni.
Egy determinisztikus hibanyelvtan, ahol ugyanaz a hiba mindenhol ugyanazt jelenti, hogy a modell érvelni tudjon róla.
Szemantikus verziózás és képességfelfedezés, hogy egy ügynök megtudhassa, mit tud egy partner ebben a negyedévben, emberi kiadási megjegyzés nélkül.
Strukturált ISO 20022 hasznos adatok, hozzájárulás és jogosultságok, valamint egy hamisításbiztos auditnapló, a lényeg, az engedély és a bizonyíték.

Állítsd ezt szembe a vállalati banki szektorral, ahogy létezik, és minden sor N dialektusra töredezik, bankonként egyre. Az ügynök, amelynek az M×N problémát kellett volna megszüntetnie, a bank határán ismét szembetalálja magát vele, mert minden intézmény valójában egy egyedi szerver, a „egyenleg" saját nyelvtanával, a „fizetési státusz" saját fogalmával, a saját hitelesítési táncával és a saját elképzelésével arról, hogy mi egy hiba. A protokoll szabványosította a vezeték ügynökoldalát. A bank oldalát senki sem szabványosította.

Egy hibamód, konkrétan

Tedd konkréttá, mert itt harap az absztrakció. Képzelj el egy likviditási ügynököt, amely fel van jogosítva arra, hogy három bank között készpénzt söpörjön össze, hogy minden számlát egy célsávon belül tartson. Három szinte azonos utasítást indít, és ahogy a hálózatok teszik, mindháromnál időtúllépésbe ütközik.

Az A bank az időtúllépést ismeretlen, biztonságosan újrapróbálható módon kezeli, így az ügynök újrapróbál, és az eredeti utasítás is elszámol: egy duplikált fizetés. A B bank ugyanazt az időtúllépést elküldve, ne próbáld újra módon kezeli, de sosem jelenít meg egy visszaigazolást, amelyet az ügynök értelmezni tudna, így az utasítás bizonytalanságban marad, miközben az ügynök, sikert nem látva, eszkalál vagy átirányít: egy elakadt fizetés és egy kétszeresen könyvelt pozíció. A C bank egy vidám HTTP 200-at ad vissza, a hasznos adat törzsében elrejtett elutasítással; az ügynök beolvassa az állapotkódot, késznek jelöli a söprést, és továbblép: egy néma hiba, amely csak másnap reggel bukkan fel egy egyeztetési eltérésként, amelyet senki sem tud megmagyarázni.

Három bank, egy feltétel, három egymásnak ellentmondó igazság: duplikált pénz kifelé A-nál, egy befagyott utasítás B-nél, egy fantom siker C-nél. Egy emberi treasurer felhívott volna három kapcsolattartót, és ebédig megoldotta volna. Az ügynök nem tud felhívni senkit. Pontosan ezért nem az „idempotencia mint garancia" és a „determinisztikus hibanyelvtan" építészeti csecsebecsék: nélkülük ugyanaz a széttöredezettség, amely korábban csupán emberi órákba került, most valós pénzt mozgat helytelenül, gépi sebességgel, egyszerre minden partnernél.

Miért nem megoldás az, hogy „minden bankot MCP-szerverbe csomagolunk"

A reflexszerű válasz az, hogy minden banknak adunk egy MCP-szervert, és készen vagyunk. Nem tartható, mert a széttöredezettséget áthelyezi, nem pedig megszünteti. Negyven bankból negyven szerver lesz negyven szemantikával, negyven hitelesítési folyamattal és megosztott jelentés nélkül, és ami kritikus, megosztott nem funkcionális alapszint nélkül: nincs közös késleltetési keret, nincs megegyezett rendelkezésre állási szint, nincs összehasonlítható idempotenciagarancia. A fenti hibamód sértetlenül túléli a csomagolást. Ami rosszabb, a hívó fél most egy nem determinisztikus modell, írási hozzáféréssel a fizetési csatornákhoz, ami nem pusztán integrációs kérdés, hanem egy modellkockázati és működési ellenállóképességi kérdés, amely egyenesen az SR 11-7-re, a DORA-ra és az EU AI Actre esik. Az MCP emberi felügyeletet biztosító primitívjei, a megerősítéshez való elicitáció, az érveléshez való mintavétel, szükségesek és üdvözlendők, de egy megerősítő párbeszédablak nem helyettesíti a kiszámíthatóan viselkedő partnert. Nem lehet nagy léptékben kormányozni azt, amit nem lehet egységesen leírni. Ezer egyedi szerver nem szabvány; ugyanaz a mocsár, JSON-RPC mázzal.

Két jövő és egy stratégiai választás

Az, hogy ki oldja fel ezt, meghatározza, ki birtokolja a vállalati kapcsolatot a következő évtizedben, és csak két jelölt van.

Az elsőben a bankok szabványosítják a saját felületeiket. Ügynökkész API-kat tesznek közzé, megtartják a közvetlen kapcsolatot a treasurerrel, és maradnak az a partner, amelyet az ügynök felfedez és meghív. A másodikban az aggregátorok szabványosítják helyettük. Egy maroknyi platform definiálja a de facto ügynökszerződést, és a bankok mögötte felcserélhető végpontokká válnak, csak valaki más absztrakcióján keresztül elérhetők. Ez nem spekuláció; ez a lakossági történet egy szegmenssel előregörgetve. A McKinsey saját 2025-ös tranzakciós banki munkája leírja az olyan treasury-menedzsment platformokat, mint a Kyriba és a GTreasury, valamint az olyan CFO-iroda platformokat, mint a Bill.com, amelyek az ügyfelek és a bankok közé pozicionálják magukat egyetlen, bankfüggetlen pozíciónézettel. Pontosan ez az a réteg, amely a lakossági szektorban csendben eltüntette a hosszú farkat a Plaid és a Tink mögött. Ugyanez a kutatás megjegyzi, hogy a vállalati treasurerek most a fogyasztói alkalmazásaik mércéjéhez mérik a bankjaikat, és váltani fognak, ha a bekötés, a jogosultságok és az API-integráció csalódást okoz.

A választás stratégiai tartalma nyers. Egy bank, amely egy aggregátor ügynökszerződése mögötti végponttá válik, egyszerre három dolgot ad fel. Árrést, ahogy a szolgáltatásait árucikké teszik és valaki más felületén keresztül elsősorban ár szerint hasonlítják össze. Ügyfélbirtoklást, ahogy a kapcsolat, a kontextus és a váltási költség a platformra vándorol. És adat- és elemzőerőt, ahogy az áramlást, amelyet egykor végponttól végpontig látott, most egy közvetítő közvetíti, amely többet lát az ügyfélből, mint a bank. A saját felület szabványosítása nem technikai higiéniai projekt. Ez a különbség aközött, hogy partner vagy, vagy árucikk.

Mit kell a szabványnak előírnia

A hiányzó irány nem egzotikus. Minden komponens már nyíltan létezik: az ISO 20022 az adatokhoz, a Swift Payment Initiation és Instant Cash Reporting API-jai a referenciaműveletekhez, a BIAN a szemantikához, a Berlin Group openFinance-e a hozzájárulás-és-katalógus mintához, a FAPI a pénzügyi szintű hitelesítéshez, az MCP az eszközök közzétételéhez, az A2A az ügynökök közötti orkesztrációhoz. Ami hiányzik, az az aktus, hogy ezeket egy kötelező érvényű szerződéssé állítsuk össze a vállalati térhez, és a fegyelem, hogy két alapszintet specifikáljunk, ne egyet. A meglévő B2B-API-irodalom, beleértve a McKinseyét is, az API-kat nagyrészt növekedési és élménylehetőségként kezeli. Keveset mond a determinizmusról, a futásidejű képességfelfedezésről vagy a szabványosított nem funkcionális elemekről, pontosan arról a mulasztásról, amelyet az ügynökök nem tűrnek. Így a szabványnak egyértelműnek kell lennie mind abban, hogy mi a felület, mind abban, hogyan viselkedik kormányzás alatt.

A technikai alapszint

Egy OpenAPI-first szerződés, egy kanonikus MCP eszközmanifeszttel, amely abból generálódik, nem pedig kézzel írva mellette, hogy az eszközök, amelyeket egy ügynök lát, sose sodródhassanak el az API-tól, amelyet a bank futtat.
FAPI-szintű hitelesítés és hozzájárulás mint az egyetlen kézfogás a felület egészén.
Idempotencia és determinisztikus hibataxonómia, stabil kódok, hibánként egy jelentés, magában a szerződésben dokumentálva.
ISO 20022-natív hasznos adatok, strukturáltan és hibrid-címre készen.
Szemantikus verziózás futásidejű képességfelfedezéssel, egy ügynök megkérdezheti, mit tud ma ez a partner, és gépi választ kaphat.

A kormányzási és ellenállóképességi alapszint

Közzétett, kikényszerített nem funkcionális SLO-k, késleltetés, rendelkezésre állás, átbocsátóképesség, straight-through-processing és emberi ráfordítás, valós idő-és-mozgás számokban kifejezve, nem marketingnyelven.
Jogosultságok, hozzájárulás és egy hamisításbiztos auditnapló, a végrehajtási úthoz kötve, nem pedig egy sávon kívüli portálban lebegve.
Modellkockázati és működési ellenállóképességi kontrollok, az SR 11-7-hez, a DORA-hoz és az EU AI Acthez igazítva, hogy egy ügynök hívásai kormányzott események legyenek gazdával, ne egzotikus peremesetek.

Van itt egy kemény tanulság, amely a lakossági tapasztalatba van temetve. Egy szabványnak, amelyet egy gép hajt végre, pontosabbnak kell lennie, mint amelyet egy emberi integrátor csendben megjavíthat; az alulspecifikálás már nem egy fejlesztői órákban fizetett puha költség, hanem egy hibásan elküldött fizetésekben fizetett kemény hibamód. Sokatmondó, hogy az iparág leghitelesebb harmonizációs erőfeszítése, a CPMI és a PMPG harmonizált ISO 20022 adatkövetelményei, amelyek átvételére a világ fizetési rendszereit 2027 végéig sürgetik a G20 határon átnyúló fizetési programja keretében, épp e széttöredezettség elleni küzdelemért, saját leírása szerint sem szabályozás, sem API-szabvány. Az adatokat harmonizálja. A felület még mindig senki dolga.

Egy célkép

Az építés kevésbé ijesztő, mint a diagnózis, mert három rétegről van szó, nem egy programról. Egy kanonikus vállalati banki API a fizetéseket és a készpénzjelentést REST-en és OpenAPI-n keresztül teszi elérhetővé, ISO 20022-natív hasznos adatokkal és FAPI-szintű hitelesítéssel, egy szerződés, egy nyelvtan, egy kézfogás. Egy MCP híd ül fölötte, és közvetlenül abból az OpenAPI-szerződésből generálja az ügynök felé néző eszközmanifesztet, így a felfedezés, a sémák és az engedélyek a felületből származnak, nem pedig azzal párhuzamosan karbantartva. És egy szabályzati és ellenállóképességi réteg minden ügynökhívást körülvesz azokkal a kontrollokkal, amelyek az autonómiát biztonságossá teszik: tranzakciós és partnerlimitek, szegmentálás, emberi felügyeletet kiváltó triggerek (elicitáció magas kockázatú műveleteknél), élő SLO-monitorozás és egy kemény vészleállító kapcsoló. Nincs szükség diagramokra a lényeg megragadásához: a szabvány nem egy új csatorna, hanem a már létező csatornák fegyelmezett elrendezése, ahol az ügynökút és a kormányzási út az első committól be van építve, nem pedig az incidens után rácsavarozva.

Mit tesznek a hiteles bankok a következő 24 hónapban

Ha elfogadod, hogy a hívó fél megváltozott, a munka konkrét, és öt sávra bontható.

Tegyél közzé egy ISO 20022-natív, OpenAPI-first felületet. Vegyél egy nagy értékű folyosót, jellemzően a határon átnyúló fizetéseket és a készpénzjelentést, és tedd elérhetővé egyetlen, verziózott OpenAPI-definíción keresztül ISO 20022 hasznos adatokkal, a meglévő CBPR+ sémáidhoz igazítva, nem pedig egy ötödik kitalált nyelvtanhoz. Tedd nyilvánossá az ügyfelek és a belső ügynökök számára, egy homokozóval, és kezeld a változásokat termékkiadásként. Az első év sikere nem a teljes lefedettség; az annak bizonyítása, hogy egy folyosó végponttól végpontig ügynökcímezhetővé tehető.
Szabványosítsd a hitelesítést és az idempotenciát rajta keresztül. Vegyél át egyetlen FAPI-szintű profilt egyedüli kézfogásként, írj elő idempotenciakulcsokat minden íráson, és tedd az „ugyanazt az utasítást újrapróbálni" dokumentált garanciává a szerződésben, kockázatból biztonságos feltételezéssé alakítva azt, hogy „az ügynökök újrapróbálnak".
Definiálj egy determinisztikus hibanyelvtant és képességfelfedezést. Adj minden hibának egy stabil kódot és következetes szemantikát, adj hozzá szemantikus verziózást, és tegyél elérhetővé egy képességkatalógust, amelyet egy ügynök futásidőben lekérdezhet, explicit jelzőkkel a részleges támogatáshoz, az elavuláshoz és a „még nem elérhető" állapothoz.
Csatold a jogosultságokat, a hozzájárulást és az auditot ugyanahhoz a felülethez. Helyezd át a hozzájárulási és jóváhagyási folyamatokat az API-útra, bocsáss ki egy hamisításbiztos naplót minden ügynök által kezdeményezett utasításhoz, ki, mit, mikor, melyik szabályzati sáv alatt, és igazítsd explicit módon az SR 11-7-hez, a DORA-hoz és az EU AI Acthez, hogy a második vonal jóváhagyhassa.
Tegyél közzé nem funkcionális alapszinteket, majd futtass egy felügyelt ügynökpilotot. Vállalj késleltetési, rendelkezésre állási, átbocsátóképességi és STP-célokat a folyosóra, és műszerezd fel őket; majd állíts fel egy felügyelt likviditási vagy készpénzsöprő ügynököt, amely csak ezt a felületet használja, kemény limitekkel, emberi felügyeleti ellenőrzőpontokkal és teljes audittal, hat-tizenkét hónapig. Ez az a kényszerítő funkció, amelyet magad irányítasz: bebizonyítja, hogy egy ügynök biztonságosan mozgathat pénzt szabályzati sávokon belül, amikor a felület kiszámítható, és gyorsan megmondja, hol a szabványod még mindig törekvés, nem tény.

A kényszerítő funkció

Az iparág épp most bizonyította be, hogy tud mozdulni, ha valami kényszeríti. A Swift 2026 novemberi strukturált-cím átállása, amely után a strukturálatlan címeket a határon átnyúló fizetésekben egyszerűen elutasítják, mindenféle vészhelyzeti konverzió nélkül, egy vonakodó piacot húzott a strukturált ISO 20022 adatok felé egy rögzített dátumra, megerősítve a CPMI 2027 végi lökésével a harmonizált adatkövetelmények felé a G20 fizetési programban. Vedd észre, mit szabványosít mindkét erőfeszítés: az adatokat, nem a felületet. A nyelvtant tisztára kényszerítik. A felületet minden bank saját belátására bízták, ami pontosan az a belátás, amivel az ügynökök nem tudnak dolgozni. Egy ügynök számára ez azt jelenti, hogy a hasznos adatok végre következetesek lesznek, miközben a mögöttük lévő viselkedés eltérő marad, annak inverze, amire egy gépnek valójában szüksége van, ami előbb kiszámítható viselkedés, aztán tiszta adat.

Tehát ez a kikényszerítetlen hiba, amelyet el kell kerülni: egy globális bizottságra várni, hogy megáldjon egy vállalati banki API-szabványt, mielőtt cselekednénk. Azok a bankok, amelyek most tesznek közzé egy ISO 20022-natív, ügynökkész felületet, egy OpenAPI-szerződést, egy belőle generált MCP-manifesztet, pénzügyi szintű hitelesítést és nem funkcionális alapszinteket, amelyek mögé valóban ki is állnak, az autonóm treasury alapértelmezett partnereivé válnak. Az ő eszközeik lesznek azok, amelyeket az ügynökök felfedezhetnek, megbízhatnak bennük és meghívhatnak ember nélkül a középen. Azok a bankok, amelyek várnak, csak egy aggregátor absztrakcióján keresztül lesznek elérhetők, saját ügyfélkapcsolatukat bérbe adva annak, aki az adaptert birtokolja.

Nyelvtan irány nélkül nem szabvány. Az ISO 20022 megmondta a vállalati banki szektornak, hogyan beszéljen. Sosem mondta meg, hová menjen. Az ügynökök megérkeztek, folyékonyan és türelmetlenül, és a térkép még mindig nincs ott. Megrajzolása most a legjelentősebb infrastruktúramunka a tranzakciós banki szektorban, és, most az egyszer, a határidőt nem egy szabályozó szabja meg, hanem a gépek, amelyek már a felületnél várnak.

Gyakran ismételt kérdések

Nem az ISO 20022 a hiányzó szabvány? Nem. Az ISO 20022 adatnyelvtan, nem API-szerződés. A pain.001 megmondja egy rendszernek, hogyan fogalmazzon meg egy átutalást; nem mondja meg, melyik végpont hozza létre, hogyan hitelesít, hogyan lapoz, vagy hogyan jelent hibát. A nyelvtan készen áll az ügynökökre. A felület, a géppel felfedezhető, egységesen viselkedő interfész, amelyet egy ügynök valójában meghív, nem.

Miért ne csomagoljunk minden bankot egy MCP-szerverbe? Mert a széttöredezettséget áthelyezi, nem pedig megszünteti. Negyven bankból negyven szerver lesz negyven szemantikával, negyven hitelesítési folyamattal és, ami kritikus, közös nem funkcionális alapszint nélkül: nincs közös késleltetési keret, nincs megegyezett rendelkezésre állási szint, nincs összehasonlítható idempotenciagarancia. A hívó fél most egy nem determinisztikus modell, írási hozzáféréssel a fizetési csatornákhoz, ami egy modellkockázati és működési ellenállóképességi probléma az SR 11-7, a DORA és az EU AI Act alatt. Ezer egyedi szerver nem szabvány.

Mi a leghasznosabb első lépés egy bank számára? Tegyél közzé egy ISO 20022-natív, OpenAPI-first folyosót, jellemzően a határon átnyúló fizetéseket és a készpénzjelentést, egy FAPI-szintű kézfogással, az idempotenciával mint dokumentált garanciával, és egy determinisztikus hibanyelvtannal. Majd futtass egy felügyelt ügynökpilotot csak ezen a felületen, kemény limitekkel, emberi felügyeleti ellenőrzőpontokkal és teljes audittal. Egy folyosó végponttól végpontig való bizonyítása felülmúl egy ütemtervet, amely mindent lefed és semmit sem ír elő.

Ki oldja fel ezt, ha a bankok nem? Az aggregátorok. Egy maroknyi treasury és CFO-iroda platform fogja definiálni a de facto ügynökszerződést, és a bankok mögötte felcserélhető végpontokká válnak, egyszerre feladva az árrést, az ügyfélbirtoklást és a végponttól végpontig terjedő adatot. Ez a lakossági történet, ahol a Plaid és a Tink elnyelte a hosszú farkat, egy szegmenssel előregörgetve a vállalati banki szektorba.

Hivatkozások

Model Context Protocol, hivatalos dokumentáció ⧉. [Az MCP-t 2024 novemberében nyílt forráskódúvá tették, és 2025 decemberében a Linux Foundation Agentic AI Foundationjének adományozták a Block és az OpenAI mellett; a futásidejű eszközfelfedezési réteg, amelyre az elemzés épül. A szövegben szereplő elterjedési adatok irányadó iparági olvasatok, és ekként jelölve.]
Berlin Group, NextGenPSD2 és openFinance ⧉. [A de facto európai lakossági API-szabvány és annak a vállalati felhasználási esetek felé való kinyúlása, a hozzájárulás-és-katalógus mintához és a lakossági-vállalati kontraszthoz idézve.]
Financial Data Exchange (FDX) ⧉. [Az amerikai lakossági adatmegosztási szabvány, a szabványosított lakossági szerződések léptékéhez idézve, amellyel szemben a vállalati banki szektornak nincs egyenértékű megoldása.]
McKinsey & Company, pénzügyi szolgáltatások betekintések ⧉. [Tranzakciós banki API-kutatás: host-to-host / SFTP örökség, a ~85%-os készpénzkezelési-API befektetési szándék, és a treasury-platform közvetítés. A piaci diagnózishoz idézve; a keretezés és a következtetések itt a szerző sajátjai.]
Bank for International Settlements (CPMI), harmonizált ISO 20022 adatkövetelmények ⧉. [A 2027 végi lökés a fizetési adatok harmonizálására, saját leírása szerint sem szabályozás, sem API-szabvány, a „nyelvtan felület nélkül" ponthoz idézve.]
Swift, ISO 20022 pénzügyi intézmények számára ⧉. [CBPR+ és a 2026 novemberi strukturált-cím mérföldkő; a Payment Initiation és Instant Cash Reporting API-k referenciaműveletekként idézve, nem egyetemes felületként.]

Utoljára felülvizsgálva 2026 júliusában. Eredeti elemzés; a források hivatkozva vannak, nem reprodukálva. Az elterjedési és piaci adatok irányadó iparági olvasatok, újraközlés előtt ellenőrizze őket elsődleges forrásokkal szemben. A CC-BY-4.0 licenc alatt.

Utolsó felülvizsgálat 2026-07-14.

A cikk újraközlése

A széttöredezettségtől a törésvonalig: a vállalati banki szektor hiányzó API-szabványa az ügynöki korszakban — Sebastien Rousseau

A lakossági banki szektor egy évtizede megkapta az API-szabványát. A vállalati banki szektor sosem, és most, hogy az AI-ügynökök és a Model Context Protocol az integrációt futásidejű döntéssé tették, a rés törésvonallá vált.

Ez a cikk a következő licenc alatt áll: Creative Commons Attribution 4.0 International. Az újraközléshez a kanonikus URL forrásmegjelölése szükséges.

A széttöredezettségtől a törésvonalig: a vállalati banki szektor hiányzó API-szabványa az ügynöki korszakban — Sebastien Rousseau

A lakossági banki szektor egy évtizede megkapta az API-szabványát. A vállalati banki szektor sosem, és most, hogy az AI-ügynökök és a Model Context Protocol az integrációt futásidejű döntéssé tették, a rés törésvonallá vált.

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

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER