Quick answer: documentary trade-finance automation turns a presentation of invoices, transport documents, certificates and other required records into a structured comparison problem. A bank first identifies the document type, extracts fields, normalises names/dates/amounts, then checks the extracted data against the documentary credit and against the other stipulated documents. Some checks are exact; others require contextual compatibility rather than literal identity. The system should produce candidate discrepancies with evidence and confidence, not pretend that OCR has converted international banking practice into a fully mechanical yes/no problem. Human documentary-credit specialists remain important where language, document structure, legal effect or ICC practice requires judgement.

The algorithm is not checking whether the ship sailed or the goods are good. It is checking whether the presented documents satisfy the documentary promise the bank was asked to examine.

Safety and authority boundary: this article explains public documentary-credit and document-processing concepts. It is not legal advice, sanctions-evasion guidance, a substitute for UCP 600/ISBP expertise, or an instruction to any bank on whether to honour a particular presentation.

Page role: document examination, not general payments or AML

Bukit Timah Tutor already covers transaction reconciliation and AML transaction monitoring. Those are different jobs.

This article owns a narrower trade-finance problem: how a bank can computationally assist the examination of documents presented under a documentary credit without collapsing documentary compliance into generic text matching.

1. The documentary-credit logic comes first

Under UCP 600, banks examine documents rather than the underlying goods, services or performance. ICC material on Article 14 explains that a nominated, confirming or issuing bank must determine compliance on the basis of the documents, and has a maximum of five banking days following the day of presentation for that examination. See the ICC UCP 600 library and the ICC Academy guide to documentary credits.

That gives the automation system an exact page role:

credit terms + stipulated documents + applicable documentary practice → evidence about whether the presentation appears compliant.

2. “Same” is not the same as “not conflicting”

A naive document engine searches for literal equality. UCP 600 Article 14 contains a more subtle principle: data across a document, the credit and other stipulated documents need not be textually identical, but should not conflict when read in context and against international standard banking practice.

This is an algorithmic warning. Consider:

“ABC Trading Pte Ltd” versus “ABC Trading Private Limited”;
“Singapore” versus “Republic of Singapore”;
“USD 100,000.00” versus “US$100,000”;
an address split across two lines in one document and one line in another.

Exact string comparison can generate false discrepancies. But excessive fuzzy matching can suppress real conflicts. The correct job is contextual equivalence with controlled tolerance.

3. Build a structured document schema

Before comparing documents, the system needs to turn them into structured records. A public teaching schema might contain:

document type;
issuer;
beneficiary/applicant names;
invoice or document number;
dates;
currency and amount;
goods description;
quantity and unit;
shipment/loading/discharge places;
carrier/vessel/flight references;
signature/endorsement indicators;
page count and originals/copies;
machine confidence for each extracted field.

This converts the problem from “compare two PDFs” into “compare typed fields whose provenance remains traceable to the source image or electronic record.”

4. OCR is only the first probabilistic layer

Optical character recognition converts document images into candidate text. It can fail on stamps, handwriting, low-resolution scans, skewed pages, dense tables and unusual fonts.

Suppose OCR reads an invoice amount as 108,000 when the source image says 106,000. A perfect rules engine downstream will confidently detect a discrepancy that does not exist.

The system therefore needs two separate questions:

Extraction confidence: did we read the document correctly?
Compliance confidence: assuming extraction is correct, does the field satisfy the documentary requirement?

Combining these into one opaque score makes debugging much harder.

5. Layout matters because meaning is spatial

A bill of lading, invoice and certificate are not bags of words. Meaning can depend on where text appears: shipper field, consignee field, marks-and-numbers box, freight notation, signature block or date area.

A document-understanding system can therefore represent each token as:

token = [text, bounding box, page, nearby label, visual style, OCR confidence].

Layout-aware extraction reduces the risk that the bank compares an amount printed in an unrelated footer with the invoice total simply because both look like currency.

6. Normalisation should preserve the original evidence

Before matching, the system can normalise common representational differences:

upper/lower case;
punctuation and whitespace;
currency symbols and ISO currency codes;
date formats;
company suffixes;
number separators;
controlled location identifiers.

But normalisation should be reversible. A reviewer should always be able to inspect the original extracted text and the source document region. Otherwise the algorithm can silently erase the very difference it was supposed to assess.

7. Convert the credit into machine-checkable constraints

A documentary credit can be represented as a set of obligations and tolerances:

C = {required documents, latest shipment date, expiry/presentation rules, amount/currency, shipment conditions, documentary data requirements, permitted tolerances, applicable rules}.

Each requirement becomes a test, for example:

invoice present?
required transport document present?
shipment date no later than permitted date?
invoice currency compatible with credit?
required certificate issuer matches stipulated requirement?
presented amount within applicable credit tolerance?

The difficult rules are not those with clean Boolean answers. They are those whose interpretation depends on document type and ICC practice.

8. Model the document set as a consistency graph

Represent every extracted entity as a node and each required relationship as an edge.

Examples:

invoice amount ↔ credit amount;
invoice beneficiary ↔ credit beneficiary;
transport shipment date ↔ latest shipment date;
goods description ↔ invoice/credit context;
container or reference number ↔ other stipulated records.

The graph makes cross-document contradictions visible. It also lets the system preserve why an item was flagged rather than returning “document risk score 72.”

9. Discrepancy detection is a typed rule engine

A useful discrepancy object can contain:

[rule ID, source requirement, document field, observed value, expected relation, extraction confidence, severity, evidence pointer, reviewer status].

This matters because a discrepancy should be reproducible. If a reviewer cannot reconstruct which rule, document region and comparison produced the flag, the automation is difficult to govern.

10. Dates are a temporal-logic problem

Trade documents contain many dates: issue date, invoice date, shipment date, on-board date, presentation date, expiry date and certificate dates.

The system therefore needs relational tests such as:

shipment date ≤ latest permitted shipment date

and applicable presentation-window logic, rather than simply sorting dates chronologically.

ICC’s public materials note that UCP 600 gives banks a maximum five-banking-day examination period after presentation. That deadline belongs to the bank’s review process and should not be confused with the beneficiary’s separate presentation/expiry conditions.

11. A confidence threshold should route uncertainty, not erase it

If OCR confidence on a vessel name is 0.58, the system has several choices:

accept it silently;
reject the document automatically;
route the field for human confirmation.

The third option is often mathematically sensible because human attention has value when model uncertainty is high.

A generic routing rule is:

review if expected cost of automated error > cost of human verification.

That turns “human in the loop” from a slogan into a resource-allocation decision.

12. Documentary compliance and financial-crime screening should remain separate ledgers

A presentation can be documentary-compliant while still requiring sanctions, AML or trade-based-financial-crime review under separate obligations. Conversely, an innocuous trade can contain a documentary discrepancy.

The system should therefore preserve:

documentary-compliance outcome ≠ sanctions outcome ≠ AML/TBML outcome.

Combining them into one opaque “trade risk” score destroys authority boundaries and makes a false positive difficult to diagnose.

13. Electronic transferable records change the evidence model

Trade documents are moving from paper images toward native electronic records. The UNCITRAL Model Law on Electronic Transferable Records (MLETR) provides a legal framework built around functional equivalence, integrity and the concept of control as the electronic analogue of possession for transferable records. See UNCITRAL MLETR.

This changes the algorithmic question. Instead of asking only “Does this scan look authentic?”, a system may need to verify:

which electronic record is authoritative;
whether integrity has been preserved;
who has control;
whether a transfer of control is valid;
whether the jurisdiction recognises the electronic form.

UNCITRAL’s status page currently records legislation based on or influenced by MLETR in multiple jurisdictions, including Singapore. Jurisdiction-specific law still matters. See the MLETR status page.

14. Standardised data reduces the amount of OCR the bank needs

OCR is a bridge from paper to data. A better long-run architecture is often data-native trade documentation with shared semantic standards.

The ICC Digital Standards Initiative has mapped key trade documents and data elements to support interoperable digital trade. Its 2024 framework covered 36 key trade documents and their data relationships. See the ICC Digital Standards Initiative and its supply-chain digitalisation framework.

When a field arrives as trusted structured data rather than pixels, the bank can spend less computational effort guessing what the document says and more effort checking what the data mean.

15. Counterexample: a perfect OCR match can still be a bad documentary decision

Imagine every field is extracted perfectly, but the algorithm treats two non-identical company-name formats as conflicting even though the documentary context supports equivalence. The extraction layer is correct; the compliance rule is wrong.

Now reverse it: the rule engine is correct, but OCR misreads the shipment date. The rule appears to detect a discrepancy; the evidence is wrong.

These two failures require different repairs, which is why extraction and compliance must remain separate machine layers.

16. The public document-checking pipeline

Identify the governing credit and rule version.
Inventory all stipulated and presented documents.
Classify each document type.
OCR or ingest native electronic data.
Extract layout-aware fields with confidence.
Normalise data while retaining originals.
Compile credit terms into typed constraints.
Construct cross-document consistency relationships.
Run deterministic and contextual discrepancy checks.
Route low-confidence fields and interpretive cases to reviewers.
Keep sanctions/AML decisions separate from documentary compliance.
Record each discrepancy with rule and evidence provenance.
Capture reviewer corrections as validation data.
Update after ICC practice, legal or document-format changes.

17. Failure modes

OCR certainty illusion. Extracted text is treated as ground truth.
Exact-match absolutism. Textual differences become false discrepancies despite contextual compatibility.
Fuzzy-match overreach. Real conflicts are normalised away.
Rule-version drift. The engine applies obsolete or wrong documentary practice.
Layout blindness. Values are matched without knowing which field they belong to.
Documentary/AML conflation. Different authority decisions are collapsed into one score.
Electronic-record blindness. A native transferable record is treated like an ordinary PDF without control/integrity checks.
Human-review dead end. Reviewer corrections do not return to model validation.

18. Diagnostics and falsifiers

Which document types have the lowest field-extraction confidence?
Which discrepancy rule creates the most reviewer reversals?
Are false discrepancies concentrated in names, dates, quantities or free-text goods descriptions?
Can every flag be traced to the original document region and rule?
Does the engine distinguish missing data from contradictory data?
What happens when two documents use semantically equivalent but non-identical text?
Does native digital data reduce error relative to OCR?
Which ICC or legal rule change would invalidate a current machine check?

Suppose someone claims, “The automation is accurate because OCR accuracy is 99%.” A falsifier is evidence that the remaining 1% of errors concentrate in high-value fields such as amounts, dates or transport references, or that the downstream compliance rules misinterpret perfectly extracted text. OCR accuracy is not documentary-examination accuracy.

19. Verification and update triggers

sample original images against extracted fields;
backtest machine discrepancy flags against expert review;
measure false positive and false negative rates by rule;
version every documentary rule and interpretation dependency;
retest after OCR, layout-model or document-template changes;
validate electronic-record integrity/control mechanisms separately;
review jurisdictional legal changes affecting electronic transferable records;
preserve a complete audit trail from source document to final human decision.

Research anchors

The deeper lesson

Trade-finance document automation is not “AI reads PDFs.” It is a chain of evidence transformations. Images become text. Text becomes typed data. Data become relationships. Relationships are tested against documentary obligations and practice. Uncertainty is routed rather than hidden. The strongest system therefore preserves polarity at every layer: what the source actually says, what the machine inferred, which rule applies, what appears inconsistent, and what a qualified reviewer finally decides.

Educational note: This article is a public learning explanation of document-processing and documentary-credit mathematics. It is not legal advice, trade-finance operational advice, sanctions advice or a substitute for qualified UCP/ISBP practice.

Small Group Tutorials

How Banks Automate Documentary Trade-Finance Checks: Letters of Credit, UCP 600, OCR, Data Matching, Discrepancies and Human Review