What changed
FACT (source): Treasury/IRS published proposed regulations on 2026-04-13 providing 'rules and definitions related to the excise tax imposed on certain remittance transfers that occur after December 31, 2025,' expressly stating the regs 'would affect certain remittance transfer providers and certain individuals sending remittance transfers.' INFERENCE: the proposed regs implement an excise tax enacted in 2025 tax legislation; the statutory rate, the exact definition of a covered 'cash-equivalent' transfer, and the exemption/verification mechanics are NOT stated in the provided source text and must be read from the regs before building.
Why now
FACT (source): the tax applies to transfers occurring after December 31, 2025 — i.e. the taxable period is ALREADY RUNNING while the implementing regulations are still only proposed. INFERENCE (high confidence, but not in source text): providers therefore have a live collect-and-remit obligation with unfinished guidance, which is precisely the window where a compliance product sells. INFERENCE: the return vehicle is quarterly Form 720 with EFTPS deposits; this is my assumption from how federal excise taxes are generally administered, not a source fact, and is the single most important thing to verify in the reg text before writing a line of code.
Converging signals
Three things meet at one point: (1) a federal rule that names a tax, (2) a defined class that has no choice but to collect and file it — remittance transfer providers, and (3) a federal submission channel (IRS excise filing). The convergence is not technological, it is structural: an obligation with a deadline, a named filer class, and a portal. Weak point, stated honestly: only ONE source document underlies this brief. There is no independent corroborating signal — no complaint thread, no job posting, no vendor announcement — in the input.
Customer pain
HYPOTHESIS (not evidenced in the input): a small money transmitter or crypto-remittance app must now, per transfer, decide whether the transfer is covered, apply the correct rate, collect the tax from the sender at point of sale, retain evidence supporting any exemption or sender-verification claim, hold the collected funds, deposit them on the federal schedule, and reconcile the quarterly return to the transaction ledger. Every one of those steps is a new field, a new control, and a new audit exposure on a system that was not built for it. The large providers have tax departments. The long tail does not. I am asserting this as inference; the source text says nothing about how providers are coping.
Who pays
The principal — the licensed money transmitter or MSB entity, or the crypto-remittance app operator — because the collect-and-remit liability and the return sit with the provider, not the agent location and not the sender. FACT (source): the regs 'would affect certain remittance transfer providers.' INFERENCE: the economic buyer is that provider's compliance officer or controller, a reachable non-procurement person at a company of 5-200 people. The sender bears the tax but buys nothing.
Solved today
INFERENCE, and I want to be blunt that I have no evidence for it: today the obligation is probably being handled by (a) the provider's existing core transmitter platform vendor bolting on a tax field, (b) a spreadsheet plus the outside CPA who already prepares the entity's returns, or (c) not at all yet, because the regs are still proposed. I cannot cite anyone's current workflow. Anyone building this must interview ten licensed transmitters before committing capital.
Why current solutions are bad
HYPOTHESIS: a spreadsheet cannot produce per-transfer substantiation for an exemption claim under examination, and a core-platform tax field does not reconcile the collected pool to the deposited pool to the filed return. The audit artifact — 'show me why this transfer was not taxed' — is a document-retention and evidence-linkage problem, which is a different product from a rate calculator. That gap is the only defensible part of this idea; the rate math itself is arithmetic.
Proposed product
Two components, deliberately sequenced so the hard-to-sell one comes second. (1) EVIDENCE + RETURN (the wedge, no payment-path integration): the provider exports its transaction ledger; the product ingests it, classifies each transfer as covered or exempt against a rules engine derived from the final regs, links each exemption to its supporting document in an evidence vault with immutable timestamps, reconciles collected tax against deposits, and assembles the quarterly excise return with a per-transfer workpaper the CPA signs and files. (2) POINT-OF-SALE API (later, and only after logo-and-trust): a real-time endpoint returning the tax due and an evidence token at the moment of the transfer. Component 2 is the one every competitor will demo; component 1 is the one nobody wants to build and every examiner will ask for.
MVP version
Ingest a CSV/JSON transaction export. Rules engine encoding the covered-transfer definition and each exemption from the final reg text, versioned by effective date. Evidence vault: upload, hash, link to transfer ID, retention clock. Reconciliation: collected vs. deposited vs. filed, with a variance report. Output: a completed excise-return workpaper plus a per-transfer substantiation binder as a PDF/Parquet pair. Explicitly NOT in the MVP: touching the money, holding the tax funds, PCI scope, or writing into the provider's payment flow. Read-only ingest keeps the security review survivable for a solo vendor.
30-day build
Do not write product code. Read the proposed regulation end to end and resolve the three unknowns this brief could not: the statutory rate, the precise covered-transfer definition, and the actual return/deposit vehicle (I have assumed Form 720/EFTPS — verify it). Read the comment docket: the comments on this proposed rule are a free, public, named list of the providers, trade associations, and law firms who cared enough to write in. Those commenters are the prospect list and the pain interviews. Pull the NMLS Consumer Access public registry to size and name the licensed money-transmitter universe. Target: 15 recorded conversations with compliance officers at sub-$500M-volume providers, and a hard read on whether their core platform vendor has already announced this feature. If three of the top core vendors have shipped it, kill the idea here — that is the cheapest kill available and it costs 30 days, not 30 days plus a build.
60-day build
Only if the interviews survive: build the rules engine and evidence vault against real (anonymized) transaction exports from two design partners recruited from the docket. Publish a free, genuinely useful public artifact — a clause-by-clause reading of the final rule with a covered/exempt decision tree, updated as the reg moves from proposed to final. That artifact is the distribution vehicle, because it reaches the exact person who has to make the decision and it demonstrates value without relationship selling. Get a SOC 2 Type I underway; a financial-institution buyer will ask, and the founder has the capital to pay for it.
90-day revenue plan
First revenue from the two design partners converting to paid at the first full quarterly filing cycle after the rule finalizes, plus a paid 'first return' engagement priced as a fixed fee. Realistic first-dollar timing is the quarter-end after final regs, not 90 days from today — the buyer's urgency is pinned to a filing date, and that date is set by Treasury, not by the founder. This is the one place where the founder's 30-180 day revenue preference collides with reality: the deadline that creates the demand also gates the payment.
Distribution path
The public comment docket on this exact rule (self-identified, named, motivated buyers). The NMLS Consumer Access public licensee registry — public-records extraction, which is a stated founder strength. MSB and money-transmitter trade associations. Most importantly: the MSB compliance consultants and the CPAs who already prepare these entities' returns, as a referral and white-label channel — they have the relationships, the founder has the software, and they are the incumbent 'existing spend' rather than the enemy.
Pricing hypothesis
Monthly SaaS by transfer volume band, roughly $500-$2,500/mo for the long tail, plus a per-quarter return-assembly fee of $1,500-$5,000. Do NOT price in basis points on the transfer as the input's monetization line suggests — taking a percentage of a payment flow drags the founder toward money-transmission and payment-facilitation questions he does not want and would have to answer to fifty state regulators. Flat SaaS plus per-filing keeps him a software vendor.
Technical difficulty
The computation is arithmetic. The hard parts are boring and real: reg-versioned rules with effective dates, immutable evidence linkage that survives an examination, reconciliation across three ledgers, and being a vendor a financial institution will let near its data. Moderate build, high correctness bar — a wrong exemption classification is the customer's tax liability, not a bug report. Carry E&O insurance and a contractual liability cap, and have a tax attorney review the rules engine's mapping to the reg. That is exactly the kind of modest upfront spend the founder can now fund.
Legal / regulatory risk
The founder does not become a licensed or certified party — he sells software to the regulated entity, which is the correct side of the line and the same shape as the FMCSA ELDT product. The genuine risk is professional-liability: the product asserts a tax classification the customer relies on. Mitigate with attorney review, a signing CPA in the loop for the return itself, and a liability cap. Secondary risk: the regulations are PROPOSED. They can change materially between proposal and final rule, and the rules engine must be built to be re-versioned rather than patched.
Platform dependency
None meaningful. The submission target is a federal tax system with no platform owner who can deplatform the tool. The real dependency is on each provider's core transmitter platform for the transaction export, which is why the MVP must accept a plain file rather than require an integration.
Founder fit
Very high on shape, and this is not a courtesy score. It is structurally the FMCSA ELDT product again: a federal mandate names a class that is forced to file, the class needs a submission and substantiation layer, and a solo operator can build it and charge per filing. Public-records extraction (NMLS, the comment docket) is a stated strength and is precisely how the prospect list gets built. The mismatch is the buyer: ELDT training providers are small operators who will swipe a card; money transmitters are financial institutions with vendor-risk questionnaires, security reviews, and a procurement cadence measured in months. The founder sells through demonstrated value, and a clause-by-clause public reading of the rule is a strong demonstration — but it will not compress a bank's vendor onboarding.
Breakout potential
Moderate. The evidence-vault-plus-reconciliation core generalizes to any transaction-level excise or per-transfer levy, and the same providers face overlapping state money-transmission reporting. The ceiling is set by the size of the long tail of independent providers, since the large ones will always build in-house. This is a good, durable, unglamorous cash-flow business — not a breakout.
Final recommendation
CONDITIONAL PURSUE — fund the 30-day investigation, do not fund the build. The mandate shape is the founder's exact proven wedge and the demand is structurally real: a defined class of providers must collect a tax and file a return on transfers that are already occurring. But three load-bearing facts are unknown, and all three are cheaply knowable: whether the final regs create a retained-evidence exemption regime (which is the entire moat), whether the incumbent core platforms have already shipped it (which is the entire competitive question), and whether these buyers will onboard a solo vendor at all (which is the entire go-to-market question). None requires capital to answer. Answer them by reading the regulation and the comment docket and calling fifteen compliance officers. If exemptions require retained substantiation AND no core vendor has shipped it, this is a strong, fundable, unglamorous business — build it. If exemptions are self-certifying, or two major platforms have announced the feature, kill it that week and lose nothing. Resist the pull to start coding a rate calculator; that part is easy, and being easy is the problem.
Next action
Read the full text of the proposed rule at federalregister.gov/documents/2026/04/13/2026-07085 and answer exactly three questions in writing: (1) What is the rate and the precise covered-transfer definition? (2) Do the exemptions require the provider to obtain and RETAIN substantiating documentation — and if so, is there a stated retention period? (3) What is the actual return and deposit vehicle (confirm or refute the Form 720 / EFTPS assumption)? Then pull the public comment docket for this rule and extract every commenting provider, association, and law firm as the initial prospect and interview list.