Seldomly Asked Questions
Use cases
In Trade Finance, is trace:original primarily targeted at suppliers and buyers or at financiers?
In developing trace:original, we targeted the creator and recipient of the digital original document. Such parties may be suppliers, buyers, or financiers.
The digital document itself is content-agnostic. The creator defines the content, adds their digital signature, and then transfers possession of the document to a recipient. The recipient is able to read, validate and gain possession of the digitally signed document in the certain knowledge that they are now the sole owner of the original and that the content has not been tampered with in any way.
The recipient can add additional content, if appropriate, and can transfer possession of the original back to the creator or to another party cost-free.
All the recipient needs in order to receive or transfer the original document is internet access.
The Enigio trace:original solution seems to focus on negotiable instruments and documents of title which are broadly autonomous from any associated trade transactions. Can the solution also be used for other types of documents?
We have focused on negotiable instruments and documents of title as these have, until now, been impossible to digitise. In reality, any original document can be digitised using our technology.
The unique functionality of trace:original is that the essential properties of a paper document are preserved, but with the significant advantages of being in digital form. These properties include the ability to distinguish between an original and a copy and to transfer possession of the document by delivery to the recipient.
Anything that is evidenced today in an original paper document can be recreated in digital form using trace:original. The universal accessibility and portability of paper documents are preserved but the digital original offers significant additional advantages, relative to the paper. These include:
- Cost and efficiency benefits (associated with creation, storage, retrieval, and physical delivery).
- Business continuity benefits (physical delivery and checking of paper documents have severely been impacted by COVID-19, for example).
- Fraud prevention (the use of cryptographic fingerprints and public/private key pairs underpinned by a blockchain-based notary function is infinitely more secure than paper)
- Environmental benefits (printing and moving vast quantities of paper around the world promotes deforestation and leaves a huge carbon footprint).
Can trace:original be used for digitising warehouse receipts?
The trace:original document would be very suitable for warehouse receipts or indeed for any type of receipts. Furthermore, as the document holds the full incorruptible audit trail of everything that has been written or added to it, the registration of attornments in the document would work well.
Is there a threshold in number of documents before it is worthwhile considering trace:original
There is no threshold in number of documents. The solution is easy to start using so it will make sense to anyone.
What are the key questions one should ask before looking at trace:original?
Do you still use paper documents? If yes, this is the main reason for doing so. Do you think that there is no digital solution available that is satisfactory to all i.e. the business, operations, legal, risk, compliance and IT? Do you have a very small budget but still want to try out the latest digital technology? If you answer yes to any of these questions you should definitely take a look at trace:original!
What is a typical timeline for a customer to onboard trace:original for use?
The timeline is very short. All can be set up in less than two weeks if set up by Enigio.
How can document checking companies and Enigio work together? How would the flow be?
The flow will be the same as it is today. The only difference is that a trace:original document is 100% digital and is therefore fully read by the document checking company software (no risk of missing any data as is the case for documents that have been read by OCR). In addition, a trace:original document can be issued with the data in a predefined JSON schema which means that it can also be auto processed.
Technology
How does the system work? Does each user have to create an “Enigio digital wallet” (or similar) that they have to sign in to every time they wish to transfer a digital document?
A user or a holder does not necessarily need a digital wallet. Most banks and larger corporates already have an infrastructure in place to handle cryptographic key pairs and electronic documents in a safe way.
For less frequent users there are several software solutions (wallets) and Hardware Secure Modules (HSM) solutions available. This is an industry on its own.
The responsibility for having a secure IT environment for storage rests with the holder of the document. A transfer is made by linking the document to the public key of the future holder. This is done by:
- Writing the new holder’s “public key” in the document (the file),
- Registering the new cryptographic properties of the document on the Distributed Ledger, and
- Transferring the new version of the original document to the new holder.
trace:original provides the mechanism for transfer but does not deliver specific software for interaction. This is the responsibility of the transacting parties. If a user wants to automate workflows this should be done in back-office and front-office systems using the APIs provided by Enigio.
As of today, the use of trace:original is aimed at large volume industrial users, hence the handling of keys and documents will in most cases be handled in back-office systems using HSMs. All banks and all larger organisations use cryptographic key pairs today in their IT operations to manage their day to day business to ensure integrity when different servers are connected to each other.
HSMs are standard products and there are versions designed for companies of all sizes.
For users that want to handle small volumes of documents, there are “hardware keys” that can be stored in a safe and inserted to a USB port when a document needs to be managed. The holder of a document could also use a wallet by his or her own choice.
If trace:original was to be introduced as a “retail” product we would probably launch a multi-tenant solution to make the handling smooth.
Today our primary focus is on B2B.
Is the certainty as to who is the “holder” or who has “possession” of a trace:original documents from time to time dependent on the continuation of the Enigio DLT?
We use open-source and follow industry standards regarding hash algorithms and asymmetric key pairs so the owner of a trace:original digital document is not dependent on Enigio to verify the authenticity of a document or to prove their ownership.
If Enigio were to go out of business, then the Full Node licence holders would continue to operate the ledger and would take over the operation of the Ledger Node. All licence holders will have full documentation of the entire trace:original system. Members will have the software installed and we presume they would like to have the code in escrow.
The trace:original document itself is not stored in the distributed ledger, how does this work?
The document is stored ‘off-chain’ but the cryptographic evidence, the hashes, public keys, and technical signatures are filed on the ledger. The proof of existence, originality, provenance, and ownership of a document is recorded on the ledger, but the contents of the document are not.
This makes trace:original attractive from a GDPR perspective as no business data is published on the leger. A company that wants to prove that they have complied with GDPR can use the cryptographic evidence to prove when documents are deleted and where the data was stored.
The owner of the private key and the trace:original document in combination is the only one that can write and add content to the document. How does the ability to “write and add content to the document” affect a document’s authenticity? Does it give rise to the risk of fraud?
The best way to illustrate how the integrity and authenticity of a trace:original document are preserved, mitigating the risk of fraud, is by example.
If a trace:original document is created and digitally signed, its content and the resulting obligations on the signatory cannot be amended or modified in any way by any other party. This includes a party to whom the trace:original document has been transferred.
The new owner of the trace:original document can add text to the document, but such text is not covered by the digital signature added by the creator. In other words, the signature only binds the signatory in respect of the obligations articulated in the trace:original document at the time the digital signature is added.
The analogy in the paper world is that a party signs a document, for example, in which they undertake to deliver a package to a recipient on a specified day. They hand the document to the recipient who then writes on the document words to the effect that the package will be delivered to a different destination on a different day. The creator that signed the document is not bound by the additional text added by the new owner of the document.
To stretch the analogy further, in the paper world it might be difficult if not impossible to prove that the additional text was added after the document had been signed, leading to a dispute between the creator and the recipient of the document. Using trace:original, such confusion is impossible as the sequence of actions in respect of the document is evident in the document itself. In reality, therefore, trace:original offers far greater fraud protection than is possible in the paper world.
In the paper world, certain documents are recognised in law as having an intrinsic value and a life cycle. A bill of exchange, for example, is signed by the drawer, who is liable to the payee and any subsequent indorsees should the bill be dishonoured by the drawee. Each indorser is also liable should the bill be dishonoured by the drawee. The bill may then be accepted by the drawee, creating an unconditional, irrevocable, and independent undertaking to pay the holder at maturity.
The point here is that all of these actions added to the document occur after the creator had originally signed it as a drawer. The drawer remains liable notwithstanding the subsequent additions to the document (unless, of course, the bill was drawn ‘to order’ and the first indorsement by the drawer is ‘without recourse’).
This is governed by the Bills of Exchange Act 1882 in England and Wales and by similar legislation in most parts of the world, hence the popularity of the instrument in trade finance.
Once a trace:original negotiable instrument is recognised in law as a bill of exchange, it will behave in exactly the same way as the traditional paper equivalent.
Which underlying DLT system does trace:original use?
The distributed ledger is a proprietary solution, built by Enigio for the trace:original solution. Our philosophy is that if something is built for one single purpose, you can achieve higher security, scalability, and operational robustness than if you build solutions on infrastructure that is not built for the purpose.
Enigio has created "templates" of document types (such as the bill of exchange) with different fields that can be filled. How effective is the solution when it comes to global adoption, considering the fact that most documents in finance are not standardised yet?
The principle of the document is that it is “digital paper” so as a base, you can write whatever you want in the document as free-text and without any specific data structures. We are not creating or dealing with old or new templates per see but any template can easily be used and incorporated into a trace:original document.
The document source is created as a structured text document in the form of YAML file. We have created the possibility to create schemas (JSON) or “templates” as the questions states, that require certain data fields for a specific type of document to be valid. Enigio has started creating some basic schemas that can be used or enhanced, like e.g. basic agreement, bill of exchange, business loan, mortgage, electronic payment undertaking etc. These schemas created by Enigio are published here: https://schema.traceoriginal.com
The possibility to create own schemas is in-line with the “digital paper” concept. It means that schemas do not have to be necessarily created by us, they can be created by anyone, either as an extension to an existing schema or as a new base (note, all schemas need to inherit from the latest trace:original base schema https://schema.traceoriginal.com/trace-original-en-schema-v1.2.json )
The ITFA ePU is a good example. We are also working closely with BAFT on using their 13 data points in the DLPC (Digital Ledger Payment Commitment) as a standard to be used in a trace:original document.
You can write free-text and also create “data forms” to be filled in the document. As these data forms can be interpreted by machines, the content of a schema and the data in a document following a schema can be read and processed by computers without OCR.
Therefore, considering the fact that trace:original does not require users to integrate a specific schema/data fields rather allows them to use any schemas of their choice, the solution can be adopted globally even if most documents in finance are not standardised yet.
Does Enigio have a partner for OCR, or is it internal developments to turn a physical document into an Enigio format electronic document?
Digital originals have to be “born digital”. So, there is no secure way of “transforming” a physical original to a digital one. It is possible to discard a physical original and issue a new digital original based on the physical, but it will not be the same original.
It is possible to “print” a PDF as a digital original. But there is no current generic functionality to extract data from a PDF and convert that into an Enigio data format document (based on a JSON Schema). If you want to have a data format base of the document, the document can be created with the data format and the PDF is created out of that. In that case, the original is a combination of a data file (YAML) and a PDF, where the PDF is a nice human-readable representation of the Data which is in the YAML and that can be read and processed by machines without OCR and with 100% accuracy.
What are the different fields a user can fill in a trace:original document? Do the "templates" have mandatory fields for each type of documents, or the users can add and fill any data field they want? If the platform allows users only to fill in mandatory fields, would it be possible for them to suggest more fields to add to some types of documents in order to process more data points?
As described above about templates, if a document should be/has been created with an associated data-schema the system validates that any mandatory fields are filled in for the document to be accepted/correct. Fields do not have to be mandatory.
Also, as described above, the fields are decided by the one creating the JSON schema. If you like a schema, for example, the bill of exchange schema, but would want to add some more fields, you can create an extended schema that inherits from the BoE schema. Everyone that would receive your BoE and recognise the base schema will be able to interpret those fields and the systems knowing the extended data in your schema can handle those as well.
Enigio's blockchain seems to have only one node, how come you chose to create one and why didn't you just work with an existing platform on that matter?
As you can see explained below our system does not have only one node. The reason why we have not built our application on an existing open platform, as of now, is that when we started building trace:original we evaluated existing projects but did not find any of them “ready enough”, “fast enough” or “sustainable enough” at the time and none was specifically suitable for our application.
The trace:original system is really a combined application and core DLT platform where the DLT platform has been developed solely for the target at hand. You cannot build another distributed application on the trace:original ledger by creating new own “smart contracts”. The smart contracts are hard-wired into the application and ledger and the control for the user of how documents should work can be created with the JSON document schemas or by building trace:original document applications on top of the trace:original node API:s.
We have four types of nodes;
-
Ledger node - this type of node has a notary and governance responsibility of the ledger, e.g. making sure that only registered Fullnodes can create new digital paper. Also, it facilitates the distribution of ledger events and publications on “outside network” public places like e.g. GitHub. The LedgerNode though cannot “steal” documents as it does not have access to owner-keys or wallets in the other nodes. It cannot manipulate or control any events in the ledger without that being instantly recognised by all other connected Fullnodes.
- Public Node - this is really a web-application which is free for everyone with Internet access to use and everyone who does not have an own node on the network. By using the Public node (at https://traceoriginal.com), anyone can validate documents and manage owned documents without installing a node or creating an account. This is a primary feature for the “free transferability”.
- Full node - The Fullnode is a registered node (and customer to Enigio or a Partner) with the right to create new “digital paper” on which documents can be “printed”. The Fullnode also have a responsibility to continuously audit and sign-off the accuracy of the ledger. The Fullnode holds a full own ledger instance which is iteratively growing and validated. The Fullnode has to do “proof of work” for each block and sign off the validity of each block to continue to be allowed to operate on the ledger by the LedgerNode.
- Stakeholder node - In principle the same functionality as the Fullnode but with no rights to create “digital paper” only receive originals and manage all other operations on originals. The Stakeholder node does not have the same obligation to “audit” and sign of the ledger for each block (as the Fullnode) to have access to document operations.
Could it be possible to see the list of the schemas you've done in terms of document templates?
These are not “document templates” but JSON schemas which can control the structure and data that are mandatory for a document created with the schema. https://schema.traceoriginal.com
Does trace:original use NFT to ensure the document is an original copy?
Yes and no. There is an NFT but the trace:original solution is unique compared to regular NFT solutions as it has a non-fungible asset, the document, connected with the token and ledger that can be updated with new content and secured audit trail integrity both in the document itself and in the ledger.
Each created trace:original document gets a unique id logged both in the document file and in the public ledger called the trace:original ID.
At each time and for each current version of the original document file, the associated latest entry for the document in the ledger has a unique associated owner which is also logged in the latest version of the document file.
Where is the trace:original solution hosted?
The solution can be hosted with the customer on-prem or in their cloud, or by Enigio as a SaaS in a dedicated customer cloud account in a local region on AWS.
I am assuming this solution uses DLT for storage to ensure trace. Some of the banks in APAC have embarked on this journey with Contour. Assuming this solution competes with Contour?
Enigio is not storing documents on a DLT; the documents are stored by the customer. Only cryptographic references are published on the DLT. The solution is not competing with Contour but is an excellent complement.
Legal
Does trace:original achieve legal recognition of the digital documents as negotiable instruments in the same way that equivalent paper-based instruments are recognised? Has any legal advice been obtained in this regard in any of the main international jurisdictions?
Any user would need to obtain legal advice in the relevant jurisdictions to satisfy themselves that the trace:original document enjoys the same status in law as the paper document equivalent.
As a general principle, provided the relevant legislation does not explicitly require that a negotiable instrument must be in the form of a paper document, then a digital document should be acceptable so long as it meets certain criteria.
We have obtained a legal opinion in respect of several jurisdictions including England and Wales, New York, and Sweden and this is an ongoing process.
EU
In most EU countries, the word ‘paper’ is not used in the legislation for bills of exchange or promissory notes. It refers to the instrument being ‘in writing’, ‘signed’, ‘possessed’, ‘delivered’, and ‘presented’ but does not specify the medium or carrier of such content.
The eIDAS regulation explicitly states in Article 46:
“An electronic document shall not be denied legal effect and admissibility as evidence in legal proceedings solely on the grounds that it is in electronic form.”
New York
BAFT’s legal counsel on, amongst other things, the BAFT Master Trade Loan Agreements (Michael Evan Avidon, of Moses & Singer) has opined that a digital negotiable instrument is enforceable under the Electronic Signatures and Records Act (ESRA) under New York Law Article III § 307, provided that:
“An electronic version of such record is created, stored or transferred pursuant to this article in a manner that allows for the existence of only one unique, identifiable and unalterable version which cannot be copied except in a form that is readily identifiable as a copy.”
Sweden
The Supreme Court decision of 2 November 2017 in case no. Ö 5072-16 (the ‘Collector’s Electronic Promissory Note’ case) as follows:
"An individual took a loan from Collector Bank AB and electronically signed a document entitled “Loan Application/Promissory Note”. The case concerned, among other things, whether such an electronic document can constitute a negotiable instrument. According to the Supreme Court, an electronic promissory note issued to a particular individual or order may be deemed to be negotiable provided that the debtor who makes payment by electronic means is afforded the same protections as when acknowledgement of payment is written on a physical promissory note or when the physical promissory note is returned to the debtor."
England and Wales
The Bills of Exchange Act 1882 does not use the word ‘paper’ in its main definition, although it does refer to paper in the context of ‘inchoate bills’: “Where a simple signature on a blank paper is delivered by the signer in order that it may be converted into a bill….’ On the face of it, therefore, an electronic bill of exchange ought to be enforceable under the Act.
The International Trade and Forfaiting Association (ITFA), whose membership sees real potential benefit in digitising this widely used instrument, commissioned a legal opinion from Sullivan & Worcester. They concluded that the concept of ‘possession’, which is fundamental to the effect of the Act, cannot currently be applied to a digital bill of exchange due to its nature as an intangible thing. The current interpretation of ‘possession’ under English law is that it can only apply to a tangible thing.
Discussion with The Law Commission is in progress, led by the ICC (UK), to address this challenge. We understand that there is support for the required change in respect of negotiable instruments, but the interpretation of ‘possession’ applies more broadly to other documents (e.g. powers of attorney) which apparently are a little more problematic. Nevertheless, we are given to understand that the required changes should be possible by second half of 2022. In the meantime, ITFA has developed a contract-based construct which avoids the interpretational problem under the Act and allows our trace:original digital bill of exchange to be used.
Singapore
Singapore is currently revising its signature act (Electronic Transactions Act) to allow electronic signing and the creation or execution of a will, negotiable instruments, documents of title, bills of exchange, promissory notes, consignment notes, bills of lading, warehouse receipts or any transferable document or instrument that entitles the bearer or beneficiary to claim the delivery of goods or the payment of a sum of money, or power of attorney, etc. The changes are scheduled to take effect in 2021.
Currently, the above documents are excluded from what can be e-signed under the Singapore Electronic Transactions Act.
UNCITRAL Model Law
It is worth noting that trace:original is aligned with UNCITRAL Model Law.
Would each user of trace:original document need to sign up to a member’s agreement with standard terms?
Our trace:original solution does not require users to sign up to a members’ agreement. As such it is fundamentally different from consortia and other membership-based solutions.
trace:original is designed to support both document creators and document recipients. Creators need to acquire a licence from Enigio to gain access to a Full Node in order to create new trace:original documents. Recipients of a trace:original document can use the utility to access, read, add to and transfer the digital document free of charge and it does not require a licence or signing of any member agreement.
Once created, a trace:original document can flow freely between different ecosystems or be handled manually through the use of our publicly available web-service. Anyone using a computer with reasonably modern web-browser and access to the internet can possess and manage a trace:original document.
What terms govern the use of trace:original and how can these be enforced against other users and Enigio? Who is liable for errors and functional problems with trace:original?
A subscriber with the right to create trace:original documents will sign a commercial contract with Enigio regulating the terms and conditions for using and maintaining a Full Node in the distributed ledger structure. In the unlikely event that Enigio would file for bankruptcy, the subscribers would have the right to set up a Ledger Node by using escrow software.
We envisage that the terms will not diverge much from any standard agreements normally signed between service providers and their customers.
Anyone coming into possession of a trace:original document or verifying a copy of a trace:original document will have to accept user terms when signing into the trace:original website.
The user terms will state that the responsibility for the content, signatures, and proof thereof, storage of the documents and their private keys, system access rights to any system or IT environment associated to trace:original rest with the users.
Liability, Enigio is providing technology that can create verifiable, and thereby fraud safe digital documents, where the holder can evidence possession and full control over the latest version of a document.
In a physical context, the equivalent of the digital trace:original file is the paper on which the document content is printed. The characters in the trace:original file are comparable to the ink used in the printing or writing process.
Taking this analogy one step further, the paper and the ink manufacturers do not have any liability for the content or the storage of the document and are not accountable for the value created by the combination of paper and ink in a document. The same logic also applies to a trace:original document.
As the creation, management, and verification of a trace:original document is a critical service, Enigio recognises that the service has to be very dependable and robust. To achieve this, the service incorporates a number of inherent risk mitigants to ensure that a user of the service will be able to claim the rights carried by the trace:original documents in the unlikely event that the service would fail.
The document verification is based on open standards. Verification can, therefore, be performed by using software solutions other than Enigio’s and verification could also potentially be achieved manually.
The evidence of the existence of the trace:original document and its current holder is publicly available in multiple and independent resources and held by each individual subscriber. Considering that the subscribers probably have significant values represented in trace:original documents it is in their interest to maintain and share a correct and updated copy of the verification data, (i.e. the distributed trace:original ledger).
As all ledger copies by definition are identical (up to its last entry) they share a common truth.
Each subscriber should have contingency plans in the event of telecommunication breakdowns or other unforeseen events. Subscribers could probably also have insurance coverage for their assets in a similar way as assets kept in an archive could be insured. A huge advantage when getting insurance coverage for trace:original documents, is that the documents and the keys can be subject to back-up procedures.
If the service for some reason would be subject to malfunction, the system will stop and the subscribers would have to create a queue of documents waiting to be registered until the malfunction is resolved. Any already created document would still be verifiable in any of the distributed ledger copies.
If the service for some unimaginable reason would not be restorable all trace:original documents could, from the time of breakdown and henceforth, have a continued documentation by using physical documents.
An attempt to hack a block-chained structure and the system supporting it would require enormous resources and is generally not regarded as economically feasible.
This also applies to the trace:original system. However, “assets represented as documents” are not readily liquid and have a full audit trail of possession in themselves and are therefore even less attractive for fraudsters.