Bridge — transfers, fees & minimums, external accounts
What this covers / who it's for. A durable, dated digest of Bridge's orchestration docs for the transfer lifecycle, fee/minimum mechanics, rail-specific rules, returns/recalls, and external accounts — the vendor facts an engineer needs before wiring
BridgeRailsProvider(ADR D118) to real traffic in FiatRails or Conversion. Facts reflectapidocs.bridge.xyzas fetched on 2026-09-03 — Bridge's docs and terms change; re-verify anything load-bearing via thebridge-developmentskill's fetch-and-cite protocol (llms.txt → matching.mdpage → cite URL + date) andchangelog/changelog.mdbefore relying on a fact here past its fetch date. This page holds no SDK code and makes no adapter-implementation claims — those live inapp-modules/rails/README.mdand D118.
Page index
The 20 Bridge docs pages this digest is built from (all under
platform/orchestration/{transfers,more,fees-and-mins,external-accounts}/):
| Page | URL |
|---|---|
| Transfer object | platform/orchestration/transfers/transfer.md |
| Static template transfers | platform/orchestration/transfers/static-templates.md |
| Transfer states | platform/orchestration/transfers/transfer-states.md |
| Transfer features | platform/orchestration/transfers/transfer-features.md |
| Source/destination updates | platform/orchestration/transfers/transfer-updates.md |
| Transfer errors & recovery | platform/orchestration/transfers/transfer-errors-and-recovery.md |
| External accounts API | platform/orchestration/external-accounts/external-accounts-api.md |
| Plaid link | platform/orchestration/external-accounts/plaid.md |
| External account validations | platform/orchestration/external-accounts/validations.md |
| Verification of Payee | platform/orchestration/external-accounts/verification-of-payee.md |
| Named payouts (fiat payout configuration) | platform/orchestration/more/fiat-payout-configuration.md |
| Static memos (deprecated) | platform/orchestration/more/staticmemos.md |
| Returns | platform/orchestration/more/returns.md |
| Funds requests (recalls) | platform/orchestration/more/funds-requests.md |
| Developer fees | platform/orchestration/fees-and-mins/devfees.md |
| Transaction minimums | platform/orchestration/fees-and-mins/mins.md |
| Cutoffs | platform/orchestration/more/cutoffs.md |
| Holidays | platform/orchestration/more/holidays.md |
| Payment tracking identifiers | platform/orchestration/more/payment-tracking.md |
| Rail specific details | platform/orchestration/more/rail-specific.md |
All URLs are prefixed https://apidocs.bridge.xyz/; full list with the fetch note at the bottom
of this page.
1. Transfer object & lifecycle
POST /v0/transfers (Api-Key + Idempotency-Key headers) creates a transfer: id, state,
on_behalf_of (customer id, required when moving funds for a user), amount,
developer_fee/developer_fee_percent, source, destination, source_deposit_instructions,
features, receipt (transfer.md). Directions: fiat→crypto, crypto→crypto, crypto→fiat;
fiat→fiat is not documented on this page.
Pull vs. deposit-and-match. If source is a Bridge wallet or prefunded account, Bridge
pulls funds — no deposit step. Any third-party source (a bank, an external crypto address)
instead returns source_deposit_instructions that the integrator must surface verbatim to the
end user; Bridge matches the inbound deposit against those instructions.
Lifecycle is strictly forward-only. The happy path is
awaiting_funds → funds_received → payment_submitted → payment_processed, and per the docs
"can never go backwards." Cancel is only possible from awaiting_funds, via
DELETE /v0/transfers/{transferID} → canceled.
Bridge does: deposit detection/matching, state advancement, refund routing.
Integrator does: create with an idempotency key, render deposit instructions unmodified,
consume webhooks or poll GET for state, and treat the payment_submitted tx hash as
provisional — only the hash on payment_processed is final (§2).
Implications for Stables: the FiatRails/Conversion adapter surface behind D118
(ManagesPayouts, ManagesOrders, ManagesTransactions) should model a per-transfer state
machine gated on exactly the four happy states, branching to the exception set below; persist
destination_tx_hash on every observation and overwrite (never append) on payment_processed.
2. Transfer states — all 13, exact names
| State | Meaning |
|---|---|
awaiting_funds | Waiting on customer funds; static templates live here permanently. |
in_review | Rare/temporary — data needs confirmation; usually seconds, else Bridge follows up within 24h (cutoffs page: onramp risk review may add ~2 business hours). |
funds_received | Funds in; Bridge preparing the outbound move. |
payment_submitted | Crypto payment submitted — tx hash here may be preliminary, not final. |
payment_processed | Complete; funds delivered. Terminal success. |
undeliverable | Could not deliver (invalid account, unsupported destination asset). |
returned | Payment sent but failed; funds back at Bridge; refund underway. |
missing_return_policy | Bridge wants to refund a crypto deposit but no crypto return policy is configured (§9). |
refund_in_flight | Refund initiated, in progress. |
refunded | Refund complete — original sender, per crypto return policy, or back to the originating Bridge wallet. |
refund_failed | Refund attempt failed — usually a closed/deactivated/suspended fiat receiving account; Bridge can only refund fiat to the ORIGINAL sender, so the customer must fix it with their bank before retry. |
canceled | DELETE from awaiting_funds only. |
error | Blocked; needs manual review or developer action. |
The exception set (transfer-states.md) is returned, refunded, undeliverable, error plus
the refund_*/missing_return_policy family.
Implications for Stables: alert ops on error, refund_failed, missing_return_policy, and
undeliverable — these are the states a domain handler cannot resolve by waiting.
3. Source/destination shapes per rail
Fiat in (deposit-instruction flow). Request source: {payment_rail, currency}; response
source_deposit_instructions carries bank_account_number, bank_routing_number, amount,
currency, and deposit_message for USD, with rail-specific extras (SEPA adds iban, bic,
account_holder_name, bank_name, bank_address). The deposit_message (prefixed BRG, unique
per transfer) must be attached verbatim as the wire memo / ACH description / SEPA reference /
SPEI memo — omission risks "significant delay or return" (staticmemos.md). Fiat pulled from an
existing external account instead uses source: {payment_rail: "ach", currency: "usd", external_account_id} (devfees.md example).
Crypto in. source: {payment_rail: <chain>, currency, from_address} — from_address is
required unless features.allow_any_from_address: true. Response source_deposit_instructions
adds to_address (Bridge's deposit address); memo-chains (Stellar, Tron) add blockchain_memo,
which must be included or the off-ramp is significantly delayed. A crypto return policy must be
configured before accepting crypto deposits (§9).
Bridge wallet / prefunded source. source: {payment_rail: "bridge_wallet", currency, bridge_wallet_id} — pulled, no deposit step. initiation must be sent on Create Transfer only
when the wallet's own response carried initiation_required: true, and is never echoed back.
allow_any_from_address is not supported for this rail; bridge_wallet_id cannot be set for
other rails.
Crypto out: destination: {payment_rail, currency, to_address} (static memos/VAs use
address, plus optional blockchain_memo). Fiat out:
destination: {payment_rail, currency, external_account_id} — e.g. a SEPA destination must be a
European IBAN account in EUR. Fixed-output transfers exist (validation error references
"fixed output transfers") but their request shape is not documented on these pages — treat as an
open question (§18).
Implications for Stables: the neutral Data\* DTOs behind ManagesPayouts/ManagesOrders
need per-rail source/destination shape variants (bank vs. crypto vs. bridge_wallet vs.
external_account_id) rather than one flat shape — mirror the discriminated-union approach the SDK
already uses for spec-shaped requests.
4. Fixed vs. flexible amount, and fee-mode binding
- Fixed:
amountset; the customer must send that exact amount; fee isdeveloper_fee(fixed USD, ≤2dp). - Flexible:
features.flexible_amount: true,amountomitted; any amount sent is matched andamountis populated post-match; fee isdeveloper_fee_percentONLY — a fixeddeveloper_feeis rejected on a flexible transfer. Bridge "strongly recommends" flexible to avoid validation failures; static templates auto-enable it when created with no amount. features.allow_any_from_address: trueremoves thefrom_addressrequirement; recommended for crypto sources where the sender is uncontrollable (e.g. exchange withdrawals); not valid on the prefunded rail.
Implications for Stables: amount mode and fee mode are coupled at the API level — the adapter
must choose developer_fee vs developer_fee_percent based on whether the transfer is fixed or
flexible, not independently (§13 has the full fee-mode table).
5. Static templates
features.static_template: true creates a reusable, dashboard-style "saved payment route" whose
id never changes and which stays in awaiting_funds permanently until canceled. Every matched
deposit spawns a new transfer instance with its own id (instances do not carry
static_template in features); webhooks fire on instance creation and every update. List
instances via GET /v0/transfers?template_id=<id> (the template itself is included). Updating a
template via the Update Transfer endpoint affects only future deposits.
Templates differ from virtual accounts: template deposit addresses are shared and require the deposit message; VAs give each customer a unique address with no memo needed.
Implications for Stables: if we adopt static templates for a funding surface, key inbound records by transfer-instance id (not template id) and dedupe there.
6. Source/destination back-fill (transfer-updates)
After funds arrive, Bridge back-fills rail-specific sender/receiver fields onto source and
destination — e.g. wire onramp adds bank_beneficiary_name, bank_routing_number, imad,
deprecated omad; ACH push adds description; SEPA adds bic, uetr, iban_last_4,
payment_scheme. Off-ramp: wire adds imad, ACH adds trace_number. The page is silent on
back-fill for SPEI/PIX/FPS/COP — only the identifier names in §12 (payment-tracking) are
documented for those rails.
Implications for Stables: treat source/destination as append-only growing objects;
persist the raw JSON for reconciliation rather than a fixed column set.
7. Errors & recovery
Error body: code, message, optional source.key field path (for invalid_parameters).
Notable codes: 400 invalid_parameters / frozen / has_not_accepted_tos /
requires_active_kyc_status / deactivated_external_account / duplicate_record /
not_truly_idempotent; 401 not_allowed; 403 missing_required_endorsements /
developer_limits_exceeded; 409 resource_state_conflict; 424 external_dependency_failed.
Idempotency semantics: duplicate_record = the same Idempotency-Key reused with different
parameters; not_truly_idempotent = same key, same intent, but a body mismatch on retry — reuse a
key only for an exact retry. Retry guidance: 424/500/503 retry with backoff; 409 retry only
after the conflicting state changes; 400/401/403/404/422 do not retry without changing the
request.
Implications for Stables: map code (not HTTP status) to RailsException subtypes in
BridgeExceptionTranslator; treat frozen, requires_active_kyc_status,
has_not_accepted_tos, and missing_required_endorsements as customer-state gates that should
surface to compliance/ops rather than being retried.
8. Fiat returns (fiat_deposit_return)
Applies to ACH, FedNow, Wire, and SEPA deposits (both Transfers and Virtual Accounts); always
returns to the ORIGINAL sender. Mechanism: create a transfer with
destination: {payment_rail: "fiat_deposit_return", currency: "usd", deposit_id} and a crypto
source — either a live crypto source the integrator funds, or (recommended) a bridge_wallet
source for a fully programmatic, prefunded return.
Constraints: source.currency must be crypto and equivalent to destination.currency;
on_behalf_of must match the original deposit's customer; amount must equal the original
for ACH/FedNow, and may be ≤ the original for Wire/SEPA; the return must be requested
within 60 days of the deposit. The pages are silent on SPEI/PIX/FPS/COP returns, on return
fees, and on non-USD return currencies.
Implications for Stables: treasury must keep a funded Bridge wallet available for returns, and
funding/payments handlers must persist deposit_id for every inbound fiat deposit and enforce the
60-day / exact-amount rule locally before calling Bridge.
9. Crypto returns / return policy
Bridge resolves a crypto return address in this order: (1) Bridge-originated funds → the same
Bridge wallet/prefunded account; (2) a liquidation address's return_address; (3) the originating
transfer's return_instructions.return_address; (4) the developer's configured
crypto_return_policy; (5) otherwise the transfer lands in missing_return_policy.
Policy strategies: static_address (recommended — a developer-controlled wallet) or
refund_to_sender (must be explicitly opted into; Bridge calls it "unsafe" for exchange omnibus
wallets, and it's unsupported for stablecoin-sandwich flows since Bridge won't refund into its own
omnibus wallets). One address per (currency, chain); a missing chain falls back best-effort to
the same currency on another chain. Tron accepts deposits but does not support refunds (use
Ethereum for USDT refunds); Stellar/Tron refunds require a memo.
Implications for Stables: configure a static return policy per (currency, chain) we accept
before any go-live grant to Bridge for Custody/FiatRails, and route missing_return_policy to
an ops alert — it is a stuck-funds state, not a retryable error.
10. Funds requests (recalls)
A bank/partner-initiated recall of a fiat deposit. GET /v0/funds_requests[?customer_id=&fraud=]
returns objects the docs describe only by two named fields: fraud (boolean) and deposit_id.
Before money movement completes, Bridge auto-returns the recalled funds to the sending account;
after funds have left Bridge, the developer must fall back to the fiat-return flow (§8). Bridge
Ops follows up on fraud=true; excessive recall volume can trigger remedial action against the
developer account. There are no webhooks for this surface — it is poll-only.
Implications for Stables: this is a fraud/compliance signal as much as an operational one —
fraud=true should feed the fraud-and-device-risk pipeline (see
fraud-device-risk-development), and a scheduled poller with idempotent upsert (keyed on
deposit_id) is required since there is no webhook to key off of.
11. External accounts
POST /v0/customers/{customer_id}/external_accounts (Idempotency-Key); Bridge owns
KYC/KYB validation of the destination account. Shapes vary by account_type/currency:
| Currency | account_type | Request shape | Notes |
|---|---|---|---|
| USD | us | account{routing_number, account_number, checking_or_savings} | Response masks to last_4; adds beneficiary_address_valid, active. |
| EUR | iban | iban{account_number, country, bic} | Response returns iban{last_4, bic, country}. VoP-eligible. |
| MXN | clabe | clabe{account_number} | A $0.01 MXN deposit is credited at setup; customer must hold a SPEI endorsement or creation is rejected. |
| BRL | pix | pix_key{pix_key, document_number} or br_code{br_code, document_number} | Response is masked (account_preview, document_number_last4). |
| GBP | gb | account{sort_code, account_number} | VoP-eligible; response example returns them unmasked. |
| COP | bre_b | account{bre_b_key} | — |
US validations: street/city/postal_code/country required (+state where applicable), no PO Box/PMB, street must start with a number, 3–35 chars per line — Bridge auto-formats to 3 lines and abbreviates country names.
Plaid is link-only: POST …/plaid_link_requests → client-side Plaid Link → server-side
POST /v0/plaid_exchange_public_token/{uuid}; the resulting external account is created
asynchronously (seconds to minutes) and only then visible via list. Chase/BofA via Plaid are
ACH-only (no wire) — use the direct API for wire.
Verification of Payee (VoP): POST …/external_accounts/{ea_id}/verify (no idempotency key);
only for iban/gb; requires account_owner_name; 409 if a check is already in progress; poll
for account_verification{match_level, reason_code, validated_account_owner_name, requested_at, completed_at} where match_level ∈ pending|match|close_match|no_match|error.
Undocumented: deactivate/reactivate/delete of an external account are not described on any
of these pages — the only observable signals are the active response field and the 400 code
deactivated_external_account returned when a destination account has been deactivated.
Implications for Stables: store only the Bridge external-account id + masked fields locally
(never the full account/routing number); gate SEPA/GBP payout eligibility on VoP match (or
close_match with manual review) before the funding module allows a payout; expect Plaid-linked
accounts to arrive async and poll/webhook rather than assume immediate availability.
12. Payment tracking identifiers & receipts
Per-rail tracking identifiers (payment-tracking.md): crypto source_trx_hash/
destination_trx_hash (+ blockchain_memo); ACH trace_number + ach_reference; Wire imad +
wire_message; FedNow end_to_end_id; SEPA tracking_number (UUID) + sepa_reference; SPEI
tracking_number + spei_reference; PIX tracking_number (E2E) + reference; FPS
tracking_number + reference; COP tracking_number + reference.
The transfer receipt object carries initial_amount, developer_fee, exchange_fee,
subtotal_amount, gas_fee, final_amount, destination_tx_hash, and a dashboard url —
destination_tx_hash appears only after completion.
Implications for Stables: keep a per-rail identifier map for statements and reconciliation,
and surface receipt.url to users needing a Bridge-hosted receipt link. See §17 for a naming
inconsistency between this page and transfer-updates.md.
13. Developer fees & minimums
Developer fees are withheld from the customer amount into a developer ledger and paid out monthly on the 5th, always in USD regardless of the collection currency, to a configured fee external account. A blank fee is 0.0; fees are valid only where Bridge moves funds out, not to Bridge.
- Fixed-amount transfers use
developer_fee— a fixed USD decimal (≤2dp) that must leave the destination amount at or above the transaction minimum (e.g. a $5.00 minimum with a $5.00 or $5.01 fee on a $5.00-ish transfer is rejected). - Flexible transfers, VAs, and static memos use
developer_fee_percent— a percentage of the source currency, must be less than the transaction amount, up to 5 digits of precision. - Virtual account
fee_config(beta, by request) supports per-rail flat + percent + min/max fee composition; mutually exclusive withdeveloper_fee_percent(setting one clears the other). - Liquidation addresses use a separate global
default_liquidation_address_fee_percentand an optional per-addresscustom_developer_fee_percent.
Minimums (mins.md) are enforced after fees are deducted — e.g. a $1 deposit minus a 1%
fee nets $0.99, which fails a $1 minimum. Sub-minimum "dust" is neither credited nor returned; VA
onramps accumulate microdeposits and only settle once the accumulated sum clears the minimum.
Rail minimums named on the rail-specific page: EUR 1; MXN 50; BRL 10; GBP £2.00 onramp / 3.00 of
source offramp; COP 100.
Implications for Stables: the fee-mode choice is a function of the amount mode (§4), not
independently selectable; validate net = amount − fee ≥ rail minimum client-side before
submission, since Bridge does not refund sub-minimum deposits; and model developer-fee settlement
as a monthly USD batch, not a per-transfer credit, in any treasury/statement surface.
14. Rail-specific rules
| Rail | 1st-party | 3rd-party | Notable caps |
|---|---|---|---|
| USD ACH/Wire/FedNow | Unlimited | Registered business ✓; family member sharing a surname ✓; individual P2P < $4,000 only | Blocked in New York and Texas for most 3rd-party payments |
| EUR SEPA | Unlimited | Businesses unlimited; individuals "contact account manager" | Min 1 EUR; > 1,000,000 EUR must route via SEPA Credit (1 business day) |
| MXN SPEI | 1,000,000 MXN | Individuals 15,000 MXN; businesses unlimited | EU customers unsupported; min 50 MXN; SPEI provider maintenance Thursdays 06:00 UTC, up to 2h |
| BRL PIX | Supported | No individual 3rd-party deposits; businesses supported | EU customers unsupported; onramp BR-individuals (CPF) only; $500K USD-eq/month customer cap (EDD to raise); $20M USD-eq/month developer offramp cap; min 10 BRL |
| GBP FPS | Unlimited | No individual 3rd-party deposits; businesses unlimited | EU customers unsupported; min £2.00 onramp / 3.00 source offramp; > £1M via BACS (3 business days) |
| COP Bre-B/Bank Transfer | Unlimited | No individual 3rd-party deposits; businesses unlimited | EU customers unsupported; min 100 COP; Bre-B max 11,552,000 COP (larger auto-routed as Bank Transfer) |
Implications for Stables: these per-rail caps and the recurring "EU customers not supported"
flag are eligibility gates that belong in the provider-support matrix pattern D117 introduced
(see wiki/engineering/decisions/d117-onboarding-activity-declaration.md) — a routed Bridge grant
without enforcing these locally would let a customer submit a transfer Bridge will reject at the
API layer instead of at intake.
15. Cutoffs, settlement & holidays
Fiat rails run on banking days/hours; crypto is 24/7/365. A missed cutoff pushes settlement to the
next business day; transfers over $500K may add up to an hour on any rail; onramp in_review may
add ~2 business hours.
Selected destination-rail cutoffs (ET): Same-day ACH cutoffs 9:30 AM / 1:45 PM / 2:30 PM → same-day settlement (before 2:30 PM guaranteed), $1M limit, else falls back to next-day ACH; Wire cutoff 4:45 PM → ≤2h; SEPA Instant → ≤5 min (≤€1M, auto-reroutes to SEPA Credit if the beneficiary bank doesn't respond); SPEI/PIX/Bre-B → ≤30 min; FPS → ≤30 min (>£1M via BACS, ≤3 business days); USDT (all chains, traded not 1:1) ≤60 min; USDC/EURC/Bridge-issued stablecoins ≤30 min.
Holidays are tabulated per rail for 2026–2027; USD ACH/Wire follow Fed holidays, EUR SEPA Credit has 6 named holidays, MXN SPEI and COP Bank Transfer have national lists, and SEPA Instant/PIX/FPS/Bre-B observe none. A transfer initiated on a holiday for its destination rail queues to the next business day.
Implications for Stables: any settlement-time estimate we surface to users should be computed from destination rail + ET cutoff + the holiday calendar, not a flat SLA.
16. Named payouts (fiat payout configuration)
The originator name shown on a fiat payout is one of customer (premium, via Support/AM),
developer, bridge, or payment_provider — support varies per rail (usd.wire defaults to
developer, allows customer; usd.ach is bridge-only; eur.sepa is customer-only;
brl.pix/mxn.spei are payment_provider-only). Configured via the dashboard's "payout
identity" tab or the fiat-payout-configuration PATCH API; names are the onboarded legal-entity
names and cannot be changed after the fact. Bulk enablement is capped at ≤5 PATCH/s within the
global 10 req/s rate limit.
Implications for Stables: if we ever need customer-named payouts (SEPA, premium USD wire),
that's a per-tenant configuration step against Bridge's dashboard/API, not something the adapter
can set unilaterally per-transfer.
17. Static memos (deprecated) — historical reference only
Long-lived wire/ACH-push deposit instructions bound to a fixed crypto destination
(POST /v0/customers/{id}/static_memos). Bridge's own docs mark this deprecated in favor of
static template transfers (§5); it is documented here only because its event-history model
(funds_received → payment_submitted → payment_processed, plus in_review/refund/
account_update) is the same shape virtual-account event history uses. Do not build new
integration on static memos.
Bridge doc inconsistencies noticed
awaiting_source_depositvsawaiting_funds. The static-templates page states a template's state "will remainawaiting_source_deposit" while its own JSON example showsawaiting_funds, and the dedicated transfer-states page lists onlyawaiting_fundsas a real state. Treatawaiting_fundsas canonical;awaiting_source_depositlooks like stale prose on Bridge's side.destination_tx_hashvsdestination_trx_hash. The receipt object and thetransfer-updatespage both usedestination_tx_hash; the payment-tracking page's per-rail crypto identifier table instead usesdestination_trx_hash. These read as the same field named two ways across pages — confirm against a live response before hard-coding either spelling in a mapper.- Undocumented external-account lifecycle. Deactivate/reactivate/delete operations on an
external account are never described on any of the 20 pages this digest covers, despite the
activefield and thedeactivated_external_accounterror code implying such a lifecycle exists server-side. - Undocumented
return_instructionsand fixed-output request shapes. Both are referenced by name (in the returns page and in a transfer validation error, respectively) but neither page documents how to populate them on a create-transfer request.
Open questions for Bridge
Consolidated + tracked in flow-alignment.md §Open questions; this section keeps this page's own detail.
- Which spelling is authoritative,
destination_tx_hashordestination_trx_hash— or do both exist as distinct fields in different contexts? - What is the canonical
awaiting_funds/awaiting_source_depositstate name, and is the static-templates page's prose simply stale? - What is the request shape for a fixed-output transfer (currency-pair conversion with a fixed destination amount), referenced only by its validation error message?
- What is the
return_instructionsobject's shape on a transfer create/response — is it settable by the integrator, or purely a Bridge-populated read field? - Are external accounts deactivated/reactivated/deleted via an undocumented endpoint, a support request, or only implicitly (e.g. a bank-side NACHA return marks them inactive)?
- Does a fiat return support currencies other than USD, and are there any fees on a
fiat_deposit_returntransfer? - Do SPEI/PIX/FPS/COP deposits support the fiat-deposit-return flow described for ACH/FedNow/Wire/SEPA (§8), and if not, what is the equivalent for those rails?
- What are the funds-request (recall) object's full response schema and resolution-deadline
semantics — the docs name only
fraudanddeposit_id? - Under what conditions does an ACH pull/debit source get rejected with
ACH pull/debit not supported, referenced only in a validation-error example?
Fetched 2026-09-03
All 20 pages retrieved as raw .md over HTTPS from https://apidocs.bridge.xyz/, discovered via
llms.txt, on 2026-09-03. Re-verify via the bridge-development skill's protocol and
changelog/changelog.md before relying on any fact above past this date.
platform/orchestration/transfers/transfer.mdplatform/orchestration/transfers/static-templates.mdplatform/orchestration/transfers/transfer-states.mdplatform/orchestration/transfers/transfer-features.mdplatform/orchestration/transfers/transfer-updates.mdplatform/orchestration/transfers/transfer-errors-and-recovery.mdplatform/orchestration/external-accounts/external-accounts-api.mdplatform/orchestration/external-accounts/plaid.mdplatform/orchestration/external-accounts/validations.mdplatform/orchestration/external-accounts/verification-of-payee.mdplatform/orchestration/more/fiat-payout-configuration.mdplatform/orchestration/more/staticmemos.mdplatform/orchestration/more/returns.mdplatform/orchestration/more/funds-requests.mdplatform/orchestration/fees-and-mins/devfees.mdplatform/orchestration/fees-and-mins/mins.mdplatform/orchestration/more/cutoffs.mdplatform/orchestration/more/holidays.mdplatform/orchestration/more/payment-tracking.mdplatform/orchestration/more/rail-specific.md
Back to the Bridge cluster index · ← Engineering wiki.