Real-Time Settlement Paths

Prerequisite: Payment Rails, Executing Money Flows

A customer taps their card at a coffee shop. The authorization succeeds in 200ms. The merchant sees “approved.” But the actual money — the movement of funds from the cardholder’s bank to the merchant’s bank — does not happen for another 24 to 48 hours. During that window, the merchant has delivered the coffee, the cardholder has walked away, and neither bank has moved a dollar. The merchant is extending credit to the network. The network is extending credit to the issuer. The entire system runs on promises that settle later.

Real-time settlement eliminates that window. The money moves when the transaction happens — not hours or days after. The engineering problem is making that happen without breaking the authorization latency budget that the card networks enforce.

Why Settlement Is Slow

Traditional settlement delays are not technical limitations. They exist because batch processing is cheaper, netting reduces the number of interbank transfers, and the correspondent banking system was designed before real-time was possible.

Rail	Settlement timeline	Why
Card networks (Visa/Mastercard)	T+1 to T+2	Clearing files batch overnight; netting reduces interbank volume by 90%+
ACH	T+1 (same-day ACH: same day)	Batch windows at the Federal Reserve: 4 per day for same-day, 2 for standard
Wire (Fedwire)	Same day, minutes	RTGS — settles individually, but costs $0.25–$25 per transfer
SWIFT (cross-border)	T+1 to T+5	Correspondent chain: each hop is a separate settlement
FedNow	Seconds	Real-time gross settlement, 24/7/365, but limited to US domestic

Netting is the primary reason card settlement is batched. If a merchant processes 1,000 Visa transactions in a day, the clearing system nets those against all other flows between the same banks. Instead of 1,000 individual transfers, the banks exchange a single net amount. This reduces Fedwire volume and cost by orders of magnitude — Visa processed 212 billion transactions in fiscal 2023, but the number of interbank settlement transfers was a fraction of that.

The cost of real-time settlement is forgoing this netting benefit. Every transaction settles individually, which means every transaction incurs its own transfer cost and liquidity requirement.

The Stablecoin Settlement Thesis

Stablecoins offer a settlement rail that is always on, settles in seconds, and does not require correspondent banking relationships. A USDC transfer on Solana confirms in approximately 400ms. On Ethereum, 12–15 minutes for probabilistic finality, or 15 minutes for the finalized checkpoint. On Base (Ethereum L2), under 2 seconds for soft confirmation.

The thesis: replace the overnight batch-and-net cycle with an immediate stablecoin transfer at the moment of transaction. The merchant receives stablecoins (or fiat funded by an immediate stablecoin burn) instead of waiting for next-day settlement.

Visa’s stablecoin settlement pilot validates the scale. Visa settled over $225 million in USDC transactions across Solana and Ethereum in its initial pilot phase, primarily for cross-border settlement between acquirers and issuers. The settlement happens in minutes instead of days. The correspondent banking chain — originator bank → intermediary → beneficiary bank — collapses to a single on-chain transfer.

See Payment Rails. The traditional card settlement flow — authorization, clearing, settlement — remains the same at the network level. Stablecoin settlement replaces only the final leg: the interbank funds transfer.

The Card-to-Stablecoin Path

A stablecoin-backed card transaction follows a specific sequence. The cardholder’s funds are held in stablecoins. The card authorization must happen in fiat (card networks do not process stablecoin amounts). The settlement converts between the two.

Cardholder taps card
    → Visa network routes authorization request
    → Issuer processor receives auth request
    → Stablecoin balance check (is USDC balance ≥ purchase amount?)
    → Hold placed on stablecoin balance
    → Authorization response: approved (200ms total)

... later (seconds to minutes, not days) ...

Clearing file received
    → Stablecoin burn executed (redeem USDC for USD)
    → USD credited to settlement account
    → Settlement funds transferred to acquirer

The authorization path runs entirely in the traditional card network. Visa sees a normal card transaction. The issuer processor translates between the stablecoin balance and the fiat authorization. The cardholder’s stablecoin balance is the funding source, but the network never touches it directly.

The settlement path is where stablecoins change the timeline. Instead of waiting for the netting cycle, the issuer burns stablecoins immediately upon receiving the clearing file, converts to fiat, and settles with the acquirer.

