從碎裂到斷層：智能體時代裡企業銀行缺席的那套 API 標準

TL;DR. 零售銀行早在十年前就有了自己的 API 標準。企業銀行始終沒有——如今 AI 智能體與 Model Context Protocol 已把整合變成一項執行期決策，這道缺口便成了一條斷層線。

Points clés

兩個銀行世界，其中一個已標準化. 看看零售銀行，畫面雖亂，卻可通行。歐洲有英國開放銀行（UK Open Banking）與 Berlin Group 的 NextGenPSD2，後者已為超過四分之三的歐洲銀行採用，在實務上被當成一套事實標準。美國有 Financial Data Exchange，如今橫跨超過六千萬個消費者帳戶。澳洲有 Consumer Data…
碎裂為何得以存續——以及那何以正在終結. 二十年來這尚可容忍，因為那位整合者是人類，且有耐性。一家企業要在數月、有時數季之內，把少數幾條銀行連線接上線。每一條都是一個專案：交換憑證、跑一次小額測試、為一份對應文件爭論不休。成本是真實的，但每段關係只付一次，並攤提到後續數年的支付上。當一家銀行的 API…
呼叫方已然改變. 那位使用者在十八個月內就到了。Model Context Protocol——Anthropic 於 2024 年 11 月將其開源，並於 2025 年 12 月與 Block 及 OpenAI 一同將其捐給 Linux Foundation 旗下的 Agentic AI Foundation——已成為 AI 系統觸及工具與資料的預設方式。到 2026 年初，它每月大約有九千七百萬次 SDK…
精準說出這道錯配. 把智能體剝到它從一個銀行交易對手身上真正需要的東西，這份清單既短且不容妥協：.

零售銀行早在十年前就有了自己的 API 標準。企業銀行始終沒有——而在 2026 年，這項缺漏已不再只是麻煩，而成了一條斷層線。 ISO 20022 給了業界一套共通文法；它卻從未給業界一個共通、可供智能體取用的介面。如今，呼叫方已然改變。它不再是一位有著整整一季時間可以耗在整合上的開發者，而是一個在執行期發現工具、並在政策區間內調度資金的模型。企業資金管理主管們二十年來默默吸收的那份模稜兩可，如今即將被交到一套無法吸收它的軟體手上——與此同時，底下的資料層無論銀行樂不樂意，都正被推向結構化。這篇文章談的，就是這道缺席的方向感所付出的代價、為何智能體讓今日的碎裂由單純的低效變成了不安全，以及在自主資金管理能夠規模化之前，一套企業銀行 API 標準必須強制規定什麼。

執行摘要

企業銀行有文法，沒有介面。 ISO 20022 把資料標準化了；沒有人把 API 標準化。當一位人類整合者還能吸收那份模稜兩可時，這尚可承受——一個執行期的模型無法。

呼叫方變了。 MCP 讓工具發現成了一項執行期決策。一個本應終結 M×N 整合問題的智能體，卻在銀行邊界上再度撞上它——在那裡，每一家機構都是一台各有其語意、各行其是的伺服器。

碎裂如今會以機器速度把錢調錯。 一次逾時、三家銀行、三個相互矛盾的真相——A 家重複、B 家卡住指令、C 家無聲失敗。冪等性與一套決定性的錯誤文法就此成了承重結構。

把每一家銀行都包進一台 MCP 伺服器，只是把泥沼搬了個地方。 四十台伺服器、四十套語意、沒有共通的非功能性底線——再加上一個對支付網路握有寫入權限的非決定性模型，這正正是一道 SR 11-7／DORA／EU AI Act 的問題。

把自己的介面標準化，否則就淪為大宗商品。 如今發布一套 ISO 20022 原生、可供智能體取用之 API 的銀行，會成為自主資金管理的預設交易對手；其餘的銀行則把自己的客戶關係租給了那個握有轉接器的人。

兩個銀行世界，其中一個已標準化

