本頁為便利而提供的譯本,以英文版本為準。閱讀英文版

其他轉帳方式

IP/IP 及 IPZip 轉帳

在 IFB 啟用 IPIP、IPZip 服務

IPIP 服務將於客戶帳戶處於良好狀態後,按客戶要求啟用:

其維持最低結餘,
展現一貫穩定的財務業績,並且
與合法商業活動相符。

此外,該帳戶必須具備

並無尚未解決的合規問題,及
所有交易均須遵守國際金融法規。

最終啟用須經本行合規及風險管理團隊內部審核與批准。

報文並非資金

90 秒說明為何沒有結算,任何 SWIFT 訊息、電傳或伺服器都無法劃轉資金。

以 VL1 驗證文件 →

收到付款訊息、單據或確認書?請先經核實,方可據以信賴。

本行的 IPIP 及 IPZip 服務

我們向經挑選的高淨值個人及信譽卓著的企業客戶提供 IPIP 及 IPZip 服務,尤其注重審慎、保密及機構誠信。

所有 IPIP 及 IPZip 交易均僅在已完全融入國際銀行體系的銀行之間進行,不僅確保經認證的 IPIP 電文得以安全交換,亦確保資金得以有效及時結算。缺乏此等融入程度的交易對手或許能夠傳送電文,但本質上無法完成資金結算。

根據經驗,本行收到的 IPIP 交易中,逾 86% 來自非銀行實體,或來自不具備發送資金能力的銀行。

相對而言,本行可處理不設金額上限的交易,惟僅須嚴格核實發起機構,並確認其具備可予證明的交收能力。

驗證機構及參與方無關聯銀行

IP 對 IP(IPIP)

IP 對 IP 轉帳,是指在金融機構或系統之間,利用網際網路協定(IP)位址,轉移代理銀行帳戶中的貨幣或資產、負債及權益,或相關數據的流程之一環。在金融交易中,IP 位址是分配給每一部連接網際網路的裝置的唯一數字識別碼,用於在不同系統之間傳送資訊。銀行業的 IP 對 IP 轉帳,涉及兩個系統憑各自的 IP 位址直接通訊,以完成金融交易;並另行採用特殊的驗證及授權方法,以確保資訊的完整性與安全性。

然而,須注意 IP 對 IP 轉帳在銀行業並不常見,亦不獲推薦,原因包括安全性、可靠性及合規方面的顧慮。以下各點就這些顧慮提供相關背景:

安全性:與 SWIFT 或 ACH 等成熟的銀行網絡相比,IP 對 IP 轉帳的安全性可能較低,後者設有多層安全、加密及驗證機制。兩個 IP 位址之間的直接通訊可能令敏感資料面臨潛在的安全威脅,包括駭客入侵、網絡釣魚或中間人攻擊。
可靠性:採用 IP 對 IP 轉帳並不能保證交易的可靠性,因為銀行業對於基於 IP 的轉帳並無普遍認可的標準或協議。這可能導致交易處理、追蹤及對帳方面的潛在問題。
合規:銀行及金融機構須遵守眾多法規及要求,包括反洗錢(AML)及客戶身分識別(KYC)政策。IP 對 IP 轉帳可能未能符合這些監管要求,可能使相關各方面臨法律及財務風險。

銀行及金融機構並不採用 IP 對 IP 的轉帳方式,而是傾向使用 SWIFT、RTGS 或 ACH/即時支付等既有網絡,以及 ISO 20022 等訊息標準,以促進不同機構之間安全、可靠且合規的資金轉移。

IP 對 IP 貨幣轉帳結構

實際資金轉移:此類協議擅長傳遞報文及指示等交易詳情,但並不促成資金的實際移動。實際資金轉移則必須依賴代理銀行業務、即時全額結算(RTGS)及即時支付(RTP)等系統。

在代理銀行業務中,資金於不同銀行的帳戶之間轉移。
在即時全額結算（RTGS）系統中，資金在各銀行於中央銀行開立的結算帳戶之間轉移。
同樣地,在 RTP 系統中,資金於清算帳戶之間轉移。

這些系統對於貨幣資產的實際轉移至關重要。因此,匯出銀行不僅須具備 IP 對 IP 的能力,亦須與銀行體系實現全面整合。

兩個不同層級:

