SWIFT

SWIFT 轉帳及 MT 與 MX 報文通訊

SWIFT(環球銀行金融電信協會)是一個安全的報文網絡,使銀行等金融機構能夠收發有關金融交易的標準化報文,例如付款指示及確認。SWIFT 不持有帳戶,亦不轉移資金;其功能僅在於提供一個安全可靠的資訊交換平台。

一般 SWIFT 匯款採用一系列標準化的訊息類型,即 MT(Message Type)訊息。這些訊息具有預先定義的格式和欄位,確保金融機構能夠輕鬆理解並處理其所載資訊。

MX(ISO 20022)電文是以 XML(可延伸標記語言)為基礎的新一代金融電文標準,格式更為豐富且結構化,可實現更完善的資料交換並提升直通式處理水平。MX 電文正逐步取代 SWIFT 網絡中的 MT 電文,旨在提供更佳的互通性與資料處理能力。

傳統 SWIFT 匯款數十年來一直是國際支付的支柱,但亦存在若干局限,包括透明度有限、處理時間較長及數據欠缺結構化。

Swift 103+ STP(直通式處理)

Swift 103+ STP 為針對直通式處理(STP)而優化的傳統 MT 格式;自並行期結束後,其功能已由 pacs.008 STP 使用指引取代。STP 使整個支付流程自發起至最終結算均可以電子方式完成,無需人工介入。

其他特點：

1. 標準化格式:須嚴格遵守標準化格式,以減少差錯及延誤。
2. 自動化處理:交易自動處理,確保處理更快捷、更高效。
3. 減少人工介入:將人工輸入及核對降至最低,從而減少錯誤與延誤的風險。
4. 更快結算:交易結算速度較傳統方式更快。

直通式處理(STP)的考量事項:

1. 準確輸入資料:資料必須準確輸入,以免造成延誤或遭退回。
2. 遵守格式要求:銀行必須確保嚴格遵循 103+ STP 的格式要求。
3. 軟件及系統:銀行須具備適當的軟件及系統,以有效處理直通式處理(STP)

必須區分訊息傳遞與結算。SWIFT 在機構之間傳送結構化金融訊息,但其本身並不轉移資金或持有結餘。SWIFT 確認(包括 pacs.008 訊息)僅在其對應於參與機構銀行系統內實際處理並完成對帳的交易時方為有效。

任何未經機構核實而單獨出示的 SWIFT 文件、螢幕截圖或訊息,均不應視為已完成結算的證據。

SWIFT gpi 轉帳。

SWIFT gpi(全球支付創新):

SWIFT gpi 於 2017 年推出，旨在改善傳統 SWIFT 轉帳的局限，提升跨境支付的速度、透明度及可追蹤性。SWIFT gpi 運用現有的 MT 及 MX 報文格式以優化支付服務。SWIFT gpi 的主要特點包括：

• 更快的支付:gpi 簡化了流程,並在銀行之間建立更嚴格的服務水平協議(SLA),從而縮短交易時間,通常可在數分鐘甚至數秒內完成。
• 付款追蹤:gpi Tracker 可即時追蹤交易,提升透明度並減少人工查詢。
• 費用透明度:銀行可事先向客戶提供交易費用資訊,以便客戶作出更佳決策。
• 更豐富的數據:gpi 支援更詳盡且結構化的資訊交換,有助改善對帳作業及監管合規。

SWIFT gpi 針對傳統 SWIFT 匯款的局限,透過端到端追蹤、更快的處理速度及更豐富的數據,強化跨境支付。

非 SWIFT gpi 參與者的主要參數

當非 SWIFT gpi 參與機構(例如未直接加入 gpi 的銀行或金融機構)向 gpi 參與銀行發出付款指示時,該 gpi 銀行可將其轉換為所需的 SWIFT 報文格式(客戶貸記轉帳使用 pacs.008,備付轉帳使用 pacs.009 COV,金融機構貸記轉帳使用 pacs.009)。此項轉換使付款得以在 gpi 網絡內處理及追蹤,惟前提是該指示須包含足夠資料以填寫必填欄位,並符合 gpi 規則,例如端到端可追蹤性。

