商榷ICC OPINION TA900rev

文/李钦 编辑/韩英彤

采用SWIFT开立信用证要求提交的保函，不涉及单据正副本问题，而是适用UCP还是eUCP的问题。

信用证下要求提交保函，在成套设备、大宗商品、工程承包等信用证领域运用广泛。保函作为一种担保手段，自身具有鲜明的特点，其适用规则与信用证迥异。如果保函与信用证结合使用，会增加其复杂性，也常引发争议。在2020年ICC春季会议上，意大利国家委员会提交的咨询案例，涉及通过SWIFT出具保函的争议问题。对意见草案的最终投票结果是，十八个参与投票的国家委员会中，十六票同意，两票反对。ICC遂正式以ICC OPINION TA900rev通过了该案例。鉴于信用证下要求提交保函非小概率事件，且ICC对该案例的分析和结论对实务存在影响。在学习该案例过程中，笔者认为ICC的分析还有需商榷之处，故撰写本文以便同业用ICC OPINION更好地指导实务操作。

案例简述

某开证行根据UCP600开立的信用证，除其他单据要求外，还要求提交由指定银行出具的以申请人为受益人的履约保函。

先于信用证所要求的单据提交的前几天，指定银行以SWIFT MT760格式开立了该保函，并发送给开证行，以便通知申请人。

受益人随后交单，其中信用证要求的履约保函，是SWIFT MT760纸质件。指定银行在规定时限内将全套单据转交给开证行。指定银行的寄单面函中将SWIFT MT760纸质件列为“副本银行保函”。

开证行收到单据后拒付了交单，其理由是提供的MT760为副本，而不是原件。几天后，受益人将印有正本章的SWIFT MT760纸质件再次提交，被开证行接受。

咨询者向ICC咨询的问题有二：一是开证行拒付是否成立。二是SWIFT MT760纸质件是否构成正本。

TA900rev的分析与结论

ICC认为，信用证要求（除其他单据外）提交由指定银行出具的以申请人为受益人的履约保函。虽然信用证没有说明履约保函的出具方式，但“银行通过SWIFT网络出具绝大多数保函和以纸质形式出具，是国际标准银行实务”。

ICC援引了R872 (TA861rev)号意见，在其分析中指出，“跟单信用证中规定的履约保函应根据UCP600第14(f)款进行审查。因此，开证行有责任在起草这种单据要求时尽可能准确”。

ICC继续分析说，对于这一具体咨询，履约保函由指定银行出具，并在信用证项下单据实际提交前几天以SWIFT MT760信息发送给开证行。当在信用证下提交单据时，它包括了开证行已经收到的MT760信息的打印（纸质）版本。指定银行的交单面函将该单据列为“副本银行保函”。开证行拒付了这一交单，理由是提交了MT760的副本，而不是原件。 随后，该单据增加了“正本”章被重新提交，被开证行接受。

ICC强调，根据UCP600第14(A)款规定，“按指定行事的指定银行、保兑行（如果有的话）及开证行须审核交单，并仅基于单据本身确定其是否在表面上构成相符交单”。换句话说，对单据的审查必须基于所提交的单据，而不是在任何随附的交单面函中如何描述。

ICC观点的关键在于，不可能以纸质形式提交MT760保函，因为它预先已经通过电子手段出具，即通过证实的SWIFT信息。因此，提交的纸质版是原件的物理反映，应予以相应处理。

ICC的最终结论是：（1）不符点不成立；（2）SWIFT MT760纸质件是否构成正本，不由UCP600定义，UCP600第17条中提到的正本和副本问题与此案无关。

值得商榷的五个问题

上述案例背景主要涉及采用SWIFT开立信用证要求提交的保函。ICC从几个方面对此进行了分析，并最终认可了受益人和指定银行的做法。ICC的分析部分，笔者认为有五个问题值得商榷。

