Od fragmentacji do linii uskoku: brakujący standard API w bankowości korporacyjnej w erze agentowej

Bankowość detaliczna otrzymała swój standard API dekadę temu. Bankowość korporacyjna nigdy — a w 2026 roku to zaniechanie przestało być uciążliwością i stało się linią uskoku. ISO 20022 dało branży wspólną gramatykę; nigdy nie dało jej wspólnej, gotowej dla agentów warstwy. Teraz zmienił się rozmówca. Nie jest nim już programista z kwartałem do przepalenia na integrację, lecz model odkrywający narzędzia w czasie wykonania i przesuwający pieniądze w ramach pasm polityki. Niejednoznaczność, którą skarbnicy korporacyjni po cichu absorbowali przez dwadzieścia lat, ma zostać przekazana oprogramowaniu, które nie jest w stanie jej zaabsorbować — podczas gdy warstwa danych pod spodem jest przymuszana do struktury, czy bankom się to podoba, czy nie. Oto ile kosztuje brakujący kierunek, dlaczego agenci czynią dzisiejszą fragmentację niebezpieczną, a nie jedynie nieefektywną, oraz co standard API bankowości korporacyjnej musi nakazać, zanim autonomiczny skarbiec będzie mógł osiągnąć skalę.

Streszczenie dla kierownictwa

Bankowość korporacyjna ma gramatykę, nie warstwę. ISO 20022 znormalizowało dane; nikt nie znormalizował API. Było to do przeżycia, dopóki ludzki integrator absorbował niejednoznaczność — model w czasie wykonania nie może.

Rozmówca się zmienił. MCP uczynił odkrywanie narzędzi decyzją podejmowaną w czasie wykonania. Agent, który miał znieść problem integracji M×N, napotyka go ponownie na granicy banku, gdzie każda instytucja jest szytym na miarę serwerem z własną semantyką.

Fragmentacja przesuwa teraz pieniądze błędnie, z prędkością maszyny. Jeden timeout, trzy banki, trzy sprzeczne prawdy — duplikat w A, zawieszona instrukcja w B, cicha awaria w C. Idempotentność i deterministyczna gramatyka błędów stają się nośne.

Owinięcie każdego banku w serwer MCP przenosi bagno gdzie indziej. Czterdzieści serwerów, czterdzieści semantyk, brak wspólnej podstawy niefunkcjonalnej — oraz niedeterministyczny model z prawem zapisu do szyn płatniczych, wprost problem SR 11-7 / DORA / EU AI Act.

Znormalizuj własną warstwę albo stań się towarem. Banki, które publikują teraz natywne dla ISO 20022, gotowe dla agentów API, stają się domyślnymi kontrahentami dla autonomicznego skarbca; pozostałe wynajmują swoją relację z klientem temu, kto posiada adapter.

Dwa światy bankowości, jeden z nich znormalizowany

Spójrz na detal, a obraz jest chaotyczny, lecz przejezdny. Europa ma UK Open Banking i NextGenPSD2 grupy Berlin Group, przyjęty przez ponad trzy czwarte europejskich banków i traktowany w praktyce jako standard de facto. Stany Zjednoczone mają Financial Data Exchange, obejmujący dziś ponad sześćdziesiąt milionów rachunków konsumenckich. Australia ma Consumer Data Right. Żaden z nich nie jest globalny i żaden prawdopodobnie się nim nie stanie — lecz każdy jest realnym, wersjonowanym, testowalnym maszynowo kontraktem, a tam, gdzie kontrakty się kończą, agregatorzy (Plaid, Tink, TrueLayer, Salt Edge) absorbują różnicę za pojedynczym interfejsem. Fragmentacja detaliczna jest podatkiem. Nie jest murem.

