Trade Finance & Cross-Border

Proving exclusive control of an electronic bill of lading

For trade-finance counsel, bank documentary-credit teams, and eBL platform operators who need to show a court, a bank, or a counterparty that a specific electronic bill of lading has one holder at a time and a continuous, unbroken chain of custody.

🔒 All inputs are processed locally in your browser. No data is transmitted. Do not enter real personal data — use synthetic or anonymised inputs only.
Scope. This guide covers a three-step workflow: a control-evidence checker, a possession-chain receipt builder, and a jurisdiction-adoption lookup. None of these tools is an eBL registry or title platform, and none renders a legal opinion. They check the control-transfer event log a user supplies and receipt the result.

ETR Control-Evidence Checker

Checks a supplied eBL's control-transfer events against MLETR Art. 10/11 singularity and continuous-control elements.

Open tool →

ETR Possession-Chain Builder

Hash-chains the same event log into a portable evidence pack with a Merkle root.

Open tool →

MLETR Jurisdiction-Adoption Lookup

Checks whether an eBL is legally effective end-to-end for a given origin-destination corridor.

Open tool →

The problem this solves

An electronic bill of lading is often described as "faster paper," the same negotiable-instrument function as a paper bill, just digital. That description hides the part that actually matters legally. A paper bill of lading works as a document of title because possessing the one physical original is, by construction, exclusive: only one party can hold it at a time. An electronic record has no physical original. Under UNCITRAL MLETR Art. 10 and 11, an eBL only achieves the same functional equivalence if the underlying system can demonstrate singularity (one authoritative record, not copies) and exclusive, continuous control (the ability to identify who holds control at any point, with no gap and no overlap). Without that evidence, an eBL is a well-formatted electronic message, not a transferable record a bank or court can rely on.

The practitioner gap is that most eBL platforms assert singularity and control as a feature of their internal database, without giving a counterparty (a receiving bank, an insurer, an arbitrator) an independent way to check the claim against the actual sequence of control-transfer events.

How the three tools fit together

  1. Check control evidence with the ETR Control-Evidence Checker. Supply the eBL's document digest and the platform's control-transfer event log (each event: platform identity, from-holder, to-holder, timestamp, signature, as recorded). The checker walks the events as a single chain of custody and returns a per-element MLETR Art. 10/11 verdict: integrity reference present, singularity assertion present, control chain continuous, no overlapping-control intervals, citing the specific article for each finding.
  2. Build the possession-chain receipt with the same event log in the ETR Possession-Chain Builder. Each receipt in the chain binds the hash of the receipt before it, so reordering, inserting, or deleting a transfer breaks the chain visibly. The builder computes a SHA-256 Merkle root over the whole chain, a single value a holder can present to a bank or court as the anchor for the entire possession history.
  3. Check corridor effectiveness with the MLETR Jurisdiction-Adoption Lookup, on its own branch alongside the control-evidence workflow. This is a static, citation-backed table of which jurisdictions have adopted MLETR, what scope their statute covers, and since when, used to answer whether an eBL is legally effective end-to-end for a specific origin-to-destination corridor, independent of whether the control evidence itself checks out.

What a control receipt proves, and what it does not

A clean verdict from the checker plus a valid possession-chain receipt together demonstrate that the control-transfer event log, as supplied, is internally consistent with MLETR's singularity and exclusive-control elements: no gaps, no overlaps, a continuous line of holders ending at the current one. That is strong evidence for a bank or arbitrator evaluating whether an eBL functions as a document of title.

It does not establish that the supplied event log is the only one that exists, that the underlying platform's database has not been altered outside the events presented, or that the platform itself meets MLETR's "reliable system" requirement in the broader legal sense. Those are questions about the source system, not about the interval math run over the events it reports. A jurisdiction's adoption of MLETR is also a separate question from whether any single eBL's control chain is sound: the lookup tool answers the first question, the checker and builder answer the second.

Family linkage. This workflow sits inside AINumbers' broader trade-finance tool family (letter-of-credit and UCP checkers, trade-document provenance verification): see the Trade Tech hub for the full set. A related but separate instrument family, negotiable-instrument electronic transfer under the UN Convention on the Use of Electronic Communications and the newer Model Law framework for other transferable records, is watch-grade, noted here as a future extension, not yet built.

The browser-calculator side of the same subject

These three tools are node-backed and MCP-callable: their output is hash-anchored and provable. AINumbers also runs a browser-side trade-finance suite of ten calculators covering the paper and SWIFT side of the same trade-finance lifecycle. Those tools are not provable in the same sense; they are deterministic calculators, not hash-anchored nodes, but a documentary-credit team or eBL platform operator working a live transaction will reach for most of them too:

Start at the TradeTech & Trade Finance Hub for the full suite, journey maps, and quickstarts.