看看零售銀行，畫面雖亂，卻可通行。歐洲有英國開放銀行（UK Open Banking）與 Berlin Group 的 NextGenPSD2，後者已為超過四分之三的歐洲銀行採用，在實務上被當成一套事實標準。美國有 Financial Data Exchange，如今橫跨超過六千萬個消費者帳戶。澳洲有 Consumer Data Right。這些都不是全球性的，也都不太可能變成全球性的——但每一套都是一份真實、有版本、可供機器測試的契約，而在契約力所不及之處，聚合商（Plaid、Tink、TrueLayer、Salt Edge）會把差異吸收進單一介面之後。零售的碎裂是一種稅。它不是一道牆。

企業與批發銀行則沒有對等物。一家跨國企業的資金部門，透過主機對主機（host-to-host）的檔案管道、十來個各行其是的入口網站、一套資金管理系統，或一家聚合商去觸及它的往來銀行——通常這四者同時並用。這不是稻草人論證：麥肯錫自家的交易銀行研究多年來一直記錄著同一份積習，描述著銀行如何倚賴主機對主機與 SFTP 檔案傳輸，列舉著檔案式整合眾所周知的故障模式——臃腫的 ERP 格式必須逐一為每家企業客製、無力處理條件式路由——並報告有高達 85% 的交易銀行主管打算投資於現金管理 API。對 API 的胃口毋庸置疑。缺的，是它們所指向的那份共通契約。

因為那些常被點名的候選者都不是它。ISO 20022 經常被誤認為那套缺席的標準，但它是一套資料文法，不是一份 API 契約：pain.001 告訴你一筆信用轉帳該如何措辭，卻不告訴你哪個端點會建立它、它如何認證、如何分頁，或它如何告訴你它失敗了。BIAN 給了業界一套共享的語意參考模型，不是一個強制性的介面。Swift 的 Payment Initiation 與 Instant Cash Reporting API 是朝標準化邁進的真切一步，但它們以網路為中心、且仍在萌芽階段，不是一個普世的介面。Berlin Group 的 openFinance 框架正朝企業使用情境延伸——開戶、貿易金融、動態定期支付——但它是歐洲的、早期的、且需按協議付費才屬進階。把這一切拼起來，你手上仍然沒有一套具約束力的全球企業銀行 API 標準。你有的是建材，卻沒有藍圖。

碎裂為何得以存續——以及那何以正在終結

二十年來這尚可容忍，因為那位整合者是人類，且有耐性。一家企業要在數月、有時數季之內，把少數幾條銀行連線接上線。每一條都是一個專案：交換憑證、跑一次小額測試、為一份對應文件爭論不休。成本是真實的，但每段關係只付一次，並攤提到後續數年的支付上。當一家銀行的 API 規格不足時——當一套標準如銀行自己所抱怨的那樣「把其餘部分留給實作機構自行決定」時——一位人類工程師會去讀那個入口網站、推斷其意圖，然後把缺口補上。模稜兩可之所以可承受，是因為有一個人在場化解它。

它得以存續，還有一些較少被公開說出口的理由。底下的管線確實難改：批次清算窗口、隔夜週期，以及那些從未為回答即時問題而設計的主機核心。而碎裂也不只是意外——它悄悄地是一種鎖定。資金管理主管每建一條各行其是的主機對主機管道，就累積出一筆歸於既有銀行的轉換成本。一家難以整合的銀行，在邊際上，就是一家難以離開的銀行。這一切並無陰謀；它只是尋常的誘因。但它解釋了：為何一個已在資料文法上取得共識的行業，卻從未在介面上取得共識——以及為何介面是僅存的最後一層尚未標準化的層。它之所以再也撐不住，是因為它底下那一層正被限期推向結構化，而它上面那一層剛獲得了一位新的、沒有耐性的使用者。

呼叫方已然改變