Bankowość korporacyjna i hurtowa nie ma odpowiednika. Skarbiec międzynarodowej korporacji sięga swoich banków przez rury plików host-to-host, tuzin szytych na miarę portali, system zarządzania skarbcem lub agregatora — zwykle wszystkie cztery naraz. To nie jest chochoł: własne badania McKinsey nad bankowością transakcyjną od lat katalogują to samo dziedzictwo, opisując, jak banki opierają się na transferze plików host-to-host i SFTP, wyliczając dobrze znane tryby awarii integracji opartej na plikach — nieporęczne formaty ERP, które trzeba dostosowywać per korporacja, niezdolność do obsługi warunkowego routingu — i raportując, że ponad 85% kadry kierowniczej bankowości transakcyjnej zamierza inwestować w API zarządzania gotówką. Apetyt na API nie jest przedmiotem wątpliwości. Brakuje wspólnego kontraktu, na który miałyby wskazywać.

Ponieważ zwyczajni kandydaci nim nie są. ISO 20022 jest regularnie mylone z brakującym standardem, lecz jest gramatyką danych, a nie kontraktem API: pain.001 mówi, jak sformułować przelew, a nie który punkt końcowy go tworzy, jak się uwierzytelnia, jak stronicuje ani jak informuje o niepowodzeniu. BIAN daje branży wspólny semantyczny model referencyjny, a nie egzekwowany interfejs. API Payment Initiation i Instant Cash Reporting od Swift to autentyczny ruch w stronę standaryzacji, lecz są sieciocentryczne i wciąż dopiero powstają, a nie stanowią uniwersalnej warstwy. Framework openFinance grupy Berlin Group sięga ku przypadkom użycia korporacyjnego — otwieranie rachunków, finansowanie handlu, dynamiczne płatności cykliczne — lecz jest europejski, wczesny i premium-na-podstawie-porozumienia. Złóż to wszystko razem, a wciąż nie masz wiążącego, globalnego standardu API bankowości korporacyjnej. Masz materiały budowlane i żadnego projektu.

Dlaczego fragmentacja przetrwała — i dlaczego to się kończy

Przez dwadzieścia lat było to znośne, ponieważ integrator był człowiekiem i był cierpliwy. Korporacja wdrażała garść połączeń bankowych przez miesiące, czasem kwartały. Każde było projektem: wymiana certyfikatów, wykonanie przelewu weryfikacyjnego, spór o dokument mapowania. Koszt był realny, lecz płacony raz na relację i amortyzowany przez lata kolejnych płatności. Gdy API banku było niedospecyfikowane — gdy standard „pozostawiał resztę wdrażającej instytucji", jak same banki się na to skarżą — ludzki inżynier czytał portal, wnioskował intencję i zaklejał lukę. Niejednoznaczność była do przeżycia, ponieważ była tam osoba, która ją rozstrzygała.

Przetrwała też z powodów rzadziej wypowiadanych na głos. Instalacja pod spodem jest naprawdę trudna do zmiany: okna rozliczeń wsadowych, cykle nocne i rdzenie mainframe, które nigdy nie były zaprojektowane, by odpowiadać na pytanie zadawane w czasie rzeczywistym. A fragmentacja nie jest tylko przypadkiem — jest, po cichu, formą uwięzienia klienta. Każda szyta na miarę rura host-to-host, którą buduje skarbnik, jest kosztem zmiany, który przypada w udziale podmiotowi zasiedziałemu. Bank trudny do zintegrowania jest, na marginesie, bankiem, który trudno opuścić. Nic z tego nie jest spiskowe; to zwykłe bodźce. Lecz wyjaśnia to, dlaczego branża, która uzgodniła gramatykę danych, nigdy nie uzgodniła warstwy — i dlaczego warstwa jest ostatnią nieznormalizowaną warstwą, jaka pozostała. Powód, dla którego nie może już się utrzymać, jest taki, że warstwa pod nią jest przymuszana do struktury z terminem, a warstwa nad nią właśnie zyskała nowego, niecierpliwego użytkownika.

Rozmówca się zmienił

