Stablecoin payments at an OTA

Scale, Risks & Recommendations

From a successful pilot to regional rollout and the final go/no-go for the finance team

What this part covers

Parts 1 and 2 established the case, the regulatory landscape, the internal diagnostic, the vendor work and the pilot launch. This document picks up from a live pilot producing weekly data and covers four things:

• Phase 3: Regional Rollout. How to scale beyond the pilot market in a sequenced way that keeps complexity contained, including operational changes as volumes grow and the on-chain privacy exposure that accompanies them.
• The Forward Landscape. What the largest banks are building in parallel (bank deposit tokens, not just stablecoins), and why it changes the infrastructure you are planning against.
• The Risk Register. The risks worth tracking, ordered by how likely they are to bite, not by how dramatic they sound. Each comes with practical mitigation.
• The Final Recommendation. Five recommendations on sequencing, scope and discipline - with the cost-of-delay consideration that frames the timing decision.

Phase 3: Regional Rollout

Duration: the quarter after a successful pilot, and beyond | Owner: Head of Payments and Treasurer, transitioning to business-as-usual | Outcome: stablecoin acceptance live across priority markets; supplier-payment program operating; program handed to BAU teams

6.1 Sequencing the rollout

After a successful pilot, the temptation is to launch everywhere at once. The discipline is to layer markets in waves, with each wave testing one new variable:

Size the waves for who the near-term customer actually is

Rollout volume assumptions should be built on the cohort that will actually use the rail in the near term: crypto-native travelers, and unbanked or underbanked customers who hold a wallet but lack an international credit card. Mainstream consumers are not the near-term market, as most have a working card and no stablecoin, and no discount changes that quickly.

Trip.com's rollout is consistent with this read. The option is offered through its international platform and gated by region (availability varies by the user's location) rather than launched universally, with the most aggressive incentives concentrated in Vietnam (reported at roughly 18% on flights and about 2.35% on hotels when paying in USDT). Its booking flow also asks for minimal personal information, which reads as designed for the wallet-first, card-light customer rather than the mainstream one. Plan wave volumes for that cohort per market; treat mainstream adoption as a later-wave possibility to be retested, not as a planning basis.

6.2 What changes when you scale

A few things that worked at pilot volumes will not work at production volumes. Plan for them in advance, not reactively.

• Custody policy: At pilot volume, gateway-only custody (immediate fiat conversion) is the right default. At scale, holding a working stablecoin balance for the supplier-payment program produces better economics. But this requires a real custody platform, board-approved custody policy, insurance, and audited controls. This is a Phase 3 decision, not a pilot decision.
• Reconciliation: Daily reconciliation works at low volume. At thousands of transactions per day, the reconciliation between on-chain confirmations, gateway settlements, and the ledger needs to be automated and near-real-time, with exception handling that does not depend on heroic operations effort.
• A second gateway: Single-gateway dependency is acceptable for a pilot but untenable at scale. Add a second gateway by Wave 3 for redundancy and for commercial leverage. Or required due to lack of global licensing footprint from a single platform.
• Tax and transfer pricing: Cross-border stablecoin flows through a regional collection hub create tax and transfer pricing questions that should be re-examined with tax counsel before regional scale, not after.
• Customer education: In the pilot, your customers are early adopters who need little explanation. If later waves extend the option beyond the crypto-native and wallet-first cohort (see 6.1), checkout copy, FAQ depth, and customer support enablement become the limiting factor on adoption, not the underlying rail.

6.3 On-chain privacy. A treasury exposure that grows with volume

Public blockchains are transparent by design. This is usually framed as a benefit (auditability, real-time verification) and at pilot volumes it is largely benign. At scale it becomes a treasury exposure that deserves explicit attention, because the same transparency that lets you verify a payment lets anyone else read your activity.

The mechanics matter. Once a settlement address is known or can be inferred, anyone can see, with no special access:

• Balances held at that address at any point in time.
• Counterparties: The addresses you pay and receive from, which can often be attributed to specific suppliers or partners.
• Payment cadence: How often you settle, and the rhythm of your collections and payouts.
• Transaction sizes: Individual and aggregate amounts.

Addresses do not stay neatly separated, either. Chain-analysis techniques cluster related addresses and link them to a real-world entity (the same techniques used for sanctions screening, applied in reverse). An address you treat as private can be deanonymized by correlation with known counterparties, exchange deposits, or timing patterns.

For a high-GMV OTA, the competitive intelligence this exposes is material. A competitor, an activist, or a counterparty could potentially read:

• Supplier relationships: Which hotels, airlines or local operators you pay, and the commercial scale of each relationship.
• Collection volumes: Stablecoin GMV by corridor, and how it is trending.
• Settlement timing: When and how often you move money, which can reveal liquidity cycles.
• Liquidity positions: Working balances held on-chain, if you hold any (the supplier-payment program is the relevant case).

The net for a treasurer: at pilot scale, convert-on-receipt makes this a minor issue. As on-chain volume and any held balances grow, on-chain footprint should be a named line in the custody and settlement policy, reviewed at the same cadence as the rest of the risk register.

6.4 The forward landscape. What the largest banks are building

A stablecoin acceptance program should be planned with one eye on where institutional money infrastructure is heading, because the biggest banks are not sitting this out. They are building a parallel form of on-chain money. For a treasurer, this is not background reading; it shapes which rails will exist in two to three years and where your bank relationships fit.

The key distinction: stablecoin vs bank deposit token

The instruments look similar on-chain but are legally different, and the difference matters for a treasury team:

What global banks are actually doing

JP Morgan is the clearest example, through its blockchain unit Kinexys (formerly Onyx). Its USD deposit token, JPM Coin (JPMD), went live for institutional clients on a public network (Coinbase's Base) in late 2025 and is being extended in phases through 2026 onto the privacy-enabled Canton Network. The platform reports very large cumulative institutional volumes and is used for cross-border payments, intraday liquidity, and on-chain settlement against tokenized assets.

Two points a treasurer should take from this. First, the deliberate choice of a privacy-enabled network (Canton) is the institutional answer to exactly the on-chain-privacy exposure in section 6.3. The banks will not run high-value flows on a fully transparent public chain, and neither should you at scale. Second, JP Morgan has been explicit that it is pursuing both deposit tokens and stablecoins. These two are not mutually exclusive, and the bank wants to be fluent in each. Its leadership has framed tokenization and stablecoins as a structural competitive shift the bank must move faster on, not a fad.

This is a sector move, not a single-bank one. Other global banks and consortia among them are building tokenized-deposit settlement networks with the same logic: keep dollar flows inside the regulated banking system while matching the 24/7, near-instant settlement that made stablecoins attractive to corporate treasuries in the first place.

6.5 The multi-currency reality. The FX legs move, but they don't disappear

An OTA collects in many currencies and pays suppliers in others. Settling in a USD stablecoin does not eliminate that FX complexity. It relocates and re-pricing it. At scale, the program's economics depend on modelling the full chain of conversions per corridor, not just the interchange saving. There are up to four legs, each carrying its own spread:

• Leg 1. Customer's local currency into stablecoin. The payer carries this cost at their on-ramp or exchange, but it still shapes your economics: if acquiring the token is expensive in a given market, adoption suffers, or your promotional pricing ends up absorbing the difference.
• Leg 2. The quote-to-settlement window. Inventory is priced in fiat; the token amount is fixed at quote; confirmation lands minutes later. For a USD-pegged token against a USD price, the movement is small, but for fiat prices in other currencies the token-to-invoice-currency rate can move between quote and receipt. Decide contractually who carries that movement: you, the customer, or the gateway. And over what re-quote window. This is the same decision flagged in Part 2 (section 5.1) for refunds, applied to the collection leg.
• Leg 3. Stablecoin into settlement fiat. The gateway's conversion spread. This is the leg most under your control and the one to lock in writing during the Phase 1 RFP: reference rate, spread, and a worked example per corridor.
• Leg 4. Settlement fiat into supplier or functional currency. If you settle in USD but pay suppliers in THB, VND or IDR, the payout conversion still happens on your existing treasury rails, with its existing cost. USD-stablecoin collection centralizes your USD position; it does not pay a Vietnamese hotel in VND.

The practical instruction: in the corridor-level cost model from Phase 0, lay these four legs alongside the card baseline (which has its own FX stack) and compare like for like. The stablecoin route usually still wins on cross-border corridors, but by less than the interchange-only comparison suggests, and by different amounts in different corridors.

6.6 Optional adjacencies. Evaluate later, not now

These should only be considered once the core program is stable. They are options, not commitments:

• A branded or co-branded stablecoin payment proposition. Loyalty-linked payment in a partner stablecoin or a co-branded wallet. Significant brand and regulatory lift; requires a specific commercial thesis to justify.
• A direct relationship with an issuer (Circle, Paxos). Removes a layer of conversion cost for sufficiently large flows. Realistic only at sustained high-volume throughput.
• A bank deposit token for the treasury and supplier layer (per 6.4). As bank-issued tokens like JPM Coin become available to corporates, they may offer the settlement speed of stablecoins with the credit profile of bank money and a permissioned, privacy-enabled network. Track your banks' roadmaps; keep the supplier-payment architecture token-agnostic so this stays an option.
• Card-network stablecoin settlement (Visa, Mastercard). Card acceptance with stablecoin settlement on the back end. Watch the issuer ecosystem.
• A treasury working balance in stablecoin. Holding part of regional working capital float in USDC for 24/7 supplier payouts and intra-group settlement. A real treasury policy decision with balance-sheet and on-chain-privacy implications, not an extension of the payments program. The evaluation should follow standard treasury investment discipline: principal protection first, liquidity second, yield a distant third. Within that hierarchy, a held balance can generate modest return. For example, through a yield-share program on certain tokens (GUSD is one), and some treasuries go further by deploying stablecoins into lending or on-chain strategies. That last step carries materially higher risk to both principal and liquidity, and for most corporates sits outside investment policy altogether. Note the regulatory texture on yield: under the US GENIUS Act, stablecoin issuers themselves are restricted from paying interest to holders, so yield programs are typically structured through exchanges or other third parties rather than the issuer, which introduces a counterparty layer that must be assessed on its own terms, separate from the token's reserve backing. The right sequencing: justify the balance on operational grounds (24/7 payouts, settlement speed), size it to working-capital need, and treat any yield as incidental, never the reason for holding.

7. Risk Register and Mitigations

A practitioner's risk register, ordered roughly from most likely to bite to most catastrophic if they do. Each risk should be re-scored at each phase gate.

8. The Prioritized Recommendation

Given the current market structure, the regulatory frameworks now in force across major markets, the direct competitor signal from Trip.com, the parallel build-out of on-chain settlement by the largest banks, and the realistic timeline to value, the prioritized path for an OTA finance and treasury team is:

Recommendation 1: Start the internal diagnostic (Phase 0) immediately

This phase is internal, low-cost and high-leverage. The work (corridor cost mapping, supplier payment baseline, chargeback economics) has standalone value even if the program is later paused. Sponsor: CFO. Owner: Head of Payments. Output: a working group constituted, a market shortlist framed, an EBITDA case modelled, and a written gate-pass to Phase 1 within six weeks.

Recommendation 2: Run the supplier-side and customer-side tracks in parallel

Do not sequence customer-side first and supplier-side second. Run them in parallel. The supplier-payment pilot produces a clearer ROI read sooner, builds internal treasury capability, and de-risks the customer-side launch by giving the team experience operating real stablecoin flows on internal volumes before they touch a customer transaction.

Recommendation 3: Single gateway, single market, single use case for the customer-side pilot

Resist breadth. The first pilot market should be selected for regulatory clarity (a MAS, MiCA or FCA jurisdiction), strong cross-border GMV concentration, and a country team willing to co-own the KPI. Triple-A and BVNK are credible Phase 1 RFP candidates given their licensed status and existing OTA-sector deployments; Stripe (post-Bridge) and Coinbase Commerce are worth inviting to the RFP for commercial leverage. Confirm acceptance-model fit (Part 2, section 4.2) before going deep on any one vendor.

Recommendation 4: Decide custody policy at the end of the pilot, and keep the treasury architecture token-agnostic

For the customer-side pilot, gateway-converted-to-fiat settlement is the right default: no stablecoin balance, no balance-sheet exposure, no custody complexity, and no persistent on-chain position to observe. For the supplier-payment pilot, a small working USDC balance on a regulated custody platform is acceptable with proper controls.

Within that custody decision sits a question that is easy to miss: who holds the keys to the wallets receiving customer payments. If the merchant holds the keys directly, and the group is multi-entity, receiving funds for the benefit of another entity in the group - the one actually providing the service - can constitute unlicensed money transmission. This is a licensing trap, not a technicality. It turns an internal treasury arrangement into a regulated activity. Where possible, receive through a platform licensed for the purpose, which is the working assumption throughout this guide. The trade-off is real and should be priced in. The licensed party carries heavier regulatory obligations and AML risk, which translates into more friction (onboarding, screening, occasional holds) than a self-custodied wallet would impose. That friction is the cost of not becoming a money transmitter by accident.

Design the supplier and treasury layer so it is not locked to a single token type. As bank deposit tokens (per section 6.4) reach corporates, you want to be able to adopt one from a banking partner without re-plumbing. The strategic custody decision, whether to hold on-chain money as part of regional working capital, and in what form, should be deferred to Phase 3, informed by real operational data and by your banks' roadmaps.

Recommendation 5: Set the EBITDA threshold up front and respect it

Define what success looks like at Phase 0 for example: 'the program must deliver $X annualized EBITDA contribution by month 24 of live operation, with no material increase in operational headcount.' Re-score at every phase gate. If the gate threshold is not met, the discipline is to renegotiate gateway commercials, narrow scope, or stop. Do not launch a thin program that consumes management attention without producing financial impact.

For clarity, this is the cost stack and gate sequence the threshold is scored against. This is restated from Parts 1 and 2 so this document stands alone. Every figure is a planning assumption to be replaced with your own Phase 0 corridor data:

On the cost of delay

Waiting is not free, though the cost is measurable rather than dramatic. Each quarter the program is deferred, a direct competitor that is already live (Trip.com) accumulates corridor-level adoption data you do not have, and the gateway commercial market matures as more merchants enter. The parallel bank build-out points the same way: the largest institutions are committing real infrastructure to on-chain settlement, which makes the direction durable and the capability worth building now. None of this is catastrophic in a single quarter. Together it means a later start begins from a colder baseline - worth weighing against the cost and distraction of starting now, which is the judgement the Phase 0 diagnostic exists to inform.