Stablecoin Adoption Is an Operations Product
Executive summary
Stablecoins are often presented as a faster rail. That understates the work required inside a regulated institution. Production needs wallets, bank connections, minting and redemption, user roles, dual approval, allowlists, audit logs, reconciliation and liquidity. Visa’s Stablecoin Platform packages those functions in one managed environment.
The evidence suggests movement from proof of concept toward an operations product, although scale remains early. Visa reported an annualized settlement run rate of about $7 billion as of March 2026, support for nine blockchains, and more than 160 linked-card programs live or in development. Those figures show experimentation, not replacement of cards or deposits.
The market in context
Institutional payments already pass through ledgers, correspondent accounts, treasury systems and controls. A new rail can reduce settlement windows or enable always-on transfer, but it adds keys, addresses, token liquidity and reconciliation events.
Visa’s beta begins with Open USD and allows institutions to use a managed wallet stack or connect an existing wallet. The product includes bank links, mint, burn, hold and transfer functions, dual approval, passkeys, allowlists and audit logging. These resemble treasury controls because institutional adoption depends on fitting existing responsibility structures.
The operational distinction between a stablecoin payment and a conventional account transfer is easy to blur at the user interface. Both can appear as a balance moving from one party to another. Underneath, the control problems are different. A token transfer may settle outside bank operating hours, but the institution still has to fund the wallet, value the asset, screen the counterparty, recognize fees, post the movement to its internal ledger and decide when the payment is final for accounting purposes. Speed at the network layer does not settle those questions.
That is why the most credible enterprise products are being built around a control plane rather than a bare wallet. The buyer is purchasing a way to make token activity conform to treasury policy. The value proposition becomes fewer bespoke connections between custody, banking and finance systems; the risk is that the same integration concentrates operational dependency in one provider.
Workflow integration is the wedge
Workflow integration is the wedge. Institutions do not want a standalone wallet that creates another operational island. They want token activity connected to bank accounts, permissions and reconciliation.
A managed environment can reduce implementation work, but it can also deepen dependency. If identity, wallet policy, liquidity and network connection sit behind one control plane, switching becomes hard. Buyers should map which keys, records and workflows remain portable. Supporting several chains does not make them interchangeable; fees, finality, liquidity and recovery differ.
The integration test should begin with a full lifecycle, not a successful outbound transfer. An institution should fund the wallet from a bank account, mint or acquire the token, transfer it, receive or redeem it, reconcile both legs and close the accounting period. It should then repeat the exercise with a rejected beneficiary, a delayed chain, a fee change and a partial reversal. Those cases reveal whether the product reduces work or merely gives operations another dashboard.
Portability deserves equal attention. A buyer should know whether transaction history, beneficiary lists, approval policy and wallet addresses can be exported in usable form. If a provider changes its supported chains or eligibility rules, the institution needs a migration path that does not strand records or force a hurried change in custody.
Governance is part of the product
Governance is part of the product. Dual approval limits the chance that one compromised user can initiate and approve movement. Allowlists reduce address risk. A useful audit record must connect business instruction, approving identities, wallet address, token amount, fiat reference, fees, transaction hash and ledger treatment.
An onchain record proves transfer, not business purpose. Recovery remains a differentiator because an erroneous transfer may be irreversible. Beneficiary verification, cooling-off rules, test transfers and circuit breakers belong in the normal workflow.
Role design is where a promising pilot becomes a controllable service. The person who proposes a beneficiary should not be able to approve it and release funds. Limits should vary by user, legal entity, currency, destination and time window. Emergency controls need a named owner and an after-hours process; an “always on” rail is not operationally useful if the only employee allowed to stop it works local business hours.
Address controls also need context. An allowlisted address can still belong to the wrong legal entity, and an approved counterparty can rotate addresses. Operations should bind the technical destination to a verified beneficiary record and record who approved each change. Small test transfers are useful for new paths, but they do not replace beneficiary verification or protect against later tampering.
Coexistence is more likely than replacement
Coexistence is more likely than replacement. Visa connects stablecoins to card, settlement, treasury and currency services. Linked cards convert a token balance into acceptance on the established network rather than requiring direct merchant acceptance.
The comparison is therefore flow-specific, not “stablecoin versus card.” A token can improve prefunding or weekend settlement behind the scenes while the buyer still presents a familiar credential. Start with corridors where timing, programmability or trapped liquidity has a measured cost.
Coexistence changes the business case. Stablecoins do not need to replace the customer-facing payment method to create value. A card program can use token balances for funding while the consumer pays at a conventional terminal. A treasury team can use stablecoins for weekend liquidity while retaining bank rails for domestic business-day payments. These hybrid flows may be less visible than direct merchant acceptance, but they also avoid asking every participant to change behavior at once.
The correct benchmark is the incumbent route for a specific corridor and use case. Compare time to usable funds, prefunding, foreign-exchange spread, direct fees, failure handling and reconciliation effort. An average global comparison will hide the places where the rail matters and the many places where it does not.
Implications for operators
Operators should map the current flow: parties, currencies, cutoffs, prefunding, fees, failure modes and reconciliation. Score control depth alongside chain count. Test key security, role separation, beneficiary approval, limits, emergency stop and export before production.
Finance needs a design that reconciles token units, fiat value, fees and timing. Treasury needs weekend liquidity rules. Compliance needs screening and escalation. Product teams must disclose when a customer is exposed to a token.
The core KPI is total cost per completed, reconciled payment. Faster settlement is not valuable if manual exceptions or fragmented liquidity erase the benefit.
A production scorecard should separate network performance from operational performance. Network settlement time, transaction fee and technical failure rate belong in one layer. Approval time, manual touches, reconciliation breaks, liquidity held and time to resolve an exception belong in another. Finance should also record the exchange rate and valuation timestamp used when token and reporting currencies differ. Without those layers, a fast transaction can look successful even when it creates hours of downstream repair.
Pilot design should be deliberately narrow. Choose one legal entity, one or two tokens, a limited set of approved counterparties and a corridor where the existing cost is known. Run the token flow alongside the incumbent process long enough to observe weekends, month-end close and at least one exception. Expansion should follow measured reductions in total cost and working capital, not a count of wallets created or chains connected.
What would change the view
The run rate does not show concentration, incentives or incremental volume. Programs “in development” are not active customers. Regulation, reserve treatment and token eligibility vary by jurisdiction. Chain outages, credential compromise and liquidity gaps remain live risks.
The thesis would weaken if usage stays confined to subsidized pilots, reconciliation costs exceed timing gains, or tokenized bank deposits deliver similar programmability with simpler treatment.
Concentration is another open question. A managed platform can reduce fragmentation while concentrating custody, screening, liquidity and workflow risk. An outage or policy change can then affect several control layers at once. Institutions should test manual continuity procedures and understand whether they can view balances, preserve evidence and move funds when the management interface is unavailable.
The economics can also change after launch incentives expire. Issuers, networks and infrastructure providers may subsidize early activity to establish distribution. The durable comparison must use contracted fees, normal liquidity costs and steady-state support. If the case works only while implementation assistance and rebates are unusually generous, the product has not yet proved an operating advantage.
Methodology
The cited $7 billion is an annualized company-reported run rate, not audited annual volume or a market estimate. Nine chains refers to a Visa pilot. The 160-plus figure includes programs in development. Source
A chart should compare matched payment corridors on settlement availability, prefunding, direct fees, FX spread, reconciliation minutes, exceptions and time to usable funds. Hold transaction-size and currency mix constant; no adequate public cross-client dataset currently exists.
For an internal evaluation, the unit of analysis should be a completed and reconciled payment, not an initiated blockchain transaction. Record the origin and destination, token, chain, fiat equivalent, payment purpose, approval path, time to usable funds, direct fees, foreign-exchange spread, manual minutes and every exception. Compare matched transactions on the incumbent rail and disclose whether promotional pricing or prefunded balances influenced the result.