An article-by-article analysis of eUCP variant 2.0 and eURC version 1.0 to explain for the new guidelines.
|Definitions||UCP 600||eUCP Version 2.0|
|Definitions||Where not defined or amended in the eUCP, definitions given in UCP 600 will continue to apply||Where terms are also used in UCP 600, definitions are updated for application to an electronic record|
|Scope||Paper documents (and electronic records if strictly defined, although UCP 600 only provides limited protection)||Electronic records alone or in combination with paper documents|
|Application||UCP 600||UCP 600 & eUCP Version 2.0|
|Relationship||UCP 600||In event of conflict, eUCP prevails|
|Presentation of only paper documents||UCP 600||UCP 600|
|Documents examined on their face||Review of data within a document in order to determine that a presentation complies with international standard banking practice and the principles contained in UCP||Electronic records are examined only for the data received and not the reality that such data represents|
|Document||The term suggests format in a paper medium: unless specifically allowed under the terms and conditions of a UCP 600 credit, it is expected that all presentations under such a credit be in a paper format||Adds the term ‘electronic record’ to the meaning||Place for presentation||The place where the documentary credit is available||Extends the phrase to include an electronic address||Data Processing System||Not necessarily used||A computerised or an electronic or any other automated means used to process and manipulate data, initiate an action or respond to data messages or performances in whole or in part||Electronic signature||Not specifically defined: article 3 highlights that ‘a document may be signed by handwriting, facsimile signature, perforated signature, stamp, symbol, or any other mechanical or electronic method of authentication’||Data attached to an electronic record with the intent of identifying the signer and authenticating the record||Format||Unless specifically stated otherwise, expected to be paper||The protocol by which data is organised, the version of that format, or the shorthand name by which that protocol is recognised and described||Paper document||Unless otherwise stipulated, assumption is that all ‘documents’ are in a paper medium: however, as is often the case with UCP 600, this fundamental assumption is not stated expressly and, instead, the term ‘document’ is used||Refers to a document in a paper medium, the type of document which is expected to be presented under UCP 600||Authentication||The process by which the validity of the representations and the paper documents containing them are ascertained: under UCP 600, the level of authentication of paper documents is facial||Identifying the person sending a message and the source of the message, and associating the person authenticating with the content of the message authenticated||Goods, Services or Performance||Banks deal with documents and not with goods, services or performance to which the documents may relate||Also addresses electronic records||Notice of completeness||Not applicable||Presentation does not take place until the presenter provides a notice of completeness to the nominated bank, confirming bank, if any, or to the issuing bank||Time for examination||Once presentation is made to an issuing or confirming bank, the time for examination commences||Electronic records may be presented separately and, even if paper documents are presented in one lot, they must be coordinated with the electronic records: the time for the examination of documents does not commence until the notice of completeness is received||Period for examination||Maximum of five banking days following the day of presentation to determine if a presentation is complying||Remains applicable||Approach by the issuing bank to the applicant in order to seek a waiver of discrepancies||UCP 600 sub-article 16 (b) (Discrepant Documents, Waiver and Notice)||Remains applicable||Notice process for discrepant documents||UCP 600 sub-article 16 (b) (Discrepant Documents, Waiver and Notice)||Remains applicable||Disposition of documents in event no instructions received subsequent to notice of refusal||Paper documents can be held or returned||Paper documents can be held or returned||Originals and copies||UCP 600 sub-articles 17 (b) and (c)||Any requirement for an original is satisfied by the presentation of one electronic record: in the event of a requirement for multiple copies, the condition will be fulfilled by presentation of one electronic record||Date of issuance||Requirement for a document to be dated is with respect to the identification of certain dates on transport and insurance documents. In addition, there are expectations that other documents, such as statements or certifications, must contain a date. ISBP 745 goes into more detail as to documentary requirements under UCP 600. Credits may also contain a specific requirement that a document be dated||Effectively dates electronic records, with the result that all such records must be dated: if there is to be any other way of determining the date of issuance then this will be for the eUCP credit itself to determine||Date of shipment or dispatch or taking in charge or a date the goods were accepted for carriage||Contains elaborate rules for determining the date of shipment or dispatch that are individualised according to the type of transport document involved||Date of shipment is the date in the electronic transport record indicating shipment or dispatch or taking in charge or the goods were accepted for carriage. If there is no date indicating shipment or dispatch or taking in charge or goods accepted for carriage, the date of shipment or dispatch is the date of issuance of the electronic transport record unless there is a notation evidencing shipment or dispatch or taking in charge or goods accepted for carriage||Data corruption||No rule for paper documents that are lost or rendered unreadable by a bank after they have been received; most banks have procedures in place that minimise the consequences of such loss and there is no perceived need for such a rule. These procedures involve refusing payment based on discrepancies in the documents that are presented, requesting a substitute document, or indemnifying the applicant for any harm that may result from the lost document||Provides a method by which corrupted data may be re- presented; based on the assumption that all electronic records are replaceable||Disclaimers||Contains several disclaimers that are also relevant to an eUCP credit||Additionally, disclaims banks’ liability for any divergence from the realities represented in authenticated electronic records||Force Majeure||States the force majeure events for which a bank assumes no liability or responsibility||Extended to cover the inability of a bank to access a data processing system, or a failure of equipment, software or communications network|
ARTICLE E13—ADDITIONAL DISCLAIMER OF LIABILITY FOR PRESENTATION OF ELECTRONIC RECORDS UNDER eUCP
A disclaimer is a device by which risk is shifted from one entity to another. Where the disclaimer reflects the reasonable expectations of an industry, it is typically enforceable under applicable local law, even where it is stated in rules of practice as opposed to a bilateral contract.
Due to the limited role of banks in documentary credit practice, disclaimers have been used to limit their liability from
the actions or omissions of others. Disclaimers have sometimes been asserted to excuse the responsibility of a bank for its own negligence. While modern commercial law allows parties to allocate the risk of negligence up to, but not including, so-called gross negligence or wilful disregard for the consequences of one’s action or omission, most systems of local law require more specific and detailed provisions than those contained in UCP 600 to achieve this result. The liabilities disclaimed in the eUCP and UCP 600 are the result of external systemic or third-party actions, inactions, or risk.
This article disclaims banks’ liability for any divergence from the realities represented in authenticated electronic records.
Its effect is cumulative with those of UCP 600 Articles 34 (Disclaimer on Effectiveness of Documents), 35 (Disclaimer on Transmission and Translation), and 37 (Disclaimer for Acts of an Instructed Party), and emphasises the continued applicability of the independence principle reflected in various articles of UCP 600 with respect to electronic presentations under the eUCP.
Data processing system.
This article refers ‘to the use of a data processing system for the receipt, authentication, and identification of electronic records.’ This means ‘a computerised or an electronic or any other automated means used to process and manipulate data, initiate an action or respond to data messages or performances in whole or in part.’ Any bank that engages in an eUCP transaction is responsible for maintaining a data processing system. This responsibility is a fundamental precondition for using the eUCP.
A bank cannot excuse itself from responsibility for the failure to authenticate electronic records due to errors or inadequacies
in its systems where those systems are not of the standard required to process such electronic records.
This formulation also imposes on banks that engage in processing electronic documentary credits the burden of upgrading their systems to keep them current. This article does not require a level of authentication that is extraordinary even if it were technically feasible. While some banks may choose to develop and market such systems, such a feature is a value-added aspect of their service and not a basis for the standard by which authentication is to be measured. The standard of the article is only designed to assure that the system used is not outmoded. The liabilities disclaimed in the eUCP and UCP 600 are the result of external systemic or third-party actions, inactions, or risk. Reflecting the content of URBPO 750 article 14 (Unavailability of a Transaction Matching Application), eUCP sub-article e13 (b) indicates that a bank does take on liability and responsibility for the unavailability of its own data processing system.