Can AI check letter of credit documents?

By Saurabh Goyal, Founder & CEO of Phlo Systems. Published 24 July 2026.

Letter of credit document checking looks, at first glance, like the perfect job for a large language model: it is reading, comparison and judgement over messy documents, which is what these models do. Having built an L/C compliance engine and tested it adversarially, I can report that the honest answer to "can AI check LC documents?" is: yes, for about half of the job, and the craft is in knowing precisely which half. Get the split right and you have a checker with a bank examiner's patience on every presentation. Get it wrong and you have a fluent, confident generator of wrong verdicts.

The 30-second answer: language models are strong at extraction and reading: pulling structured terms out of an MT700 or a scanned bank advice, reading a bill of lading, and spotting traps in field 47A prose that no rule library anticipates. They are weak, in ways that resist prompting, at date arithmetic, at exhaustive coverage, and at withstanding adversarial text inside documents. So the model reads and proposes; deterministic code computes everything computable, enforces completeness, and renders the verdict. The model must never be the last word.

What the model is genuinely good at

Extraction. Credits arrive as SWIFT text, bank PDFs and portal downloads; presentations arrive as scans of variable quality from carriers, inspectors, insurers and chambers of commerce. Turning that mess into structured terms, the 46A document list, the 45A description, dates, amounts, tolerances, is language work, and models do it far better than templates and regular expressions ever did.

Reading prose for traps. Field 47A carries free-text conditions, and free text is where the dangerous clauses live: a document only the applicant can countersign, a condition with no document stipulated to evidence it, a requirement that quietly contradicts another field. A rule library catches the patterns it was taught; a model reads the clause the drafter invented last week. In our engine, the model's job in the workability review is precisely this: find traps the rules missed, and only add findings, never remove them.

Cross-document reading. Does the goods description on the invoice satisfy the credit's 45A? Is the consignee on the bill of lading the party the credit names? Is the certificate signed by the issuer the credit requires? These are reading-comprehension questions across documents, squarely in the model's competence, with every claim tied to the specific field and document so a human can verify it.

Where the model must not be trusted

Date arithmetic. Asked whether an on-board date of 14 June is on or before a latest shipment date of 12 June as amended, a language model is right most of the time. Most of the time is a hopeless standard for a check on which payment for an entire cargo depends. We learned this concretely: our engine strips the model's latest-shipment finding and recomputes the 44C test in code, from the resolved credit, the amendments in force, and the bill of lading's on-board date. The same goes for every computable comparison: amounts against 32B and tolerance, presentation windows, expiry. Code is right every time, and when the answer matters at cargo scale, every time is the only acceptable rate.

Completeness. A model asked to examine a presentation will examine what draws its attention. It will not reliably notice what is absent, and absence is half of document checking. The fix is structural, not better prompting: a coverage invariant in code walks the credit's 46A list and demands a positive examination result for every required document before a clean verdict can exist. "Clean" is not the absence of findings; it is the presence of affirmative coverage.

Adversarial text. Documents in a payment dispute are not neutral inputs. A presented document could contain text crafted to steer an examiner: an instruction, a claim of compliance, a request to ignore prior rules. A model that both reads the evidence and delivers the verdict can be argued with by the evidence. This is prompt injection, and the defence is architectural: the model's output is findings, structured claims tied to fields; the verdict is derived in code from those findings plus the deterministic checks. A document can try to talk its way past the reader; it cannot talk its way past arithmetic it never reaches.

Failing open. The most dangerous behaviour in an automated checker is receiving an unreadable document, examining what it can, and issuing a partial verdict that looks whole. A serious system refuses instead: unreadable or missing inputs stop the examination and say so. In compliance checking, "I could not examine this" is a feature, and the pre-flight that refuses is protecting the verdict's meaning.

The resulting architecture

Task	Who does it	Why
Extracting terms from MT700 / MT707 / PDFs	Model	Language work over messy input
Resolving amendments into effective terms	Code	Deterministic fold; must be exact
Reading 47A prose for soft clauses and traps	Model (additive only)	Open-ended reading no rule library covers
Date, amount, tolerance and window checks	Code	Arithmetic must be right every time
Coverage of every 46A requirement	Code	Models do not reliably notice absence
Cross-document consistency reading	Model, findings tied to fields	Reading comprehension, human-verifiable
The verdict	Code, from findings + checks	The model must never be the last word
Sign-off	A human, recorded with identity and time	Accountability does not automate

The last row matters as much as the others. The system's output is an examined presentation with findings a human can inspect, override with a recorded reason, and sign off with their name on it. The AI does the patient reading; the arithmetic does the deciding; a person owns the judgement. That is also, not coincidentally, what a bank's own document examination looks like: examiners, a checklist, and accountability.

Frequently Asked Questions

Can AI replace human letter of credit document checkers?

No, and a well-designed system does not try. AI removes the mechanical burden: extracting terms, reading every document against every field, re-checking after each amendment. Humans keep the judgement calls, the overrides and the sign-off. What changes is that the human examines a structured set of findings instead of a stack of PDFs against a deadline.

Why not just ask a language model whether the documents comply?

Because verdict-by-model fails in three specific ways: it gets date and amount arithmetic wrong a small but intolerable fraction of the time, it does not reliably notice missing documents, and its verdict can be influenced by adversarial text inside the documents it is examining. All three are solved architecturally by letting the model only contribute findings while code computes the checks and derives the verdict.

What is prompt injection in document checking?

Text placed inside a submitted document designed to manipulate an AI examiner, for instance an instruction to treat the presentation as compliant. Systems where the model both reads documents and issues the verdict are vulnerable. The defence is to make the verdict a function, computed in code from structured findings and deterministic checks, so no sentence inside a document can reach it.

Will banks accept AI-checked documents?

The bank runs its own examination regardless; no presenter can outsource that. The point of AI-assisted checking is on your side of the counter: finding the discrepancies before the bank does, while they can still be cured, so the presentation that reaches the bank is clean. The measure of success is first-presentation acceptance, and most presentations today fail it.

How Phlo Systems helps

opsPhlo's L/C workbench is built exactly on this split. Claude-class models extract the credit, read the amendments and examine the prose; deterministic code resolves effective terms, computes every date, amount and tolerance test, enforces the 46A coverage invariant, and derives the verdict; unexaminable documents stop the check rather than weaken it; and every sign-off is recorded with the approver's identity, timestamp and notes. See the opsPhlo L/C workbench.

---

Related reading:

• MT700, MT707 and the current state of a letter of credit
• Why are most letter of credit presentations refused on first presentation?

Saurabh Goyal is the Founder & CEO of Phlo Systems. He has built finance and trading systems for commodity houses since 2008.