Ten użytkownik pojawił się w osiemnaście miesięcy. Model Context Protocol, który Anthropic udostępnił jako open source w listopadzie 2024 roku i przekazał Agentic AI Foundation przy Linux Foundation w grudniu 2025 roku wraz z Block i OpenAI, stał się domyślnym sposobem, w jaki systemy AI sięgają narzędzi i danych. Do początku 2026 roku notował mniej więcej dziewięćdziesiąt siedem milionów pobrań SDK miesięcznie; do połowy roku, według jednego z kierunkowych odczytów branżowych, około siedemdziesiąt osiem procent zespołów AI w przedsiębiorstwach uruchamiało agentów opartych na MCP w środowisku produkcyjnym, a ponad jedna czwarta firm z listy Fortune 500 obsługiwała serwery MCP, zabezpieczone standardową warstwą autoryzacji OAuth 2.1. Jest rutynowo, i trafnie, opisywany jako USB-C dla AI: zwija koszmar integracji M×N — każdy model połączony ręcznie z każdym narzędziem — do M+N. Jego własne podsumowanie samego siebie to zdanie, które liczy się dla banków: API są dla programów; MCP jest dla agentów. API typu REST oczekuje, że rozmówca z góry wie, który punkt końcowy uderzyć i z jakimi parametrami. Agent oczekuje, że odkryje dostępne narzędzia w czasie wykonania i sam zdecyduje, jak i kiedy ich użyć.

To nie jest hipotetyczne dla skarbca. Wzorzec jest już spójny w skarbcach banków korporacyjnych i inwestycyjnych w 2026 roku: agent czyta dane gotówkowe ISO 20022, wywołuje ograniczony zestaw narzędzi i równoważy płynność w ramach pasm polityki, z mechanizmami kontrolnymi SR 11-7, DORA i EU AI Act owiniętymi wokół niego. Gramatyka danych jest na to gotowa. Warstwa API nie jest.

Niedopasowanie, precyzyjnie

Sprowadź agenta do tego, czego faktycznie potrzebuje od bankowego kontrahenta, a lista jest krótka i bezlitosna:

Odkrywalny maszynowo kontrakt — opis OpenAPI lub manifest narzędzi, który agent może odczytać w czasie wykonania, a nie PDF, który człowiek czyta raz.
Jeden model uwierzytelniania — profil OAuth2/mTLS klasy finansowej (FAPI jest oczywistą kotwicą), a nie inny uścisk dłoni na każdy bank.
Idempotentność jako gwarancja — unikalna referencja instrukcji, która czyni ponowioną płatność operacją bez skutków, ponieważ agent będzie ponawiał.
Deterministyczna gramatyka błędów — to samo niepowodzenie znaczy to samo wszędzie, aby model mógł o nim wnioskować.
Wersjonowanie semantyczne i odkrywanie możliwości — aby agent mógł stwierdzić, co kontrahent potrafi w tym kwartale, bez ludzkiej noty wydania.
Ustrukturyzowane ładunki ISO 20022, zgoda i uprawnienia oraz odporny na manipulacje ślad audytu — treść, pozwolenie i dowód.

Zestaw to z bankowością korporacyjną, jaka istnieje, a każda linia rozłamuje się na N dialektów — jeden na bank. Agent, który miał znieść problem M×N, napotyka go ponownie na granicy banku, ponieważ każda instytucja jest w istocie szytym na miarę serwerem z własną gramatyką „salda", własnym pojęciem „statusu płatności", własnym tańcem uwierzytelniania i własnym wyobrażeniem o tym, czym jest błąd. Protokół znormalizował stronę agenta na przewodzie. Nikt nie znormalizował strony banku.

Tryb awarii, unaoczniony

Uczyń to konkretnym, ponieważ to tutaj abstrakcja kąsa. Wyobraź sobie agenta płynności upoważnionego do przemiatania gotówki przez trzy banki, aby utrzymać każdy rachunek w docelowym paśmie. Wystrzeliwuje trzy niemal identyczne instrukcje i, jak to sieci mają w zwyczaju, trafia na timeout w każdej z nich.

Bank A traktuje timeout jako nieznany — bezpieczny do ponowienia, więc agent ponawia, a pierwotna instrukcja również się rozlicza: duplikat płatności. Bank B traktuje ten sam timeout jako przesłany — nie ponawiać, lecz nigdy nie ujawnia potwierdzenia, które agent mógłby sparsować, więc instrukcja tkwi w zawieszeniu, podczas gdy agent, nie widząc powodzenia, eskaluje lub przekierowuje: zawieszona płatność i podwójnie zaksięgowana pozycja. Bank C zwraca beztroskie HTTP 200 z odrzuceniem ukrytym w treści ładunku; agent czyta kod statusu, oznacza przemiatanie jako wykonane i rusza dalej: cicha awaria, która wychodzi na jaw dopiero następnego ranka jako rozbieżność uzgodnieniowa, której nikt nie potrafi wyjaśnić.

