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

从实务操作来看，若交单行与偿付行未建立密押关系，通过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的规定来看，索偿要求需经过何种形式证实，以及证实的具体操作细节等却没有进一步的详细说明。

因此从索汇业务的严肃性来看，处于风险把控的考虑，偿付行是有权利要求偿付需经过证实的。但从便利各方而言，案例中的偿付行若认为一份无密押的报文不能满足其内部风控的要求，应主动与开证行沟通，并在“偿付承诺”中明确列明索偿要求需要被证实，及以何种形式进行证实，还要保证当偿付承诺中所规定的条件得到满足时，对索偿行进行偿付。

其次，从业务处理的时效性来看，案例中偿付行操作也稍欠稳妥。该偿付行于收到报文后的四个工作日才发电告知拒绝索汇要求，而根据URR725第11条的规定，“偿付行应在收到索偿要求后不超过3个银行工作日内处理索偿要求”。

开证行的操作是否恰当

UCP600虽未对偿付行作任何规定，但根据“谁指示、谁负责”的原则，偿付行是根据开证行的授权行事，若未能按规定履行其偿付职能，则开证行作为委托方应当承担责任。根据UCP600第13（b）（ⅲ）条关于“如果偿付行未按信用证条款见索即偿，开证行将承担利息损失以及产生的任何其他费用”的规定以及第13（c）条关于“如果偿付行未能见索即偿，开证行不能免除偿付责任”的规定，本案例中开证行的责任是不可推脱的。这意味着案例中的收汇延迟导致的利息损失，是可以向开证行进行追索的。

虽然从表面上看，本案例中的信用证条款没有表述不清或者模棱两可的地方,但结合银行实务分析则不难发现，该开证行在偿付安排和信用证的开立上是欠妥的。案例中指定银行根据信用证条款向开证行寄送相符单据并向偿付行索偿，按照URR725的规定，开证行应事先向偿付行提供偿付授权书，偿付行据此对收到的索偿要求进行偿付。然而经过后期与开证行的多番电文沟通后发现，开证行对于偿付行不接受MT999格式的索汇要求并不知情。由此可以推测，开证行与偿付行之间的偿付授权书和偿付承诺的具体条款和要素并不完善清晰，继而导致在信用证开立时未能将“索汇电文需证实”这一要素通过信用证条款的方式得以充分体现，最终引起此次争议问题的发生。

ISBP745“预先考虑事项”中明确要求，“开证行应确保其所开立的任何信用证或修改的条款没有模糊不清或互相矛盾之处”。因此在开立信用证时，建议开证行妥善处理信用证条款，通过充分沟通了解其他被指示方的需求，与偿付行间进行及时交流，特别是涉及偿付安排的规定，要全面清晰，避免出现模糊不清之处。就本案例而言，若偿付行确实存在“索偿要求须经证实”的需求，建议开证行在信用证开立时应予以明确体现，在信用证中加入相关条款，如“请通过加押电文进行索汇”或“本信用证下的索汇仅限于有代理行密押关系的银行”。此外还可以通过“允许信索汇”的形式，以“ IF YOU HAVE NO RMA WITH THE REIMBURSING BANK, YOU MAY FORWARD YOUR CLAIM VIA MAIL FORMAT UNDER SWIFT ADVICE TO US”（若与偿付行无密押关系，请信索汇并发电告知开证行），赋予信用证实务操作的灵活性。

另外从开证行后续的处理来看，在收到指定银行的电文后并没有及时主动地沟通解决问题，而是在指定银行的多次催付款电文后，才进行最后的付款。这不仅影响贸易的顺利推进，也有损开证行的声誉。

操作建议

从实务操作来看，若交单行与偿付行未建立密押关系，则通过MT999电文索汇确有一定的风险。应对之策除了在电文内容中列明索汇相关信息与关键要素外，指定银行还应提前与开证行沟通，发电告知索汇详情及与偿付行无密押的情况，以方便开证行与偿付行沟通偿付事宜，或单据相符后直接借记开证行账户，最大程度地减少各银行间反复沟通而造成的时间成本。

对于开证行和偿付行来说，若认为MT999索汇要求的电讯授权控制级别过低，则可在信用证开立之时便明确加以说明，在条款中提出“索偿要求须经证实”以及具体的证实方式，以便于后续操作和结算的顺利展开。

银行处理信用证业务，应在严格把握风险的同时做到具体问题具体分析，摆脱旧有的固化观念，充分体现ICC所强调的“信用证系付款工具而非拒付工具”的观点，在实务中通过积极思考、主动沟通、完善业务流程，来促进贸易的顺利展开，不断提高业务处理效率与客户的满意度。