淺析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所強調的“信用證系付款工具而非拒付工具”的觀點，在實務中通過積極思考、主動溝通、完善業務流程，來促進貿易的順利展開，不斷提高業務處理效率與客戶的滿意度。