OpenChainGraph Suite · OCG v0.8.13 · Corporate Treasury & FX

camt.053 Parallel-Run Recon Pack

During a bank-statement parallel run a treasury receives the same period twice: once as a Swift MT9xx message it maps itself, and once as the bank's native camt.053. This pack turns that pair into evidence. Stage 1 maps the MT leg and reports its own fidelity. Stage 2 classifies the native camt.053 leg and checks its balance equation. Stage 3 takes declared record counts and control totals for both legs and checks whether they agree, within a tolerance the caller declares rather than one this pack picks. Both legs are supplied by the caller: the pack opens no bank connection and retrieves no statement, so what it evidences is agreement between two declared legs, never that either leg is correct.

OpenChainGraph · 3 Nodes, Linear attestation mandate Hash-Anchored §4 Both Legs Declared Client-Side · Zero PII

Not a bank confirmation, not a sign-off on either statement, and not a migration approval. Both legs of the parallel run are SUPPLIED by the caller and treated as asserted: this pack performs no lookup against a bank, a payments hub, or a ledger, and cannot establish that a declared count or control total matches what the underlying system actually holds. Agreement between two legs that were both derived from the same faulty extract is still agreement, and this pack would report it as such. It does not itself satisfy any regulatory duty, and it takes no position on whether a parallel run is complete enough to cut over.

§4 Execution Hash · Workflow Definition Anchor

execution_hash:computing…

Workflow Stages · 3 Nodes · Linear

1 ROOT · MT-DERIVED LEG node

Swift MT9xx to camt Statement Migration Mapper art-563-mt9xx-camt-statement-migration-mapper

Stage 1, the MT-derived leg. A pasted MT900/910/940/942/950 statement or notification mapped to a camt.052/053/054-shaped JSON object, with a fidelity report covering truncation findings, unmappable tags, and the 60F + sum(61) = 62F balance-consistency check.

MCP Call · map_mt9xx_to_camt

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "map_mt9xx_to_camt",
    "arguments": {
      "message_text": "{1:F01BANKDEFFAXXX0000000000}{2:I940...}",
      "declared_mt_type": "940",
      "target": "camt.053"
    }
  },
  "id": 1
}

2 BANK-NATIVE LEG node

ISO 20022 camt.053 Statement Reconciliation art-258-parse-camt053-reconciliation

Stage 2, the bank-native leg. The camt.053 statement the bank sent for the same account and period, classified by Domain, Family and SubFamily per the CGI-MP usage guide, with the OPBD + sum(movements) = CLBD balance equation checked and a structured-remittance match rate scored.

MCP Call · parse_camt053_reconciliation

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "parse_camt053_reconciliation",
    "arguments": {
      "statement_id": "STMT-2026-08-07-001",
      "opening_balance": 100000.00,
      "closing_balance": 103500.00,
      "entries": [
        {"amount": 3500.00, "credit_debit": "CRDT", "bank_transaction_code": "PMNT/RCDT/ESCT"}
      ]
    }
  },
  "id": 2
}

3 BOTH-LEGS AGREEMENT · FINAL node

Payment Data Migration Completeness art-519-payment-data-migration-completeness

Stage 3, the both-legs agreement check. Declared per-partition record counts and control totals for the two legs, checked for count completeness, value completeness within a declared tolerance, and aggregate-versus-partition consistency, so a grand total that reconciles while a partition underneath does not is reported rather than passed. Final stage.

MCP Call · verify_migration_completeness

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "verify_migration_completeness",
    "arguments": {
      "partitions": [
        {
          "partition_id": "2026-08-07/DE89370400440532013000",
          "source_record_count": 412,
          "target_record_count": 412,
          "source_control_total": 103500.00,
          "target_control_total": 103500.00
        }
      ],
      "value_tolerance": 0.00
    }
  },
  "id": 3
}

Reading the Run · Three Verdicts, No Fourth

The three nodes emit their own status vocabularies. This is the reading rule for combining them into a single parallel-run verdict. It is a rule for a human or an agent to apply to the three receipts, not a fourth computation: no node emits these three words, and the pack does not derive them for you. Reading it this way keeps the honest third state visible, so a run that could not establish agreement is never quietly filed as one that did.

MATCHES Stage 1 reports its 60F + sum(61) = 62F balance check passing with no data-loss warnings, Stage 2 reports CLEAN, and Stage 3 reports MIGR_COMPLETE. The two declared legs agree on both count and value at the declared tolerance.

DIVERGES Stage 3 reports MIGR_COUNT_VARIANCE, MIGR_VALUE_VARIANCE or MIGR_PARTITION_INCONSISTENT, or either leg fails its own balance equation: Stage 1 balance check failing, or Stage 2 reporting FAILED_BALANCE. A real disagreement was measured, and the variance figures say where.

INDETERMINATE Stage 3 reports MIGR_INPUTS_REJECTED, MIGR_SAMPLED_ONLY or MIGR_UNDECLARED_TRANSFORM, or Stage 1 reports UNMAPPABLE tags or data loss, or Stage 2 reports LOW_MATCH_RATE. The run does not support either of the other two verdicts. This is a result, not a failure of the pack, and it is the state most often reached first in a real parallel run.

Standing Context · Dated Observations

Swift MT900/910/940/942/950 retirement runs the 2027-28 coexistence window, and camt receive-capability is mandated from 2027-11. Dated observation carried from art-563, not a compliance-deadline claim by this pack.

Swift provides no MT-to-ISO 20022 conversion tool, so the translation burden sits with the receiving corporate or treasury. This pack is independent of Swift and carries no Swift endorsement.

BkTxCd classification follows the CGI-MP camt.053 Usage Guide v5.0 and the ISO 20022 ExternalBankTransactionCode1Code registry 2023-03, per art-258.

The pack declares no regulatory basis. It produces evidence a migration programme can hand to its own reviewers; it does not discharge a named duty.

Export Workflow Artifact

Download a §4-compliant workflow artifact with execution hash and step definition. Hash is deterministic over canonical {policy_parameters, output_payload} per RFC 8785/JCS.

Ask your agent

Copy this paragraph into Claude, OpenClaw, or any MCP-aware agent to run this whole workflow on the server and check one field that answers a real question.

Question: Parallel run week: does the migrated camt.053 statement reconcile against our ledger closing balance, or is there a variance to chase?
Run the AINumbers MCP tool `run_chain` with {"chain":"camt053-parallel-run-recon-pack"} and read `art-258-parse-camt053-reconciliation.reconciliation_status`.
Re-run with `inputs` for `art-258-parse-camt053-reconciliation`, reusing the values that result echoed, with `closing_balance` set to 10600. Compare the same field.
Verify: call `verify_execution_hash` (https://mcp.ainumbers.co/mcp) with `claimed_hash` set to `composite_execution_hash` and the full `composite_artifact`.
Ledger, for a human re-check: https://ledger.ainumbers.co/
PII rule: send synthetic or anonymised inputs only. The MCP server runs these kernels and logs no payloads.
Chain page: https://ainumbers.co/chaingraph/chains/camt053-parallel-run-recon-pack.html