走进MT759报文

文/韩静绮 编辑/韩英彤

商业银行应在保证对应栏位使用准确的前提下，挖掘更为多元化的使用方法，加快银行系统对MT759报文相应板块的升级进程。

报文作为银行之间沟通的一种重要工具，是国际结算业务中必不可少的一个要素。在大数据、人工智能以及金融科技飞速发展的今天，为了提高银行间的沟通效率、降低贸易成本，SWIFT组织在经过数年的准备之后，于2018年11月份进行了报文格式升级。MT759就是诸多新增报文中的一种。本文主要从MT759报文的设计及实务运用方面进行分析及探讨。

MT759的替代作用

在SWIFT组织前期调研时期，各大成员银行或多或少都提出了处理杂项报文的问题。对此，MT759的设计初衷是为了逐步取代MT799类型报文。根据其官方文件，“MT759是作为跟单信用证、见索即付保函、备用信用证或其他形式承诺书的自由格式报文，名称为多用途结构性报文（“ANCILLARY TRADE STRUCTURED MESSAGE”）”。

随着国际贸易电子化进程的发展，SWIFT系统贸易类最为常见的加押自由格式报文MT799，在实务运用中逐渐显露出一些弊端。首先，是MT799被过度使用。根据SWIFT组织的相关规定，在有其他类型报文可以使用的时候，应尽量优先使用相对应的功能性报文而不是MT799，但实务中，滥用MT799的情况却比比皆是。如在发送电提不符点报文之时，有些银行也会使用MT799列明所述不符点，尽管稍微严谨一些的银行会在报文开头显示“PLS TREAT THIS MT799 AS MT750”之类。但此类报文使用MT799发送，显然不符合报文的使用规范。其次，MT799报文格式设计过于简单。对于国内银行来说，在越来越倾向于集约化管理模式的趋势下，将会导致在业务高峰期，收报行无法通过简单预判将报文快速送达至具体部门。

鉴于以上情况，在格式升级以后，为了更好地将杂项报文进行细化分类，SWIFT组织新增了MT759以替代被过度使用的MT799，且在格式上也做了显著改变。一是MT759在45D报文内容栏位允许Z字符库字符的使用。Z字符库是目前范围最大的字符库，不仅囊括X和Y字符库的所有内容，同时还允许使用“@＃ _｛”这四个字符，从而为银行在发送报文的内容及格式上提供了更多的便利。二是MT759增加了新的栏位。其中新增的“22D：FORM OF UNDERTAKING”和“23H：FUNCTION OF MESSAGE”两个核心栏位，对业务种类与报文功能进行了区分，大幅提高了报文的精确程度。

MT759在实务运用中存在的问题

从过去一年对MT759的使用情况看，虽然SWIFT组织的设计初衷是好的，但大多数银行仍然在频繁使用MT799。究其原因，一是MT759的栏位比较复杂，而大多数银行的系统并没有随之及时升级，因而无法适配MT759的发送；二是虽然官方给出了相应栏位的使用方法，但由于对某些栏位的运用范围未给出具体的指导意见，导致在实务中仍会出现报文信息模糊的情况。通过总结研究，笔者认为主要有以下问题值得关注：

对于有确定选项的栏位，在使用时无法做到相互对应

MT759作为一种多用途结构性报文，可运用的范围非常广泛，这也就造成了在使用时可能会出现“21:RELATED REFERENCENUMBER”（业务编号）与“22D:FORM OF UNDERTAKING”（业务种类）无法相互对应的情况。

如：开证行C银行于2017年9月向境外开立一笔独立保函，在SWIFT报文格式升级以前，双方银行就修改及收费事项通过MT799进行了多次沟通；升级后，对方银行开始使用MT759向开证行发送报文，内容主要涉及到告知已向开证行发送DEMAND CERTIFICATE、向开证行提供受益人收款账号以及查询款项等等。然而，开证行每次在收到报文时，都会发现报文内容有两个栏位显示如下：

21:RELATED REFERENCE

1234-LG-5678

22D:FORM OF UNDERTAKING

DOCR

从上述报文中可以发现，21栏位引用的是独立保函编号，22D业务类型使用的是DOCR（跟单信用证）。而这两个栏位是自相矛盾的，很容易导致收报行在处理时混淆业务种类。

实际上，在SWIFT组织的官方手册中，22D共设置了四种选择——DOCR、DGAR、STBY、UNDK——分别适用于跟单信用证、独立保函、备用信用证以及其他付款承诺的情景，以便能让收报行更加直观地对业务种类进行预判。鉴此，笔者建议，对于有相关业务编号的报文，发报行在使用22D栏位时，应当做到与21栏位相互对应，避免收报行后续进行二次处理，延迟业务效率。

