Sending money across borders still costs an average of 6.36% of the amount sent, and the transfer could take days to settle, according to the World Bank's September 2025 remittance data. At the same time, Swift says nearly 60% of Swift GPI payments are credited to end beneficiaries within 30 minutes. Both facts can be true because money movement is not one system getting faster at one pace. It is a stack of ledgers, messages, balance-sheet commitments, compliance checks, and software decisions.
For a business, the design question is rarely speed alone. The better question is which rail puts settlement, liquidity, counterparty risk, reversibility, and programmability in the right place for the flow. A contractor payout and a card settlement are not the same job, and each one leans on different parts of that stack. When each of those flows needs a different rail, stitching them together in-house is where the real cost hides.
How money movement works
Every money movement system has to decide which ledger changes, when that change becomes final, and who takes risk before it does.
A payment is not complete when a user taps a button or a business sends an instruction. It is finished when the receiving party can use the funds, and every institution in the path has reconciled what changed.
A payment lifecycle has several moments:
- Initiation: A customer, business, or system starts the payment.
- Authorization: A network or institution approves that the payer can send or spend.
- Routing: The instruction finds the correct institution, account, wallet, or network address.
- Clearing: The parties exchange transaction details and calculate obligations.
- Settlement: Value moves between institutions, wallets, or accounts.
- Funds availability: The recipient can use the money.
- Reconciliation: The business can match the movement to a customer, invoice, payout, order, or internal ledger.
The gap between initiation and funds availability is where architecture decisions get made and where product promises can break down.
A card payment can be authorized in seconds while settlement happens later. A cross-border bank payment can receive a tracking update quickly while funds availability still depends on intermediaries. A stablecoin transfer can settle onchain at any hour, but the business still needs fiat onramps, offramps, identity checks, custody, and accounting around it.
How correspondent banking moves money
Correspondent banking is still the default architecture for many cross-border bank payments because it extends reach through bank relationships. But that reach depends on intermediary routing, prefunded liquidity, and operating windows.
When a bank cannot settle directly with a bank in another country, the payment can pass through one or more correspondent banks that hold balances for each other through nostro and vostro accounts, meaning one bank’s “nostro” is its money held at another bank, and the other bank’s “vostro” is that same account viewed as a client deposit.
This model works because banks already understand it. Correspondent banking supports large values, regulated institutions, and a wide range of currencies. Plus, Swift GPI has made many cross-border payments faster and more transparent than the outdated assumption that banking payments are inherently slow, opaque, and unpredictable.
The tradeoff is that the money movement path still depends on intermediary banks, local cutoffs, sanctions screening, foreign exchange, and prefunded balances sitting in the right place before the payment arrives.
Where correspondent banking fits
Correspondent banking is strong for reach and institutional trust, but weaker when a business needs programmable control over every step. A cross-border supplier payment often starts with one system for the wire and another for Swift tracking. Foreign exchange, intermediary-fee reconciliation, and customer updates can sit in separate workflows.
Correspondent banking does a difficult job with a model built around bank relationships and balance-sheet coordination. Businesses have to decide whether that model gives them enough speed, transparency, and software control for the product they are building.
How card networks move money
Card networks are excellent at real-time authorization and global acceptance, but they are not the same thing as instant settlement.
When a customer taps a card, the merchant’s acquirer routes an authorization request through the card network to the issuer, which approves or declines the transaction in seconds. That response is fast because it is a permission decision.
Clearing and settlement follow after authorization. The US Bureau of the Fiscal Service describes card processing as authorization first, then clearing and settlement, with next-day funds availability in its Card Acquiring Service flow. Commercial card programs vary by region, network, acquirer, and merchant setup, but the separation is structural: the approval message and the settlement movement are different events.
That separation is why cards work so well for spending. Card networks bring broad acceptance, issuer risk decisioning, dispute rules, chargebacks, fraud controls, and familiar customer behavior. A business can accept a card from a customer it has never met because the network has already built the trust fabric around that interaction.
Those strengths come with tradeoffs:
- Speed: Authorization is fast, but settlement and funds availability can lag.
- Cost: Interchange, assessments, processing fees, and cross-border costs can be material.
- Reversibility: Chargebacks protect customers, but they also create operational and fraud exposure for businesses.
- Programmability: A card transaction carries structured data and network rules, but the rail is not designed for arbitrary business logic, custom settlement assets, or programmable treasury flows.
Where card networks fit
Cards are a strong architecture when acceptance and customer experience matter more than settlement control. They are weaker when a business is trying to move high-value funds, rebalance treasury, pay many global recipients, or build money movement that needs to choose currency, rail, and settlement behavior dynamically.
How real-time rails move money
Real-time payment rails are domestic bank-to-bank networks designed to settle each transaction as it happens, so the money is final within seconds or minutes. When both the sending and receiving banks are in the same real-time scheme, they can treat “payment sent” as “payment complete” instead of promising speed while settlement actually happens later. By contrast, batch systems group payments together and settle them afterward, which delays finality and limits what your product can safely guarantee about availability and release timing.
Major real-time rail schemes include:
- FedNow (US): Operated by the Federal Reserve, provides interbank clearing and settlement in near real time, 24/7, any day of the year
- RTP (US): Operated by The Clearing House, payments clear and settle individually with immediate finality
- Pix (Brazil): Instant payments available around the clock, widely adopted for consumer and business transactions
- Faster Payments (UK): Near-instant bank transfers available 24/7 across participating UK institutions
- SEPA Instant (Europe): Euro-denominated instant credit transfers across participating European banks
Real-time rails also carry richer payment data than many older bank rails. That helps reconciliation, dispute handling, and automated operations because the payment can arrive with more context about who sent it and why.
Where real-time rails fit
The constraint is scope. Each scheme operates within its own jurisdiction. A business serving recipients across multiple markets still has to integrate local rails separately, manage liquidity in each currency, and handle corridors where the recipient's bank doesn't participate in a real-time scheme.
Real-time rails are strongest when a business needs immediate domestic settlement through bank accounts. They do not by themselves solve multi-currency liquidity, cross-border routing, or a global product experience that needs the same money movement behavior across markets.
How stablecoin-based systems move money
Stablecoin-based systems change the architecture because the settlement asset can move directly across global networks while software controls conversion, routing, and custody. A dollar-denominated stablecoin can be sent at any hour, across supported blockchain networks, without waiting for correspondent banking windows or card settlement cycles.
The rest of the stack still matters. In production, a stablecoin flow usually touches fiat and compliance on both sides of the transfer.
A bank-account payment can convert into a stablecoin before moving across a blockchain network. From there, the recipient can hold the balance, spend it through a card, or offramp into local currency.
The stablecoin transfer is only the middle of the flow. The full architecture needs:
- Onramps: ways to convert fiat into stablecoins through bank rails, cards, or other payment methods
- Offramps: ways to convert stablecoins back into fiat for recipients, suppliers, employees, or treasury accounts
- Liquidity: reliable conversion paths between currencies, stablecoins, and blockchain networks
- Custody: wallet infrastructure, key management, permissions, and controls
- Compliance: KYC, AML, sanctions screening, transaction monitoring, and jurisdiction-specific rules
- Reconciliation: IDs, webhooks, reporting, and ledger entries that map the payment to the business event.
The regulatory environment has also changed. On July 18, 2025, Congress signed the GENIUS Act into law, establishing a federal framework for payment stablecoins in the US. The law does not remove every compliance decision, but it gives businesses a more concrete path for evaluating stablecoin infrastructure.
Where stablecoin-based systems fit
Stablecoins are strongest when money movement needs to be global, always-on, and programmable across currencies or platforms.
They are weaker when a use case depends on cardholder protections, local bank-only reach, or reversal models that blockchain settlement does not natively provide.
Rails comparison: The right rail depends on the job the payment has to do
A business should choose rails by job. Amount, geography, recipient experience, reversibility, liquidity, data, and compliance all change the answer. The same company can use cards for customer spend, real-time rails for domestic payouts, correspondent banking for certain treasury transfers, and stablecoins for cross-border flows that need faster settlement or programmable currency conversion.
Before choosing a rail, answer these questions for the flow:
- What currency is leaving and arriving?
- How does the recipient want to receive it?
- How fast does settlement need to be final?
- What happens if it needs to reverse?
- What does the compliance layer look like for that corridor?
Your answers to those questions usually point to one rail, but they can suggest a combination. That's where the architecture either holds together or starts to fragment.
Money movement gets brittle when each payment rail requires its own tools, integrations, and operating procedures. Teams often piece together different providers for ACH, wires, cards, onchain transfers, offramps, and compliance. The first payment flow usually works, but as you add more countries and currencies, the product becomes a layer over a growing mix of vendors that operations teams have to remember.
Programmability is the difference between a rail and an operating model. It means the system can take an instruction to send a $500 equivalent to a recipient in the format they can use, then execute the right sequence of steps without exposing every underlying rail decision to the customer or operator.
Programmable money movement needs an orchestration layer
Businesses still need bank rails, cards, and stablecoins. The product question is how much of that complexity they have to assemble and maintain themselves.
Bridge's Orchestration API is built to replace that complexity with one programmable layer for fiat and stablecoin flows.
The API covers transfers, virtual accounts, liquidation addresses, onramps, offramps, and stablecoin movement. So the routing, conversion, compliance, and reconciliation logic sits in one place rather than across separate integrations.
For teams building global payouts, supplier payments, remittances, digital banking, treasury products, or stablecoin-enabled accounts, Orchestration connects fiat and stablecoin movement through a single integration.
In practice, that means:
- Virtual accounts for fiat deposits: a deposit address per customer or corridor, no separate banking relationship required
- Fiat and stablecoin conversion: move between currencies and assets without managing the liquidity plumbing separately
- One API surface: onramps, offramps, and triggered transfers in a single integration.
The practical design step is to map the flow before choosing the rail: source currency, destination currency, recipient preference, settlement urgency, reversibility, and reconciliation requirement. Start with your most complex corridor. What would that map look like?
If you're ready to evaluate a programmable money movement layer for stablecoin and fiat flows, explore Orchestration in a demo today.
Bridge is not a bank. The Prepaid Debit Visa Card is issued by Lead Bank and managed by Bridge Ventures, LLC. Fees may apply. See www.bridge.xyz/legal for more details.
The content in this article is for general information and education purposes only and should not be construed as legal or tax advice. Bridge does not warrant or guarantee the accuracy, completeness, adequacy, or currency of the information in the article. You should seek the advice of a competent attorney or accountant licensed to practice in your jurisdiction for advice on your particular situation.
Request demo