Trzy banki, jeden warunek, trzy sprzeczne prawdy — zduplikowane środki wychodzące za drzwi w A, zamrożona instrukcja w B, fantomowe powodzenie w C. Ludzki skarbnik zadzwoniłby do trzech opiekunów relacji i uporządkowałby to do lunchu. Agent nie może do nikogo zadzwonić. Dokładnie dlatego „idempotentność jako gwarancja" i „deterministyczna gramatyka błędów" nie są architektonicznymi udogodnieniami: bez nich ta sama fragmentacja, która jedynie kosztowała ludzkie godziny, przesuwa teraz realne pieniądze nieprawidłowo, z prędkością maszyny, u każdego kontrahenta naraz.

Dlaczego „owinięcie każdego banku w serwer MCP" nie jest rozwiązaniem

Odruchowa odpowiedź brzmi: daj każdemu bankowi serwer MCP i po sprawie. Nie utrzymuje się, ponieważ przenosi fragmentację, zamiast ją usuwać. Czterdzieści banków staje się czterdziestoma serwerami z czterdziestoma semantykami, czterdziestoma przepływami uwierzytelniania i bez wspólnego znaczenia — oraz, co kluczowe, bez wspólnej podstawy niefunkcjonalnej: brak wspólnego budżetu opóźnień, brak uzgodnionego poziomu dostępności, brak porównywalnej gwarancji idempotentności. Opisany powyżej tryb awarii przetrwa opakowanie nienaruszony. Co gorsza, rozmówcą jest teraz niedeterministyczny model z prawem zapisu do szyn płatniczych, co nie jest jedynie kwestią integracji, lecz kwestią ryzyka modelu i odporności operacyjnej, która ląduje wprost na SR 11-7, DORA i EU AI Act. Prymitywy MCP z człowiekiem w pętli — elicytacja dla potwierdzenia, próbkowanie dla rozumowania — są konieczne i mile widziane, lecz okno dialogowe potwierdzenia nie zastępuje kontrahenta zachowującego się przewidywalnie. Nie da się rządzić w skali czymś, czego nie da się opisać jednolicie. Tysiąc szytych na miarę serwerów to nie standard; to to samo bagno z fornirem JSON-RPC.

Dwie przyszłości i strategiczny wybór

To, kto rozwiąże tę kwestię, przesądza o tym, kto będzie posiadał relację korporacyjną przez następną dekadę, a kandydatów jest tylko dwóch.

W pierwszym scenariuszu banki normalizują własne warstwy. Publikują gotowe dla agentów API, zachowują bezpośrednie połączenie ze skarbnikiem i pozostają kontrahentem, którego agent odkrywa i wywołuje. W drugim agregatorzy normalizują ją za nie. Garść platform definiuje agentowy kontrakt de facto, a banki stają się wymiennymi punktami końcowymi za nim — osiągalnymi wyłącznie poprzez cudzą abstrakcję. To nie jest spekulacja; to historia detaliczna biegnąca naprzód o jeden segment. Własna praca McKinsey nad bankowością transakcyjną z 2025 roku opisuje platformy zarządzania skarbcem, takie jak Kyriba i GTreasury, oraz platformy biura CFO, takie jak Bill.com, ustawiające się między klientami a bankami z pojedynczym, niezależnym od banku widokiem pozycji. To dokładnie ta warstwa, która w detalu po cichu usunęła długi ogon za Plaid i Tink. Te same badania odnotowują, że skarbnicy korporacyjni rozliczają dziś swoje banki wedle standardów swoich aplikacji konsumenckich i zmienią bank, gdy wdrożenie, uprawnienia i integracja API zawiodą.