问题一，信用证是否需要对单据出具方式进行约定。TA900rev的分析认为，“信用证没有说明履约保函的出具方式”；但笔者认为，履约保函既然作为信用证下要求提交的单据，对其的单据化要求应与对其他信用证要求的单据一样，即如果没有特殊规定，应出具一份纸质正本单据。其理由如下，一是ICC在《EUCP2.0版和EURC1.0版评述》中明确表示，“正如在UCP600中使用的那样，单据一词暗示了纸质介质的格式。 除非UCP600的条款和条件特别允许，预期在这种信用证下所有提交的都是纸质格式”。这表明UCP600的单据应为纸质。二是UCP600第十七条A款规定，“信用证规定的每一种单据须至少提交一份正本”，这是UCP600单据的正本性。结合上述两点，信用证下要求提交的单据，均应为纸质正本单据，除非信用证另有规定。因此，信用证将履约保函规定为必须提交的单据，其也必须是纸质正本保函。对此，信用证无需再对该保函出具方式进行特别约定。

问题二，什么是出具保函的国际标准银行实务。对此，TA900rev草案中的表述是“银行通过SWIFT网络出具保函是国际标准银行实务”。这样的表述完全不符合银行出具保函的实务，因为采用纸质方式出具正本保函比比皆是，而且部分保函受益人还特别要求以纸质形式出具保函，以方便将纸质形式的保函作为重要法律文件留存。笔者在草案讨论期间，对上述表述持反对态度。可喜的是正式版修改了上述表述，改为“银行通过SWIFT网络出具绝大多数保函和以纸质形式出具，是国际标准银行实务”。修改尊重了保函出具实务，将SWIFT出具和纸质出具，都平等视为国际标准银行实务。但需要注意的是，单独出具保函，与信用证下作为要求提交的单据出具保函，还是有不同之处的：后者最大的差异是默认纸质正本。

问题三，ICC OPINION R872 (TA861rev)的分析是否适用本案。TA900rev的分析援引了TA861rev的分析部分：“跟单信用证中规定的履约保函应根据UCP600第14(f)款进行审查。因此，开证行有责任在起草这种单据要求时尽可能准确。”但TA861rev案例背景是提交的保函包含有不由保函受益人控制的效期缩短和保函金额减少条款，因此，ICC在其分析部分指出。“……开证行有责任在起草这种单据要求时尽可能准确。单据审核员应检查履约保函中的数据是否与信用证中的数据相冲突，虽然表面上可以不需要等同，但必须在上下文进行读取”。ICC认为，效期缩短条款和保函金额减少条款与信用证效期金额要求构成矛盾。而TA900rev案并不涉及提交保函内容与信用证规定不一致的问题，因此TA861rev案例并不适用本案背景。

问题四，开证行预先收到SWIFT MT760存在哪些窘境。TA900rev的分析认为，“对于这一具体咨询，履约保函由指定银行出具，并在信用证项下单据实际提交前几天以SWIFT MT760信息发送给开证行。开证行似乎没有争议他们收到的MT760，也没有声明这种出具方法是不可接受的”。据笔者的实务经验，当一家银行收到SWIFT MT760信息，一般是由保函部门进行处理而非信用证部门。绝大多数情况下，保函部门只会将该MT760按照普通通知保函流程进行处理，并及时通知该保函受益人（即信用证下的申请人），保函部门不会争议收到的MT760和这种出具方法。但信用证下要求提交的保函，采用这样的出具方式，会使开证行陷入窘境。例如开证行是否需要把收到的SWIFT MT760当作一次交单；开证行是否需要按照信用证审核SWIFT MT760的内容；如果发现SWIFT MT760的内容与信用证不一致，开证行怎样拒付；如果SWIFT MT760与之后收到的SWIFT MT760纸质件内容不一致，以谁为准；开证行收到的SWIFT MT760，怎样才能归于正确信用证下等等。出现这些操作性问题，不只是采用SWIFT MT760出具保函后提交MT760纸质件判断正副本的问题，深层次的问题是受UCP600约束的单据，是否可以采用SWIFT出具和提交的问题。

