Skip to main content
Loading navigation
Back to prompt library

Build a Trade Finance Letter of Credit Inconsistency Inspector — implementation

Linked challenge: Build a Trade Finance Letter of Credit Inconsistency Inspector

Prompt source

implementation64 lines11 sectionsNo variables1 code block
## Build
Inspect trade finance documents including bills of lading, commercial invoices, and letters of credit for counterparty discrepancies. Collate address mismatches and missing ports into an investigation dossier.

## User
Trade finance operations auditor

## Workflow
1. Ingest simplified normalized trade finance packets containing LC rules, commercial invoices, and shipping bills.
2. Extract counterparties, cargo descriptions, declared weights, and loading/unloading port codes.
3. Reconcile shipping party names against GLEIF legal entity names to verify counterparty authority.
4. Flag cross-document discrepancies such as destination port drift or altered cargo descriptions in an audit log.

## Interface
Side-by-side document comparison split-screen highlighting discrepancies between LC stipulations and shipping manifests.

## Data
Construct 35 synthetic trade finance dossier JSON objects featuring consistent transactions and intentional discrepancies.
Starter examples below are synthetic. They are not downloaded records.

## Source
[GLEIF API](https://www.gleif.org/en/lei-data/gleif-api)
Verifies legal names and jurisdiction registration of trade counterparties against simulated GLEIF reference records.

## Tools
pydantic-ai, pydantic, fastapi.
Pydantic AI structures multi-document validation logic and generates structured discrepancy reports.
Local or hosted LLM API capable of document reasoning with structured output validation.

## Deliverables
Submit runnable source, pinned dependencies, setup commands, a working interface, example outputs, and a recorded end-to-end demo. Include tests and an action log.

## Acceptance
- Detects discrepancies between letter of credit stated destination and invoice destination.
- Verifies freight forwarder entity status against simulated GLEIF legal entity records.
- Compiles an exportable JSON trade reconciliation summary for trade compliance analysts.

## Starter Examples
```json
[
  {
    "input": {
      "lc_id": "LC-100",
      "lc_applicant": "Oceanic Traders",
      "invoice_buyer": "Oceanic Traders",
      "port_of_loading": "SGSIN",
      "port_of_discharge": "NLRTM"
    },
    "expected_output": {
      "discrepancies": [],
      "status": "COMPLIANT"
    }
  },
  {
    "input": {
      "lc_id": "LC-101",
      "lc_applicant": "Oceanic Traders",
      "invoice_buyer": "Oceanic Logistics Sub",
      "port_of_loading": "SGSIN",
      "port_of_discharge": "USNYC"
    },
    "expected_output": {
      "discrepancies": [
        "Port of discharge mismatch: NLRTM expected vs USNYC provided",
        "Counterparty name discrepancy between LC applicant and invoice buyer"
      ],
      "status": "DISCREPANT"
    }
  }
]
```

## Safety
Demonstration tool for document reconciliation; does not delay port shipments or halt financial letters of credit.
Use mock external writes. Require human review before any real deployment.