Stripe’s Bridge Path

Stripe acquired Bridge to build this exact flow. Bridge provides the stablecoin orchestration layer — mint, burn, custody, and multi-chain management — while Stripe provides the card network integration through Stripe Issuing.

The architecture has three layers:

Layer	Responsibility	Latency
Card network (Visa/Mastercard)	Authorization, clearing	200ms auth, hours for clearing
Stripe Issuing	Issuer processing, cardholder management	Milliseconds (API)
Bridge	Stablecoin custody, mint/burn, multi-chain settlement	Seconds (burn + fiat conversion)

A cardholder with USDC on Ethereum wants to buy coffee. Stripe Issuing receives the authorization request from Visa, checks the cardholder’s stablecoin balance via Bridge, places a hold, and approves the transaction. When the clearing file arrives, Bridge burns the held USDC and credits the settlement account in USD.

The settlement timeline collapses from T+1–T+2 to minutes. The merchant still receives funds through the normal acquirer settlement process — the acceleration happens on the issuer side.

The cardholder experience is identical to a traditional card. They tap, the terminal says approved, they leave. The stablecoin mechanics are invisible. If the burn fails after authorization, the issuer bears the settlement risk — the merchant has already been promised payment.

Failure Modes

Each step in the real-time path has a distinct failure mode, and the failure handling differs from traditional settlement because the timeline is compressed.

Authorization failures

The authorization must complete within the card network’s timeout — typically 3–5 seconds for Visa, with most issuers targeting under 500ms. If the stablecoin balance check takes too long (chain congestion, RPC node failure, custody system timeout), the authorization times out and the transaction is declined. The cardholder sees a declined card at the register.

Mitigation: cache the balance locally. Read the on-chain balance periodically (every few seconds) and authorize against the cached value. The cache may be stale by one or two balance updates, but a stale-high cache (authorizing against a balance that is slightly too high) creates a small overdraft risk that is cheaper than declining legitimate transactions.

Burn failures

The authorization succeeded but the stablecoin burn fails — chain congestion, gas price spike, smart contract pause, or insufficient gas in the hot wallet. The cardholder has already left with their coffee.

Failure type	Cause	Recovery
Gas price spike	Network congestion pushes gas above threshold	Retry with higher gas; queue if spike persists
Contract pause	Emergency pause on the stablecoin contract	Queue burns; settle in fiat from reserve float
Chain reorg	Burn confirmed then reverted	Re-submit burn; if reorg depth exceeds threshold, flag for manual review
RPC failure	Node provider outage	Failover to backup RPC; multi-provider configuration

The issuer must maintain a fiat reserve float — enough USD to cover settlement obligations if burns are delayed. The float size depends on the maximum expected burn delay and the daily transaction volume. A $10M daily volume with a 4-hour maximum burn delay requires approximately $1.7M in float ($10M × 4/24).

Fiat credit failures

The burn succeeds but the fiat credit to the settlement account fails — bank processing delay, compliance hold, or banking partner outage. The stablecoins have been burned (supply reduced) but the USD has not arrived. The issuer’s books show a liability (owed to the acquirer) without a corresponding asset (USD in the settlement account).

This is a timing mismatch, not a loss. The USD will arrive when the bank processes the credit. The risk is that the acquirer expects settlement on a specific timeline and the delay triggers a breach of the settlement agreement.

Pre-Funding vs Post-Funding

The capital efficiency question: does the cardholder pre-fund their stablecoin balance (buy USDC before spending), or does the issuer post-fund (convert fiat to stablecoins after the transaction)?

Model	Capital efficiency	Settlement risk	Complexity
Pre-funded	Low — cardholder locks capital in stablecoins	Low — funds exist before transaction	Low — balance check is sufficient
Post-funded	High — cardholder holds fiat until needed	Higher — conversion must succeed after authorization	High — FX risk if conversion is delayed
Hybrid	Medium — partial pre-fund with post-fund overflow	Medium — pre-funded portion is safe, overflow has risk	Medium — two funding paths

Pre-funding is simpler but requires the cardholder to hold stablecoins. Post-funding is more capital-efficient but introduces conversion risk — the fiat-to-stablecoin conversion might fail or the exchange rate might move between authorization and settlement.