问题五，要求纸质方式出具，是否允许自行以电子方式出具。TA900rev的分析认为，“不可能以纸质形式提交MT760保函，因为它预先已经通过电子手段出具，即通过证实的SWIFT信息”。ICC的这段分析，说到了本案例的关键点和本质点，即受UCP600约束的信用证，受益人是否允许自行采用电子方式出具并提交单据。笔者的答复是否。笔者认为，采用SWIFT开立信用证要求提交的保函，不涉及单据正副本问题，而是适用于UCP还是eUCP的问题，理由如下：一是联合国国际贸易法委员会的《电子商务示范法》将数据信息定义为“通过电子、光学或类似手段生成、发送、接收或存储的信息，包括但不限于电子数据交换（EDI）、电子邮件、电报、电传或传真”。该委员会的《电子可转让记录示范法》则将电子记录定义为“通过电子手段生成、传达、接收或存储的信息，包括（适当时）逻辑上与记录相关联或以其他方式链接在一起，从而成为记录的一部分的所有信息，而无论这些信息是否同时生成”。换言之，电传件、传真件、电子邮件都可以在满足条件下成为电子记录，何况SWIFT信息属于电子数据交换（EDI）信息，更是电子记录。而电子记录的提交，属于eUCP2.0的范畴。二是ICC近期发布的《关于Covid-19对受国际商会规则约束的贸易融资交易影响的指导文件》指出，“就遵循UCP600的存量信用证而言，如果商业当事人打算从纸质文件改为电子记录，他们可以通过同意将信用证从遵循UCP600修改为遵循eUCP 2.0版本。扫描单据属于eUCP 2.0版本中电子记录的定义范围，但是需要满足eUCP第e6条中提到的证实要求。同样，在跟单托收项下，各方也可约定使用eURC 1.0版本的电子记录，但需要满足eURC第e7条中提到的证实要求”。上述观点进一步佐证了扫描单据满足证实要求后，即为电子记录而适用eUCP。三是SWIFT MT760开立的保函，ICC自己也认为是“已通过电子手段出具，即通过证实的SWIFT信息”，因此，SWIFT MT760开立的保函，完完全全属于经证实的电子记录。这表明，本案例产生的问题和不符，不是正副本的问题，而是受UCP约束的信用证，指定银行擅自提交了受eUCP约束的电子单据（即SWIFT MT760信息）的问题。这在UCP600下是禁止的，除非修改适用的规则。

相关建议

虽然ICC OPINION TA900rev已正式通过，ICC认可了信用证下保函先通过SWIFT MT760开立，后提交SWIFT MT760纸质件这样的交单方式，但笔者认为，此案中ICC的分析值得商榷之处颇多，如此交单方式存在诸多风险，会使开证行陷入窘境；更重要的是涉及规则适用性的问题。为更好地指导实务，笔者特提出以下几种解决方案，供同业在具体操作中选择采用：

一是在信用证条款中增加出具方式。TA900rev的分析认为信用证没有说明履约保函的出具方式。虽然笔者对此并不认可，但鉴于该案例已正式通过,如果申请人的真实意图是要求提交纸质正本保函，保险起见，建议在信用证条款中增加“由指定银行出具以申请人为受益人的纸质正本履约保函”的规定。

二是在信用证条款中允许SWIFT交单。鉴于银行通过SWIFT网络出具绝大多数保函是实务事实，如果申请人同意指定银行通过SWIFT网络出具保函，建议在信用证明确，“由指定银行通过SWIFT出具以申请人为受益人的履约保函，随附提交SWIFT MT760副本”。

三是采用eUCP交单。由于SWIFT MT760开立的保函属于电子记录，笔者更倾向建议将规则由UCP600改为eUCP2.0，信用证中仅规定“指定银行通过SWIFT出具以申请人为受益人的履约保函”。这样信用证就变成适用eUCP2.0的混合交单模式。受益人通过SWIFT发出履约保函后，向指定银行提交其他纸质单据时，是需要提交交单完成通知的，这样开证行遭遇的窘境，如开证行是否需要把收到的SWIFT MT760当作一次交单；开证行是否需要按照信用证审核SWIFT MT760的内容；如果发现SWIFT MT760的内容与信用证不一致，开证行怎样拒付；开证行收到的SWIFT MT760，怎样才能归于信用证下等问题，都会一一化解。

四是待受益人满足保函要求后再开证或电汇。毕竟保函作为一种担保手段，具有自身鲜明特点，其适用规则与信用证也不同。因而保函作为一种单据在信用证下提交，会增加其复杂性。此外，信用证下对保函的单据化要求比较简单，一般只涉及出具人、保函受益人、保函金额、保函期限等内容，未必能满足信用证申请人的全部要求，一旦出现问题，容易引起争议。鉴此，笔者还是建议保函与信用证分离，保函单独提交给信用证下的申请人，待申请人审核保函内容并加以确认后，再申请开立信用证或直接电汇。这样就会大大减少出现争议的可能性。