非 gpi 參與者通常透過本地支付計劃、API 或舊有格式提供上述參數,並由 gpi 銀行處理 gpi 特有的附加項目(例如在未提供 UETR 時予以生成,惟非 gpi 機構傳遞該項目屬可選)。具體要求可能因司法管轄區、貨幣及雙邊協議而異,但核心參數源自 CBPR+(跨境支付及報告增強版)指引及 ISO 20022 標準。自 2025 年 11 月 22 日並行期結束後,跨境支付指示均以 ISO 20022 格式交換;下文所列舊有 MT 欄位參照僅供參考。
1. 當事方識別(付款人及收款人資料)
此等資料用於識別發起人及受益人,確保符合 FATF 第 16 號建議有關「旅行規則」的要求。

• 債務人/匯款客戶:全名、結構化地址(街道、城市、郵遞區號、國家)及帳戶識別資料(例如 IBAN 或帳號)。在原有的 MT 103/MT 202 COV 中,對應欄位 50a;在 pacs.008/pacs.009 中,則對應 <Dbtr> 及 <DbtrAcct>。
• 債權人/受益客戶:全名、結構化地址及帳戶識別資料。對應原 MT 103/MT 202 COV 中的第 59a 欄位;於 pacs.008/pacs.009 中對應 <Cdtr> 及 <CdtrAcct>。
• 最終債務人/債權人(如適用):若與主要當事方不同,請列明其詳細資料,以提高透明度(屬選填,惟建議提供,以便進行 gpi 追蹤)。對應 pacs.008/pacs.009 中的 <UltmtDbtr>/<UltmtCdtr>。

必要性:有助確保準確的路由處理及合規檢查;資料不完整可能導致退回或延誤。

2. 代理行及路由資訊
列明付款鏈中涉及的金融機構。

• 付款人代理行(Debtor Agent):發送銀行的 BIC(銀行識別碼)或其他識別碼。對應原 MT 103 的第 52a 欄;於 pacs.008/pacs.009 中為 <DbtrAgt>。
• 收款代理行:收款銀行的 BIC。對應原 MT 103/MT 202 COV 的 57a 欄位;於 pacs.008/pacs.009 中為 <CdtrAgt>。
• 中介代理行(如已知):任何代理行之 BIC(最多三層)。對應原 MT 電文之第 56a 欄;於 pacs.008/pacs.009 中為 <IntrmyAgt1-3>。
• 指示/受指示代理行:鏈條中直接發送方/接收方的 BIC。屬選填項目,有助於序列式或補償式(cover)付款方式的處理。
• 先前指示代理行(如適用):如屬多層轉匯鏈,最多可列明三家先前代理行。

必要原因:確保中介機構路由正確;在 pacs.009 COV 中,為求精確,應使用 BICFI 而非名稱。

3. 交易詳情
結算所需的核心財務要素。

• 金額及貨幣:銀行間結算金額及 ISO 4217 貨幣代碼(例如 USD、EUR)。對應原 MT 103/MT 202 COV 的 32A 欄位;於 pacs.008/pacs.009 中為 <IntrBkSttlmAmt>。
• 指示金額(如有不同):扣減前的原始金額。
• 銀行間結算日:結算的起息日。對應 MT 報文中欄位 32A 的一部分;於 pacs.008/pacs.009 中為 <IntrBkSttlmDt>。
• 結算方式:註明經由 RTGS(CLRG)、頭寸補償方式(COVE)或代理行(INDA/INGA)結算。無直接對應的 MT 電文,惟已隱含於內。

必要原因:界定價值轉移內容;所有格式均為必填項。

4. 參考及追蹤識別碼
用於確保可追溯性,尤其適用於 gpi。

• 端到端識別碼:用以連結整條交易鏈的參考編號(例如發票或交易編號)。見 pacs.008/pacs.009 中的 <EndToEndId>。
• 指令識別碼:發送方的參考編號(於 MT 中限 16 個字符)。對應舊有 MT 的欄位 20;於 pacs.008/pacs.009 中為 <InstrId>。
• 唯一端到端交易參考編號(Unique End-to-End Transaction Reference,UETR):用於端到端追蹤的 UUID。於 pacs.008/pacs.009 中屬必填項目;於原有的 MT103/MT202 中則載於第 121 欄;如發起渠道未提供該編號,則由鏈中首家 SWIFT 銀行生成。
• 交易識別碼:額外的內部參考編號。

