The pitch that moved stablecoins from experiment to infrastructure is a cost pitch. Traditional cross-border payments cost 2 to 7 percent once fees and FX spreads are counted; the World Bank's Remittance Prices Worldwide puts the global average at 6.36 percent as of late 2025. Stablecoin rails quote all-in costs under 1 percent, and the on-chain transfer itself costs cents. Since the GENIUS Act established a US federal framework for payment stablecoins in July 2025, volume has followed the pitch: payouts platforms, remittance providers and B2B payment companies are moving real corridors onto USDC and its peers.
The pitch is true. It is also incomplete, in a way that finance teams discover on their first serious invoice review. A Federal Reserve analysis of payment stablecoins made the point plainly this spring: the on-chain cost of moving stablecoins between holders is likely to be small, while the greater costs sit at the on-ramp and off-ramp, where stablecoins are exchanged for fiat currency. The fees did not disappear. They moved to the edges of the rail, into contracts with a new class of provider, and they leak there for exactly the same structural reasons PSP fees always have.
TL;DR
- The on-chain leg of a stablecoin payment costs cents. The real costs sit at the on-ramp and off-ramp, in conversion fees and FX spreads on the fiat legs.
- Ramp provider contracts have the same structure as PSP contracts: basis-point pricing, volume tiers, corridor terms, minimums and timing rules. The invoices drift the same way.
- All six fee leakage categories apply to stablecoin rails, with FX markup the most opaque because the conversion spans an on-chain rate and an off-chain one.
- Sub-1 percent economics only hold if someone verifies them. Fee leakage of 0.2 to 0.5 percent of volume erases most of the advantage the rail was chosen for.
- Verification means reconstructing the expected charge for every conversion and transfer from the signed contract, not sampling invoices.
Short answer
Stablecoin fee reconciliation is the process of verifying what on-ramp, off-ramp and stablecoin infrastructure providers actually charged against the pricing terms in their contracts, per transaction. Because on-chain transfer costs are near zero, almost all verifiable cost sits in conversion fees, FX spreads and settlement deductions at the fiat legs.
Where the fees actually live on a stablecoin rail
Follow one payout end to end. A platform funds in dollars and converts to USDC through an on-ramp provider: that conversion carries a fee, typically priced in basis points, sometimes with a spread on the rate. The USDC moves on-chain for a network fee measured in cents, the one leg of the journey that is genuinely near free. At the destination, an off-ramp provider converts to local currency and pays out: another conversion fee, an FX spread against some reference rate on the local leg, and often payout charges that vary by method and corridor.
Industry research points the same direction from the market side. A January 2026 infrastructure review by BCG and Allium found the on-chain layer production-ready while identifying off-ramp infrastructure as the primary bottleneck, and practitioner surveys consistently note that on-ramp and off-ramp fees plus FX conversion at the fiat legs are what separate quoted on-chain costs from realized all-in costs. For a platform running multiple corridors, the ramps are where nearly all of the money is, and therefore where nearly all of the verification problem is.
Ramp contracts are PSP contracts wearing new clothes
Look at a contract with a modern on/off-ramp or stablecoin infrastructure provider and the structure is familiar: per-conversion fees in basis points, volume tiers that step pricing down as monthly flow grows, corridor-specific rates, FX spread commitments quoted against mid-market or interbank, monthly minimums, and timing rules for when fees may be assessed. It is a PSP pricing schedule with new nouns.
The market's youth makes the drift worse, not better. Providers are repricing quickly as competition compresses margins, which means contract versions churn: v2 supersedes v1 mid-quarter, the provider's billing system flips on a different day than your records do, and invoices straddle the seam. New corridors launch with provisional pricing that is supposed to be trued up later and often is not. Every one of these is a place where the charge on the invoice quietly detaches from the charge in the contract.
The six fee leakage categories, translated to stablecoin rails
The failure modes that drive fee leakage on card and bank rails map one to one onto stablecoin rails.
1. Rate deviation
The contract says 25 basis points per conversion on this corridor; the provider charges 32. Small per conversion, invisible in aggregate, six figures across a quarter of payout volume.
2. Tier misapplication
Your volume crossed into a cheaper band mid-month and the billing system kept charging the old tier, or applied the wrong corridor's schedule entirely. The fee is the right type. The tier is wrong.
3. FX markup
The contracted spread is X basis points over mid-market on the local currency leg. The statement shows a blended rate. Whether the spread held requires reconstructing the reference rate at the moment of conversion, which almost nobody does.
4. Missing fees and rebate omissions
Volume rebates and corridor incentives, common in a market fighting for flow, quietly absent from the invoice. You only catch the omission if you know the credit was owed.
5. Settlement deduction error
Charges netted out of the payout leg that the contract says belong on the invoice. The money is gone before any bill arrives, which is why these never surface in an invoice review.
6. Timing violation
Minimums applied before a ramp period ends, fees assessed on excluded periods, charges raised outside the contracted window. Not arithmetic errors. Clause violations, visible only when the date is checked against the contract.
None of these requires bad faith. They require only what every young billing system has: complexity, version churn and no automated link between the pricing schedule you signed and the line items you receive.
Why stablecoin reconciliation is both harder and easier than card reconciliation
Harder, because one payment now crosses three legs and at least two providers, each with its own reporting format and maturity level. Reporting from newer ramp providers is thinner than the settlement files card processors have refined over decades, and a single corridor may involve an on-ramp, a chain and an off-ramp that have never heard of each other.
Easier, in one respect that finance teams should exploit: the middle leg is public. The on-chain transfer is a timestamped, independently verifiable record, which is more than can be said for any correspondent banking chain. That timestamp is exactly what FX verification needs: the moment of conversion is knowable, so the mid-market reference rate at that moment is reconstructable, and the contracted spread can be checked rather than trusted. The rail that created the new reconciliation problem also ships the evidence needed to solve part of it.
What verifying stablecoin fees actually requires
The requirements mirror what works on any provider rail, applied per transaction across every leg. First, the contract has to become executable: every conversion fee, tier, spread commitment, minimum and timing rule turned into pricing logic a system can apply. Second, every conversion and transfer needs an expected charge computed from that logic, using the transaction's actual properties: corridor, amount, timestamp, method. Third, the comparison against what was billed, deducted or netted has to produce evidence-grade records: the source transaction, the clause, the expected figure, the actual figure and the variance, in one place.
Sampling invoices does not get there, and spreadsheets collapse under multi-leg, multi-provider volume for the same reasons they always have. The teams treating this as a per-transaction system from day one are the ones whose sub-1 percent rail actually costs sub-1 percent.
The bottom line
Stablecoin rails are winning corridors because their economics are better, and the advantage is real. But an advantage measured in tens of basis points is an advantage that fee leakage of 20 to 50 basis points can consume entirely, invisibly, at the ramps. The cost case for the new rail depends on verification the old tooling was never built to do.
The platforms scaling on these rails have a rare opening. The providers are new, the contracts are fresh and the chain itself hands over a public evidence trail. Teams that build provider economics into their stablecoin stack now will compound the rail's advantage instead of donating it back, one unverified conversion at a time, and they will do it with better evidence than any payment rail has ever offered.
Frequently asked questions
What is stablecoin reconciliation?
Stablecoin reconciliation is the process of verifying every charge from on-ramp, off-ramp and stablecoin infrastructure providers against the pricing terms in their contracts, at the transaction level. It covers conversion fees, FX spreads, network costs and settlement deductions across all legs of a stablecoin payment.
How much do on-ramp and off-ramp providers charge?
Pricing is typically quoted in basis points per conversion, with volume tiers, corridor-specific rates and FX spread commitments on local currency legs. All-in costs on stablecoin rails commonly land between 0.1 and 0.5 percent, against 2 to 7 percent on traditional cross-border rails, though realized costs vary by corridor and payout method.
Are stablecoin payments really cheaper than traditional rails?
Generally yes, materially so on emerging-market corridors. The on-chain transfer costs cents, and total costs typically run well under 1 percent versus a 6.36 percent global average for remittances. The caveat is that most of the remaining cost sits with ramp providers, and unverified drift in those charges erodes the advantage.
How do I verify USDC transaction fees?
Reconstruct the expected charge for each conversion and transfer from your provider contracts, then compare it to what was actually billed or deducted. The on-chain timestamp helps: it fixes the moment of conversion, which makes the mid-market reference rate reconstructable and FX spread commitments checkable.
Why do stablecoin provider invoices contain errors?
For the same structural reason PSP invoices do: pricing logic lives in the contract while charges are generated by the provider's billing system, with no automated link between them. Fast repricing and contract version churn in a young market widen the gap.
Can spreadsheets handle stablecoin fee reconciliation?
Not at scale. A single payment spans an on-ramp, a chain transfer and an off-ramp, each with separate records, and contract rules are conditional logic that nested formulas encode fragilely. Per-transaction verification across legs and corridors requires a system, not a workbook.
