帳本對帳本(Ledger-to-Ledger,L2L)

銀行通訊伺服器、中間層伺服器、核心/結算伺服器與總帳/帳戶伺服器之間的主要差異

在銀行科技領域,伺服器對確保金融交易及記錄保存的順暢運作具有決定性作用。銀行倚賴的伺服器主要有兩類:通訊伺服器與分類帳/帳戶伺服器。兩者雖然同樣至關重要,但用途各異,處理的資料類型亦不相同。

通訊伺服器

通訊伺服器是銀行與金融機構之間安全數據交換的骨幹。以下為通訊伺服器的主要功能及特點:

1. 安全資料交換:該等伺服器促進安全的資料交換,確保敏感財務資訊得以在機構之間傳輸而不受損害。
2. 協議與標準:其採用 SWIFT、SEPA 或 ACH 等標準化協議進行銀行同業通訊,確保不同平台之間的一致性與可靠性。
3. 加密與身分驗證:為確保安全,通訊伺服器採用先進的加密方法及嚴格的身分驗證協定,保障資料在傳輸過程中的安全。
4. 交易處理:其主要職能是處理交易請求、訊息及指示,作為中介機構傳遞交易所需的資訊。
5. 不涉及資金劃轉:重要的是,這些伺服器不會直接劃轉資金或更新帳戶結餘;其功能僅在於促成此類操作所需的通訊。

核心銀行系統伺服器

核心銀行伺服器是金融機構的數碼骨幹,負責統籌貨幣交易的精確執行、核實及結算。它們安全地處理收到的交易指示(例如 SWIFT 訊息),維護詳盡的客戶帳戶及內部帳戶,將這些交易與代理銀行及中介銀行所確認的實際資金結算進行核對,並相應準確更新客戶結餘。

除交易處理功能外,核心伺服器亦負責管理監管合規、執行自動化對帳以及 AML/KYC 驗證、落實風險管理程序,並生成完整的稽核軌跡,從而保障本機構各項銀行業務的營運完整性、財務準確性及法規遵循。

分類帳/帳戶伺服器

另一方面,分類帳/帳戶伺服器是銀行財務記錄的保管者。其主要特點如下:

1. 財務記錄維護:這些伺服器儲存並維護銀行的核心財務記錄,確保每一筆交易均準確入帳。
2. 交易記錄:負責記錄所有交易,包括借記及貸記,並負責更新及保存當前帳戶結餘。
3. 總帳管理:帳簿伺服器管理銀行的總帳及各客戶帳戶,提供財務狀況的全面視圖。
4. 數據完整性:確保數據的一致性與完整性至關重要,因為這些記錄是準確財務報告及合規的基礎。
5. 嚴密的安全措施:鑑於資料的敏感性,分類帳伺服器通常採用更為嚴格的安全措施,包括額外的加密層級及嚴謹的存取控制。

通訊伺服器啟動並促成交易,而分類帳伺服器則於交易經核實後,最終將其記錄並反映於銀行帳冊之中。

在當代銀行體系中,這些職能往往相互整合,安全的行內通訊協議與分類帳管理系統協同運作。此種整合確保全行整個金融生態系統的即時更新及一致性,從而提升效率與安全性。

銀行業務中作為分類帳調整的交易

發生金融交易時,例如將貨幣由一個帳戶轉至另一帳戶,並無實體貨幣流動。交易實際上是透過調整代理銀行、中央銀行或即時支付(RTP)清算系統各自帳戶中的分類帳分錄而執行。銀行體系減少一個帳戶的餘額,並增加另一個帳戶的餘額,以反映價值的轉移,有待另行結算。

對帳及最終結算:相關銀行對交易進行對帳,以確保準確無誤。如交易涉及中間銀行,各銀行透過其代理銀行關係結算各自負責的部分。

報告與記錄保存:銀行為合規、審計及報告目的,保存所有交易的記錄。

核心銀行系統(CBS)如何運作

I. 關鍵區別:指示與實際結算

SWIFT 報文,例如 pacs.008(客戶轉帳)或 pacs.009(金融機構轉帳),本質上是一項安全的通訊或指示。它通知收款銀行預期將有資金到帳,並列明受益人資料、交易金額及路由指示,但其本身並不會轉移資金。唯有透過涉及代理銀行或中間銀行的銀行間機制,將指示金額結算,並由各機構帳戶結餘的實際變動予以核實,資金轉移方告完成。