Strategiczna treść tego wyboru jest dosadna. Bank, który staje się punktem końcowym za agentowym kontraktem agregatora, oddaje trzy rzeczy naraz. Marżę, gdy jego usługi zostają utowarowione i porównywane najpierw według ceny przez cudzy interfejs. Własność klienta, gdy relacja, kontekst i koszt zmiany migrują do platformy. Oraz potęgę danych i analityki, gdy przepływ, który niegdyś widział od początku do końca, jest teraz pośredniczony przez podmiot widzący więcej z klienta, niż widzi go bank. Normalizacja własnej warstwy nie jest projektem higieny technicznej. Jest różnicą między byciem kontrahentem a byciem towarem.

Co standard musi nakazać

Brakujący kierunek nie jest egzotyczny. Każdy komponent istnieje już otwarcie — ISO 20022 dla danych, API Payment Initiation i Instant Cash Reporting od Swift dla operacji referencyjnych, BIAN dla semantyki, openFinance grupy Berlin Group dla wzorca zgody-i-katalogu, FAPI dla uwierzytelniania klasy finansowej, MCP dla ekspozycji narzędzi, A2A dla orkiestracji między agentami. Brakuje aktu złożenia ich w wiążący kontrakt dla przestrzeni korporacyjnej — oraz dyscypliny, by wyspecyfikować dwie podstawy, nie jedną. Istniejąca literatura o API B2B, w tym McKinsey, traktuje API w dużej mierze jako szansę na wzrost i doświadczenie. Mówi niewiele o determinizmie, odkrywaniu możliwości w czasie wykonania czy znormalizowanych cechach niefunkcjonalnych — dokładnie o tym zaniechaniu, którego agenci nie mogą tolerować. Standard musi zatem być wyraźny co do obu spraw: czym interfejs jest i jak zachowuje się pod nadzorem.

Podstawa techniczna

Kontrakt oparty na OpenAPI z kanonicznym manifestem narzędzi MCP z niego wygenerowanym — nie napisanym ręcznie obok niego, aby narzędzia, które widzi agent, nigdy nie mogły odbiec od API, które bank faktycznie uruchamia.
Uwierzytelnianie i zgoda klasy FAPI jako pojedynczy uścisk dłoni w całej warstwie.
Idempotentność i deterministyczna taksonomia błędów — stabilne kody, jedno znaczenie na niepowodzenie, udokumentowane w samym kontrakcie.
Natywne dla ISO 20022 ładunki, ustrukturyzowane i gotowe na adres hybrydowy.
Wersjonowanie semantyczne z odkrywaniem możliwości w czasie wykonania — agent może zapytać, co ten kontrahent potrafi dzisiaj, i otrzymać odpowiedź maszynową.

Podstawa ładu korporacyjnego i odporności

Opublikowane, egzekwowane niefunkcjonalne SLO — opóźnienie, dostępność, przepustowość, przetwarzanie od początku do końca (STP) oraz nakład pracy człowieka — wyrażone jako realne liczby czasu i ruchu, a nie język marketingowy.
Uprawnienia, zgoda i odporny na manipulacje ślad audytu związane ze ścieżką wykonania, a nie unoszące się w portalu poza pasmem.
Mechanizmy kontroli ryzyka modelu i odporności operacyjnej zgodne z SR 11-7, DORA i EU AI Act, aby wywołania agenta były zdarzeniami podlegającymi ładowi, z właścicielem, a nie egzotycznymi przypadkami brzegowymi.

Jest w doświadczeniu detalicznym ukryta twarda lekcja. Standard, który wykonuje maszyna, musi być bardziej precyzyjny niż taki, który ludzki integrator może po cichu naprawić; niedospecyfikowanie nie jest już miękkim kosztem płaconym w godzinach programistów, lecz twardym trybem awarii płaconym w błędnie wysłanych płatnościach. Wymowne jest, że najbardziej autorytatywne wysiłki harmonizacyjne branży — zharmonizowane wymogi dotyczące danych ISO 20022 opracowane przez CPMI i PMPG, do których przyjęcia do końca 2027 roku wzywane są systemy płatnicze na całym świecie w ramach programu G20 dla płatności transgranicznych, właśnie po to, by zwalczać tę fragmentację — są, wedle własnego opisu, ani regulacją, ani standardem API. Harmonizują dane. Interfejs wciąż nie jest niczyim zadaniem.

