Everything that
goes wrong.

What is not real here

Four of the five rails in this build are simulated. Each is disclosed on-screen at the moment it matters, and the badge text is read from the provider registry rather than written into the screens, so a screen cannot claim a leg is real while a fixture is bound.

The full list

Every failure mode the corridor produces, with what the user sees and what residual risk remains after mitigation. Residual is the column that matters: a register where everything is fully mitigated is a register that has not been thought about.

The 60-day problem

This is the failure that shaped the product. Everything else on this page is engineering; this one is a balance sheet wearing an engineering costume.

• The shape of it. ACH is pull-based and reversible. Corridor debits the sender's bank, mints USDC, sends it on Base, and a Turkish bank credits lira. The lira is irreversible. The ACH debit is not.
• Holding to settlement covers the common cases. R01 insufficient funds and R08 stop payment surface within about two banking days. Waiting for settlement before releasing the payout eliminates both, which is exactly why screen 09 shows "USD received" as a discrete, timestamped step rather than hiding a two-day wait inside a spinner.
• It does not cover R10. An unauthorised-debit return can arrive up to 60 days later. By then the recipient has spent the lira. No holding period a customer would tolerate closes this window.
• So it is priced, not solved. Residual exposure sits in the $3.75 fee and is bounded by per-user velocity limits that rise with settled history rather than elapsed time. First transfer capped low; limits earned, not aged into.
• The alternative is a real product, not a mistake. Fronting the funds buys same-day delivery and requires working capital plus fraud scoring. That is the right call at scale and the wrong one for a first corridor.

// The distinction the fold has to make, and why `clawback` exists.
// An ACH return before value leaves is a clean refund.
// The same return after payout is a loss event.
case 'onramp_returned':
  achReturn = e.code;
  state = state === 'funding' ? 'refunded' : 'clawback';
  break;

What Türkiye cannot tell you

Local IBAN validation catches typos, transpositions, wrong-country pastes and bad lengths, all before a network call, on every keystroke. It cannot catch a structurally perfect IBAN belonging to the wrong person, and Türkiye has no name-check service to resolve that.

• Markets that offer confirmation-of-payee (UK CoP, and increasingly the EU) let you verify the account holder's name before debit. Türkiye does not, so name mismatch is discovered by the receiving bank after the money is already in flight.
• The design absorbs what it cannot prevent. Warn loudly at entry with the real consequence and the real delay; mark previously-successful recipients verified and default to them; make the returned-payout path non-catastrophic.
• Screen 11c leads with "Your money is safe" above any explanation, because a user watching ₺26,420 fail needs the location of their funds in the first second, not the third paragraph.
• The timeline stays visible with the failure in place, so the return reads as a completed round trip rather than a hole. Fees for the leg that did not happen are refunded.

Three clocks, one story

Bridge, the payout partner and the chain all report independently. They will deliver late, twice, and out of order. None of that is exceptional; a design that only handles the happy path stalls silently in production.

• Push is the fast path, polling is the floor. Any transfer not in a terminal state is re-polled on exponential backoff. Dropped webhooks are expected, not escalated.
• seq is assigned by Corridor on ingress, never taken from the provider. A vendor's ordering guarantees are that vendor's business.
• State is a fold over an append-only log. Redelivery is idempotent because duplicates are dropped by seq; reordering is corrected by sorting before folding. Both are covered by tests.
• Steps are monotonic in the UI. A late event that would move a completed step backwards is recorded in the log but not reflected on screen. A user watching a completed step un-complete has just learned not to trust the screen, and they would be right.
• parseWebhook returns null rather than throwing on unknown or badly-signed payloads. A provider shipping a feature you have not heard of should never be an outage.

What this build does not do

Distinct from the simulated rails above: these are gaps in the artifact itself, not in the design.

What breaks first

If this corridor took real volume tomorrow, in the order I would expect things to hurt:

• 1 · Fraud, not engineering. A US-outbound corridor to a high-inflation market is an attractive laundering route. Velocity limits and settled-history tiers are a start; real operation needs transaction monitoring, device fingerprinting and a SAR process. Nothing on the screens hints at how much of this exists behind them, which is correct.
• 2 · The R10 reserve. Unauthorised-return exposure scales linearly with volume and lands 60 days behind it. Growth makes this worse in a way that feels fine right up until it doesn't.
• 3 · Payout partner concentration. One Turkish partner is a single point of failure for the entire corridor. The PayoutProvider seam makes a second one cheap to add, which is most of the argument for having built it.
• 4 · Rate risk on the lock. A 15-minute lock is a free option written to the customer. At volume, in a currency that moves like TRY, that needs hedging or a shorter window.
• 5 · Reconciliation. Three providers, three clocks, and a ledger that must balance daily against all of them. The event log makes this tractable; it does not make it small.