The 1% Remittance Excise Tax Is a Compliance Architecture Problem, Not a Tax Rate Problem

Treasury's proposed remittance excise tax will break unprepared payment systems long before it costs anyone real money.

The new 1% excise tax on outgoing U.S. remittance transfers is not a revenue story. It is a systems story — and most remittance transfer providers are not ready for what Treasury just proposed.

The One Big Beautiful Budget Act (OBBBA) enacted this tax, and Treasury and the IRS have now issued proposed regulations fleshing out the mechanics. The rate sounds trivial. The compliance infrastructure required to execute it correctly is not.

What the Proposed Regulations Actually Require

Let me be direct about what Treasury put on the table. Remittance transfer providers — RTPs — are required to collect, report, and remit the excise tax on Form 720, the Quarterly Federal Excise Tax Return. The obligation attaches to outgoing U.S. remittance transfers, and the clock starts ticking with calendar quarters following finalization of the rules.

Form 720 is not a form most enterprise tax functions touch regularly. It lives in the excise tax world — fuel, tobacco, air transportation, indoor tanning. Adding remittance transfers to that universe creates a new compliance lane that most corporate tax departments have never staffed for. The operational question is not "how do we calculate 1%?" The question is: who owns this, what systems feed it, and what does "remittance transfer" mean precisely enough to build logic around it?

That last question is where the proposed regulations get serious. Treasury included anti-avoidance rules that would recharacterize or disregard transactions entered into with the principal purpose of circumventing the tax. That is not boilerplate. That is Treasury signaling that they anticipate providers will attempt to restructure transaction flows — splitting transfers, rerouting through intermediaries, recharacterizing payment types — and that such attempts will be treated as the underlying remittance transfer they are.

I have seen this pattern before. When a new excise or transaction tax arrives with a low rate, the instinct is to engineer around it. Treasury wrote these rules anticipating that instinct. Build your compliance program assuming the anti-avoidance rules will be enforced aggressively from day one.

Why Form 720 Compliance Is Harder Than It Looks

If you run tax for a bank, a fintech, a money services business, or any enterprise with a meaningful cross-border payments operation, here is what the Form 720 obligation actually demands:

None of this is architecturally simple. The data required to execute Form 720 correctly for remittance transfers sits across payment platforms, customer data systems, and general ledger entries that were never designed to talk to each other for this purpose.

I built tax transformation programs at Deloitte for two decades. The failures I saw most often were not failures of tax knowledge. They were failures of data architecture. The tax team understood the rule. The systems could not produce the data the rule required. That gap — between legal obligation and data reality — is exactly where this regulation will expose unprepared RTPs.

Anti-Avoidance Rules Change the Risk Calculus

The anti-avoidance provisions deserve their own section because they fundamentally change how RTPs need to approach transaction structuring decisions going forward.

Treasury's authority to recharacterize transactions means that restructuring a payment flow to avoid the excise tax — even if the restructured flow technically falls outside the statutory definition of a remittance transfer — creates legal exposure if the principal purpose of that restructuring was tax avoidance. This is a facts-and-circumstances standard. It requires documentation of business purpose. It requires that any transaction redesign be driven by genuine operational rationale, not tax savings.

For enterprise tax and treasury teams that routinely optimize cross-border payment flows for efficiency, FX costs, and operational simplicity, this creates a new documentation discipline. Every structural change to a remittance-adjacent payment flow after the effective date of these regulations needs a documented business purpose that stands independent of the excise tax.

I am not saying you cannot optimize your payment operations. I am saying you need to be able to prove, in writing, that the optimization existed for reasons other than avoiding this tax. Build that documentation practice now, before the rules are final, so it is operational by the time finalization occurs.

The Broader Signal: Transaction Taxes Are Getting More Granular

This regulation does not exist in isolation. It is part of a broader pattern in which transaction-level taxes — excise taxes, digital services taxes, e-invoicing mandates, and financial transaction taxes — are becoming more granular, more real-time, and more dependent on data infrastructure that most enterprise tax functions have not built.

Pillar Two imposed country-by-country minimum tax calculations that require entity-level financial data at a granularity most ERP systems were not designed to produce. E-invoicing mandates in the EU, Brazil, India, and now spreading to additional jurisdictions require transaction-level tax determination at the point of invoice issuance, not at period close. The remittance excise tax follows the same logic: tax attaches at the transaction level, reporting is periodic, and the data required to comply sits in operational systems, not tax systems.

This is the operating system argument I make consistently. Tax is not a period-end calculation layer sitting on top of your ERP. Tax is a property of every transaction your enterprise executes. Until your data architecture treats it that way — until tax attributes are captured at transaction origination, not reconstructed at quarter close — you will spend every new regulation cycle scrambling to retrofit compliance onto systems that were never designed for it.

The 1% rate on remittance transfers will not break anyone's P&L. The compliance gap will break your quarter-end close if you are not prepared.

What to do Monday morning

1. Map your remittance transfer exposure this week. Pull your cross-border outgoing payment volumes and identify which flows meet the statutory definition of a remittance transfer. Do not wait for the regulations to be finalized. The proposed rules give you enough definitional clarity to scope the problem now.

2. Assign Form 720 ownership explicitly. Someone in your tax function needs to own this return. If your team has never filed Form 720, get your excise tax counsel or your Big Four contact on the phone this week and assess the gap. This is not a VAT return. It requires specific procedural knowledge.

3. Audit your payment system's data outputs. Determine whether your payment platform can produce transaction-level data with sender jurisdiction, transfer amount, and transfer date in a format that feeds a quarterly excise tax calculation. If it cannot, that is a systems project, not a tax project — and it needs to start now.

4. Document business purpose for any current or planned payment flow restructuring. If you have open projects to redesign cross-border payment flows, get legal and tax in the room together and document the operational rationale. Anti-avoidance exposure starts the moment these rules are finalized.

5. Set a finalization watch. The proposed regulations are not yet final. Assign someone to track the finalization timeline and IRS comment period. The effective date — calendar quarters after finalization — is the hard deadline for operational readiness. You need lead time measured in months, not weeks.

Sources