Trade Finance Document Data for Letter-of-Credit Checking AI

Why LC examination is a different task from trade document extraction

LC checking is a comparison task, not a field-capture task: the model must decide whether documents appear on their face to comply with the credit, the rules it incorporates and with each other. A commercial invoice extractor can capture nearly every field correctly and still miss that the invoice goods description does not correspond with field 45A, or that the bill of lading shows a port of loading outside the range in 44E. That is why this page is separate from commercial invoice and certificate of origin extraction data, which covers capture of the underlying fields.

Under UCP 600 Article 14(b), each nominated, confirming and issuing bank has a maximum of five banking days following the day of presentation to determine compliance. That fixed window, which replaced the UCP 500 "reasonable time" test, is the business case for examiner-assist tools. It also defines the evaluation target: a model that flags discrepancies examiners would not raise wastes the window as surely as one that misses real ones.

Examination practice is shaped by ICC rules (UCP 600, the ICC's International Standard Banking Practice publication, and eUCP for electronic presentations). Your labeling guide should cite the edition your counterparties use, and buyers should verify every rule reference against the ICC primary text before training or publishing evaluation criteria.

The three data layers a document-checking model needs

A usable training record joins credit terms, presented documents and the examiner's outcome under one presentation ID; any missing layer turns the record into plain extraction data. Ask for each layer explicitly.

Credit terms. The cleanest source is the SWIFT Category 7 traffic: MT700 for issuance, MT701 when fields 45a, 46a and 47a overflow, and MT707 for amendments. Field 46A (Documents Required) is the checklist the examiner works from, while 47A (Additional Conditions) holds the non-standard clauses that drive many judgment calls. Amendments matter: a model trained on the original MT700 without the accepted MT707 will flag discrepancies that were cured.

Presented documents. Expect a packet of mixed scans: commercial invoice, transport document (ocean bill of lading, air waybill, multimodal), insurance certificate, certificate of origin, packing list, inspection or analysis certificates, beneficiary certificates and the draft. Page order, stamps, signatures, endorsements on the reverse of bills of lading and handwritten corrections all carry examination meaning, so ask for full-resolution page images, not OCR text only. See signature, stamp and seal detection data and page-stream segmentation data for the supporting tasks.

Examiner outcome. The ground truth is the examiner's decision with reasons: compliant, discrepant, refused or discrepancies waived by the applicant. In SWIFT terms, the refusal is the MT734 advice of refusal, which states that documents do not appear to comply, lists each discrepancy and states the disposal of documents. Field 77J lists the discrepancies in free text, while field 77B carries disposal code words (HOLD, NOTIFY, PREVINST, RETURN) that map to the Article 16 options, so parsers need both coded and free-text handling.

Labeling discrepancies so a model can learn from them

Each discrepancy should be a structured object linking a credit clause, one or more document regions and a reason code, not a single line of examiner free text. Bank checklists and MT734 narratives are written for humans ("INV GOODS DESCR NOT AS PER LC"), so the value added in preparation is mapping each note to a clause reference, document type, page and bounding box.

Three label distinctions repay the effort. First, separate document-versus-credit conflicts from document-versus-document conflicts (invoice weight versus packing list weight). Second, record whether the discrepancy was raised, then waived, refused or later disputed. Third, record examiner overrides of a rules engine or checklist tool, because those disagreements are the hardest and most valuable cases for evaluation.

Illustrative example: invented to show structure; it does not describe an available dataset.

{
  "presentation_id": "PRS-000184",
  "credit_ref": "LC-REF-REDACTED-01",
  "credit_terms": {
    "source": "MT700+MT707#1",
    "46A_documents_required": ["commercial_invoice x3", "full_set_clean_onboard_BL", "insurance_certificate_110pct"],
    "44E_port_of_loading": "ANY US GULF PORT",
    "47A_additional_conditions": ["ALL DOCS TO SHOW LC NUMBER"]
  },
  "documents": [
    {"doc_id": "D1", "type": "commercial_invoice", "pages": [1, 2], "file": "D1.tiff"},
    {"doc_id": "D2", "type": "bill_of_lading", "pages": [3, 4], "file": "D2.tiff"}
  ],
  "examiner_findings": [
    {
      "finding_id": "F1",
      "credit_clause": "44E",
      "doc_id": "D2",
      "page": 3,
      "bbox": [412, 220, 690, 248],
      "reason_code": "PORT_OF_LOADING_MISMATCH",
      "examiner_note": "B/L SHOWS PORT OF LOADING OUTSIDE LC RANGE",
      "conflict_type": "document_vs_credit"
    }
  ],
  "outcome": {"decision": "discrepant", "refusal_message": "MT734", "field_77B": "HOLD", "applicant_waiver": true},
  "pii_handling": {"method": "pseudonymized_parties", "sanctions_hits_removed": true}
}

Where real LC packages and discrepancy decisions sit

Issuing, advising and confirming banks hold the examiner decisions, but beneficiaries and their agents hold the same packages from the other side. Exporters keep the credit copy, their presentation set and the discrepancy notice they received; freight forwarders and document-preparation firms often keep pre-check work papers that show what was corrected before presentation. Those pre-check corrections are a useful second label source, because they capture discrepancies caught before a bank ever saw them.

Data typically lives in trade finance platforms (bank-side LC modules such as Oracle FLEXCUBE), document imaging archives keyed by LC reference, and exporter ERP or shared drives. The join key is the hardest part: scanned packets are often filed by shipment or invoice number while SWIFT traffic is keyed by the credit reference in field 20. Ask suppliers how they will link the two and what share of presentations they can link end to end.

Public data will not close the gap. Form datasets such as FUNSD contain 199 annotated noisy scanned forms [1] and help with layout and key-value pretraining, but no common public set pairs credit terms with examiner decisions. See which public document datasets allow commercial use and synthetic versus real documents for where generated packets break: synthetic data rarely reproduces the long tail of 47A clauses, carrier-specific bill of lading wording and examiner judgment on "not conflicting with" data.

Request checklist for an LC document-checking dataset

A good request specifies coverage, linkage, label depth and handling rules up front, so suppliers can say early whether their records fit. Use the list below as a starting draft.

Illustrative example: invented to show structure; it does not describe an available dataset.

For the generic version of this table, see the document dataset requirements spec.

Privacy, sanctions and governance constraints buyers should plan for

LC packages are dense with business identifiers, so plan for de-identification and screening exclusions as part of the dataset, not as a cleanup step. Party names, addresses, account and IBAN numbers, signatures and individual contact details appear on almost every page. If the data touches EU residents, GDPR applies unless the information is genuinely anonymous, judged by the means reasonably likely to be used to identify someone [2]; pseudonymized party names in a small corridor can remain identifiable from routes, goods and amounts.

Sanctions content needs its own rule. Screening alerts, OFAC or other list matches, investigation notes and suspicious-activity material should generally be excluded from training data, and counsel should confirm what can be disclosed at all. If you need a sanctions-aware feature, ask for the clause and document fields that trigger screening, not the screening outcomes.

If the system will be used in a regulated or high-risk setting, data governance duties such as those in EU AI Act Article 10 cover training, validation and test data [3]. As of October 2026, Article 10 applies only to high-risk AI systems, and amended start dates apply, so confirm scope with counsel. Ship the dataset with machine-readable documentation, for example a Croissant-RAI card covering lifecycle and labeling [4], and store metadata like the fields in metadata a licensed corpus should ship with.

This page is general information, not legal advice. Confirm requirements with counsel for your jurisdiction and use case.

Evaluating an examiner-assist model on real presentations

Evaluate at the discrepancy level and the presentation level separately, because a model can find most discrepancies yet still reach the wrong compliant-or-refused call. Measure discrepancy recall and precision by reason code, localization accuracy against the examiner's region, and presentation-level agreement with the final decision.

Weight false positives honestly: every spurious flag consumes examiner time inside the Article 14 window. Report results separately for waived discrepancies, since a model that flags a real but routinely waived discrepancy is correct under the rules but may not reduce workload. For the field-level side, see document extraction evaluation ground truth, and compare with the analogous design in insurance policy checking discrepancy data.

How SourceX handles requests for trade finance document data

SourceX sources operational datasets from US companies on request, including document collections and finance workflows, and manages the licensing and ongoing purchases. Datasets are not held in stock, and a request does not guarantee a match. You describe the data you need, such as linked credit terms, presented documents and examiner findings, and SourceX looks for US businesses that hold it; every release is approved by the supplying company. The process runs Find, Assess (data and licensing permissions), Agree (pricing and allowed uses in a license), Transact and Manage, and nothing is contracted until a supplier agrees. Teams in banking can also review the finance buyer overview or the document AI and RAG use case, and you can submit a data request as a buyer.

Every dataset is rights-reviewed for ownership and consents and delivered under a license that defines the records, uses, term and delivery. Personal details such as names, emails, phones and account numbers are removed or replaced before delivery, the method is recorded and a sample is checked, though no method is perfect. Delivery runs through private, access-controlled workflows only after an executed agreement and supplier approval. Browse related tasks in the document AI data hub or the AI data hub.

Request LC document-checking data

If you are building a letter-of-credit examiner-assist or discrepancy-detection model, describe the credit terms, document types and examiner findings you need. SourceX sources on request from US businesses, with rights review and a license defining allowed uses, and serves AI teams wherever they are based. Describe your LC dataset requirements to SourceX.