Most stablecoin card programs use pre-funding. The cardholder deposits fiat, receives stablecoins, and spends from that balance. The issuer holds the stablecoins in custody and burns them at settlement. The cardholder’s capital is locked, but the settlement path is deterministic.

Latency Budgets

A real-time settlement flow has a strict latency budget. Each component must complete within its allocation, or the end-to-end guarantee breaks.

Authorization path (target: < 500ms total)
├── Network routing:           50–100ms
├── Issuer processing:         20–50ms
├── Balance check (cached):    5–10ms
├── Hold placement:            10–20ms
└── Response to network:       50–100ms

Settlement path (target: < 5 minutes total)
├── Clearing file receipt:     0 (triggered by clearing)
├── Stablecoin burn:           400ms (Solana) to 15min (Ethereum L1)
├── Burn confirmation wait:    1–3 confirmations chain-dependent
├── Fiat conversion:           seconds (pre-arranged) to minutes (spot)
└── Settlement credit:         seconds (FedNow) to hours (wire)

The settlement path latency is dominated by two factors: the chain’s finality time and the fiat conversion method. Solana’s 400ms slot time with 32-slot confirmation means the burn is confirmed in approximately 13 seconds. Ethereum L1 requires 2 epochs (approximately 13 minutes) for finality. Using an L2 like Base reduces this to seconds for soft confirmation with the L1 finality backstop.

The fiat leg depends on the banking relationship. If the issuer and acquirer share a banking partner, the USD transfer is a book transfer — instant. If they use different banks, the transfer goes through Fedwire (minutes, business hours) or FedNow (seconds, 24/7). Cross-border settlement adds correspondent banking hops, each with its own processing time.

Settlement Risk

Between authorization and final settlement, someone bears the risk that the money will not arrive. In traditional card settlement, the risk allocation is well-defined and backed by decades of network rules.

Stage	Risk bearer	Exposure	Duration
Auth to clearing	Issuer	Full transaction amount	Hours
Clearing to burn	Issuer	Full amount minus hold	Minutes (real-time) vs days (traditional)
Burn to fiat credit	Issuer	Burn amount	Seconds to hours
Fiat credit to acquirer settlement	Acquirer’s bank	Settlement amount	Minutes to days

Real-time settlement compresses the duration column. A traditional card transaction carries issuer risk for 24–48 hours between authorization and settlement. A stablecoin-settled transaction carries that same risk for minutes. The risk per transaction is identical — the aggregate risk at any point in time is dramatically lower because the exposure window is shorter.

The aggregate risk reduction is significant. An issuer processing $10M daily with T+2 settlement carries $20M in outstanding settlement risk at any moment. The same issuer with 5-minute settlement carries approximately $35,000 in outstanding risk ($10M × 5 minutes / 1,440 minutes per day). The capital reserved against settlement risk drops proportionally.

Settlement finality on a blockchain is not the same as settlement finality in the banking system. A confirmed on-chain burn is final on that chain — no chargeback, no reversal. But the card network’s chargeback rules still apply to the authorization. The merchant can receive a chargeback up to 120 days after the transaction. The stablecoin settlement is final; the payment is not.

When Real-Time Settlement Breaks Down

Real-time settlement works when the volume is predictable, the chains are operational, and the fiat rails are available. It breaks down at the edges.

Batch spikes. A merchant processes 10,000 transactions during a Black Friday sale. Traditional settlement nets these into a single interbank transfer. Real-time settlement processes 10,000 individual burns. At $0.001 per Solana transaction, the chain cost is $10 — negligible. But 10,000 burns in an hour require gas management, nonce coordination, and monitoring capacity that a batch file does not.

Chain outages. Solana has experienced multiple outages lasting hours. During an outage, no burns execute. The issuer must fall back to fiat settlement — maintaining the traditional settlement path as a backup, not an optimization target. The system must operate correctly in both modes and switch between them without manual intervention.

Cross-border complexity. A cardholder in Tokyo spends JPY. The stablecoin balance is in USDC. The merchant settles in EUR. The path is JPY authorization → USDC burn → USD → EUR settlement. Two FX conversions, each with spread and timing risk, replace the single net settlement that Visa’s cross-border clearing would have provided. The real-time benefit must outweigh the FX cost, and for small transactions, it often does not.