走进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的便利而颇多受益。