那位使用者在十八個月內就到了。Model Context Protocol——Anthropic 於 2024 年 11 月將其開源，並於 2025 年 12 月與 Block 及 OpenAI 一同將其捐給 Linux Foundation 旗下的 Agentic AI Foundation——已成為 AI 系統觸及工具與資料的預設方式。到 2026 年初，它每月大約有九千七百萬次 SDK 下載；到年中，依業界一份具方向性的解讀，約有七成八的企業 AI 團隊在正式環境中運行以 MCP 為後盾的智能體，且超過四分之一的《財星》五百大企業正在營運 MCP 伺服器，並透過一套標準的 OAuth 2.1 授權層加以保護。它一貫、且準確地被形容為「AI 的 USB-C」：它把 M×N 的整合噩夢——每個模型都要手工接上每一項工具——收攏成 M+N。它對自己的那句總結，才是對銀行至關緊要的一句：API 是給程式的；MCP 是給智能體的。 一個 REST API 期待呼叫方事先就知道該打哪個端點、帶哪些參數。一個智能體則期待在執行期發現可用的工具，並由它自己決定該如何、該何時使用它們。

這對資金管理而言絕非空談。這套模式在 2026 年的企業與投資銀行資金部門之間已然一致：一個智能體讀取 ISO 20022 現金資料、呼叫一組有界的工具，並在政策區間內重新平衡流動性，外圍則包覆著 SR 11-7、DORA 與 EU AI Act 的控管。資料文法已為此就緒。API 介面尚未。

精準說出這道錯配

把智能體剝到它從一個銀行交易對手身上真正需要的東西，這份清單既短且不容妥協：

一份可供機器發現的契約——一份 OpenAPI 描述，或一份工具清單（tool manifest），供智能體在執行期讀取，而非一份人類讀過一次的 PDF。
單一的認證模型——一套金融級的 OAuth2／mTLS 設定檔（FAPI 是顯而易見的錨點），而非每家銀行各一套交握。
把冪等性當作一項保證——一組獨一無二的指令參照，讓一筆重試的支付變成一次空操作（no-op），因為一個智能體一定會重試。
一套決定性的錯誤文法——同一種失敗在任何地方都代表同一件事，好讓模型能對它進行推理。
語意化版本管理與能力發現——好讓一個智能體無需人類的釋出說明，就能得知一個交易對手這一季能做什麼。
結構化的 ISO 20022 酬載、同意與授權，以及一份防竄改的稽核軌跡——實質、許可，以及證據。

把這份清單對照今日既存的企業銀行，每一行都裂成 N 種方言——每家銀行各一種。那個本應終結 M×N 問題的智能體，卻在銀行邊界上再度撞上它，因為每一家機構實際上都是一台各行其是的伺服器，對「餘額」有它自己的文法、對「支付狀態」有它自己的概念、有它自己的認證舞步、也有它自己對錯誤是何物的想法。這套協定把智能體那一側的線路標準化了。沒有人把銀行那一側標準化。

把一個故障模式化為具體

把它說具體，因為這正是抽象開始咬人之處。設想一個流動性智能體，獲授權在三家銀行之間調撥現金，以將每個帳戶維持在一個目標區間內。它發出三筆幾乎相同的指令，而正如網路常有的情形，三筆各自撞上一次逾時。

A 家銀行把這次逾時當作未知——可安全重試，於是智能體重試，而原始指令也照樣清算了：一筆重複的支付。B 家銀行把同一次逾時當作已提交——請勿重試，卻從未給出一個智能體能解析的確認，於是那筆指令懸在半空，而智能體因為看不到成功，便升級或改道：一筆卡住的支付，加上一個被重複入帳的部位。C 家銀行回傳一個歡快的 HTTP 200，把一則拒絕埋進酬載本體裡；智能體讀了狀態碼、把這次調撥標記為完成，然後往下走：一次無聲的失敗，直到隔天早上才以一筆沒人解釋得清的對帳差異浮現。

