走進MT759

文/胡捷 編輯/韓英彤

目前MT759尚未被廣泛應用。鑒此，各家銀行應盡快熟悉這位“新人”，在充分學習、研究的基礎上逐步嘗試使用它，推廣它。將來，必定會因其便利而頗多受益。

此次SWIFT升級牽涉廣泛，CATEGORY 7中幾乎每類報文都或多或少有所變動，而全新增加的MT759則可謂“不熟悉的陌生人”。這位閃亮登場的“新人”是這次SWIFT升級變革的典型代表，它的結構清晰、功能強大，如果運用得當，能極大增加銀行間的溝通效率。

MT759（Ancillary Trade Structured Message，貿易輔助結構化報文）發揮的是輔助功能，并具有高度結構化特點。根據SWIFT手冊的定義，MT759用于在信用證、保函、備用證等交易下“提供或請求提供信息”，例如欺詐預警或融資請求等。

基礎欄位

MT759的欄位不少，擁有9個欄位。

（1）第一欄，27，Sequence of Total。其功能與MT700中的27欄一樣，用于表明759報文（在多于一個時）的系列報文總數，數值可以介于1—8。這意味著在內容最多可以額外添加7個759報文。

（2）20欄和21欄。筆者建議20欄為必輸項而21欄為可選項。

（3）22D和23H。這是759報文中最核心的兩個欄位，其存在嚴格的對應關系。759的功能性和結構性幾乎全部體現在這兩個欄位上。可以將22D欄位理解為“業務類型（type of instrument）”，可以明晰759報文對應的業務品種。該欄是一個代碼欄位，共可以選擇輸入四種代碼：DGAR、DOCR、STBY和UNDK，分別代表獨立保函、跟單信用證、備用證、其他付款承諾。

（4）23欄位是用來輸入與22D對應的業務編號，如保函編號、信用證編號等。應注意的是，23欄應該嚴格輸入唯一性的保函號碼、信用證號碼等業務編號，而非其他，以方便接收方快速識別業務。雖然是非必輸項，建議在有確定的undertaking number時，盡量輸入該欄。

（5）52a欄與23欄相輔相成，用于表明23欄中信用證、保函等的開立人。同樣是非必輸項。然后就是非常復雜的23H欄。

特殊代碼

23H欄位的名稱是Function of Message，報文功能。必輸欄位。根據定義，該欄用于表明報文內容的具體要求或功能。

與22D不同的是，23H的代碼極多，一共有12個，而且部分代碼縮寫程度較深，縮寫規律也不同于日常英語，其中還有部分代碼“出雙入對”。

第一對代碼是CLSVCLOS和CLSVOPEN。這一對代碼表示（Closing/Opening of client service call by Trade Operations，某項貿易服務的開啟或關閉）。

第二對代碼是ISSUANCE、ISSAMEND和REQISSUE、REQAMEND。ISSUANCE、ISSAMEND為開立和開立修改的意思，但這里的開立是指開立除信用證、保函和備用證以外的其他自由格式貿易結算工具，即22D欄位中的第四個代碼——UNDK，如非獨立保函（dependent guarantee）。

因為信用證、保函和備用證都已有專門的報文700/707和760/767等用于開立，因此不應使用759。除此之外的非獨立保函等付款承諾，此前往往只能通過799開立，升級后均應使用規范的759開立和修改。與之相應，REQISSUE和REQAMEND是用于請求開立上述UNDK及其修改的。

余下是6個落單的CODE：

6-1. FRAUDMSG，Advice of a fraud attempt，報告欺詐企圖。當交易涉及欺詐時，可以用這個代碼表明報文的主要目的。

6-2. GENINFAD，General information advice，通知相關信息。大部分信息交涉、業務溝通類的報文都可以使用這個代碼。

6-3. OTHERFNC，Other request，其他請求。

6-4. REIMBURS，Request related to a reimbursement。S W I F T為償付業務單獨設置了一個代碼，催款時可以打上“REIMBURS”。

6-5. REQFINAN。FINAN指finance，REQ在上面也出現過，所以這個代碼的意思是Financing request。當要求開證行、議付行、保兌行、海外行等進行議付、融資、貼現時，可使用這個代碼。

6-6. TRANSFER。這是一個完整的單詞，0縮寫。但要特別注意，手冊里對TRANSFER的定義可能會引發誤解。這里的undertaking很容易被理解為22D里的UNDK，從而誤認為是指除信用證、保函和備用證以外的非獨立付款承諾的轉讓。其實，這里的轉讓包含保函和備用證，即獨立保函和備用證以及非獨立的其他付款承諾在辦理轉讓時，均可使用759報文，并在23H欄位選擇TRANSFER代碼。

核心欄位

不論其他各種欄位的要式性多么強，規則多么復雜，報文的實質內容是體現在45D的。特別是在發報人沒能準確規范地使用22D、23H等欄位時，收報人仍應該以45D中陳述的內容為準（除非欄位間存在明顯矛盾）。例如，如果22D欄位顯示DGAR，而23、52a和45D中明確引用了信用證編號、開證行BIC CODE和與該筆信用證相關聯的交涉內容，顯然應該忽視DGAR這個誤用的CODE。

另外，可以注意到45D的長寬是150×65z，這應該是目前7類報文中容量最大的Narrative欄位了，可以錄入150行內容，每行可以打65個字符。

Last and maybe least，23X，非必輸。該欄位表明與交易相關的文件的名稱編號和寄送方式，包含很多四字代碼，包括COUR、EMAL、FACT、FAXT、HOST、MAIL和OTHR，用于代表寄送和發送文件的各種方式。23X欄位一種可能的使用場景是：通過759開立一份非獨立保函，要求在索賠時提交一份申請人簽署的文件，并聲明簽字樣本已通過快遞方式發送給通知行，那么759的23X中會使用COUR代碼，同時列明文件的名稱（如SIGNATURE SPECIMEN）、快遞公司（如DHL）和快遞編號等。不過，手冊中23X的使用規則里要求，“該欄內容應經各方同意（This field should be agreed between parties）”。實務中到底如何規范使用，有待考察。

使用規則

準確地說，MT759的控制規則就是22D和23H兩個欄位之間的控制規則。雖然22D和23H兩欄內各項代碼可以自主選擇，但是，當其中一欄內的代碼已經選定時，另一欄位內代碼的選擇就會受到限制，必須與之匹配。銀行系統升級改造時，應納入這一邏輯規則，否則會影響報文正常發送。

ISSUANCE、ISSAMEND和REQISSUE、REQAMEND這兩對代碼僅用于表示開立或請求開立以非獨立保函為代表的一類付款承諾，所以當23H欄位選擇這4個代碼時，22D欄位只能選擇UNDK。當23H欄位選擇TRANSFER時，22D欄位可以選擇DGAR、STBY和UNDK，但不可選擇DOCR。

剩下的CLSVOPEN、CLSVCLOS等7個代碼，代表較為通用的功能，不區分業務品種，因此23H欄位選擇這7個代碼時，22D欄位可以隨意選擇。

綜上，可將控制規則歸納如下：

（1）業務類型為信用證（DOCR）時，23H不可選擇與開立和轉讓相關的代碼，其他代碼均可選擇；

（2）業務類型為保函和備用證（DGAR/STBY）時，23H不可選擇與開立相關的代碼，其他代碼均可選擇；

（3）業務類型為非獨立付款承諾（UNDK）時，23H所有代碼均可選擇。

使用現狀

MT759在799的基礎上做了較大的改進，報文欄位結構清楚、目的明確，既能清楚地表達發報者的溝通意圖，又能滿足較長的交涉篇幅，且其自帶的“業務品種標簽”功能也有助于銀行進行篩選和統計，足以成為銀行間溝通交涉報文的首選。不過，目前MT759尚未得到廣泛應用。筆者認為，各家銀行應盡快熟悉這位“新人”，在充分學習、研究的基礎上逐步嘗試使用它、推廣它。將來，必定會因MT759的便利而頗多受益。