Obraz docelowy

Budowa jest mniej zniechęcająca niż diagnoza, ponieważ są to trzy warstwy, a nie program. Kanoniczne API bankowości korporacyjnej eksponuje płatności i raportowanie gotówki przez REST i OpenAPI, z natywnymi dla ISO 20022 ładunkami i uwierzytelnianiem klasy FAPI — jeden kontrakt, jedna gramatyka, jeden uścisk dłoni. Most MCP siedzi nad nim i generuje manifest narzędzi zwrócony ku agentom bezpośrednio z tego kontraktu OpenAPI, dzięki czemu odkrywanie, schematy i uprawnienia są wyprowadzane z warstwy, a nie utrzymywane równolegle do niej. A warstwa polityki i odporności owija każde wywołanie agenta mechanizmami, które czynią autonomię bezpieczną: limity transakcji i kontrahenta, segmentacja, wyzwalacze człowieka w pętli (elicytacja przy działaniach wysokiego ryzyka), monitorowanie SLO na żywo oraz twardy wyłącznik awaryjny. Żadne diagramy nie są potrzebne, by pojąć sedno — standard nie jest nową szyną, jest zdyscyplinowanym układem szyn, które już istnieją, ze ścieżką agenta i ścieżką ładu wbudowanymi od pierwszego commita, a nie przykręcanymi po incydencie.

Co wiarygodne banki robią w ciągu najbliższych 24 miesięcy

Jeśli przyjmiesz, że rozmówca się zmienił, praca jest konkretna i rozpada się na pięć torów.

Opublikuj natywną dla ISO 20022, opartą na OpenAPI warstwę. Weź jeden wartościowy korytarz — zazwyczaj płatności transgraniczne i raportowanie gotówki — i wyeksponuj go poprzez pojedynczą, wersjonowaną definicję OpenAPI z ładunkami ISO 20022, dopasowaną do istniejących schematów CBPR+, a nie do piątej wymyślonej gramatyki. Uczyń go publicznym dla klientów i agentów wewnętrznych, z piaskownicą, i traktuj zmiany jak wydania produktu. Sukcesem pierwszego roku nie jest pełne pokrycie; jest nim udowodnienie, że jeden korytarz da się uczynić adresowalnym dla agentów od początku do końca.
Znormalizuj uwierzytelnianie i idempotentność w jego obrębie. Przyjmij jeden profil klasy FAPI jako jedyny uścisk dłoni, nakaż klucze idempotentności przy każdym zapisie i uczyń „ponów tę samą instrukcję" udokumentowaną gwarancją w kontrakcie — zamieniając „agenci będą ponawiać" z ryzyka w bezpieczne założenie.
Zdefiniuj deterministyczną gramatykę błędów i odkrywanie możliwości. Nadaj każdemu niepowodzeniu stabilny kod i spójną semantykę, dodaj wersjonowanie semantyczne i wyeksponuj katalog możliwości, który agent może odpytać w czasie wykonania, z jawnymi flagami dla częściowego wsparcia, wycofania i „jeszcze niedostępne".
Przypnij uprawnienia, zgodę i audyt do tej samej warstwy. Przenieś przepływy zgody i zatwierdzania na ścieżkę API, emituj odporny na manipulacje ślad dla każdej instrukcji zainicjowanej przez agenta — kto, co, kiedy, w ramach którego pasma polityki — i dopasuj go wprost do SR 11-7, DORA i EU AI Act, aby druga linia obrony mogła go zatwierdzić.
Opublikuj podstawy niefunkcjonalne, a następnie przeprowadź nadzorowany pilotaż agenta. Zobowiąż się do celów opóźnienia, dostępności, przepustowości i STP dla korytarza i oprzyrząduj je; następnie uruchom nadzorowanego agenta płynności lub przemiatania gotówki, który korzysta wyłącznie z tej warstwy, z twardymi limitami, punktami kontrolnymi człowieka w pętli i pełnym audytem, na sześć do dwunastu miesięcy. To funkcja wymuszająca, którą kontrolujesz samodzielnie — dowodzi, że agent może bezpiecznie przesuwać pieniądze w ramach pasm polityki, gdy warstwa jest przewidywalna, i szybko mówi ci, gdzie twój standard jest wciąż aspiracją, a nie faktem.