II. 代理銀行與中間銀行的定義及角色

A. 代理銀行

• 代理銀行與其他銀行維持直接的雙邊帳戶(往來帳戶(Nostro)/來帳戶(Vostro))。
• 此類帳戶反映於另一金融機構持有的實際現金結餘,便利跨境付款及結算。

B. 中間銀行

• 在發送銀行與受益銀行之間並無直接代理行關係時,中介銀行在付款鏈中擔任轉接節點。
• 它彌合彼此之間並無代理行關係的銀行之間的缺口,處理貨幣兌換、國際支付及路由複雜性等事宜。

III. 核心銀行系統如何確認資金實際到帳

核心銀行系統採用嚴謹的對帳及確認流程,並就代理銀行與中間銀行兩種情形分別處理,詳列如下:

A. 透過代理銀行核實

當交易涉及直接代理帳戶(往來帳戶(Nostro))時:

詳細工作流程:

1. 指令到達(pacs.008/pacs.009):CBS 接收並暫時儲存 SWIFT 指令。
2. 暫時入帳:資金可能暫時出現於內部暫記帳或交收分類帳中,待核實後處理。
3. 往來帳戶(Nostro)對帳單核對:收款銀行會自其代理銀行收到自動化帳戶對帳單(camt.053、舊式 MT 940/950 或電子 API),反映實際帳戶結餘及入帳記錄。核心銀行系統(CBS)會依據唯一識別碼(UETR——唯一端到端交易參考編號),將該等對帳單與 SWIFT 指示自動核對。
4. 最終入帳:唯有在 SWIFT 指示與代理銀行確認的入帳記錄完全相符後,核心銀行系統(CBS)方會將資金最終記入受益人的客戶帳戶。

B. 透過中間銀行進行核實

當資金經由中間銀行(多層路由)匯轉時,核實程序會稍為複雜:

詳細工作流程:

1. 指示到達(pacs.008):核心銀行系統(CBS)首先記錄收到的指示訊息。
2. 中間銀行結算核實:經中間銀行匯出的資金,通常會產生多項 SWIFT 確認訊息,包括入帳通知(camt.054,前稱 MT 910)或表明資金已轉付的後續 pacs.009 訊息。中間銀行發出入帳通知,確認資金已成功存入收款銀行的代理行往來帳戶(Nostro)。CBS 接收該等中間機構的確認訊息,以便逐步對帳。
3. 代理銀行最終核實:代理銀行發出的最終對帳單(camt.053,或舊式 MT 940/950)確認現金已實際結算至收款銀行的往來帳戶(Nostro)。
4. 最終客戶入帳:唯有在收到並核實代理銀行發出的實際結算確認(經中介機構確認後),CBS 方會最終將款項記入受益人帳戶。

IV. 核心銀行系統所採用的技術與系統

• 自動對帳軟件:(例如 SmartStream TLM、Temenos、Oracle FLEXCUBE)
• 即時監控工具:透過 API 整合及數碼銀行結單,實現即時核實。
• 訊息閘道:SWIFT Alliance Access、SWIFT gpi 追蹤工具,可即時確認交易狀態。
• 唯一交易參考編號(UETR),由 SWIFT 強制要求使用,以確保每筆付款訊息在整個付款生命週期內均可被唯一識別。
• 雙層對帳核查。自動化電子對帳，並輔以專責營運團隊的人工核實。
• AML/KYC 及合規控制。每項付款指示在入帳前均經篩查及驗證,以確保遵守監管義務(FATF、反洗錢指令、OFAC、歐盟/聯合國制裁)。
• 審計軌跡及報告。完整保存電子審計軌跡,以符合監管合規及審計要求。

核心銀行系統並不以單純收到 SWIFT 指示訊息作為資金已結算的憑證,而是透過與代理銀行(持有往來帳戶的最終清算機構)及中間銀行(透過貸記通知或後續確認來確認後續轉帳的交易路由銀行)所發出的已確認對帳單進行對帳,有系統地核實實際的資金流動。

唯有在代理行層面的實際貨幣餘額發生變動,且中間銀行與代理銀行的銀行對帳單均顯示已確認的入帳時,核心銀行系統方會最終確認並將資金分配至受益客戶帳戶,從而確保付款指示與實際現金結算之間的精確區分。

將銀行及中央銀行的帳外資金轉換為帳內資金

將表外資金轉為表內資金,涉及把先前未記錄於正式資產負債表的金融活動納入主要會計系統。此舉對確保財務報告準確、提高透明度及符合監管規定至關重要。以下就商業銀行及中央銀行兩者,詳述此程序,涵蓋識別、核實、對帳、記錄及審計。

A. 商業銀行

1. 識別表外資金

帳外資金來源:

• 特殊目的實體(SPE):為特定交易(例如證券化)而設立的法律實體,可持有資產及負債,並置於銀行主要資產負債表之外。此類實體可包括結構性投資工具(SIV)及導管機構。
• 證券化資產:已售予投資者但仍由銀行負責服務的貸款或應收款項,例如按揭抵押證券(MBS)及資產抵押證券(ABS)。
• 租賃義務:根據舊有會計準則原不予資本化的營運租賃,依據國際財務報告準則第16號(IFRS 16)等新準則,現須納入資產負債表。
• 衍生工具及或有負債:包括掉期、期貨及期權等金融工具,以及來自保證函和信用證的潛在負債。

2. 核實與確認

驗證步驟:

• 金融工具評估：進行詳細分析，以釐定資產負債表外項目的性質、風險及價值。
• 估值模型:運用貼現現金流(DCF)分析、按市價計值(MTM)估值及其他金融模型,評估衍生工具及證券化資產的公允價值。
• 信用風險分析:評估資產負債表外交易所涉及的相關資產及交易對手的信用狀況。
• 監管審閱:確保符合相關會計及監管標準。
• IFRS 9 及 IFRS 16:分別規範金融工具及租賃的確認與計量。
• Basel III 框架:風險加權資產(RWA)計算及槓桿比率對表外風險承擔處理方式的影響。

協議與標準:

• IFRS 與 GAAP:確保一致應用《國際財務報告準則》(IFRS)及《公認會計原則》(GAAP),以達致準確的財務報告。
• 反洗錢及客戶身分識別合規:遵循反洗錢(AML)及客戶身分識別(KYC)規定,以防範非法活動。

3. 對帳流程

對帳方法:

• 詳細交易審閱:對資產負債表外交易進行徹底審查,並與內部記錄逐一核對。
• 交易層面核對:確保每一項資產負債表外項目均準確反映,並與相應的資產負債表內分錄核對一致。
• 例外情況報告:透過自動化系統或人工介入,識別並解決差異。

工具及軟件:

• ERP 系統:採用 SAP 及 Oracle Financials 等企業資源規劃系統,使對帳流程自動化。
• 專業對帳軟體:如 BlackLine 及 SmartStream 等工具,用於大批量交易配對及異常偵測。

4. 總帳記錄

記錄方式:

• 會計分錄:將表外項目詳細入帳至總帳,確保所有相關細節均已記錄。
• 自動過帳:運用核心銀行系統自動記錄交易,將人工輸入錯誤減至最低。
• 集團內部及銀行內部分錄:確保涉及銀行集團內多個實體的交易得到妥善的會計處理。

協議與標準:

• 複式記帳:確保每筆交易至少影響兩個帳戶,以維持會計等式(資產 = 負債 + 權益)。
• IFRS/GAAP 合規:遵守國際及各國會計準則,以確保財務報告的透明度與一致性。

5. 審計與合規

審計程序：

• 內部審計:定期進行內部審查,以確保政策與程序獲得遵循,以及財務報告準確無誤。
• 持續監察:實施實時審計系統,以偵測異常情況並確保持續合規。
• 風險導向審計:聚焦衍生工具及特殊目的實體(SPE)等高風險領域,以確保有效監督。
• 外部審計:由外部核數師進行獨立核查,以確保符合會計準則及法規。
• 審計追蹤維護:保存所有交易及調整的完整記錄,以提供清晰的審計追蹤。

合規框架:

• 《薩班斯-奧克斯利法案》(SOX):確保企業披露資料的準確性及完整性(僅適用於美國)。
• 歐盟審計規例:確保歐洲財務報告的準確性與透明度。

協議與技術:

• 監管報告工具:如 AxiomSL 及 Wolters Kluwer 等用於編製及提交監管報告的軟件
• 區塊鏈及分散式帳本技術(DLT):運用分散式帳本技術(DLT),使金融交易的記錄不可篡改並具透明度。

B. 中央銀行

1. 識別表外資金

表外資金來源:

• 外匯掉期額度:已承諾但尚未動用的掉期額度,以及掉期的遠期交割部分,僅以承諾形式列示。
• 或有負債:未列入資產負債表的保證及其他潛在義務。
• 託管持有項目:為其他中央銀行託管的黃金及證券,此等資產從不計入託管機構的資產負債表。

2. 核實及驗證

驗證步驟:

• 儲備估值:評估外匯儲備及其他表外資產的市場價值。
• 市場價格及匯率:使用最新市場數據對儲備進行準確估值。
• 風險評估:評估持有該等儲備所涉及的信用風險及市場風險。
• 監管審查:確保符合國際貨幣基金組織(IMF)等所訂立的國際標準。
• 國際貨幣基金組織(IMF)指引:遵循 IMF 國際儲備及外匯流動性數據模板。

協議與標準:

• IMF 準則:國際貨幣基金組織就外匯儲備及其他貨幣統計數據的申報所訂的指引。
• 中央銀行會計準則:中央銀行會計及財務報告的特定準則及慣例。

3. 對帳程序

對帳方法:

• 持有資產詳細審查:將外匯儲備及其他表外項目的記錄與實際持有情況進行核對。
• 帳簿與實際核對:確保所記錄的數據與實物或帳戶結餘相符。
• 貨幣對帳:定期將外幣持倉與市場匯率及交易進行核對。

工具及軟件:

• 中央銀行系統:為管理中央銀行交易及持有資產而量身訂製的軟件解決方案。
• 專用對帳工具:專為大批量外匯交易及儲備對帳而設計的工具。

4. 記入總帳

記錄方式:

• 日記帳分錄:詳列相關分錄,以反映表外項目併入總帳的處理。
• 自動化系統:運用集中式銀行系統,將總帳的記錄與更新自動化。
• 多幣種會計:確保以多種貨幣進行的交易及持倉均能準確入帳。

協議與標準:

• 複式記帳:透過複式記帳法維持借貸平衡的財務記錄。
• 國際貨幣基金組織(IMF)及中央銀行準則:遵循國際指引及中央銀行的特定會計準則。

5. 審計與合規

審計程序：

• 內部審計:定期檢視,以確保央行內部之準確性及政策合規。
• 實時監控:實施持續監控系統,並具備實時審計能力。
• 風險為本方法:聚焦於風險敞口較大的領域,例如外匯儲備及或有負債。
• 外部審計:由獨立機構進行審計,以確保遵守國際標準及報告的透明度。
• 完整文件:保存所有交易及調整的詳盡記錄,以供審計之用。

合規框架:

• IMF 指引：確保國際儲備及外匯流動性報告的透明度與準確性。
• 中央銀行規例:遵守規管中央銀行本身的法定及會計規則。

協議與技術:

• 區塊鏈及分散式帳本技術(DLT):透過不可篡改的記錄及分散式帳本技術提升透明度及準確性。
• 監管報告工具:協助準確及時地編製和提交監管報告。

簡言之
將表外資金轉入帳內,是一項細緻而多面向的程序,須審慎進行識別、核實、對帳、記錄及審計。商業銀行與中央銀行均須遵守嚴謹的標準及規程,以確保其財務報表的準確性、透明度及合規性。透過運用先進工具並遵循國際標準,此等機構能有效管理表外項目併入主要會計系統的工作,確保其財務報告的完整性。

IFB – Interledger 協議(ILP)閘道及補充性支付渠道

宗旨與定位

ILP 是 IFB 跨帳本策略的核心:它提供附帶條件、以密碼學綁定的轉帳,在訊息層面數秒內即可完成,同時維持本行 DMZ 連接器與核心 ISO 20022 帳本之間的隔離。然而,現代支付環境並非單一標準。客戶可能需要針對特定通匯走廊、流動性特徵或監管司法管轄區而優化的支付通道。以下列出客戶須遵循的 ILP 規格,以及主要的替代通道,並說明各自在審慎監管或技術上的理據。

1 Interledger Protocol – 標準規範

• 連接器層(Connector Tier)——在強化的中間層採用 Rafiki v 1.3 以上版本或 Interledger.rs;對外流量以 TLS 1.3 傳輸 BTP/STREAM;內部則轉換為 ISO 20022 PACS.008/009。此拓撲結構符合 NIST SP 800-53 Rev 5 的 SC-7「邊界保護」控制項。
• 憑證管理——代幣化 BTP 憑證每九十天輪換一次,並可於二十四小時內撤銷,符合 OWASP 應用程式安全驗證標準(Application Security Verification Standard)對憑證管理的要求。
• 路徑驗證測試 – 先進行三筆 0.01 歐元的小額付款(往返時延 ≤1 秒),繼而進行 1 歐元的 STREAM 突發傳輸(損耗 <0.5%,時延 <750 毫秒),在不觸及申報門檻的情況下驗證傳輸能力。
• 結算終局性——每個已履行的資料包均會向 T2(前稱 TARGET2)或代理銀行的往來帳戶(Nostro)發出 pacs.009 指示;在收到不可撤銷的確認之前,不會向受益人入帳,從而符合 CPMI-IOSCO《金融市場基礎設施原則》(國際清算銀行,巴塞爾,2012 年 4 月)第 8 項原則「結算終局性」。

2 Swift 即時跨境支付——傳統支付渠道

• 概述 – Swift 連接各國國內即時支付系統以處理跨境付款;在雙方國內系統均支持的情況下,受益人可於數秒內收款,所採用者為 ISO 20022 pacs.008 報文。
• IFB採用此方式的原因——依託現有代理銀行帳戶,無需新建代幣基礎設施,並具備全球銀行覆蓋網絡。
• 監管優勢 – 由於結算仍在傳統 RTGS 渠道上進行,資本及流動性處理依循 Basel III 既定框架,無需顧及 ILP 的附條件託管細節。

3 SEPA 即時貸記轉帳 – 泛歐歐元支付通道

• 概況 – 歐洲支付委員會(European Payments Council)的 SCT Inst 計劃讓收款人可於十秒內收到歐元貸記轉帳,全年每日 24 小時運作。自 2025 年規則手冊(2025 年 10 月)起,該計劃不再設定最高金額;各支付服務提供者自行訂定其限額。
• 重要性——對於純歐元的資金通道,SEPA Instant 可避免外匯價差,並透過 TARGET 即時支付結算系統(TIPS)或其他清算機制,以中央銀行貨幣完成結算。
• 監管優勢——根據《即時支付條例》(EU) 2024/886,歐元區內的支付服務提供者必須能夠發送及接收即時支付,且收費不得高於標準貸記轉帳。

4 RTGS.global——原子化貨幣同步交收(PvP)網絡

• 簡介——RTGS.global 正在建立一個網絡,供參與銀行之間進行跨境多幣種支付的原子式款對款交收。
• 重要性所在——款項對付(PvP)可消除外匯結算中的本金風險;ILP 在履約後仍需進行往來帳戶(Nostro)對帳,而 RTGS.global 則將交易雙方兩邊綁定於單一原子指令之中。
• 監管優勢 – 巴塞爾委員會有關外匯結算風險的監管指引建議,在切實可行的情況下一律採用 PvP 結算。

5 Ripple Payments(前稱 RippleNet)——基於 API 的帳本橋接

• 概況 – Ripple Payments 為參與機構之間提供訊息傳遞、外匯報價及結算統籌服務,並可選擇使用 XRP 或穩定幣提供流動性。
• 重要性——部分交易對手已於 Ripple 網絡上運作;接入該網絡可避免重複整合。
• 監管附註——如以加密資產進行結算,除支付監管規定外,亦適用各司法管轄區的加密資產規則。

6 Mojaloop – 普惠即時支付系統(IIPS)

• 概況 – Mojaloop 是開源的參考模型,適用於可互通的小額流動支付。其內部整合 ILP,並加入為普惠金融而設計的目錄及報價服務。
• 重要性所在 – 小額匯款可在基於 Mojaloop 的各國支付體系之間路由,而無須支付代理銀行費用。
• 政策背景——此舉有助於實現聯合國可持續發展目標第 8.10 項有關取得金融服務的具體目標。

7 項路線圖式發展可能性

• 批發型央行數位貨幣同步交收(PvP)通道——各國央行測試的多邊央行數位貨幣平台,可在央行貨幣中實現款券對付(DvP)及同步交收(PvP)的原子性結算。
• 代幣化存款網絡——SWIFT 共享帳本(自 2026 年 7 月起試行)及受監管負債網絡(Regulated Liability Network)等項目,探索將銀行存款以代幣形式置於共享帳本上,並透過現有系統完成最終結算。

8 決策矩陣——何時選用何種通道?

• 當多資產串流、小額支付或可編程條件設定為首要考量時,請選擇ILP。
• 選擇 Swift 即時跨境支付,可在極低整合負擔下觸達全球銀行。
• 僅涉及歐元的支付通道,請選用受歐洲中央銀行監管的 SEPA Instant。
• 若董事會首要關注的是消除雙邊同步交收(PvP)風險,則宜選擇 RTGS.global。
• 若交易對手已在 Ripple 網絡上營運,請選用 Ripple Payments。
• 如需在新興市場辦理小額、以普惠金融為導向的匯款,可選用 Mojaloop。

9 結語
IFB 以 Swift 即時支付、SEPA Instant、RTGS.global、Ripple Payments 及 Mojaloop 補充 ILP,並將在適當時候納入央行數碼貨幣及代幣化存款支付通道,為客戶提供一系列治理嚴謹的支付路徑。每一支付通道均對應明確的審慎監管依據,確保無論客戶選擇何種方案,其底層結算機制均與全球監管準則及 IFB 自身對營運韌性的承諾保持一致。

IFB 之協定(ILP)連接 —— 規格、治理及策略考量

1 概要

IFB 已採用 Interledger Protocol(ILP),作為外部支付網絡與本行內部 ISO 20022 結算基礎設施之間的近實時橋樑。ILP 支援附帶條件且經密碼學驗證的轉帳,有關轉帳終止於中間層連接器而非核心銀行分類帳,從而保持網絡分隔;法律上的結算則經由下文所述的結算渠道完成。以下規範載明 ILP 的實施方式、各項控制措施的設置原因,以及作為該等要求依據的法律或審慎監管文件。

2 網絡架構與隔離

• 三層拓撲架構。ILP 流量僅由部署於非軍事區(DMZ)中間層的強化連接器接收。該連接器對外以 TLS 1.3 運行 BTP/STREAM,並將每個已履行的資料包轉換為 ISO 20022 PACS.008 或 PACS.009 報文,經內部整合匯流排傳送至核心帳務系統。核心帳務系統的 VLAN 內不容許任何 ILP 通訊端。原因何在?此設計遵循 NIST SP 800-53 Rev 5 的 SC-7「邊界保護」控制措施,以及 PCI DSS 對網絡分段的要求。
• 連接器技術堆疊。IFB 統一採用 Rafiki v 1.3 或更高版本(其內建自有的 BTP 實作)。Interledger.rs 被維持為經核准的等效方案。ilp-plugin-btp 等已棄用的函式庫一律禁止使用,以避免供應鏈風險及無人維護的相依項目。
• 傳輸安全。所有對外連接均強制採用具備前向保密(Perfect Forward Secrecy)的 TLS 1.3;加密套件限於德國聯邦資訊安全局(BSI TR-02102-2,2025 年版)核准者。

3 連接模式及憑證管理規範

• 首選模式——Open Payments / HTTPS 支付指針。收款方公布一個 well-known 端點(/.well-known/pay/*),返回符合 ILDCP 的 JSON(ILP 地址、assetCode、assetScale、STREAM 憑證)。端點發現過程自動進行並自帶說明。
• 備援模式——靜態 BTP 對等連接。靜態憑證經由 PGP 加密通道交換,每九十日輪換一次,且須能在二十四小時內撤銷。
• 速率限制。連接器將入站請求限制在每分鐘 500 個資料包,超出時返回 HTTP 429。原因何在?此舉有助於落實 ISO/IEC 27002:2022 及 OWASP 應用程式安全驗證標準所要求的監控與濫用偵測控制。

4 路徑證明驗證

在獲准進行商業往來之前,交易對手須:

1. 執行三筆每筆 €0.01 的小額支付;每筆須於 ≤1000 毫秒內完成。
2. 觸發 1 歐元的吞吐量突發測試(透過 STREAM 分塊傳送);封包遺失率須維持在 0.5% 以下,平均往返延遲須低於 750 毫秒。
3. 輪換 BTP 令牌,並重複步驟 1,以證明憑證輪換。

原因何在?小額支付可驗證 STREAM 的附條件託管邏輯,同時不觸及監管申報門檻;而權杖輪替則可測試 OWASP 與 ISO 27002 所要求的憑證生命週期控制。

5 結算最終性與審慎合規

• 有條件履行與法定結算。ILP 的履行會釋放資料包,但法定的最終性須待金融市場基礎設施(FMI)作出不可撤銷的結算後方告產生。因此,每一個已履行的資料包均會觸發一條 ISO 20022 PACS.009 金融機構對金融機構指令,經由 T2(歐元)或經核准的代理行往來帳戶(Nostro)路由。核心帳務系統須待 T2 或往來帳戶(Nostro)上的結算獲確認後,方會貸記受益人帳戶。此雙步驟模式符合 CPMI-IOSCO《金融市場基礎設施原則》(2012 年 4 月)第 8 項原則「結算最終性」,以及 Basel III 的操作風險框架(最終文本,2017 年 12 月)。
• 失敗處理。若於起息日(T+0)未能達成最終性,ILP 託管將自動撤回,事件將依據 Basel III 營運風險指引記錄,並將例外報告呈報首席風險官。

6 合規與監察控制措施

• KYC/KYB 及制裁篩查。在建立業務關係前,交易對手須提交完整的 KYC/KYB 文件、最終受益所有權架構圖及最新的資金證明。每個 ILP 目的地標籤均會依據歐盟理事會綜合金融制裁名單及 OFAC SDN 名單進行實時篩查,符合歐盟制裁規例、(EU) 2024/1624 號規例(歐盟反洗錢規例)及經 2025 年 6 月修訂的 FATF 第 16 號建議。
• 反洗錢交易監控。ILP 封包流量輸入異常偵測引擎;任何可疑模式均會上報,並在必要時及時向主管金融情報單位申報;依照第 (EU) 2023/1113 號規例(資金轉移規例)的要求,付款人及收款人資訊隨每筆轉帳一併傳遞。
• 數碼營運韌性。連接層被視為關鍵的資訊及通訊科技組件,並遵循歐盟《數碼營運韌性法案》(DORA,第(EU) 2022/2554號規例)的標準。每年的滲透測試、每季的漏洞掃描,以及符合DORA時限要求的事故通報均屬強制規定。
• 日誌保存。所有 ILP 數據包日誌、ISO 20022 報文及合規文件均保存七年,符合與 ISO/IEC 27001 相一致的記錄保存慣例。

7 保密與安全條款(統一版)

傳輸採用 TLS 1.3 加密;BTP 權杖以 AES-256 加密方式靜態儲存;資料外洩通知期限為二十四小時。本整合條款取代早期草案中所有重複的「安全與保密」陳述,簡化管治並便利日後修訂。

8 合約里程碑及分期撥付

• 驗證成功後,雙方簽署就緒證書及主服務協議(結算窗口為二十四小時;爭議窗口為四十八小時)。
• 首期款項:依商業條款清單約定,例如100,000歐元,經由已驗證的ILP渠道撥付。
• 每季重新驗證及每年滲透測試,確保技術完整性持續有效。

9 策略回報

IFB 將 ILP 置於獨立隔離的中間層,採用現代化連接器工具,嚴格執行憑證管理規範,並使每一程序步驟均依據權威準則(NIST SP 800-53、ISO 27002、CPMI-IOSCO PFMI、Basel III、DORA、FATF 第16號建議及歐盟制裁法規),從而為客戶提供兼具前沿技術、符合監管要求且營運穩健的跨帳本轉帳能力。訊息近乎即時傳送,而結算仍以受監管的支付渠道為基礎。簡言之,IFB 的 ILP 融合速度與確定性,以創新的步伐創造價值,同時植根於全球銀行監管的嚴謹紀律。

與替代性或傳統轉帳方式相關的術語,應在銀行基礎設施的脈絡下理解。此類術語或用以描述通訊渠道、內部處理方式或過往慣例,但並不取代對受規管機構、認可支付系統及正式結算程序的要求。

任何轉帳,無論名稱為何,最終均須在既有金融體系內處理、清算及對帳。

如欲進一步了解如何將資金轉入您在本行開立的帳戶,請聯絡 Marie Mayer。