系列之五 | MT759报文升级内容解析

根据SWIFT组织2018至2019年对SWIFT报文格式的升级安排，2018年11月18日信用证相关报文的升级新增了MT744、MT759和MT708三种报文，其中MT759报文为标准化、格式化的自由报文，旨在于逐步替代实务中使用较频繁的MT799报文。SWIFT组织对MT759报文的条款设置更加规范，使用范围更加明确，既可以满足实务中对自由报文的使用需求，也有助于解决目前MT799报文不规范使用的问题。另外，MT759作为新增格式化报文，在使用初期必然会面临转换和不规范使用带来的问题挑战。银行与企业都需要了解并规范使用MT759报文。一、报文格式解析新增的MT759报文是基于独立保函、跟单信用证、备用信用证以及其他担保如从属性保函等基础结算方式而使用的格式化自由报文，与目前实务中使用的MT799报文相比，MT759报文通过设置固定格式、条款代码选择项以及报文检测使用规则明确了可以使用此报文的基础交易种类与报文用途，较MT799报文加长了报文条款录入的长度，增加了报文拆分规则，在满足实务需求的基础上实现了SWIFT报文的规范化管理。（一）明确了报文适用的基础交易类型。MT759报文明确规定其可用于Demand guarantee（独立保函）、Documentary credit（跟单信用证）、Standby letter of credit（备用信用证）和Undertaking (for example guarantee, surety）（其他担保方式如从属性保函）共4类基础交易，基本能够涵盖实务中贸易结算经常使用的几种主要方式。（二）明确了报文的用途分类。MT759报文以代码的形式明确设置了12种用途，且报文中必须以代码的形式展示，包含基础贸易客户服务、一般信息通知、自由形式保函（通常指从属性保函）的开立、修改和转让、偿付安排、融资安排、试图欺诈通知以及其他需求等。详细用途如下：代码用途CLSVOPENOpening of client service call by Trade OperationsCLSVCLOSClosing of client service call by Trade OperationsFRAUDMSGAdvice of a fraud attemptGENINFADGeneral information adviceISSAMENDAmendment of a free-form undertaking such as a dependent guaranteeISSUANCEIssue of a free-form undertaking such as a dependent guaranteeOTHERFNCOther requestREIMBURSRequest related to a reimbursementREQAMENDRequest to amend an undertakingREQFINANFinancing requestREQISSUERequest to issue an undertakingTRANSFERTransfer of a undertaking（三）细化了报文的检测和使用规则。MT759报文通过设置检测和使用规则限制了不同用途可以匹配的基础交易类型。主要规则如下：报文用途（23H)基础交易类型(22D)ISSUANCE, REQISSUE, REQAMEND, or ISSAMENDUNDKTRANSFERDGAR, STBY, or UNDKCLSVOPEN, CLSVCLOS, FRAUDMSG,GENINFAD, OTHERFNC, REIMBURS, orREQFINANDGAR, DOCR, STBY, or UNDK即当报文用途（23H）选择ISSUANCE（开立担保）,ISSAMEND（修改担保）、 REQISSUE（要求开立担保）, REQAMEND（要求修改担保）时，基础交易类型（22D）只能选择Undertaking (for example guarantee, surety）（其他保证方式如从属性保函），而Demand guarantee（独立保函）、Documentary credit（跟单信用证）、Standby letter of credit（备用信用证）是不适用的。报文实务中，如果出现23H选择issuance，22D选择undertaking，而报文主体内容为见索即付保函或备用信用证情形，应该如何认定该报文的类型和性质？SWIFT报文关于Undertaking选项的设计为将来付款责任的独立和从属性争议留有争议和不确定性，需要银行实务中特别关注。当报文用途选择TRANSFER（转让担保）时，基础交易类型（22D）适用除DOCR（信用证）以外的其他三种基础交易。其他7个报文用途可用于全部4种基础交易类型。与MT799相比，设置此规则的主要目的是规范报文的正确使用，防止实务中错用乱用MT759报文。原则上Demand guarantee（独立保函）、Documentary credit（跟单信用证）、Standby letter of credit（备用信用证）三种结算方式都有专门对应的报文类型可用于开立和修改，MT700报文和MT707报文可用于信用证（或备用证）的开立和修改，MT760和MT767可用于独立保函或备用证的开立和修改，因此无需也不能使用MT759报文进行开立和修改；MT720/721报文可以用于转让信用证，而其他三种基础交易没有专门的报文类型用于转让；其他7个用途可能会涉及以上4种基础交易，因此都允许使用MT759报文。（四）增加报文显示的长度和拆分规则。MT759报文较MT799报文加长了报文条款录入和显示的长度，MT799报文的NARRATIVE项只能录入35*50x个字符，而MT759报文可以录入150*65z个字符,字符数和字符种类增加；MT799报文过长时不能拆分显示成多个报文，而MT759报文最多可以通过27项以1!n/1!n的方式拆分显示为8个报文，基本可以满足实务中对报文显示长度的需求。二、报文逐项条款解析1、27 Sequence of Total（1!n/1!N，number/total）解析：此项内容用于显示MT759报文的报文序号和拆分数量，分母total显示拆分报文的总数，分子number代表报文的序号，一笔业务最多可以发送8个759报文，即此项数字的分母最大为8。实务影响：银行应配合做好交易录入字符数和报文拆分规则的系统设置，在报文长度超过字符容量时，自动将整体报文分解为多个报文，并依次排序，保证报文内容不重复，不冲突，并应保证报文的连续性和完整性。2、20 Transaction Reference Number(16x)和21 Related Reference Number(16x)解析：这两项条款和MT799等大多数报文的显示规则相同，字符规则为16位数字，其中20项为必须显示项。即MT759报文中需显示发报行和收报行相关的业务编号，以便于报文的识别和处理。实务影响：银行需结合各自业务操作系统做好业务编号的自动带入设置。结合实务需要，建议在系统中对21项收报行业务编号设置为可以手工录入的字段，以保证报文的准确展示。3、40A Form of Undertaking(4!C--DGAR/DOCR/STBY/UNDK)解析：此项用于显示报文的基础交易类型，为必须显示项，且只能以固定代码的形式展现，包含4个选择项，即：DGAR-Demand guarantee，DOCR-Documentary credit，STBY-Standby letter of credit，UNDK-Undertaking (for example guarantee, surety)，详细内容解析请参照报文格式解析第（一）部分。实务影响：银行可根据各自的系统设置特点设置此项条款的自动带入或者手工录入规则。如系统支持，可设置为通过交易名称自动识别为相应的交易代码并带入报文对应字段；也可在系统中设置字段，以下拉框的形式由业务人员手工选择正确代码。4、23 Undertaking Number（16x)解析：此项条款用于显示基础交易业务编号，为非必须显示项。实务中此编号可能会出现与20项编号相同的情况。如信用证编号下的查询沟通报文等，当然也可能不一致，如在信用证单据编号下处理的报文业务，20项编号显示为单据编号，但23项显示的是基础交易信用证业务的编号，因此建议银行根据实际业务种类设置显示正确的编号，也可通过个性设置选择是否显示此项编号。5、52a Issuer(A or D)解析：此项条款用于显示信用证、保函、备用证、担保或反担保的出具人，为非必须显示项，可以以SWIFT代码的A格式或者银行名称加地址的D格式展示。6、23H Function Of Message(8!C)解析：此项条款是MT759报文与MT799报文最大的区别，以固定代码的方式明确报文的12个可选择使用的用途，为必须显示项。详细用途使用规则和解析请参照第一部分报文格式分析的第（二）、（三）部分。实务影响：一是单证操作人员和客户应正确理解此条款中各项代码的具体用途，以便准确使用和把握报文内容。二是银行应做好系统录入方式和报文取值规则的设置，确保报文的正确显示和发送。7、45D Narrative(150*65z)解析：此项条款内容类似MT799报文的79项，用于描述报文的主体内容，为必须显示项。本次报文升级最重要的一个变化是将很多报文的录入字符规则由x字符变更为z字符，MT759报文则直接取用了z字符规则，很好地满足了实务对一些特殊字符的使用需求。实务影响：实务中MT759报文拆分为多个报文展示的功能主要与此项条款内容相关，因此银行应根据报文字符限制数的规则合理设置系统中此字段的录入字符总数和录入域内容的拆分规则，保证报文的连续性、准确性和完整性。8、23X File Identification（/4!c/65x）解析：此项条款用于描述附属文件的处理方式，必须以代码的形式展示，包括COUR、EMAL、FACT、FAXT、HOST、MAIL、OTHR等7种代码，并可以在代码后用不超过65个x字符描述文件的具体传输方式和相关信息。实务影响：银行单证人员应了解此条款的录入使用规则，建议银行可通过细化系统录入域的设置来规范此项内容的选择和具体内容录入。三、实务操作影响1、银行应做好新增报文的全面系统改造。MT759报文作为基于多种基础交易的新增自由报文，其与多种结算方式的多个交易都相关，因此银行在进行系统改造时应全面梳理4种基础交易类型涉及的全部交易，避免遗漏影响升级后报文的使用。在系统改造时可以比拟MT799报文覆盖的交易范围进行相应设置，以应对未来可能以MT759代替MT799报文的情况的发生。以进口信用证相关自由报文交易为例，目前很多银行使用MT799发送承兑报文，升级后不排除某些银行要求以MT759发送承兑报文的情况，因此也应优化设置单据承兑交易产生的报文类型。2、单证操作人员应尽早熟练掌握报文的使用规则。MT759报文更加标准化格式化，而且一旦报文升级投产后，可能很快会在实务中推广使用，这就要求单证操作人员应尽快熟悉MT759的条款项内容及使用规则，保证投产后报文的正确使用和发送。3、升级后正确使用MT759报文处理从属性保函的开立、修改和转让业务。目前实务中银行大多使用MT799报文完成从属性保函的开立、修改和转让，升级后则应逐步选择使用标准格式的MT759报文的相应用途完成交易。但是，SWIFT报文关于Undertaking选项的设计为将来付款责任的独立和从属性留下了争议和不确定性，需要银行实务中特别关注。