商榷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，怎樣才能歸于信用證下等問題，都會一一化解。

四是待受益人滿足保函要求后再開證或電匯。畢竟保函作為一種擔保手段，具有自身鮮明特點，其適用規則與信用證也不同。因而保函作為一種單據在信用證下提交，會增加其復雜性。此外，信用證下對保函的單據化要求比較簡單，一般只涉及出具人、保函受益人、保函金額、保函期限等內容，未必能滿足信用證申請人的全部要求，一旦出現問題，容易引起爭議。鑒此，筆者還是建議保函與信用證分離，保函單獨提交給信用證下的申請人，待申請人審核保函內容并加以確認后，再申請開立信用證或直接電匯。這樣就會大大減少出現爭議的可能性。