SWIFT升级 | 2018 SWIFT升级要点梳理 - 759

Posted 2021-04-27 可卜

除了信用证（70X、71X、72X）和保函/备用证（76X、77X、78X）外，此次SWIFT升级涉及的常用报文还有730、732、734、740、742、744、747、750、752、754、756、759，姑称之为交涉类报文。其中变革最大、交涉性最强的自然要数此次全新登场的759，所以今天我们首先来看759。

相对于老前辈799，初出茅庐的759前卫新潮、功能强大，而且看上去很是有些复杂。不过，只要抓住“栏位”和“规则”这两个重点，就基本可以抓住759的小辫子。

 

在具体看“栏位”和“规则”这两个重点之前，我们先认识一下759的学名和定义。

01 | 学名

 

759的完整名称叫Ancillary Trade Structured Message，光是这个名称就很酷，酷到没朋友。中文名可以叫做“贸易辅助结构化报文”。

Trade，不用解释。

 

Ancillary，辅助性的，说明759发挥的是辅助功能，当其他类型的报文不能够或不足以实现某些目的时，就由759来辅助实现。

 

Structured，结构化，这是在说759的特点——高度结构化。这一高度的结构化具体就体现在前面提到的两个重点上：栏位（栏位多、栏位细）和规则（栏位之间存在控制规则）。

 

 

02 | 定义

 

根据SWIFT手册的定义，759用于在信用证、保函、备用证等交易下“提供或请求提供信息（request or to provide information）”，例如欺诈预警或融资请求等。

 

定义中的关键词是“信息”，提供信息，提供与欺诈或融资相关的信息。但如果759提供的信息仅限于欺诈和融资相关，那范围显然太窄了，这样的功能完全无法取代今天满天飞的799，所以我认为需要更广义地来理解这个定义——759中提供或请求的信息可以是与信用证、保函等相关的任何内容。

 

具体可以是哪些内容，不同方面的内容又该怎么放置到这个新的759里，下文会谈到。

 

 

03 | 栏位

 

759的栏位不少，有9个之多，而且很多是之前听也没听过的栏位。

 

第一栏，27，Sequence of Total。这是旧酒装新瓶，功能和700中的27栏一样，用于表明759报文（在多于一个时）的系列报文总数，数值可以介于1-8，这意味着在内容多到写不下时，最多可以额外添加7个759报文——妈妈再用不用担心我忘记在799报文末尾打上“SEE NEXT MT799”了……

20栏和21栏，老朋友了。注意20为必输而21为可选。为了方便对方识别报文，加快对方响应速度，我建议尽量在21栏输入对方或相关业务编号。

 

 

接下来是22D。22D和下面马上要提到的23H是759报文中最核心的两个栏位，而且这两个栏位之间存在严格的对应关系。759的功能性和结构性几乎全部体现在这两个栏位上。

22D栏位名称为Form of Undertaking，可以把它理解为“业务类型（type of instrument）”，这个栏位可以让你一目了然地知道这份759报文对应的业务品种是信用证，还是保函，抑或是备用证，甚至是其他。

 

该栏是一个代码栏位，共可以选择输入四种代码：DGAR、DOCR、STBY和UNDK，分别代表独立保函、跟单信用证、备用证、其他付款承诺。其中关于“其他付款承诺（UNDERTAKING）”，手册中的举例是guarantee/surety等，例子不是很明确，但从手册对后面23H栏位中部分代码的解释可以侧面推知这里的“其他付款承诺（UNDERTAKING）”主要指区别于独立保函和信用证的其他非独立保函或非独立付款承诺。这一点我们后面会再详细谈到。

接着22D的是23，Undertaking Number。顾名思义，该栏是用来输入与22D对应的业务编号，如保函编号、信用证编号等。应注意的是，实际业务中一笔信用证或保函下当事各方可能会各自产生多个reference number，但23栏应该严格输入唯一性的保函号码、信用证号码等业务编号，而非其他，以方便接收方快速识别业务。

个人认为23栏的增设效果会很好，避免了此前使用799时编号太多、无处安放、难以识别的尴尬。虽然是非必输项，我建议在有确定的undertaking number时尽量输入该栏。

 

再下面是52a，Issuer。52a与23栏相辅相成，用于表明23栏中信用证、保函等的开立人。同样是非必输项。

然后就是非常复杂的23H栏。

 

23H栏位的名称是Function of Message，报文功能。必输栏位。根据定义，该栏用于表明报文内容的具体要求或功能。

跟22D相同的是，23H也是一个代码栏位，但跟22D不同的是，23H的代码极多，一共有12个，而且部分代码缩写程度较深，缩写规律也不同于日常英语，刚开始的时候很容易忘记代码所代表的完整含义是什么。

 

硬要找规律的话，那可能就是12个代码长度一样，都是8个字母，可能也正因为追求长度一样，所以导致缩写没有规律，有的缩得极其严重（猜猜CLSVCLOS代表什么？），有的则一字未缩（如ISSUANCE）。

04 | 成双

 

我猜测，23H可能是所有7类报文中代码最多的一个栏位，而且很多代码都出双入对。

 

第一对代码是CLSVCLOS和CLSVOPEN。

说它们是一对，因为这两个代码都是在说同一个事情，一个我不太懂的事情，Client Service Call by Trade Operations，简称CLSV（CL代表Client，SV代表Service），这是两个代码相同的前四个字母。

 

后四个字母分别是CLOS和OPEN。OPEN是一个完整的单词，开。相应地可以猜测CLOS对应的单词，CLOSE，关。

 

所以，这一对代码表示Closing/Opening of client service call by Trade Operations。字面意思看是指某项贸易服务的开启或关闭，但没接触过所谓的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及其修改。

 

 