Funkcja wymuszająca

Branża właśnie udowodniła, że potrafi się ruszyć, gdy coś ją do tego zmusza. Przejście Swift na adres ustrukturyzowany z listopada 2026 roku — po którym nieustrukturyzowane adresy w płatnościach transgranicznych są po prostu odrzucane, bez awaryjnej konwersji — przeciągnęło niechętny rynek ku ustrukturyzowanym danym ISO 20022 na ustaloną datę, wzmocnione naciskiem CPMI na zharmonizowane wymogi dotyczące danych do końca 2027 roku w ramach programu płatności G20. Zwróć uwagę, co oba wysiłki normalizują: dane, nie interfejs. Gramatyka jest przymuszana do czystości. Warstwę pozostawiono uznaniu każdego banku — a to właśnie to uznanie, z którym agenci nie mogą pracować. Dla agenta oznacza to, że ładunki będą wreszcie spójne, podczas gdy zachowanie za nimi pozostaje rozbieżne — odwrócenie tego, czego maszyna faktycznie potrzebuje, czyli przewidywalnego zachowania na pierwszym miejscu i czystych danych na drugim.

Oto zatem błąd niewymuszony, którego należy uniknąć: czekanie, aż globalny komitet pobłogosławi standard API bankowości korporacyjnej, zanim się zacznie działać. Banki, które publikują teraz natywną dla ISO 20022, gotową dla agentów warstwę — kontrakt OpenAPI, wygenerowany z niego manifest MCP, uwierzytelnianie klasy finansowej oraz podstawy niefunkcjonalne, za którymi faktycznie staną — staną się domyślnymi kontrahentami dla autonomicznego skarbca. Ich narzędzia będą tymi, które agenci potrafią odkryć, zaufać im i wywołać bez człowieka pośrodku. Banki, które zaczekają, będą osiągalne wyłącznie poprzez abstrakcję agregatora, wynajmując własną relację z klientem temu, kto posiada adapter.

Gramatyka bez kierunku nie jest standardem. ISO 20022 powiedziało bankowości korporacyjnej, jak mówić. Nigdy nie powiedziało jej, dokąd iść. Agenci przybyli, biegli i niecierpliwi, a mapy wciąż nie ma. Jej narysowanie jest teraz najbardziej doniosłą pracą infrastrukturalną w bankowości transakcyjnej — i, ten jeden raz, termin wyznacza nie regulator, lecz maszyny już czekające na interfejsie.

Najczęściej zadawane pytania

Czy ISO 20022 nie jest tym brakującym standardem? Nie. ISO 20022 jest gramatyką danych, a nie kontraktem API. pain.001 mówi systemowi, jak sformułować przelew; nie mówi, który punkt końcowy go tworzy, jak się uwierzytelnia, jak stronicuje ani jak raportuje niepowodzenie. Gramatyka jest gotowa dla agentów. Warstwa — odkrywalny maszynowo, jednolicie zachowujący się interfejs, który agent faktycznie wywołuje — nie jest.

Dlaczego po prostu nie owinąć każdego banku w serwer MCP? Ponieważ przenosi to fragmentację, zamiast ją usuwać. Czterdzieści banków staje się czterdziestoma serwerami z czterdziestoma semantykami, czterdziestoma przepływami uwierzytelniania i — co kluczowe — bez wspólnej podstawy niefunkcjonalnej: brak wspólnego budżetu opóźnień, brak uzgodnionego poziomu dostępności, brak porównywalnej gwarancji idempotentności. Rozmówcą jest teraz niedeterministyczny model z prawem zapisu do szyn płatniczych, co jest problemem ryzyka modelu i odporności operacyjnej pod SR 11-7, DORA i EU AI Act. Tysiąc szytych na miarę serwerów to nie standard.