对于没有确定范围的栏位，在使用时仍需以判断内容为主

对于新增的“23H:FUNCTION OF MESSAGE”（报文功能）栏位，官方手册只给出了相应的选项，并未就各个选项下所涉及的内容范围提供明确的指导方案。

众所周知，商业银行之间进行报文往来的时候，涉及到的内容范围非常之广。MT759新增23H栏位，就是为了把这些复杂的内容细化为更简洁的模块，并设置了十三个代码以方便选择。这些代码可以被理解为使用报文时所能运用的不同场景，也就是报文功能。比如，提示欺诈风险的FRAUDMSG以及代表转让功能的TRANSFER，都可使收报行对场景分类一目了然。

然而，由于自由格式报文本身内容所涉范围的广泛性以及23H栏位代码的多样性，其中多数代码使用频率极低。比如CLSVOPEN和CLSVCLOS是一组相互对应的代码，分别代表贸易业务的开启和关闭；但在实务中，两者出现的概率极低。究其原因，主要是受到这些代码定义模糊的影响，如对CLSVCLOS，并未明确其是否可以作为告知信用证已闭卷的报文进行发送。另一个问题是，部分报文的功能归类不够清晰。举例来说，实务中经常会遇到的“TO DATE WE HAVE NOT RECEIVED YOUR ADVICE OF PAYMENT ON THE ABOVE BILL.PLS LET US HAVE YOUR ADVICE OF PAYMENT BY AUTHETIATED SWIFT（直到今天我行仍未收到上述款项的付款信息，请通过加押报文回复具体情况）”此类对信用证款项的查询，各银行在23H栏位的使用上就莫衷一是：有的使用GENINFAD（基本信息通知），有的使用OTHERFNC（其他业务），还有的会使用REIMBURS（偿付请求）。确实，不同的银行可以对此产生不同的理解，既可以把这笔报文的内容理解为对什么时候可以收到款项的信息查询，又可以理解为杂项类的催款报文，也可以理解为偿付行的付款请求。这就使得23H栏位并没有达到其设计的效果——通过代码的选择和应用帮助收报行及时判断应用场景——因而对于收报行业务的推动意义不大。

对此，笔者建议SWIFT组织，对这种容易出现交叉模块的报文信息能够推出更详细的使用手册，进一步明确23H各个选项的可应用场景和范围；同时建议各商业银行，在使用过程中积极总结需要细化的场景及分类，以便更为规范地运用MT759。在目前的实务操作中，对于无法判断场景的报文仍然以判断内容为主。

发展建议

在本次报文格式升级中，SWIFT组织通过大幅的格式改变及大量的栏位新增，使得报文结构向标准化及格式化的方向又迈出了一步。这是一次意义重大的数字化变革，为各商业银行拓宽金融科技创新道路提供了坚实的基础。其中，MT759报文的栏位细化及多重代码为银行系统精确抓取报文结构化信息提供了可能，可为大数据及人工智能的发展提供更多的便利。此外，根据目前国际结算业务信用证的使用比例逐步下降、保函使用日趋上升的趋势，未来商业银行及企业对保函的使用需求肯定会越来越大。新推出的MT759恰好能够满足目前的贸易形势变化：它除了可应用于信用证，还可用作独立保函和备用信用证业务项下，并且可以开立从属性保函，具有较强的功能性及实用性。

由此可见，MT759报文对于商业银行的未来发展及实务操作都具有很大的意义。但由于推出的时间较短，目前MT759运用最多的情景仅限于DOCR项下的GENINFAD（基本信息通知）和OTHERFNC（其他业务），而DGAR、STBY、UNDK以及23H报文功能栏位下其他选项则很少被使用。鉴此，建议SWIFT组织推出更详细的指导手册，逐步明确各栏位可运用的具体场景，不断完善报文在实务中的应用方式，尽量避免在实务中出现信息模糊的状况，以此来提高MT759的使用效率，也为即将到来的保函类报文升级做好更充足的准备。

对于各商业银行来说，作为SWIFT系统的受益者，应当在保证对应栏位使用准确的前提下，挖掘更为多元化的使用方法，加快银行系统对MT759报文相应板块的升级进程，以便在尽早享受新版报文带来便利的同时，能够同步推进银行内金融科技业务的发展，为进一步提升银行自身的国际市场竞争力打下更加坚实的基础。