浅析MT999电文能否用于向偿付行索汇

在部分信用证业务中，指定银行确认相符交单后根据信用证条款会向偿付行电索汇。而如果指定银行与偿付行之间无SWIFT密押关系，则指定银行只能采用MT999电文的形式进行索汇。实务中，部分偿付行会以未建立密押关系为由而拒绝索汇要求。这种做法是否合理呢？下面将通过案例来进行具体解析。

案例背景

某开证行开立了一个即期自由议付信用证，部分条款如下：

78：银行间指示

+该信用证项下的银行间偿付遵循URR725行事

+议付行确认交单相符后向偿付行进行电索汇

受益人于6月10日提交单据至指定银行。指定银行经审核后确认单据相符后，于当日将单据寄送至开证行，并根据信用证条款向偿付行发送电文进行索汇。由于指定银行与偿付行之间无密押关系，故使用了MT999电文（自由格式报文）进行索汇处理，并在电文内容中声明“PLS TREAT THIS MSG AS MT742”（请将此电文视作MT742），同时列明索汇要求的相关事项和要素。四个工作日后，指定银行收到偿付行的电文，声称由于与指定银行无密押关系，MT999只是自由格式报文，不符合偿付行内部的政策要求，故拒绝指定银行的索汇要求。

指定银行认为该理由是不合理的，遂在与受益人沟通后，立即向开证行发电说明此情况，并催促开证行如若单证相符，请尽快安排付款。三个工作日后开证行回复电文称，正在与偿付行沟通解决此事，之后再无回应。为了保护客户的权益和指定银行的利益，指定银行随后多次发电催促，但直至7月2日，才收到开证行将由其进行全额付款的电文,并于次日收到该笔款项。而此时，距离受益人的交单已经过去了16个工作日，受益人对此次收汇的延迟表示不满。

案例分析

指定银行能否用MT999电文向偿付行进行索汇

这是本案例争议的焦点。首先，从SWIFT报文本身的功能看，相较于传统的电传密押，SWIFT密押仅在代理行之间相交换，可通过对全部文件加押，使其保密性和可靠性更高，是现代银行业普遍采用的收发报文系统。

根据《SWIFT报文标准实用手册》，第1类至第8类均为加押电报，第9类和第0类则不须加押。其中第7类的报文适用于跟单信用证和保函，但对于第9类电文能否用于付款或索偿，相关的国际惯例中并无规定。

实务中，某些银行间因未建立密押关系，故发送电文只能采用MT999格式。在这种情况下，MT999报文也常被应用于承兑、拒付、寄单通知等。本案例中MT999报文中已列明“PLS TREAT THIS MSG AS MT742”及索汇要求的相关事项和要素，已表明该电文要求索汇的实质。因此，基于实质大于形式的原则，我们应关注“索汇”这个动作本身的意义，因为“索汇”这一行为的实质已远远大于其形式。

另一方面，指定银行也需认识到，虽在电文内容上已将索汇意图及信息列明，但出于索汇业务的严肃性，各家银行的风控考量也不尽相同，因而实务中无密押形式的索汇电文存在很大的被拒绝风险。鉴此，案例中的指定银行应在其决定按指定行事之时，主动了解业务背景，提前与开证行沟通并告知此情况，设法化解可能存在的争议：若开证行与偿付行接受MT999形式的索汇，便可在出单时进行如上索汇；若不能接受，则可共同商议解决措施或单证相符时由开证行直接付款。

偿付行的操作是否合理

本案例中偿付行以无密押关系不能满足其行内政策为由，拒绝索汇要求。这主要是因为，偿付行认为指定银行的索偿要求是未经SWIFT AUTHENTICATED证实的，因此不能进行偿付。

首先，从银行间偿付的通用规则看，案例中信用证78栏中已明确表明“此信用证下的偿付行为遵循URR725行事”。URR725是规范和统一信用证业务项下银行间偿付业务的重要操作标准和依据，那么URR725对于索偿要求及其是否需要经过证实又是如何规定的呢？其第十条索偿要求的标准规定，“索偿行的索偿要求必须采用电讯方式，除非偿付授权书明确禁止，或者采用正本信函的方式，偿付行有权要求索偿要求须经过证实。在此种情况下，偿付行对因此发生的延误所导致的任何后果不承担责任”。 由此可见，偿付行是有权要求指定银行的索偿要求是经过证实的。但仅从URR725的规定来看，索偿要求需经过何种形式证实，以及证实的具体操作细节等却没有进一步的详细说明。