三家銀行、一個條件、三個相互矛盾的真相——A 家有重複的資金流出門外、B 家有一筆凍結的指令、C 家有一次幻影般的成功。一位人類資金管理主管本會打給三位關係經理，午餐前就把它理清。而智能體打不了電話給任何人。這正正是為何「把冪等性當作一項保證」與「一套決定性的錯誤文法」不是架構上的錦上添花：少了它們，那份原本只耗費人力工時的碎裂，如今會以機器速度、同時橫跨每一個交易對手，把真金白銀調錯。

為何「把每一家銀行都包進一台 MCP 伺服器」不是解方

反射式的答案，是給每一家銀行一台 MCP 伺服器，然後就此了事。這站不住腳，因為它是把碎裂搬了個地方，而非把它移除。四十家銀行變成四十台伺服器，帶著四十套語意、四十套認證流程，沒有共享的意義——而且，關鍵在於，沒有共享的非功能性底線：沒有共通的延遲預算、沒有議定的可用性層級、沒有可比的冪等性保證。上面那個故障模式，原封不動地熬過了這層包裝。更糟的是，呼叫方如今是一個對支付網路握有寫入權限的非決定性模型，而這不僅僅是一道整合問題，更是一道模型風險與營運韌性問題，正正落在 SR 11-7、DORA 與 EU AI Act 上。MCP 的人在迴路（human-in-the-loop）原語——用於確認的引出（elicitation）、用於推理的取樣（sampling）——是必要且值得歡迎的，但一個確認對話框，替代不了一個行為可預測的交易對手。你無法規模化地治理你無法一致描述的東西。一千台各行其是的伺服器不是一套標準；它是同一片泥沼，只是罩了一層 JSON-RPC 的外衣。

兩種未來，以及一項策略抉擇

由誰來化解這件事，決定了未來十年由誰擁有企業客戶關係，而候選者只有兩位。

在第一種未來裡，銀行把自己的介面標準化。它們發布可供智能體取用的 API，保住與資金管理主管的直接連線，並仍是智能體會發現並呼叫的那個交易對手。在第二種未來裡，聚合商替它們標準化。少數幾個平台定義出事實上的智能體契約，而銀行則淪為它背後可互換的端點——只能透過別人的抽象層才被觸及。這不是臆測；這是零售那段故事往前推演了一個區段。麥肯錫自家 2025 年的交易銀行研究，描述了 Kyriba 與 GTreasury 這類資金管理平台，以及 Bill.com 這類財務長辦公室（office-of-the-CFO）平台，如何以一套與銀行無涉、對部位一以貫之的視圖，把自己安插在客戶與銀行之間。這正正是那一層——在零售裡，它悄悄地把長尾隱沒到了 Plaid 與 Tink 之後。同一份研究指出，企業資金管理主管如今以他們消費級 App 的標準來要求往來銀行，而當開戶、授權與 API 整合令他們失望時，他們便會轉換。

這項抉擇的策略內涵直白得很。一家淪為某家聚合商智能體契約背後端點的銀行，會一次交出三樣東西。利潤，因為它的服務被大宗商品化，並透過別人的介面被以價格優先加以比較。客戶所有權，因為關係、脈絡與轉換成本都遷往那個平台。以及資料與分析的力量，因為它曾經端到端看見的那股金流，如今被一個比銀行更了解客戶的中介所居間隔開。把自己的介面標準化不是一項技術衛生專案。它是「當交易對手」與「淪為大宗商品」之間的分野。

這套標準必須強制規定什麼