指令層面及實際資金轉移層面

IPIP 協議

FIX(Financial Information eXchange):證券交易的訊息標準:用於經紀商、交易所與投資者之間的委託、成交及分配。其承載的是交易數據,而非付款資訊。
EBICS(Electronic Banking Internet Communication Standard):企業客戶與其往來銀行之間進行安全檔案交換的標準,主要用於德國、法國、瑞士及奧地利的付款檔案與對帳單傳輸。
全銀(Zengin):全銀系統(Zengin System)是日本的國內銀行間資金轉帳網絡,全銀檔案格式用於國內轉帳及直接扣款。
AS2(適用性聲明 2):一項協議,用於經互聯網以簽署方式安全傳送商業文件(EDI、XML),並以回執確認送達。
SNMPv3(簡單網路管理協定第 3 版):一項用於監控及管理網路設備的協定,具備身分驗證與加密功能。該協定用於管理基礎設施,並不承載交易。
Kerberos:一種網絡身份驗證協議,透過受信任伺服器簽發的票據,使客戶端與服務得以相互證明身份。
OAuth 2.0:一項關於委託授權的開放標準:應用程式獲發有限度的存取權杖,而無需取得用戶密碼。大多數開放銀行應用程式介面均以此為基礎。
基於 TLS 的 LDAP:對目錄服務的受保護存取;目錄服務存放用戶身份及存取權限。
基於 SSH 的 SFTP 及 SCP:伺服器之間的加密檔案傳輸及複製,廣泛用於支付及對帳單檔案。

上述各項協議均用於保護數據交換或系統存取的安全。在涉及貨幣、銀行資產、負債及權益轉移的 IPIP 交易中,上述協議屬必要條件,但不足以完成金融交易:

向本行進行 IPIP 資金轉帳

為減輕在 pacs.008 經由 IPIP 而非 SWIFT 發送予本行時可能產生的部分合規疑慮,閣下可考慮請匯出銀行在代理銀行對代理銀行的資金傳送所使用的 pacs.009 COV 中,於格式允許的情況下,納入以下補充資料:

匯款人資料:提供匯款人的詳細資料,與 MT103 第 50 欄類似,可包括姓名、地址及帳號。
受益人資料:填寫受益人詳情,對應 MT 103 中的第 59 欄,應包括受益人名稱、地址及帳號
付款目的:明確說明交易原因,此舉可在一定程度上減輕反洗錢(AML)方面的疑慮。
監管申報資訊:如貴司所在司法管轄區有所要求,請載明用於監管申報的代碼或識別碼。
提述 IPIP pacs.008:明確註明該 pacs.009 COV 與某一 IPIP pacs.008 相關聯,可為中間銀行提供背景資訊。
聯絡資料:請提供負責該筆付款的合規部門或交易經理的具體聯絡方式,以便收款銀行在需要時即時查詢。
特別處理指示:向收款銀行提供的任何額外指示,以利識別及妥善處理所轉移的資金。
收費及費用資訊:在沒有 SWIFT pacs.008 的情況下,明確交易相關費用由何方承擔,有助避免誤解。
附加識別碼：包括可將 pacs.009 COV 與 IPIP pacs.008 相關聯的任何其他交易識別碼，例如發票編號或內部交易編號。

合規說明

在 pacs.009 COV 中加入額外資訊，未必能完全緩解合規風險，尤其是通常透過 SWIFT pacs.008 訊息處理的 AML 及 CFT（打擊資助恐怖主義）核查；並須確保經修改的 pacs.009 COV 仍符合適用標準及銀行同業協議。

銀行通訊伺服器與總帳/帳戶伺服器之主要差異

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

通訊伺服器

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

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

分類帳/帳戶伺服器

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

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

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

在當代銀行體系中,上述功能往往整合運作,由安全的行內通訊協定與分類帳管理系統協同配合。此項整合確保全行金融生態系統即時更新並保持一致,從而提升效率與安全。許多銀行混合採用本地部署與雲端伺服器,以兼顧安全、合規及可擴展性之要求。

銀行之間可以轉移哪些項目?

銀行資產:

現金及現金等價物:指可即時或近乎即時動用的資金,包括實體現金、存放於其他銀行的存款,以及國庫券等高流動性證券。
投資/證券:此為銀行為賺取回報而投資的金融工具,例如政府債券及公司債券、股票及其他證券。
貸款及墊款:此為銀行向客戶提供的資金,並產生利息收入,可包括個人貸款、按揭貸款、商業貸款、信用卡餘額及透支。
固定資產:指本行擁有的有形財產,例如樓宇、土地、設備及傢俱。
無形資產:包括軟件、專利、商標及商譽等非實物資產。
其他資產:此類別可包括應收應計利息、遞延稅項資產及衍生金融工具等。

銀行負債:

存款:指個人及企業存放於銀行的資金,包括支票帳戶、儲蓄帳戶及定期存款。此等款項屬負債,因為銀行有責任應要求或於指定到期日向存款人返還該等資金。
借入資金:此類資金是銀行向其他金融機構、中央銀行借入,或透過發行債務證券所籌集的款項。
債務證券:此類證券為本行發行以籌集資金的債券或其他形式的債務工具。本行有義務向債券持有人償還本金及利息。
其他負債:包括應計費用、應付帳款、遞延稅項負債、貸款損失準備及衍生金融工具等項目。
次級負債:此類債務在銀行破產時,須於所有其他債務清償後方予償付。

銀行股本:

普通股:此為銀行所有者持有的股權,持有人享有表決權,並可獲派股息。
優先股:此類股本對盈利及資產之索償權高於普通股,但通常不附帶投票權。
留存收益:指銀行多年累積的淨盈利,並選擇再投資於業務而非以股息形式分派。
庫存股:指銀行從市場購回的自身股份。
其他全面收益:尚未於損益中確認的收益及虧損,例如若干投資及對沖工具的重估。
非控制性權益(少數股東權益):指子公司淨資產中,不由母公司直接或透過子公司間接持有之權益所應佔的部分。

資產、負債及權益的實際轉移:證券的轉移由中央證券存管機構(CSD)記錄,其保存所有權的法律記錄;貸款、固定資產及其他部位則依適用法律以轉讓或移轉協議辦理。兩者均超出通訊協定的範圍。資產及權益的轉移亦會影響銀行的財務報表,改變負債、資產及權益餘額。向相關監管機關提交此類財務報告,以及必要的合規事項,均超出協定的數據傳輸能力,需要另行辦理財務及監管程序。

總而言之,儘管各項協定對於 IPIP 交易中資訊的安全高效交換至關重要,但完整流程仍涉及其他系統,以處理實際的貨幣、資產、負債及權益的劃轉、結算、法律登記及財務報告,從而確保整項交易依照監管銀行標準合規執行。

IP ZIP 傳輸

機構付款指示的安全檔案傳輸

IP ZIP 轉帳最宜理解為一種以檔案為基礎的安全傳輸方式,透過網際網路協定網絡,在經認證的機構系統之間直接傳送結構化的付款指示及相關交易資料。

術語的使用須格外精確。

IP ZIP 傳輸並非清算系統、結算系統、支付渠道,亦非轉移貨幣價值的獨立機制。ZIP 壓縮檔僅為傳輸容器,IP 連線僅為通訊渠道,檔案內所載者為指示、數據集或交易訊息。

因此:

IP ZIP 傳送支付資訊及指示,其本身並不結算資金。

從概念上而言,這與適用於 ISO 20022 pacs.008(金融機構間客戶貸記轉帳)訊息的區別相類似。pacs.008 可承載高度結構化的銀行同業貸記轉帳指示,但不得將該訊息本身與中央銀行貨幣、商業銀行貨幣或代理帳戶餘額的最終移轉及結算混為一談。

同一原則亦適用於 IP ZIP 傳輸。

1. 技術架構

結構妥當的 IP ZIP 交易可如左圖所示。

因此,關鍵的區別在於傳輸層、指示層與結算層之間的分野。

這些層面不可混為一談。

2. ZIP 檔案作為安全交易容器

ZIP組件主要作為容器化及封裝機制。

發起機構可將相關檔案彙集為單一受控資料包,而非分別傳送各項交易組成部分。

視乎雙方協定的規格,此類文件包可能包含:

結構化付款指示;
XML 付款報文;
兼容 ISO 20022 的數據集;
JSON 交易物件;
CSV 或固定格式交易記錄;
專有銀行同業支付檔案;
債務人及債權人資料;
發起方及受益人帳戶資料;
交易識別碼;
貨幣及金額資料;
所要求的執行日及起息日;
代理銀行指示;
中間行資料;
匯款附言;
結算路由資訊;
合規文件;
KYC 或 KYB 參考資料;
資金來源資料;
交易清單;
數碼簽署;
密碼雜湊值;
證書;
時間戳記;
對帳檔案;以及
控制總數。

因此,該存檔可能同時包含主要付款指示,以及驗證、核實、處理及對帳該指示所需的附屬資料。

壓縮在技術上屬附帶性質。主要目的在於實現受控的打包及傳輸。

因此,切勿將 ZIP 壓縮檔視為其中所載資金已存在、可動用、無產權負擔或已結算的證據。

3. 結構化付款指示

若設計得宜,IP ZIP 套件所載的付款指示可發揮與傳統結構化金融報文類似的功能。

例如,機構可傳送一份 XML 指令,其欄位對應於通常見於 ISO 20022 pacs.008 報文中的資訊,包括:

訊息識別碼;
建立日期及時間;
交易筆數;
結算資訊;
指示代理行；
被指示代理行;
債務人;
付款人帳戶;
債務人代理行;
債權人代理行；
債權人;
債權人帳戶;
指示金額;
貨幣;
費用承擔方;
付款識別;
端到端識別;及
匯款附言資訊。

關鍵區別在於,資料結構並不決定結算機制。

一項在技術上有效的付款指示,可能已被接收系統接收、認證並接納,但相應的資金交收仍未完成。

因此:

收到指示 ≠ 收到資金

指示已驗證 ≠ 資金已結算

檔案成功匯入 ≠ 收款人已收到最終資金

伺服器確認 ≠ 結算確認

此區分是 IFB 處理另類轉帳方式的根本依據。

4. 傳輸協議

機構 IP ZIP 傳輸應僅在受控且經認證的通訊環境中進行。

視雙邊技術安排而定,傳送可採用下列技術:

SFTP

基於 SSH 的安全檔案傳輸協定提供加密傳輸、伺服器驗證及受控的用戶驗證。

就機構連線而言,一般應優先採用公開金鑰驗證,而非僅憑密碼的驗證方式。

FTPS

如舊有基礎設施有所需要,FTP 可通過 TLS 加以保護,惟須實施適當的證書驗證、加密標準及存取控制。

HTTPS / REST API

該文件包可透過經認證的 HTTPS 端點或 API 架構傳送,並採用 TLS 及適當的應用層身份認證。

雙向 TLS(Mutual TLS)

對於更高保證級別的機構連線,雙向 TLS(mTLS)可使雙方端點透過數碼證書相互認證。

相較於僅採單向伺服器驗證,此做法可針對未經授權的終端提供實質更強的保護。

VPN

在應用層傳輸開始之前,可透過站點對站點的 IPSec 或同等的 VPN,在參與機構之間建立加密的專用通道。

專用私人連線

如交易量、安全要求或機構風險狀況有此需要,可採用專用或私人網絡連線,以補充或取代經由公共互聯網的傳輸。

在營運啟動前,必須雙方協商確定具體的協議流程。

5. 端點驗證

接收機構必須確認該傳送確實來自其所聲稱代表的機構。

相關控制措施可包括:

機構數碼證書;
SSH 公開/私密密鑰對;
雙向 TLS 憑證;
API 憑證;
IP 允許清單;
VPN 身分驗證；
硬體安全模組;
在適當情況下採用證書綁定(certificate pinning);
多重因素管理員驗證;
受控服務帳戶;
基於角色的存取控制;及
生產環境與測試環境相互隔離。

僅憑 IP 位址不足以證明機構身分。

同樣地,持有某一端點、伺服器登入資料、API 憑證或 ZIP 密碼,並不能確立對相關資金的所有權。

6. 加密

保密原則上應在多個層面上予以確立。

傳輸加密

通訊管道應採用經適當配置的現行通訊協定（如 TLS 或 SSH）進行加密。

此措施保障傳輸中的資訊。

酬載加密

如有需要,交易文件包本身亦可另行加密。

此舉可獨立於傳輸渠道而保護財務資訊,並可大幅降低檔案在暫存、經由中介基礎設施路由、歸檔或非同步處理等環節所面臨的風險。

靜態資料加密

待處理的檔案應存放於受控的儲存環境中,設有適當的存取限制,並對靜態資料進行加密。

然而,加密僅能確立保密性,並不能確立交易在財務上的有效性。

7. 加密完整性

接收機構亦必須有能力判斷所傳送的文件包在建立後是否曾被更改。

因此,可為該文件包或其組成檔案生成密碼學雜湊值。

例如:

原始交易資料包
→ 生成加密雜湊值
→ 傳送資料包
→ 接收系統獨立計算雜湊值
→ 將計算所得雜湊值與所傳送或已簽署的雜湊值比對

不一致即表示所接收的資料包與原先經認證的資料包在密碼學上並不相同。

可視實施情況採用現代加密雜湊演算法(例如 SHA-2 或 SHA-3 系列的適用成員)進行完整性驗證。

8. 數碼簽署

數位簽章所發揮的功能與加密有本質上的區別。

加密技術保護保密性。

雜湊運算有助於確立完整性。

妥善實施的數位簽章可協助確立:

真實性 - 該文件包已使用相關私鑰簽署;
完整性 - 已簽署的數據其後未被更改;及
問責性 - 簽名可與相關機構憑證相關聯,惟須受適用的 PKI 及管治框架約束。

接收機構應在交易指示進入支付處理程序之前,對照相應的可信證書或公開金鑰核實簽名。

簽署私鑰應受到適當保護,宜透過機構級密鑰管理基礎設施,並在有需要時採用硬件安全模組。

9. 重放及重複攻擊防護

金融檔案傳輸須設有控制措施,以防止同一有效指令被重複提交。

因此,設計妥善的架構應納入唯一交易識別碼及適當的控制措施,例如:

唯一的訊息識別碼;
唯一的交易編號;
時間戳記;
序列號;
檔案識別碼;
重複訊息偵測;
冪等性控制;
處理狀態登記冊;以及
與先前已處理的指示進行對帳。

收款機構應依據雙方約定的作業程序,拒絕、隔離或調查重複的指示。

10. 檔案驗證

成功接收檔案應觸發驗證程序,而非自動結算。

安全處理環境可能對整套文件施行若干連續控制:

第一階段 – 運送驗證

確認文件包裹已經由授權渠道送達。

第 2 階段 – 端點驗證

確認傳送系統及機構憑證。

第三階段 – 惡意軟體及檔案安全控制

在壓縮檔及其所含檔案匯入支付基礎設施之前,對其進行檢查。

第 4 階段 – 加密驗證

驗證雜湊值、簽章及憑證。

第 5 階段 – 結構驗證

確認檔案符合約定的結構綱要、命名慣例、字元編碼及資料規格。

第 6 階段——語義驗證

確認必填付款欄位均已填列,且內容前後一致。

第 7 階段 – 交易驗證

核實貨幣、金額、帳戶、路由資訊、交易參考編號及結算指示。

第 8 階段 – 合規驗證

反洗錢(AML)、制裁、KYC/KYB、交易監控及其他適用之控制措施。

第 9 階段 – 結算驗證

確認確實存在可結算相應金融價值的機制。

上述各項控制措施完成後,指示方可按收款機構的適用程序進入執行階段。

11. 確認不等同於結算

IP ZIP 環境可能產生多項技術確認訊息。

例如:

ACK – 檔案已收悉

此僅可證明接收端點已取得該文件包。

ACK – 文件已通過驗證

此舉確立身分驗證控制措施已順利完成。

ACK – 檔案已驗證

此舉確立該資料包符合適用的結構或技術驗證要求。

ACK – 指示已獲接納

這或可證明該付款指示已進入收款機構的處理流程。

上述狀態未必意味著:

已結算

結算須另行發生一項財務事件。

此區別與傳統金融電文相若：付款電文的成功傳送與接受，必須有別於相關貨幣債務的最終結算。

12. 基礎交易的結算

IP ZIP 付款指示一經驗證、核實、接受及授權，其所涉貨幣價值即須透過適當的金融基礎設施進行結算。

視乎所涉及的貨幣、機構及司法管轄區，結算可透過以下途徑進行：

代理銀行業務;
往來帳戶(Nostro)/來帳戶(Vostro);
中央銀行帳戶;
RTGS 基礎設施;
認可的結算系統;
本地支付系統;
即時支付基礎設施；
代理結算銀行;或
另一項在法律及運作上獲認可的結算安排。

因此,簡化的交易流程可如圖所示。

因此,財務價值是透過結算基礎設施轉移,而非透過 ZIP 壓縮檔。

13. 與 ISO 20022 pacs.008 的比較
兩者的區別可概念性地說明如下:

此項比較著眼於功能而非規範。pacs.008 是依據 ISO 20022 正式定義的金融報文。「IP ZIP」並非與之對等的國際標準化報文類型。

因此,IP ZIP 架構必須透過雙邊約定,自行訂明其報文結構、安全架構、驗證規則、確認邏輯、例外處理、對帳程序以及與結算之間的關係。

14. 安全原則

IFB 對所有替代性轉帳方式一律適用一項根本區分:

安全傳輸僅證明資料可被安全傳送,並不證明款項可予結算。

加密並不能證明資金的存在。
數碼簽署並不能證明資金存在。
伺服器上的結餘並不構成資金證明。
交易檔案並不構成資金證明。
檔案成功導入並不能證明資金存在。
技術性確認並不構成結算的證明。

決定性的財務問題仍然是:發起機構是否已核實流動資金,並具備能夠透過公認銀行基礎設施交付相應貨幣價值的可運作結算途徑。

15. IFB 接納框架

僅在經技術、法律及合規審查並令人滿意後,IFB 方會考慮為經批准的機構交易對手及獲接納的客戶處理 IP ZIP 傳輸。

在建立正式生產環境連線之前,IFB 可能要求核實下列事項:

發起機構;
傳送該交易的機構授權;
實益擁有權及交易各方;
資金來源及其合法性;
相關的經濟目的;
發送及接收基礎設施;
端點所有權;
IP 及網絡架構；
認證方法;
證書及加密憑證;
加密標準;
檔案格式及結構;
支付報文結構;
交易識別方法;
確認通知協議;
重複及重放控制;
例外處理;
對帳程序;
代理銀行關係;
結算帳戶;
流動性安排;及
最終結算途徑。

僅有技術上的互通性並不足夠。

IFB 不會將 IP ZIP 資料包的成功傳送視為收訖資金。僅當相應價值已透過約定的銀行或結算基礎設施成功結算,且該結算可被獨立核對時,交易才在財務上完成。

基本原則

IP ZIP 是指令的安全傳輸；結算則是相應金融價值的轉移。

這兩項程序可能屬於同一交易工作流程的組成部分,但並非同一事件。

以機構銀行業務術語而言:

報文傳送 → 驗證 → 核實 → 接受 → 執行 → 結算 → 對帳

僅在適用的結算程序完成後,方可確認交易的資金部分已告完成。

IP Direct

IP Direct 機制涉及銀行同業業務範疇內的一項專門交易處理程序。茲說明如下:

往來帳戶(Nostro)與來帳戶(Vostro)關係:此項交易的基礎,在於兩家銀行機構之間建立「Nostro–Vostro」帳戶關係。在此安排下,「指示銀行」於 International Finance Bank(IFB)持有「Nostro」帳戶(意大利語,意為「我們的」,即「我方在貴方開立的帳戶」),而 IFB 則相應為指示銀行維持「Vostro」帳戶(意為「你們的」,即「貴方在我方開立的帳戶」)。此雙邊帳戶安排對促成 IP Direct 交易至關重要。

IP Direct 機制:採用 IP Direct 方式時,匯出行發起的交易直接透過兩家銀行的整合支付系統處理,繞過 SWIFT(環球銀行金融電信協會)等較傳統且往往更為複雜的國際支付系統路徑。IP Direct 的主要優勢在於,由於銀行之間建立了直接的通訊通道,交易執行可能更為迅速,交易成本亦可能較低。

交易流程:在 IP Direct 交易中,匯出行利用既有的往來帳戶(Nostro)與來帳戶(Vostro)關係,直接向 IFB 發出付款指令。IFB 收到該指令後,將按所收到的指示對相關帳戶進行貸記或借記。此流程通常較為簡化,效率可能高於標準做法,對交易量龐大或需要加急處理的銀行尤其如此。

有效運作的條件:要使 IP Direct 發揮最佳效能,須符合若干條件: