Build a Cross-Border Counterparty Data Correction Queue — implementation

## Build
Inspect inconsistent cross-border counterparty records against official LEI reference datasets using the GLEIF API. Detect address drift and BIC mismatches to format structured remediation proposals for payment operations analysts.

## User
Cross-Border Payment Operations Analyst

## Workflow
1. Ingest simplified normalized payment records containing counterparty names, destination BICs, and declared addresses.
2. Query GLEIF API search endpoints to match counterparties by legal name, BIC code, and registration country.
3. Compare counterparty postal codes, registered cities, and legal status to detect corporate changes or drift.
4. Synthesize structured remediation change tickets specifying original, suggested, and verified corporate registry attributes.

## Interface
A web queue presenting side-by-side original payment counterparty records against official GLEIF corporate data with inline edit approvals.

## Data
Generate synthetic payment records paired with mocked GLEIF API response payloads simulating public Golden Copy entity endpoints.
Starter examples below are synthetic. They are not downloaded records.

## Source
[GLEIF API](https://www.gleif.org/en/lei-data/gleif-api)
GLEIF API search endpoint features and field structures (BIC mappings, address structures, and parent-child relationship filters).

## Tools
pydantic-ai, fastapi, httpx.
Enforces type-safe schema validation on incoming payment fields and outgoing remediation ticket structures.
Fast local instruction-tuned LLM or cloud API supporting strict JSON schema generation.

## 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
- Correctly flags BIC and address discrepancies between payment records and registry data.
- Generates typed correction payloads matching the verification review schema.
- Simulates outbound remediation patch payloads without mutating external databases directly.

## Starter Examples
```json
[
  {
    "input": {
      "payment_id": "PMT-88210",
      "counterparty_name": "Nordic Industrial Solutions AB",
      "bic": "NDEASESS",
      "address": "Kungsgatan 12, Stockholm, SE"
    },
    "expected_output": {
      "payment_id": "PMT-88210",
      "lei": "5493006MHB84DD0ZWV18",
      "match_confidence": 0.95,
      "discrepancies": [
        {
          "field": "address.postal_code",
          "payment_val": "Kungsgatan 12",
          "registry_val": "Kungsgatan 12, 111 35 Stockholm"
        }
      ],
      "remediation_status": "PROPOSED_UPDATE"
    }
  },
  {
    "input": {
      "payment_id": "PMT-99301",
      "counterparty_name": "Unknown Global Trading",
      "bic": "INVALIDBIC",
      "address": "Unknown"
    },
    "expected_output": {
      "payment_id": "PMT-99301",
      "lei": null,
      "match_confidence": 0,
      "discrepancies": [
        {
          "field": "bic",
          "payment_val": "INVALIDBIC",
          "registry_val": null
        }
      ],
      "remediation_status": "UNRESOLVED_ESCALATION"
    }
  }
]
```

## Safety
Ensures no live SWIFT or payment network updates are executed; all outputs are mock staging proposals.
Use mock external writes. Require human review before any real deployment.