> ## Documentation Index > Fetch the complete documentation index at: https://docs.lumx.io/llms.txt > Use this file to discover all available pages before exploring further. # Migrate SWIFT wires to local payout rails > A copy-paste prompt that maps each SWIFT corridor to the local rail Lumx settles on, rebuilds beneficiaries as destinations and cuts over safely. Paste this prompt into your coding agent if you pay suppliers or staff abroad by international wire today. The agent builds a corridor table, rebuilds beneficiaries as destinations, and moves each corridor to a local rail where one exists, with wires as the fallback. ## Before you start * A Sandbox API key. See [Authentication](/get-started/authentication). * Your beneficiary list with country, currency, and the bank identifiers you hold. ## Prompt ```text Prompt theme={null} You are a senior backend engineer moving an existing international wire flow — MT103 instructions, correspondent banks, IBAN and BIC on file — onto Lumx, settling on a local rail wherever one exists. 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. Every page has a .md twin at its own path; /get-started/coverage carries the rails and settlement times. 2. https://lumx-docs-public-prod.s3.us-east-1.amazonaws.com/api-production.yaml — the OpenAPI 3.1 spec. The rail enum in the spec is the list you are allowed to build against. Work against sandbox at https://api-sandbox.lumx.io with a server-side key sent as "Authorization: Bearer ". 1. Build the corridor table first, from the spec's rail enum and the coverage page: which of your destination countries settles on a local rail, which stays on SWIFT, and what each one costs in settlement time. This table is the decision, and it is what a human reviews before any code ships. 2. Rebuild each beneficiary as a destination with POST /destinations. A wire record maps onto the SWIFT branch — bic plus iban or accountNumber, with a bank object — and for EUR onto SEPA, which takes iban and bic. It does not map onto PIX, SPEI or FPS, which need a local identifier you do not have on file. Mark those rows as needing collection from the beneficiary. 3. Set holder.relationship from the closed enum on every destination. A wire instruction does not carry it, so it has to come from your own records. 4. Quote with POST /exchange-rates when the payer compares the wire cost against the local rail; type LOCKED returns an id and an expiresAt you must respect. 5. Pay with POST /transactions/off-ramp, sending an Idempotency-Key that is a UUID v4 stored against your payment reference before the call, so a retry reuses it and cannot duplicate a payment a wire system would have sent once. 6. Replace wire-confirmation polling with the offramp.* webhook events, and confirm with GET /transactions/{id} before marking a supplier paid. There is no MT103 to reconcile against; the transaction receipt is the record. 7. Cut over one corridor at a time behind a feature flag, keeping wires available as the fallback until a full cycle reconciles. Constraints: - Do not put a rail in your mapping that is not in the spec's rail enum. The coverage page also lists rails badged for a future quarter; those are not available to build against today, and naming one in code is the failure mode this task exists to avoid. - Do not state a rate limit while iterating beneficiaries. None is published. Handle 429 TOO_MANY_REQUESTS with exponential backoff. - Match errors on code, never on message. Deliverables: - The corridor table: country, currency, rail, settlement time, and the beneficiary fields still missing. - A destination builder per rail branch, with the unmigratable rows listed rather than filled in. - A flagged payout path that runs local-rail and wire side by side for one cycle. ``` ## How to use 1. Export your current beneficiary list with country, currency and the identifiers you hold. The corridor table is only as good as that input. 2. Collect the missing local identifiers from beneficiaries yourself — a PIX key or a CLABE is not derivable from an IBAN, and the agent will correctly refuse to invent one. 3. Pick the first corridor to cut over from the table, not from volume. The one with the cleanest beneficiary data is the one that proves the path. ## What the prompt builds | **Endpoint** | **What the agent uses it for** | | :- | :- | | `POST /destinations` | Rebuilds each beneficiary as a destination | | `POST /exchange-rates` | Quotes the local-rail payout against the wire cost | | `POST /transactions/off-ramp` | Sends the payout | | `GET /transactions/{id}` | Confirms the payout before marking a supplier paid | ## Errors to expect These codes come from the [errors catalog](/developer/errors), for the resources this prompt uses. Match on `code`, not on `message`. | **Code** | **Status** | **When it happens** | | :- | :- | :- | | `RAIL_NOT_ENABLED` | 403 | Rail is not enabled for this project. | | `EXCHANGE_RATE_EXPIRED` | 422 | Locked rate has expired. | | `INVALID_PAYMENT_DESTINATION` | 400 | Payment destination is invalid. | | `INSUFFICIENT_BALANCE` | 422 | Balance is too low for the operation. | ## Related resources Supported currencies, rails, and stablecoin pairs. Cut-offs and settlement times per rail. Replace a spreadsheet and a bank portal with API payouts. Pay out from a stablecoin balance to a local bank account. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.