ISO 20022 和 JSON，平衡 API 中的標準化和靈活性

ISO 20022 的日益普及以及對 API 日益增長的需求，已為金融業帶來諸多創新。然而，ISO 20022 豐富的數據標準，可能與 JSON（API 中事實上的數據格式）所提倡的簡潔和極簡主義產生衝突。這個問題可能阻礙業界實現 ISO 20022 可帶來的優勢。

在本文中，我們探討了開發人員和業界在嘗試調和 JSON 的靈活性和簡潔性與 ISO 20022 的資料豐富性時所面臨的問題。我們還將審視旨在解決此重要問題的持續努力。

ISO 20022 是一個全球標準，用於金融機構之間交換數據，涵蓋支付、外匯、卡片、貿易融資和證券等領域。該標準豐富、結構化且靈活，相較於先前的全球標準 ISO 15022（SWIFT 的 MT 格式）和 ISO 8583（用於卡片支付和帳戶對帳戶支付）而言，是一個巨大的飛躍。

業界已群策群力推動採用 ISO 20022，因為當所有人都使用時，其優勢便會更顯而易見。隨著更多舉措轉用新系統——全球許多自動清算所 (ACH) 現正將新格式用於高價值和低價值支付，以及 SWIFT 的跨境支付系統——這一變革的步伐已加快。其應用尚未普及，部分系統特別是批量付款仍支援舊有格式，然而，對於本地實時支付系統而言，ISO 20022 的使用已廣泛應用。

ISO 20022 的範疇側重於資訊交換，但主要優勢來自機構利用 數據字典 支援其內部數據模型，實質上是採用通用語言。例如，這意味著構成一方（Party）的屬性（姓名、地址、出生日期及地點等），當該方（Party）在跨境交易中是債務人，或在帳戶轉換請求中是帳戶持有人時，這些屬性保持一致。

ISO 20022 作為一種標準，其格式無關，但特定的訊息架構僅以 XSD（XML 綱要定義）形式正式發布，並可從訊息目錄獲取，這導致 XML 成為交換 ISO 20022 訊息最廣泛使用的格式。

隨著 ISO 20022 的使用日益增加，對新用例和新資料交換方式的需求也隨之增加，其中一個突出例子是金融機構用於多種應用程式的 API，例如允許存取帳戶資訊、發起支付、開放銀行或內部系統整合。

API 開發人員，特別是在設計 REST API1 時，通常會採用簡約主義方法，優先考慮效率，僅傳輸特定請求和回應所需的必要數據。透過 API 交換的資訊通常以 JSON（JavaScript 物件標記法）格式發送，其類似於 XML，但存在一些輕微的不兼容性。

由於 ISO 20022 沒有發布 JSON 綱要，且目前尚無普遍遵循的規則來表示這種格式2，這可能會對希望使用該標準的 API 開發人員帶來挑戰。

ISO 20022 在全球範圍內支援金融訊息傳遞用例，這意味著每條訊息將包含許多元素。儘管執行特定商業訊息交換（例如信用轉帳）所需的關鍵要素（債務人名稱、債權人名稱、金額、貨幣等）保持相當一致，但這些要素的使用方式卻存在差異。例如，在本地清算所中，德國的債務代理（債務銀行）使用 BIC（商業識別碼）或 Bankleitzahl（BLZ – 源自 IBAN）定義，但在澳洲，則使用 BSB 號碼（銀行州分行）識別。

為此，ISO 20022 訊息的結構可讓你提供其中一個，但這種靈活性會導致訊息比任何特定應用案例所需的要大。

當開發人員設計 API 時，如果強調簡約性，他們通常只會包含特定於其用例的元素；例如，如果他們在英國，則幾乎沒有理由包含 BSB 號碼，因為所有代理都將透過排序代碼識別。同樣地，如果代理人只能透過分行代碼識別，那麼，當元素名稱可以更改時，為何還要包含 ISO 20022 訊息的部分結構呢？以下例子說明了這一點。

這是一個基於XML的ISO 20022實例中，英國分類代碼和帳號的顯示方式：

</CdtrAcct>

<CdtrAgt>

<FinInstnId>

            <ClrSysMmbId> 

<ClrSysId>

<Cd>GBDSC</Cd>

</ClrSysId>

                <MmbId>080800</MmbId> 

            </ClrSysMmbId> 

        </FinInstnId> 

</CdtrAgt>

<CdtrAcct>

<Id>

            <Othr> 

<Id>21325698</Id>

            </Othr> 

</Id>

    </CdtrAcct> 

代碼「GBDSC」定義會員ID為「英國國內分類代碼」，且Id/Other/Id包含帳號。

相比之下，以下是相同的資料將如何透過英國開放銀行 API 傳輸的範例，這些 API「在可用時使用 ISO 20022 訊息元素和組件設計」3，請注意其尺寸較小，以及元素名稱、代碼和結構的變化：

"CreditorAccount":
{ "SchemeName": "UK.OBIE.SortCodeAccountNumber", "Identification":
"08080021325698" }

這個問題並非英國開放銀行獨有，而是整個行業都在發生，即基於 ISO 20022 的 API 在沒有明確最佳實踐指南或未發布官方 JSON 架構的情況下實施。方法碎片化的風險很高，導致實施之間不兼容，並未能實現標準化旨在達到的一些好處。業界已識別此風險，ISO 20022 已採取一些措施來緩解此風險：

• API SEG（標準評估組）在新分頁中開啟成立旨在註冊、開發和維護 API 資源。
• ISO/TC 68/WG4（即技術委員會 68/第四工作組），負責管理和更新 ISO 20022 標準的團隊，一直在研究如何修改該標準，以正式引入基於 JSON 的 ISO 20022 資源，並引入一個範本，以協助建模師註冊該標準將發佈的不同格式（即JSON Schema）。
• ISO 20022 技術支援小組 (TSG)在新分頁開啟 正在尋求更新和修訂其 JSON 最佳實踐白皮書（在頁腳中引用），以提供有關建模 JSON 的進一步指導。

隨著金融業持續發展，持續的標準化和互操作性至關重要。採用基於 JSON 的訊息傳遞是創新的關鍵推動因素，但它也帶來了行業需要警惕的潛在陷阱。否則，它將面臨使之前許多艱鉅的工作付諸東流的風險。

Mastercard 積極參與這些計劃，並將繼續與業界合作，致力建立一個框架，以適應新格式，同時保持對未來創新至關重要的標準化和互通性。