那道缺席的方向感並不奇特。每一個組件都已在公開領域裡存在——ISO 20022 管資料、Swift 的 Payment Initiation 與 Instant Cash Reporting API 作為參考操作、BIAN 管語意、Berlin Group 的 openFinance 提供同意與型錄的模式、FAPI 管金融級認證、MCP 管工具揭露、A2A 管智能體對智能體的協調。缺席的，是把它們組裝成一份具約束力、面向企業空間之契約的那個動作——以及那份去指明兩道底線、而非一道底線的紀律。既有的 B2B API 文獻，包括麥肯錫的在內，大致把 API 當成一個成長與體驗的機會。它對決定性、對執行期能力發現，或對標準化的非功能性面向著墨甚少——而那正正是智能體無法容忍的缺漏。所以這套標準必須就兩件事都說清楚：這個介面是什麼，以及它在治理之下如何行為。

技術底線

一份 OpenAPI 優先的契約，並由它產生一份標準的 MCP 工具清單——不是在它旁邊手寫，好讓智能體所見的工具永遠不會與銀行實際運行的 API 產生漂移。
FAPI 等級的認證與同意，作為橫跨整個介面的單一交握。
冪等性與一套決定性的錯誤分類法——穩定的代碼、一種失敗對應一種意義，並記載於契約本身之中。
ISO 20022 原生的酬載，結構化且已備妥混合式地址。
語意化版本管理搭配執行期能力發現——一個智能體能問這個交易對手今天能做什麼，並得到一個機器能懂的答覆。

治理與韌性底線

已發布、且強制執行的非功能性 SLO——延遲、可用性、吞吐量、直通式處理（STP）與人力投入——以真實的工時與作業數字表達，而非行銷用語。
授權、同意與一份防竄改的稽核軌跡，綁定在執行路徑之上，而非漂浮在一個帶外（out-of-band）的入口網站裡。
模型風險與營運韌性控管，對齊 SR 11-7、DORA 與 EU AI Act，好讓一個智能體的呼叫成為有主的受治理事件，而非奇特的邊角案例。

這裡的零售經驗裡，埋著一課硬道理。一套由機器執行的標準，必須比一套人類整合者能悄悄修補的標準更加精準；規格不足不再是一筆用開發者工時支付的軟性成本，而是一種用錯送的支付支付的硬性故障模式。頗堪玩味的是，業界最具權威的協調努力——CPMI 與 PMPG 的協調化 ISO 20022 資料要求，全球各支付系統正被敦促在 G20 跨境支付計畫之下於 2027 年底前採用它，以對抗的正正是這種碎裂——依其自身的說法，既不是一項法規，也不是一套 API 標準。它協調的是資料。介面仍然是沒人負責的事。

一幅目標圖像

要建的東西，比那份診斷來得不那麼令人卻步，因為它是三層，不是一個大計畫。一套標準的企業銀行 API，透過 REST 與 OpenAPI 揭露支付與現金報告，帶著 ISO 20022 原生的酬載與 FAPI 等級的認證——一份契約、一套文法、一次交握。一座MCP 橋接坐落其上，直接從那份 OpenAPI 契約產生面向智能體的工具清單，好讓發現、綱要與權限都衍生自那個介面，而非與它並行維護。以及一層政策與韌性層，把每一次智能體呼叫都包上那些讓自主變得安全的控管：交易與交易對手限額、分段、人在迴路的觸發（在高風險動作上引出確認）、即時 SLO 監控，以及一個強制的緊急關閉開關。要抓住這一點無需任何圖表——這套標準不是一條新的支付網路，它是把那些早已存在的支付網路做出有紀律的排列，並讓智能體路徑與治理路徑從第一次提交（commit）起就內建其中，而非在事故發生後才拴上去。

未來 24 個月裡可信的銀行會做什麼

如果你接受呼叫方已然改變，那麼工作是具體的，並拆成五條路線。

