The thing that breaks production wealth-tech is almost never the case the test corpus was built around. It is the case the test corpus didn't include — the multi-state filer in the year of a partial-year move, the household that crossed an IRMAA bracket because of a Roth conversion, the wash-sale that linked an HSA purchase to a taxable-account loss.
These cases are not exotic. They appear in real production populations at frequencies between 1% and 10%. They are exotic only in test corpora that were built without explicit edge-case coverage as a goal.
This article is the triage guide — ten edge cases, ranked roughly by the prevalence-and-impact product of the bugs they prevent. Calibrate your test corpus against the list.
1. ITIN filers (no SSN)
Households with at least one member filing under an Individual Taxpayer Identification Number rather than an SSN. ITINs are issued to non-citizens who don't qualify for SSNs but have US tax filing obligations — a population that includes recent immigrants, dual-country workers, and certain visa holders.
Frequency in modal fintech populations: 2-5%. Higher in geographic markets with recent-immigrant concentrations.
Why it matters: backend systems that hard-fail on non-SSN tax IDs reject these customers at onboarding silently, often without flagging the rejection as a recoverable edge case. The engineering team thinks the system handles all tax IDs because the test corpus included only SSNs.
The corpus must include ITIN-filing households with the structurally distinct fields — tax_id_type: 'ITIN', alternative-document-pathway flag, country-of-origin field. Algorithms that branch on tax-ID validation must be exercised against these households.
2. Multi-state tax residents (commuter, snowbird, partial-year mover)
Households whose tax residency spans multiple states in any single tax year. The cases include commuters (NJ → NY each weekday), snowbirds (FL six months, NY six months), and partial-year movers (CA Jan-Aug, FL Sep-Dec).
Frequency: 5-8% in national populations; concentrated in specific corridors.
Why it matters: state-tax allocation rules differ across states (resident vs. non-resident, source-state rules, reciprocity agreements). Engines that assume single-state residency produce wrong tax projections, wrong credit-for-state-tax calculations, and wrong state filing obligations.
The corpus must include households with multiple state-residency annotations — states[], allocation methodology, source-state rules. The longitudinal corpus must include partial-year-move events that propagate forward.
3. K-1 income with QBI / SSTB classification
Households receiving Schedule K-1s from partnerships or S-corporations, with the §199A Qualified Business Income (QBI) deduction analysis. The classification of Specified Service Trade or Business (SSTB) status — accounting, consulting, financial services, etc. — affects deduction eligibility differently from non-SSTB pass-throughs.
Frequency: 8-15% in upper-middle-income populations; nearly 50% in HNW populations.
Why it matters: QBI deduction calculation has W-2 wage limits, qualified property limits, taxable-income thresholds, and SSTB phase-outs. Engines that compute "20% of QBI" without these constraints produce wrong tax math. The deduction is large enough — up to 20% of QBI — that the error is consequential.
The corpus must include K-1 households with structured pass-through detail — SSTB flag, W-2 wages from the entity, qualified property basis, taxable-income status against the threshold. Multiple-K-1 households are particularly important; aggregation logic across K-1s has its own bug class.
4. Cross-account wash-sale conflicts
Households where harvesting in account A would trigger a wash sale because the spouse's IRA, the same investor's other taxable account, or another family-graph account purchased the substantially-identical security within 30 days.
Frequency in households with multiple accounts: ~6% of would-be-harvestable lots have cross-account conflicts.
Why it matters: per-account wash-sale checking misses these triggers. Tax-loss-harvesting algorithms that don't handle cross-account get the easy case right and the consequential case wrong. The disallowance produces wrong 1099-B reporting and wrong realized-loss totals.
The corpus must include household-graph relationships explicitly — joint accounts, beneficial-owner mappings, related-party trust structures — and the algorithm-test scenarios where cross-account conflicts exist.
5. RMD age crossings under SECURE 2.0
Households where one or more members crossed (or are about to cross) the SECURE 2.0 RMD age — currently 73, rising to 75 in 2033. The first RMD year has specific rules (first RMD can be deferred to April 1 of the following year, but this typically forces two RMDs in the deferred year).
Frequency: 3-5% of populations annually as boomer cohorts age in.
Why it matters: RMD calculation uses the Uniform Lifetime Table (or Joint Life and Last Survivor for spouse-as-beneficiary in specific cases). Account-aggregation rules require RMDs from each traditional IRA separately but allow aggregation for 403(b)s. Inherited accounts have different rules entirely. Engines that mis-compute RMD produce IRS-eligible 50%-penalty exposure for the customer.
The corpus must include households at the RMD-crossing age, households with multiple traditional IRAs (aggregation), households with inherited IRAs (separate rules), and households with the spouse-RMD election option from SECURE 2.0.
6. Surviving-spouse trajectory after first death
Married households where one spouse will die during the longitudinal projection window, leaving the surviving spouse to handle account consolidation, single-filer brackets, reduced Social Security, and step-up basis events.
Frequency in retiree populations: meaningful — over a 30-year projection window, first death is a near-certainty for couples both currently alive.
Why it matters: retirement-planning engines that treat households as joint-filing forever systematically under-recommend Roth conversions (which are more attractive at joint rates than at later single rates), under-estimate future tax burden, and miss the surviving-spouse RMD election.
The corpus must include longitudinal households with projected spouse-death events, the resulting single-filer transition, and the step-up basis events at death.
7. AMT-binding households with ISO exercises
Households where the Alternative Minimum Tax actually binds — typically high-state-tax + ISO exercise + private-activity-bond interest + other preference items. ISO exercises in particular create AMT preference items that can produce surprise tax bills measured in hundreds of thousands of dollars.
Frequency in tech-employee populations: 5-15% in any given year for ISO exercisers.
Why it matters: equity-comp platforms that don't model AMT systematically advise clients to exercise more than they can afford. The clients pay AMT they didn't plan for, sometimes by selling vested shares at unfavorable prices.
The corpus must include ISO-holding households with bargain-element data per exercise, AMT-credit history, and the multi-year recovery scenarios where the credit slowly reduces future regular-tax bills.
8. Concentrated equity positions (>25% in single security)
Households where a single security represents more than 25% of liquid net worth. The case is especially common for tech employees, founders, and post-IPO equity holders.
Frequency: 5-10% in active-investor populations; nearly universal among founders.
Why it matters: concentration is a Reg BI red flag and triggers different supervisory paths. Tax-aware planning has different shape — the client may have specific reasons not to diversify (QSBS holding period, founder's ongoing role, lock-up provisions). Engines that recommend "diversify the concentration" without modeling the client-specific constraints produce advice the client correctly ignores, eroding platform credibility.
The corpus must include concentrated-position households with the structural reasons for the concentration documented — QSBS attestation, lock-up status, related-employer status.
9. Crypto / DeFi positions with cost-basis history
Households holding cryptocurrency or DeFi positions with the full receipt history (every airdrop, swap, staking reward is a basis event under current IRS guidance). Form 1099-DA is rolling out for tax years 2025-2026, materially changing reporting obligations.
Frequency: 10-15% in retail-investor populations with rapid growth.
Why it matters: every receipt is a basis event. A naive engine that aggregates crypto holdings to a position-level cost basis produces wrong tax math at sale. The full receipt history is required for accurate basis tracking.
The corpus must include crypto-holding households with the lot-level acquisition trail — purchases, swaps, airdrops, staking rewards, hard-fork-attributable receipts, and DeFi-protocol position events.
10. Trust-owned accounts with grantor / non-grantor distinction
Households where one or more accounts are owned by a trust — revocable living trusts, irrevocable grantor trusts (IDGTs, SLATs), and non-grantor trusts (CRTs, dynasty trusts). The grantor-vs-non-grantor distinction determines whose tax return reports the income.
Frequency: 5-15% in HNW populations; near-universal among family-office clients.
Why it matters: grantor trusts pass through income to the grantor's individual return; non-grantor trusts pay their own (compressed-bracket) tax. Engines that assume all accounts are individual-owned produce wrong tax projections, wrong account-titling, and wrong audit trails.
The corpus must include trust-owned accounts with structured trust-type fields (revocable / irrevocable, grantor / non-grantor), beneficiary structure, and trustee identification. Multi-trust households (the common HNW case) are particularly important.
What the catalog implies
Each of these ten edge cases represents a structurally distinct code path that real customers exercise. A corpus that omits them passes QA on the modal customer and ships features that crash on the long tail.
The order of priority — implied by the frequency-and-impact product — is roughly: cross-account wash-sale (#4) → multi-state (#2) → K-1 / QBI (#3) → ITIN (#1) → AMT / ISO (#7) → RMD (#5) → trust-owned accounts (#10) → concentrated positions (#8) → crypto (#9) → surviving-spouse (#6).
The triage practical implication: if the corpus has zero of these cases, prioritize #4 and #2 first. If the corpus has the modal cases plus one or two edge cases, fill in the gaps systematically. If the corpus has all ten, your test infrastructure is more mature than 90% of fintech production environments today.
Key takeaways
- Most production wealth-tech incidents trace to one of a known list of edge-case archetypes. The set is enumerable and most fintech corpora cover only 3-4 of the ten.
- Cross-account wash-sale conflicts (~6% of would-be harvests) are the highest-leverage gap. Per-account checking is the most-common implementation; cross-account is required for credible tax-aware advice.
- Multi-state tax residency affects 5-8% of national populations and the engine bugs propagate through state filing, credit-for-state-tax calculations, and source-state rules.
- Surviving-spouse trajectory is the most under-recommended planning angle. Engines that treat households as joint-filing forever miss conversion-window opportunities measured in six figures of lifetime tax savings.
- Treat the list as a triage starting set, not exhaustive. Each production incident that traces to a missing archetype should add to the corpus before remediation is considered complete.
Edge-case coverage is the cheapest engineering investment a wealth-tech team can make for production reliability. The cases are knowable; the curation work is the constraint. Teams that take the list seriously ship fewer surprise-incidents per quarter and recover faster from those that do occur.