05 | 落单

 

然后是剩下的6个落单的CODE。

1/6，FRAUDMSG，Advice of a fraud attempt，报告欺诈企图。当交易涉及欺诈时，可以用这个代码表明报文的主要目的。

2/6，GENINFAD，General information advice，通知相关信息。大部分信息交涉、业务沟通类的报文都可以使用这个代码。

3/6，OTHERFNC，Other request。我一直觉得这个代码里的FNC表示的是function，即other function，但手册里写的是request，不过效果倒是差不多。当报文内容太复杂，不知道该怎么选代码时，就选“OTHERFNC”吧。

 

4/6，REIMBURS，Request related to a reimbursement。感动，SWIFT居然为偿付业务单独设置了一个代码。以后催钱的时候可以打上“REIMBURS”来开门见山了。

5/6，REQFINAN。FINAN肯定是指finance，REQ在上面也出现过了，所以这个代码意思是Financing request。当我们要求开证行、议付行、保兑行、海外行等进行议付、融资、贴现时，可以使用这个代码。

6/6，TRANSFER。这是一个完整的单词，0缩写。意思大家都懂，转让。但要特别注意，手册里对transfer的定义可能会引发误解——transfer of undertaking。这里的undertaking很容易被理解为22D里的UNDK，从而误认为是指除信用证、保函和备用证以外的非独立付款承诺的转让。其实，这里的转让包含保函和备用证，即独立保函和备用证以及非独立的其他付款承诺在办理转让时均可使用759报文，并在23H栏位选择TRANSFER代码。

在此之前，保函和备用证不像信用证一样有720可以直接拿来用，办理转让时往往需要用一个甚至多个799来转述条款，非常麻烦。升级后，都可使用新增的759办理转让。

 

至此，包含12个代码的23H栏位终于讲完了。

 

 

06 | 实质

 

还剩下最后两个栏位。

 

首先是（我认为）同样非常重要的45D报文详述栏位。

不论其他各种栏位的要式性多么强，规则多么复杂，报文的实质内容是体现在45D的，光填入几个CODE，解决不了任何实际问题。特别是在发报人没能准确规范地使用22D、23H等栏位时，收报人仍应该以45D中陈述的内容为准（除非栏位间存在明显矛盾）。例如，如果22D栏位显示DGAR，而23、52a和45D中明确引用了信用证编号、开证行BIC CODE和与该笔信用证相关联的交涉内容，那么显然应该忽视DGAR这个误用的CODE。

 

另外，可以注意到45D的长宽是150*65z，这应该是目前7类报文中容量最大的Narrative栏位了，可以录入150行内容，每行可以打65个字符。要知道，799的79栏也只有35*50，700的46和47也只有100*65。一个759的字符容量相当于5.6个799，所以，绝大部分情况下27栏应该1/1就够了。

 

当然，这样大的栏位容量也是为了方便开立UNDK类付款承诺或办理转让时在45D栏位内完整录入条款文本。

 

07 | 不详

 

Last and maybe least，23X，非必输。

该栏位具体功能不详，直接上原文吧：This field identifies the type of delivery channel and associated file name or reference。

 

字面含义是表明与交易相关的文件的名称编号和寄送方式。该栏位包含很多四字代码，包括COUR、EMAL、FACT、FAXT、HOST、MAIL和OTHR，用于代表寄送和发送文件的各种方式。

 

推测23X栏位一种可能的使用场景是：通过759开立一份非独立保函，要求在索赔时提交一份申请人签署的文件，并声明签字样本已通过快递方式发送给通知行，那么759的23X中会使用COUR代码，同时列明文件的名称（如SIGNATURE SPECIMEN）、快递公司（如DHL）和快递编号等。

 

不过，手册中23X的使用规则里提到一句“该栏内容应经各方同意（This field should be agreed between parties）”，实务中到底如何规范使用，有待考察。

 

 

08 | 规则

 

终于说了完了759一共9个栏位，但还没完，与759中这些的新老栏位同样重要的，是759的控制规则。

 

准确的说，是22D和23H两个栏位之间的控制规则。

虽然22D和23H两栏内各项代码可以自主选择，但是，当其中一栏内的代码已经选定时，另一栏位内代码的选择就会受到限制，必须与之匹配。银行系统升级改造时，应纳入这一逻辑规则，否则会影响报文正常发送。

 

前面说过，ISSUANCE、ISSAMEND和REQISSUE、REQAMEND这两对代码仅用于表示开立或请求开立以非独立保函为代表的一类付款承诺，所以当23H栏位选择这4个代码时，22D栏位只能选择UNDK。

 

TRANSFER的含义前面也重点分析过，是指除信用证以外的其他所有类型付款承诺的转让，因此当23H栏位选择TRANSFER时，22D栏位可以选择DGAR、STBY和UNDK，不可选择DOCR。

 

剩下的CLSVOPEN、CLSVCLOS等7个代码，代表较为通用的功能，不区分业务品种，因此23H栏位选择这7个代码时，22D栏位可以随意选择。

 

不过，按照我们惯常的思维模式，在编写报文时通常都是先确定业务品种，再考虑报文功能，也即先选22D，再选23H，所以上述控制规则按照我们正常的思路捋一遍就是：

 

1. 业务类型为信用证（DOCR）时，23H不可选择与开立和转让相关的代码，其他代码均可选择；

2. 业务类型为保函和备用证（DGAR/STBY）时，23H不可选择与开立相关的代码，其他代码均可选择；

3. 业务类型为非独立付款承诺（UNDK）时，23H所有代码均可选择。

好了，759的要点差不多就是这些了。自学成果，或有错漏，和各位讨论。

 

后续会继续梳理其他7类报文。

 

☆☆☆☆☆

往期文章··············

---