必要原因：支援 gpi 追蹤及關聯（例如 pacs.008 與 pacs.009 COV）；UETR 是實現通用確認的關鍵。

5. 用途及服務資訊
劃分付款類別。

• 用途代碼及類別用途代碼:標示交易性質的 ISO 代碼(例如以 SALA 表示薪金)。在若干匯款通道中屬必填項目;於 pacs.008 中為 <Purp> 及 <CtgyPurp>。
• 服務級別代碼:用以識別 gpi 服務(例如 G001 代表 gpi 客戶貸記轉帳);非 gpi 銀行除非另有約定,不應納入 gpi 專用代碼。對應 MT 的 Field 23E;在 pacs.008/pacs.009 中對應 <SvcLvl>。
• 本地票據代碼:適用於特定機制(例如集團內部轉帳)。

必要性:確保合乎監管規定並獲得處理優先權;在 ISO 遷移之後,此項要求日益成為強制性規定。

6. 匯款及附加指示

• 匯款資訊:非結構化(最多 140 個字元)或結構化(例如發票明細)。對應原 MT 103 中的第 70 欄;在 pacs.008/pacs.009 中對應 <RmtInf>。
• 代理行指示:例如 /REC/ 表示收款方、/ACC/ 表示帳戶,或電話指示(PHOB)。對應原 MT 報文的第 72 欄;在 pacs.008/pacs.009 中則對應 <InstrForNxtAgt>/<InstrForCdtrAgt>。
• 結算時間指示:所要求的時間(例如以 CLSTm 表示 CLS 時間)。

必要原因:提供背景資料及處理指示;對 pacs.009 COV 中的補償付款方式不可或缺。

7. 監管及合規數據

• 監管報告:代碼或詳情(例如稅務識別號碼、CRED/DEB 等報告指示符)。對應 MT 報文之第 77B 欄;於 pacs.008/pacs.009 中則對應 <RgltryRptg>。
• 退回原因代碼(適用於退回款項時):例如 AC04 表示帳戶已結清,於 pacs.004 中與原始報文相關聯。

所需原因:符合 AML/KYC 及申報義務;在受監管的匯款通道中屬強制性要求。

就最佳作業慣例而言,非 gpi 參與行應妥善建構資料,以避免在 MT 至 MX 轉換過程中發生資料截斷,並就特定需求諮詢 gpi 成員銀行。若付款涉及覆蓋付款方式,則各訊息所載之基礎客戶資料必須一致(例如由 pacs.008 至 pacs.009 COV)。

SWIFT gpi 中的支付訊息

在 SWIFT gpi(Global Payments Innovation)框架下,原始付款電文(例如客戶匯款所用的 pacs.008,或覆蓋匯款所用的 pacs.009 COV)一經發送即視為不可更改。收款銀行無法直接變更這些電文的內容,因為 SWIFT 電文的設計旨在於整個付款鏈中維持完整性及可稽核性。任何更改、更正或取消,均須透過另行發送的後續電文、經由 gpi Tracker 發出的狀態更新,或 gSRP(gpi Stop and Recall Payment,gpi 止付及召回付款)等專用服務處理。此舉確保可藉由唯一端到端交易參考編號(UETR)實現端到端的可追溯性。

然而,收款銀行(通常擔任債權人代理行或中介機構)可回應發送方提出的更改請求,或採取行動而實際導致付款結果有所變更(例如退回或暫緩處理)。在特定條件下,收款銀行亦可要求發送方作出澄清或修訂。上述程序受SWIFT規則手冊、市場慣例指引(例如來自支付市場慣例小組(Payments Market Practice Group,PMPG)的指引)及監管規定所規範,並以自動化、透明度及防範欺詐為優先。

收款銀行要求或促成更改的條件
當原始付款無法按指示處理時,收款銀行可要求更改(例如更正資料)或採取暗示需要更改的行動。此舉通常透過查詢訊息(例如 MT 195/199)或對發送方所提出請求的回覆進行。主要條件包括:

• 付款資料有誤:若出現不準確之處,例如收款人帳戶有誤(如帳戶已關閉 – 代碼 AC04)、貨幣錯誤(代碼 CURR)、代理行路由錯誤(代碼 AGNT)或技術問題(代碼 TECH),收款銀行可將該筆付款暫時扣留,並要求匯款人提供更正資料或重新發出付款指示。此做法可避免直接退回,同時讓問題得以解決。
• 無法入帳:根據代碼 CUTA(Cancel Upon Unable to Apply,無法入帳時取消),若因資料不符(例如姓名/帳號不一致或資料不足)而無法將款項入帳,收款銀行可要求發送方提供取消或修改的詳情,以作補正。
• 涉嫌欺詐或未經授權交易:如屬欺詐(代碼 FRAD),收款銀行可自行發現問題,並無須待付款方請求即主動啟動退款。收款銀行亦可回應付款方的召回請求,將款項隔離,並在款項已入帳時要求提供彌償(代碼 INDM),以便在退回前降低風險。
• 重複或不當付款:DUPL(重複付款)或 UPAY(不當付款)等代碼,可讓收款銀行在交易有誤或缺乏正當理由時作出標記,並要求撤銷。
• 監管或合規問題:如該筆付款違反當地法律、制裁規定或 AML 要求(代碼 LEGL),收款銀行可拒絕或扣留該款項,並要求發款人提供補充文件或作出修訂。
• 客戶或受益人的決定：如受益人拒絕該筆付款（代碼 CUST 或 NOAS——受益人無回應），收款銀行可將款項退回並通知匯款方，並可能要求確認相關更改。
• 待處理決議:對於待處理個案(代碼 PDCR),例如等待扣帳授權(RQDA)或下一代理行回覆(PTNA),收款銀行可暫緩處理該筆付款,並要求提供進一步指示或修改,以便繼續處理。

在所有情況下,請求均須以可自動化處理的方式編製(例如包含 UETR、原始參考編號如欄位 20/32A/50/59,以及報文欄位 79 中的特定代碼),以支援直通式處理。如款項已入帳,雙方可能須簽訂賠償協議;接收銀行並無義務接受有關請求,但須優先處理緊急請求(例如涉及欺詐的請求)。

涉及的流程

• 對付款方發起之撤回請求的回應:付款方(債務人代理行)通常透過 gSRP 服務,以 MT 192/292(或 ISO 20022 的對應訊息,如 camt.056)發起撤回請求,並以串行或直接方式發送予收款銀行。收款銀行須立即確認收悉,並使用 CNCL(已取消)、RJCR(附理由拒絕)或 PDCR(待處理)等代碼,以 MT 196/296(若為結構化訊息則使用 MT 199/299)作出回應。如獲接受,款項將透過 pacs.004(付款退回)退還。
• 收款銀行的自主行動:若內部發現欺詐,收款銀行可使用附有結構化詳細資料的 pacs.004 退回資金,並透過 Tracker 通知,以便即時更新狀態。
• 修改/澄清請求:收款銀行透過查詢類電文(例如 MT 195/295)請求變更,例如補充詳細資料。此情況常見於暫緩處理的付款。
• 追蹤器整合:所有操作均即時更新 gpi Tracker,可透過 API 或圖形介面存取,確保各方均可掌握進度。gpi 成員須遵守 gCCT(客戶貸記轉帳)、gCOV(覆蓋付款)及 gSRP 的強制性規則手冊。
• 局限與成功因素:修改並無保證;成功與否取決於付款階段(入帳前較易處理)、受益人的配合及司法管轄區。如款項已入帳,退回須經受益人同意或提供賠償保證。法規始終優先於指引。

上述做法主要適用於 gpi 成員，但非 gpi 銀行亦可透過閘道參與。如需最新詳情，請查閱 SWIFT 官方規則手冊，因相關流程持續演進（例如隨 ISO 20022 遷移而變化）。

SWIFT gpi 中訊息傳遞與結算的分離

SWIFT gpi 主要透過訊息傳遞(例如用於客戶轉帳的 pacs.008、用於金融機構轉帳的 pacs.009 等 ISO 20022 格式,或舊式的 MT103/MT202)處理付款指令及追蹤,而資金的實際流動則在結算層面另行進行。結算通常透過代理銀行關係(往來帳戶(Nostro)/來帳戶(Vostro))、雙邊淨額結算,或清算及結算機制(CSM)完成,例如即時全額結算(RTGS)系統(如歐洲的 T2〔前稱 TARGET2〕、美國的 Fedwire 或英國的 CHAPS)。gpi 追蹤器可即時顯示訊息狀態,但資金轉移仍依賴上述底層系統。

跨境支付指令的並行期已於 2025 年 11 月 22 日結束:MT 103 及 MT 202 等支付指令已由 pacs.008 及 pacs.009 等 ISO 20022(MX)報文取代,其他 MT 類別則將於稍後日期陸續停用。以下說明退回及暫扣款項解除在帳戶、清算及結算層面的處理方式。

款項如何在帳戶、清算及結算層面退回
退款於召回請求成功(透過 gSRP——gpi 止付及召回服務)或經獨立發現(例如欺詐、錯誤)後啟動。gSRP 使用發送方發出的 camt.056(付款取消請求),並以 camt.029(調查結果)回覆。一經接受,資金退回將透過一項新的付款指示執行,使資金流向逆轉,即自收款銀行帳戶扣款,並沿鏈路逐級回存。此舉並非更改原始報文,而是另一項獨立交易。

主要結算方式與退回流程
結算方式決定退回款項的處理方式:

• CLRG(透過市場基礎設施清算):透過 RTGS 或 CSM(例如經由中央銀行)進行結算。退回款項使用 pacs.004 指示市場基礎設施借記接收代理行的帳戶並貸記前一代理行的帳戶,通常即時或於當日完成。
• INGA(指示代理行先行結算):發送方於發出報文前先行結算資金。經 pacs.004 退回之款項,於結算後自被指示代理行之帳戶扣除。
• INDA(受指示代理行於收訊時結算):接收方於收到訊息時結算。如未結算,則透過 pacs.002 拒絕(無資金移動);如已結算,則透過 pacs.004 退回。
• COVE(覆蓋匯款方式):適用於附帶覆蓋匯款(pacs.009 COV)的大額付款。退回款項沿相反路徑辦理:由受益人代理行經 pacs.004 退回至各中間行,並相應借記或貸記代理行帳戶。

結算層面的退回流程逐步說明

1. 發起及接受:發送方提出撤回請求(例如透過附有 UETR 的 camt.056)。接收方作出回應(camt.029),若資金可用或尚未記入受益人帳戶,則予以接受(於入帳前較為容易)。若已入帳,則可能須取得受益人同意或賠償保證。

2. 資金退回指示:接收方發出 pacs.004(付款退回)或附有退回代碼(例如 RETN)的傳統 MT 103/MT 202 報文。該報文包括:

• 原始參考編號(UETR、端到端識別碼、指示識別碼)。
• 角色互換:原債權人成為債務人;原債務人代理行成為債權人。
• 結算詳情:原銀行同業結算金額/日期、匯率(如涉及外匯)、費用(如已扣除)。
• 退回原因代碼(例如:AC04 表示帳戶已結清,FRAD 表示欺詐)。
• 結算帳戶欄位(如原始報文中有)用以指明入帳帳戶。

3. 結算執行:

• pacs.004 會觸發從收款銀行的往來帳戶(Nostro)/來帳戶(Vostro)(於前一代理行或金融市場基礎設施機構開立)扣帳。
• 資金採用相同的結算方式(例如 CLRG 中的 RTGS 轉帳),沿鏈逐層回撥入帳。
• 如為部分退回,請於「附加資訊」欄註明「PART」及按比例計算的金額。
• 追蹤器即時更新狀態(例如「已退回」),可透過 API 或圖形介面查看。

4. 最終入帳:原匯款人帳戶入帳,通常須扣除費用。若經 CSM 處理,結算具原子性;在雙邊安排下,則可能涉及日終淨額結算。

5. 退回後通知:使用 camt.053/054(帳戶報表/借貸記通知)確認分類帳已更新。不再就「退回的退款」發出 pacs.004:請改用查詢。
退回在可行時以自動化方式處理,但如涉及合規或資金遭凍結,則可能需要人工介入。資金追回並無保證,關鍵取決於召回指示發出的速度及資金是否已入帳。若尚未結算(例如結算前遭拒絕),則無資金移動:請改用 pacs.002。

被暫扣的付款如何在帳戶、清算及結算層面獲准放行(綠燈放行)

當付款因故無法即時處理(例如因錯誤、合規檢查或有待澄清)時,即會被擱置,處於未結算的「待處理」狀態,直至問題解決前不會借記或貸記任何資金。gpi Tracker 會顯示「On Hold」或「Pending」(例如 PDCR 代碼)等狀態,並透過查詢報文(MT 195/199 或 camt.029)進行處理。

導致凍結的情形

• 資料不符(例如帳戶與戶名不一致——CUTA 代碼)。
• 監管檢查(例如制裁——LEGL 代碼)。
• 等待受益人回覆(NOAS 代碼)或扣帳授權(RQDA)。
• 受益行的離線時段或批量處理。

結算層面的放行程序
1. 暫扣通知:接收方發出 pacs.002(狀態更新)或附有待處理代碼的 MT 199,如屬部分結算(例如採用頭寸補償方式),則將資金暫存於暫記或託管帳戶。
2. 解決:發送方提供修訂或澄清(例如透過 MT 195 回覆或 camt.029)。如問題獲得解決,接收方即「放行」,處理原始指示。
3. 結算執行:

• 原 pacs.008/pacs.009 自暫停狀態解除並予以放行。
• 資金按指定方式結算:先借記付款方帳戶,再貸記收款方帳戶(例如透過CLRG的RTGS系統),最後貸記受益人帳戶。
• 受益人環節(收款銀行至最終客戶)往往是延誤發生之處,在設有資本管制或基礎設施有限的市場尤為如此。
• 追蹤狀態更新為「已入帳」或「已完成」,並由 pacs.002(付款狀態報告)確認。

4. 如未予放行:如仍未解決(例如逾時後),則按上述方式透過 pacs.004 退回,或以 pacs.002 拒絕(不予結算)。

gpi 規則要求在可行情況下於當日入帳;Swift 於 2018 年報告,近 50% 的 gpi 付款在 30 分鐘內入帳,幾乎 100% 在 24 小時內入帳。資本管制或銀行離線時段等因素可能延長資金滯留時間,但 gpi 強調透過自動化將其降至最低。

SwiftNet Instant

SwiftNet Instant。這是一個全天候運作的實時、低延遲訊息平台，支援清算及結算機制（CSM）與其參與者之間即時支付流的安全交換。

客戶可透過其現有的 Swift 連線及安全基礎設施（包括 VPN 設備、專線及硬體安全模組）連接 SwiftNet Instant。與銀行資訊科技環境的整合則透過 Alliance Gateway Instant（AGI）實現。

即時支付鏈上的所有參與方均可使用 AGI 及 SwiftNet Instant 訊息服務。應用場景包括：由疊加服務發起付款、間接成員與擔保成員之間的通訊，或企業收取付款確認。

SWIFT Instant 與各國境內即時支付系統相連,採用 ISO 20022 標準,實現境內及跨境交易的即時處理。這些系統體現了金融業持續推動支付流程現代化與簡化的努力。

SWIFT 直接扣款

SWIFT 體系下的直接扣款是一種支付方式,使企業及個人得以跨多個國家,以多種貨幣自付款人銀行帳戶收取款項。有別於專為 SEPA 區域設計、僅限歐元交易的 SEPA 直接扣款,SWIFT 體系下的直接扣款適用於全球,並支援多種貨幣。

在 SWIFT 系統內啟動直接扣帳交易的程序,通常包括以下步驟:

1. 債權人與債務人之間的協議:債權人與債務人之間須已訂有協議,其中載明直接扣款交易的條款及細則。該協議亦可能涉及設立授權書或授權,使債權人得以從債務人的銀行帳戶收取款項。
2. 電文交換:債權人銀行向債務人銀行發送 SWIFT 電文以發起直接扣帳——在 ISO 20022 中為 pacs.003(客戶直接扣帳)或 pacs.010(金融機構直接扣帳),前身為 MT 104 或 MT 204。該電文載有交易詳情,例如金額、貨幣、債務人帳戶資料及其他必要資訊。
3. 核實與授權:付款人之銀行核實交易詳情,查核付款人帳戶內之資金是否充足,並確認該筆交易之授權。如一切無誤,付款人之銀行即從付款人帳戶扣款。
4. 資金轉移:資金透過代理帳戶或清算及結算系統,在債務人銀行與債權人銀行之間完成結算。
5. 確認:收到款項後,債權人的銀行向債權人發出確認訊息,通知其直接扣款交易已成功完成。

於 SWIFT 系統內發起直接扣帳交易的先決條件如下:

1. 銀行帳戶:債權人與債務人均須在屬於 SWIFT 網絡的金融機構開立銀行帳戶。
2. 協議與授權:債權人與債務人之間須預先訂立協議並取得授權(委託),方可進行直接扣款交易。
3. SWIFT 報文格式:債權人及其銀行須使用適當的報文格式:以 pain.008 發起直接扣款,銀行之間則使用 pacs.003 或 pacs.010。
4. 銀行費用:債權人及債務人應留意 SWIFT 系統內直接扣款交易所涉及的任何費用,有關費用可能因銀行及國家而異。

銀行間 SWIFT 電文中的 RMA

在銀行及金融業,銀行之間安全而高效的通訊至關重要。SWIFT(環球銀行金融電信協會)在此扮演關鍵角色,承載大部分國際銀行同業電文。確保此等通訊安全性及選擇性的關鍵組成部分,正是關係管理應用程式(RMA)。

何謂 RMA?

關係管理應用程式(Relationship Management Application,RMA)是一款 SWIFT 軟件應用程式,金融機構可藉此界定哪些交易對手可向其發送 SWIFT 報文,並確保 SWIFT 網絡通訊僅限於經認證的用戶。RMA 是銀行同業通訊管理中的基本安全層,可過濾未經授權的報文,降低欺詐風險。

RMA 的重要性

對於 IFB 等從事國際金融業務的銀行而言,RMA 工具不可或缺。它不僅強化了安全協議,亦確保符合全球銀行監管規定。透過管理哪些機構可向其發送電文,銀行得以防止未經授權的資訊請求及金融指令,從而保護自身及客戶的利益。

RMA 的運作方式

RMA 流程包含以下幾個主要步驟:

1. 建立 RMA 關係:兩家銀行在開始透過 SWIFT 交換資訊之前,必須相互同意建立 RMA。此協議猶如數位握手,代表雙方互信並同意進行通訊。
2. 交換密鑰:各銀行透過 RMA 應用程式發出 RMA 授權,由對手方接受。RMA 取代了先前的雙邊密鑰交換(BKE);訊息本身則透過 SWIFTNet PKI(公開密鑰基礎設施)驗證。
3. 配置 RMA 設定:各銀行使用 RMA 工具配置權限,並指定接受對方銀行的哪些類型報文。此設定可作概括分類,亦可細化至特定報文類型及子類別。
4. 啟用與監控:RMA 設定完成並啟用後,銀行即可監控收到的報文是否符合既定權限。如業務需要或基於安全考量,RMA 亦提供修改或撤銷權限的工具。

實務應用

對於專注為高淨值個人及企業實體提供投資及財富管理服務的 IFB 而言，RMA 帶來若干益處：

• 強化安全:透過管控訊息流量,IFB 可保障客戶交易及敏感資料免遭未經授權的存取。
• 營運效率:與受信任實體之間簡化的通訊,有助加快合法電文的處理,縮短回應時間並提升客戶滿意度。
• 監管合規:RMA 有助於遵守國際銀行業規管要求,該等要求嚴格管控資訊交換,以防範洗錢及欺詐等金融犯罪。

RMA 與 MT799。在通道允許的情況下,銀行可使用 MT799 請求或協調 RMA 關係。RMA 授權本身須在 RMA 系統中授予;單憑 MT799 不會啟動任何權限。倘若缺少 MT799 所需的 RMA 授權,則無法透過直接發送 MT799 而繞過該授權。此時,相關安排須透過 Swift 關係管理入口網站的 RMA 通訊功能(該功能專為在交換授權之前與交易對手協調而設計)或其他獲准的通道商定。因此,「透過 MT799 辦理 RMA」可用以描述隨附的銀行函電往來;技術層面的 RMA 授權則屬獨立的步驟。

簡而言之

對 IFB 而言,有效落實 RMA 不僅是技術要求,更是其全球營運中的策略性資產。這既彰顯本行對安全及監管合規的承諾,亦提升其通訊網絡的效率。隨著國際金融環境不斷演變,RMA 等工具對於致力維持最高營運誠信及客戶服務標準的銀行而言,仍然不可或缺。

RMA 構成安全且具選擇性的銀行間通訊的基石,確保經由 SWIFT 網絡交換的每一則報文均符合最高安全標準並獲得完整認證。對 IFB 等銀行而言,了解並管理 RMA 對於保障自身營運、建立與全球合作夥伴之間的信任至關重要。

Swift 數位區塊鏈金融指令

2025 年 9 月,Swift 宣布已聯同逾 30 家金融機構開始設計及開發共用數位分類帳。2026 年 7 月 9 日,Swift 宣布該分類帳已可供初步使用,17 家銀行正準備試行代幣化存款的實際交易:ANZ、BNP Paribas、BNY、Citi、DBS、First Abu Dhabi Bank、FirstRand、HSBC、Itaú Unibanco、Lloyds、Mashreq、MUFG、OCBC、Standard Chartered、UBS、UOB 及 Wells Fargo。首項應用將集中於實現銀行之間即時、全天候(24/7)的跨境指令——這是對國際交易處理架構的重要提升。

首個概念原型由 Consensys 協助建立。該分類帳旨在成為機構之間金融指令的安全、不可篡改的實時登記冊,將記錄、排序及驗證交易報文,並透過智能合約執行營運及合規規則。互通性是核心原則:該分類帳將與現有及新興基礎設施相連,同時維持 Swift 一貫的韌性、信任及對監管的遵循。

正如 Swift 行政總裁 Javier Pérez-Tasso 所說明:
「將共享帳本與 Swift 現有的報文、API 及 ISO 20022 相結合,構建出更為強大的架構——可在交易流程之初即嵌入風險、管控及合規要求,同時以 Swift 向來著稱的信任、安全、韌性、可擴展性及卓越營運水平,實現全天候即時的銀行間跨境指令。一切均符合我們一貫秉持的負責任創新之道。」

基礎設施的延伸

共享帳本是對 Swift 現有支付網絡的補充,並非取而代之。其設計旨在擴展協調與互通能力,確保金融機構能以更快的速度、更高的可預測性,在真正的全球規模上交換指令。

在 Sibos 大會上,Pérez-Tasso 強調此雙軌並行的做法:
「金融基礎設施必須持續專注於卓越營運、監管合規及治理等基本要務,同時亦須為未來做好準備。而在 Swift,我們的做法是沿兩條並行軌道推進創新。」

跨業協作

來自 16 個國家的金融機構自始即參與共享帳本的設計、治理及發展路徑的塑造。這項集體努力彰顯了一項共識:推進全球銀行間指令基礎設施的發展,需要規模與協作。

展望未來

共享帳本是 Swift 早前數碼資產試驗的自然延伸,亦屬其致力於公共與私有網絡互通性的更廣泛承諾之一。這將使受監管的代幣化價值與傳統工具得以在各系統之間順暢流轉。

佩雷斯-塔索(Pérez-Tasso)概述其願景:
「這是一個面向未來的強大平台,日後更可帶來更深遠的變革。」

常見問題

何謂 Swift 區塊鏈共享帳本？
一種區塊鏈基礎設施，為機構之間的金融指令提供共享的即時記錄，實現持續、合規的跨境處理。

適用對象
必須提供更快速、更透明之交易指示，並為數碼化未來作好準備的銀行及金融機構。

有哪些優勢?

• 指示的即時可視性與排序
• 透過智能合約實現自動化合規
• 傳統網絡與數碼網絡之間的互操作性
• 受監管代幣化價值流動的安全處理

這如何與 Swift 平台配合?
它擴展了 Swift 值得信賴的基礎設施,在維持穩健性、安全性及合規的同時,嵌入數碼指令功能。

首個應用情境為何?
實時、全年無休的跨境銀行同業交易指令。

參與機構有哪些?
來自16個國家的逾30家金融機構參與了方案設計;17家銀行正試行首批實際交易。

何時可供使用?
Swift 宣布該帳本已於 2026 年 7 月 9 日備妥,可供初步使用。試點銀行在受控的上線階段進行首批實際交易;最終結算仍透過現有系統進行。功能及可用範圍將於其後逐步擴大。

如欲進一步了解如何透過代理銀行體系轉移資金,請聯絡本行代理銀行業務主管 Amri Elarisse 先生。