Jaki jest jeden najbardziej użyteczny pierwszy ruch banku? Opublikuj jeden natywny dla ISO 20022, oparty na OpenAPI korytarz — zazwyczaj płatności transgraniczne i raportowanie gotówki — z uściskiem dłoni klasy FAPI, idempotentnością jako udokumentowaną gwarancją i deterministyczną gramatyką błędów. Następnie przeprowadź nadzorowany pilotaż agenta wyłącznie na tej warstwie, z twardymi limitami, punktami kontrolnymi człowieka w pętli i pełnym audytem. Udowodnienie jednego korytarza od początku do końca bije mapę drogową, która pokrywa wszystko i nie nakazuje niczego.

Kto rozwiąże tę kwestię, jeśli banki tego nie zrobią? Agregatorzy. Garść platform skarbcowych i biura CFO zdefiniuje agentowy kontrakt de facto, a banki staną się wymiennymi punktami końcowymi za nim — oddając marżę, własność klienta i dane od początku do końca naraz. To historia detaliczna, w której Plaid i Tink zaabsorbowały długi ogon, biegnąca naprzód o jeden segment w bankowość korporacyjną.

Bibliografia

Model Context Protocol — oficjalna dokumentacja ⧉. [MCP udostępniony jako open source w listopadzie 2024 roku i przekazany Agentic AI Foundation przy Linux Foundation w grudniu 2025 roku wraz z Block i OpenAI; warstwa odkrywania narzędzi w czasie wykonania, na której opiera się analiza. Dane o adopcji w tekście są kierunkowymi odczytami branżowymi i tak są oznaczone.]
Berlin Group — NextGenPSD2 i openFinance ⧉. [Europejski detaliczny standard API de facto i jego sięganie ku przypadkom użycia korporacyjnego — cytowany dla wzorca zgody-i-katalogu oraz kontrastu detal-korporacja.]
Financial Data Exchange (FDX) ⧉. [Amerykański detaliczny standard udostępniania danych, cytowany dla skali znormalizowanych kontraktów detalicznych, wobec których bankowość korporacyjna nie ma odpowiednika.]
McKinsey & Company — analizy dla usług finansowych ⧉. [Badania nad API bankowości transakcyjnej: dziedzictwo host-to-host / SFTP, ~85% zamiaru inwestycji w API zarządzania gotówką oraz pośrednictwo platform skarbcowych. Cytowane dla diagnozy rynku; ujęcie i wnioski są tu własnością autora.]
Bank for International Settlements (CPMI) — zharmonizowane wymogi dotyczące danych ISO 20022 ⧉. [Nacisk na harmonizację danych płatniczych do końca 2027 roku — wedle własnego opisu ani regulacja, ani standard API — cytowany dla tezy „gramatyka bez warstwy".]
Swift — ISO 20022 dla instytucji finansowych ⧉. [CBPR+ i kamień milowy adresu ustrukturyzowanego z listopada 2026 roku; API Payment Initiation i Instant Cash Reporting cytowane jako operacje referencyjne, a nie uniwersalna warstwa.]

Ostatni przegląd: lipiec 2026. Analiza oryginalna; źródła są cytowane, nie reprodukowane. Dane o adopcji i rynku są kierunkowymi odczytami branżowymi — przed ponowną publikacją zweryfikuj je wobec źródeł pierwotnych. Licencja CC-BY-4.0.

Ostatnia weryfikacja 2026-07-08.

Opublikuj ponownie ten artykuł

Od fragmentacji do linii uskoku: brakujący standard API w bankowości korporacyjnej w erze agentowej — Sebastien Rousseau

Bankowość detaliczna otrzymała swój standard API dekadę temu. Bankowość korporacyjna nigdy — a teraz, gdy agenci AI i Model Context Protocol uczynili integrację decyzją podejmowaną w czasie wykonania, luka stała się linią uskoku.

Ten artykuł jest objęty licencją Creative Commons Attribution 4.0 International. Ponowna publikacja wymaga przypisania do kanonicznego adresu URL.

Od fragmentacji do linii uskoku: brakujący standard API w bankowości korporacyjnej w erze agentowej — Sebastien Rousseau

Bankowość detaliczna otrzymała swój standard API dekadę temu. Bankowość korporacyjna nigdy — a teraz, gdy agenci AI i Model Context Protocol uczynili integrację decyzją podejmowaną w czasie wykonania, luka stała się linią uskoku.

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

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER