The 2026 "remittance tax" affecting US-to-Mexico stablecoin payouts is a US federal rule, not a Mexican one: the 1% remittance excise under IRC §4475, enacted as part of OBBBA and effective 1 January 2026. It applies only to US-origin remittances funded by cash, money orders, or cashier's checks. Bank/ACH/wire transfers, debit and credit cards, and crypto-funded transfers are exempt. For B2B operators paying Mexican contractors or suppliers from a US business bank account, the excise is out of scope, and the practical work is clean SPEI handoff and CFDI/SAT documentation at the Mexican off-ramp.
What the US 1% remittance excise actually covers
OBBBA created a new federal excise under IRC §4475 imposing a 1% tax on certain outbound remittance transfers from the United States. The rule went into effect 1 January 2026. Scope is defined by the funding instrument at the sending end, not by the destination country or the rail used downstream.
The excise applies when the sender funds the remittance with cash, a money order, or a cashier's check. Bank/ACH/wire transfers from a US deposit account are explicitly exempt. Debit and credit card-funded transfers are exempt. Crypto-funded transfers are exempt. Because the law keys on origination instrument, the same destination corridor can be in scope or out of scope depending only on how the sender paid in.
For a US fintech or SaaS operator paying Mexican contractors from a US business bank account that funds a USDC purchase, then sends USDC to a Mexican off-ramp settling via SPEI, the excise does not attach. The funding step is a bank debit, not cash or a money order, and the onward transfer is crypto-funded.
Personal remittance vs B2B payout: the line that matters
The US political framing of the excise is consumer-facing: families wiring cash from US storefronts to relatives abroad. The legal framing maps directly to that, because origination instrument is the test. A retail customer walking into a money-transfer storefront with cash is in scope. A corporate AP function pushing ACH out of a treasury account is not.
Three common B2B fact patterns and how they typically map to the US-side classification:
US company funds a USDC purchase by ACH or wire from its operating account, then sends USDC to a Mexican off-ramp. Out of scope. The origination is a bank debit, and the onward leg is crypto-funded.
US company prepays a card-based payouts provider and the provider pushes funds to Mexico. Card-funded transfers are exempt, so this is out of scope on the excise even before the stablecoin question arises.
A founder uses personal cash to fund a money-transfer app paying a Mexican contractor. In scope. This is the narrow pattern the rule targets, and it should not be how a business pays contractors regardless of the tax.
The exposure for a US operator is concentrated in the third pattern, which is mostly a hygiene issue rather than an architectural one. Pay from the business bank account, not from cash or money orders, and the excise is not the thing to optimize against.
What the operator can actually control (US-side levers)
Three levers, in order of leverage:
1. Origination instrument. Always fund payouts from a US business deposit account. ACH or wire into a regulated stablecoin issuance or brokerage relationship keeps the origination clearly outside the cash/MO/cashier's-check trigger.
2. Provider classification on the US side. Confirm in writing how your US-side counterparty (the brokerage, exchange, or issuance partner that converts USD to USDC or USDT) treats the funding instrument and what reporting it produces. The excise is collected by US "remittance transfer providers," so being clear about who is and is not a remittance transfer provider in your stack matters.
3. Documentation trail end to end. Even though the excise does not attach, treasurers benefit from a clean trail: bank debit memo, stablecoin purchase confirmation, onchain transfer hash, off-ramp settlement file, SPEI confirmation, contractor CFDI. That trail also serves Mexican tax documentation downstream.
SPEI off-ramp provider matrix
The Mexican SPEI-licensed off-ramp landscape for institutional stablecoin flows is concentrated. Bitso is the most established and operates a licensed Mexican entity with direct SPEI access. Other providers operate via banking partners or via licensed affiliates. Once the excise is set aside, the matrix that matters is straightforward, and it is about Mexican tax and operational readiness rather than US withholding:
License venue. Is the entity SPEI-licensed directly under the Mexican IFPE/CNBV framework, or is it routing through a Mexican bank partner.
CFDI and SAT documentation. Does the provider produce SAT-aligned records the operator and the contractor can use at year-end. This is the live Mexican compliance surface for B2B contractor payouts, not stablecoin withholding.
Reporting outputs. Settlement files, FX rate transparency, and a reconciliation format that the operator's finance stack can ingest.
Onchain support. Which stablecoins does it accept, on which chains. USDC on Base or Arbitrum, USDT on Tron, and MXNB across its supported chains are the realistic surface area.
For most US operators, the practical short list is Bitso and one or two licensed competitors. The MXNB path covered in the companion piece on MXNB is itself a Bitso-led flow, so an operator who already runs MXNB has the SPEI plumbing in scope by default.
Worked example: a US SaaS paying Mexican contractors
A US SaaS pays 80 Mexican contractors monthly, average ticket roughly $2,000, total monthly outflow around $160,000. The architecture: ACH debit from the US business bank account funds USDC purchase on a regulated venue. USDC on Base is sent to a Mexican licensed off-ramp partner. The partner converts to MXN and pushes SPEI to each contractor's CLABE. The contractor issues a CFDI.
Under the 1 January 2026 US excise, this architecture has zero excise exposure: the funding is a bank debit, the onward transfer is crypto-funded, and neither category is in scope. The architectural reason is that the rule keys on origination instrument and explicitly carves out bank-funded and crypto-funded transfers.
The actual operational work is on the Mexican side and unchanged from the pre-2026 baseline: confirm each contractor's Régimen Fiscal, ensure CFDI issuance per payment, and reconcile SPEI settlement against the off-ramp's reporting. Treasurers occasionally conflate the US excise with a hypothetical Mexican withholding rule; as of June 2026 no such Mexican stablecoin remittance withholding rule exists.
What this is not
This is not a Mexican stablecoin withholding rule. As of June 2026, no live SAT rule withholds tax on stablecoin remittances at the off-ramp layer. KPMG's 2026 Mexican tax review covers digital-platform VAT and income-tax withholding, but it does not introduce a stablecoin-specific withholding mechanism. Operators should be skeptical of secondary commentary that frames the OBBBA excise as a Mexican rule; it is a US federal rule with a defined origination-instrument trigger.
It is also not a ban on stablecoins, not a chain-level restriction, and not a Bitso-specific issue. It is a US-side excise with a narrow scope, and it does not attach to the bank-funded and crypto-funded patterns that dominate B2B contractor payouts.
How this connects to the rest of the LATAM stack
Mexico has a coherent IFPE and CNBV framework for licensed off-ramps and SPEI access, and SAT's CFDI infrastructure makes contractor payout documentation cleaner than in most LATAM jurisdictions, but there is no live stablecoin withholding rule layered on top. That framing matters: the Mexican stack is workable for institutional operators, and the 2026 noise is primarily US-side.
The corollary is that operators routing into Mexico need to think about the US-side origination architecture explicitly, and then about Mexican documentation discipline at the off-ramp and contractor layer. The two surfaces are independent.
For the underlying peso-rails view, see support/en/articles/15575502. For the broader corridor benchmark including Mexico against Brazil and Argentina, see support/en/articles/15575499. For network-selection on the upstream USDC vs USDT decision, see support/en/articles/15575500.