How a bank reads a letter of credit

Paying against paper

A letter of credit is a promise by a bank to pay a seller, on the buyer's behalf, provided the seller presents documents that comply with the credit's terms. The crucial and counterintuitive part is that the bank pays against the documents, not against the goods. It never sees the cargo. It sees a bill of lading, an invoice, an insurance certificate, a packing list, and it decides whether to pay based on whether those documents, examined on their face, conform to what the credit demanded and agree with one another.

This makes document examination the heart of trade finance, and it is governed by one of the most refined rulebooks in commerce, the UCP 600, the Uniform Customs and Practice for Documentary Credits. The doctrine is strict compliance: the documents must conform, and a discrepancy, even a seemingly minor one, can entitle the bank to refuse payment. An invoice that describes the goods differently from the credit. A presentation made after the deadline. A document that conflicts with another document in the same set. Each is a discrepancy, and discrepancies are the entire game.

Examination is a web, not a line

What makes this hard, and what makes it a real engine problem, is that the checks are not independent. Examining a letter of credit presentation is not running down a checklist of single documents. It is checking each document against the credit, and then checking the documents against each other, because UCP 600 requires that the data across the presentation not conflict. The amount on the invoice must sit within the credit. The description of the goods must be consistent across documents. The dates must form a coherent sequence: shipment before presentation, presentation within the credit's validity. A single fact, the shipment date, ripples across several documents and several rules at once.

{
  "rule_id": "CROSSDOC-AMT-001",
  "title": "Invoice amount exceeds the credit amount",
  "source": "UCP 600 Article 18; Article 14",
  "severity": "block",
  "expected_outcome": {
    "action": "review",
    "message": "The commercial invoice amount exceeds the amount available under the credit. Under UCP 600 this is a discrepancy and may entitle the issuing bank to refuse. Confirm against any tolerance stated in the credit."
  },
  "conditions": [
    { "type": "numeric_comparison", "source": "invoice.amount", "operator": ">", "target": "credit.amount" }
  ],
  "deterministic": true,
  "validation_status": "expert_reviewed"
}

This is a cross-document rule: it reads a field from the invoice and a field from the credit and compares them. Multiply that by the dozens of consistency checks UCP 600 implies across a full presentation, and you have a web of rules over a web of documents. The engine's job is to run that whole web and surface every discrepancy, each traced to the article that makes it one.

Reading first, then deciding

Before any of these rules can run, the documents have to be turned into fields. A scanned bill of lading becomes structured data: shipper, consignee, dates, port of loading, description. This is the normalization step, and in trade finance it is heavy, because the documents are varied and the formatting is inconsistent. The model reads the documents into structure. Then the rules, deterministic and UCP-cited, examine that structure for discrepancies. The reading is the model's job. The discrepancy finding is the rule's. A bank cannot pay or refuse on "the model thought the documents looked fine." It refuses on a specific discrepancy, against a specific article, and that is what the rules produce.

The point

Trade finance is where this engine began, and it began here for a reason: document examination is the demanding case. The decision is not one check but a web of them, each document tested against the credit and against the others, every discrepancy traced to UCP 600. The skills the engine learned doing it, reading messy documents into clean fields, running cross-document consistency rules, citing the article behind each finding, are exactly the skills every later domain turned out to need. The letter of credit taught the engine to examine. Everything after it was that lesson, pointed somewhere new.