發布一套 ISO 20022 原生、OpenAPI 優先的介面。 挑一條高價值走廊——通常是跨境支付與現金報告——並透過一份單一、有版本的 OpenAPI 定義搭配 ISO 20022 酬載加以揭露，對齊你既有的 CBPR+ 綱要，而非另創第五套文法。讓它對客戶與內部智能體公開，附一個沙盒，並把變更當成產品的釋出來對待。第一年的成功不在於全面覆蓋；它在於證明一條走廊能被端到端地做成智能體可定址。
在其上把認證與冪等性標準化。 採用一套 FAPI 等級的設定檔作為唯一的交握、在每一次寫入上強制冪等性金鑰，並把「重試同一筆指令」做成契約中一項有記載的保證——把「智能體會重試」從一項風險變成一項安全的假設。
界定一套決定性的錯誤文法與能力發現。 給每一種失敗一個穩定的代碼與一致的語意、加上語意化版本管理，並揭露一份智能體能在執行期查詢的能力型錄，附上針對部分支援、棄用與「尚未提供」的明確旗標。
把授權、同意與稽核附加到同一個介面上。 把同意與核准流程移到 API 路徑上、為每一筆由智能體發起的指令發出一份防竄改的軌跡——誰、什麼、何時、在哪個政策區間之下——並把它明確對齊 SR 11-7、DORA 與 EU AI Act，好讓第二道防線能為它簽核放行。
發布非功能性底線，然後跑一次受監督的智能體試點。 為這條走廊承諾延遲、可用性、吞吐量與 STP 目標並加以量測；接著建起一個只使用這個介面的受監督流動性或現金調撥智能體，帶著強制限額、人在迴路的查核點與完整稽核，運行六到十二個月。這是你自己能掌控的那個逼迫函數——它證明當介面可預測時，一個智能體能在政策區間內安全地調度資金，並很快告訴你，你那套標準在哪裡仍是願景、而非事實。

那個逼迫函數

業界剛剛證明了，當某樣東西逼它時，它動得起來。Swift 於 2026 年 11 月的結構化地址切換——此後跨境支付中的非結構化地址將被直接拒收，沒有應急轉換——已把一個不情願的市場，在一個固定日期上，硬拖向了結構化的 ISO 20022 資料，並由 CPMI 於 2027 年底前橫跨 G20 支付計畫、推動協調化資料要求的努力所強化。留意這兩項努力標準化的是什麼：資料，不是介面。文法正被逼得乾淨。介面則被留給每家銀行自行裁量——而那正正是智能體無法配合的裁量。對一個智能體而言，這意味著酬載終於會一致，而它們背後的行為卻依然分歧——這恰恰顛倒了一台機器真正需要的順序，也就是先要可預測的行為、再要乾淨的資料。

所以這才是要避開的非受迫失誤：在動手之前，苦等一個全球委員會來為一套企業銀行 API 標準賜福。如今就發布一套 ISO 20022 原生、可供智能體取用之介面的銀行——一份 OpenAPI 契約、一份由它產生的 MCP 清單、金融級的認證，以及它們真的會站在後頭撐住的非功能性底線——會成為自主資金管理的預設交易對手。它們的工具會是那些智能體無需中間有人、就能發現、信任並呼叫的工具。而觀望的銀行，將只能透過某家聚合商的抽象層才被觸及，把自己的客戶關係租給那個握有轉接器的人。

有文法而無方向，不成其為標準。ISO 20022 告訴了企業銀行該怎麼說話。它從未告訴企業銀行該往哪裡去。智能體已經到了，流利而沒有耐性，而那張地圖依然不在。畫出它，如今是交易銀行裡最舉足輕重的一件基礎設施工程——而且，難得一次，設定大限的不是監管者，而是那些早已守在介面前等候的機器。

常見問答

ISO 20022 難道不就是那套缺席的標準嗎？ 不是。ISO 20022 是一套資料文法，不是一份 API 契約。pain.001 告訴一套系統一筆信用轉帳該如何措辭；它不說哪個端點會建立它、它如何認證、如何分頁，或它如何回報失敗。文法已為智能體就緒。介面——那個智能體實際會呼叫、可供機器發現、行為一致的介面——尚未。

為什麼不乾脆把每一家銀行都包進一台 MCP 伺服器？ 因為那是把碎裂搬了個地方，而非把它移除。四十家銀行變成四十台伺服器，帶著四十套語意、四十套認證流程，而且——關鍵在於——沒有共享的非功能性底線：沒有共通的延遲預算、沒有議定的可用性層級、沒有可比的冪等性保證。呼叫方如今是一個對支付網路握有寫入權限的非決定性模型，這在 SR 11-7、DORA 與 EU AI Act 之下是一道模型風險與營運韌性問題。一千台各行其是的伺服器不是一套標準。

對一家銀行而言，最有用的第一步是什麼？ 發布一條 ISO 20022 原生、OpenAPI 優先的走廊——通常是跨境支付與現金報告——搭配一次 FAPI 等級的交握、把冪等性當作一項有記載的保證，以及一套決定性的錯誤文法。然後只針對那個介面跑一次受監督的智能體試點，帶著強制限額、人在迴路的查核點與完整稽核。把一條走廊端到端地證明出來，勝過一份覆蓋一切、卻什麼都不強制的路線圖。

如果銀行不化解這件事，由誰來化解？ 聚合商。少數幾個資金管理與財務長辦公室平台，會定義出事實上的智能體契約，而銀行則淪為它背後可互換的端點——一次交出利潤、客戶所有權與端到端的資料。這是零售那段故事——Plaid 與 Tink 在那裡吸收了長尾——往前推演一個區段、走進了企業銀行。

參考資料

Model Context Protocol — 官方文件 ⧉。[MCP 於 2024 年 11 月開源，並於 2025 年 12 月與 Block 及 OpenAI 一同捐給 Linux Foundation 旗下的 Agentic AI Foundation；本文分析所立基的執行期工具發現層。文中的採用數字為業界具方向性的解讀，並已如此標註。]
Berlin Group — NextGenPSD2 與 openFinance ⧉。[事實上的歐洲零售 API 標準，及其朝企業使用情境的延伸——引以說明同意與型錄的模式，以及零售對比企業的差異。]
Financial Data Exchange (FDX) ⧉。[美國的零售資料共享標準，引以說明已標準化零售契約的規模——企業銀行對此並無對等物。]
麥肯錫公司（McKinsey & Company）— 金融服務洞察 ⧉。[交易銀行 API 研究：主機對主機／SFTP 的積習、約 85% 的現金管理 API 投資意向，以及資金管理平台的居間介入。引以佐證市場診斷；此處的框架與結論為作者本人所有。]
國際清算銀行（BIS，CPMI）— 協調化 ISO 20022 資料要求 ⧉。[於 2027 年底前協調化支付資料的推動——依其自身的說法，既非一項法規，也非一套 API 標準——引以佐證「有文法而無介面」這一點。]
Swift — 面向金融機構的 ISO 20022 ⧉。[CBPR+ 與 2026 年 11 月的結構化地址里程碑；Payment Initiation 與 Instant Cash Reporting API 引為參考操作，而非一個普世的介面。]

最後審閱於 2026 年 7 月。原創分析；來源均經引用，未予轉載。採用與市場數字為業界具方向性的解讀——重新發布前請對照第一手來源查證。依 CC-BY-4.0 授權。

最近審閱 2026-07-08.

Republish this article

從碎裂到斷層：智能體時代裡企業銀行缺席的那套 API 標準 — Sebastien Rousseau

零售銀行早在十年前就有了自己的 API 標準。企業銀行始終沒有——如今 AI 智能體與 Model Context Protocol 已把整合變成一項執行期決策，這道缺口便成了一條斷層線。

This article is licensed under Creative Commons Attribution 4.0 International. Republication requires attribution to the canonical URL.

從碎裂到斷層：智能體時代裡企業銀行缺席的那套 API 標準 — Sebastien Rousseau

零售銀行早在十年前就有了自己的 API 標準。企業銀行始終沒有——如今 AI 智能體與 Model Context Protocol 已把整合變成一項執行期決策，這道缺口便成了一條斷層線。

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

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER