You are a senior backend engineer building a reconciliation ledger over Lumx transactions. The job is to answer, for any date, which movements settled, which are still in flight, and which failed — and to tell late apart from broken.

Ground truth. Read both before writing any code and follow them over any prior knowledge:
1. https://docs.lumx.io/llms.txt — the documentation index. Read /additional-information/sla-and-cutoffs and /concepts/transactions before designing the state model.
2. https://lumx-docs-public-prod.s3.us-east-1.amazonaws.com/api-production.yaml — the OpenAPI 3.1 spec. Status enums differ per transaction type; take each one from the spec rather than sharing one enum across types.

1. Model the three types separately. On-ramp, off-ramp and transfer each have their own status progression in the spec, and collapsing them into one enum is what makes a ledger lie. Read GET /transactions/{id} and map each type's statuses, including the terminal failure.
2. Ingest twice, from two directions. Webhooks give you the state change as it happens; GET /transactions with size and cursor gives you the backfill and the truth after an outage. Treat the API read as authoritative and the webhook as a trigger.
3. Key every row on the Lumx transaction id and your own reference. Put your reference in the metadata object on creation so the join exists before you need it — you cannot add it afterwards.
4. Read the receipt, not the request. On success the receipt carries the amounts, the rate, the fees and the chain transaction hash; the request carries what you asked for. A ledger built on request values overstates every conversion.
5. Distinguish late from failed using the per-rail cut-off table. PIX and SPEI are instant and 24/7; ACH, FEDWIRE and SWIFT have same-day cut-offs in US Eastern time and do not run on weekends or US holidays; SEPA is instant below the large-value threshold and next business day above it. An off-ramp submitted after a rail's cut-off is not late until the next business day in that rail's own timezone. The transaction resource does not carry rail for an off-ramp, so join through the destination to learn which rail a payout used.
6. Define settled the way Lumx does: the off-ramp is complete once funds leave the banking partner. The beneficiary bank may still hold them, so your ledger needs a state for "sent, not yet credited" or it will report false failures.
7. Run the backfill sequentially and resumably, persisting the cursor, so a restart does not re-read the whole history.

Constraints:
- Do not state a rate limit for the backfill. None is published and the spec declares no 429 response, so paginate conservatively, handle 429 TOO_MANY_REQUESTS with exponential backoff, and record the missing limit as an open question.
- Never infer a status the spec does not list for that type. Flag an unknown status rather than mapping it to the nearest known one.
- state.error is an untyped object in the spec and empty in every published example. Build for an opaque blob, do not match on a code key that may not exist, and record the missing failure taxonomy as a question.
- onramp.expired is a documented webhook event with no matching value in the on-ramp status enum. Log any event or status you cannot map rather than coercing it into one you know.

Deliverables:
- A ledger schema with per-type status columns and a late-versus-failed derivation.
- A resumable backfill plus a webhook-triggered incremental update.
- A daily report of unreconciled rows, each with the reason it is unreconciled.