Most production fintech incidents that trace back to test-data gaps look the same: a transaction shape that the test corpus didn't include showed up in production, the engine processed it like a different shape, and a customer's account state went wrong. The fix is usually small. The detection time is long — weeks to months — because the affected accounts are the long tail and the corruption is silent.
The set of "interesting" transaction shapes is structurally enumerable, and the catalog below is the twelve archetypes we use as the floor for any wealth-tech test corpus. Each entry says why the shape matters, the bug class that typically ships when it's missing, and the data-model assertion that proves the engine actually handles it.
1. Standard buy / sell with full quantity match
The base case. Customer places an order, the order fills at a single price for the full requested quantity, the trade settles on T+1, and the position updates cleanly. This case works in every test corpus and rarely produces production bugs by itself.
It belongs in the catalog as the baseline against which all other shapes are calibrated. Most engines handle this correctly; checking the assertion sets the validation bar for the rest.
2. Partial fills across multiple executions
A market order for 1,000 shares fills in three executions: 400 at $50.00, 300 at $50.05, 300 at $50.10. The engine must aggregate the executions into a single trade record with weighted-average cost, while preserving the per-execution detail for tax-lot tracking and broker-side reconciliation.
The bug class: engines that store only the aggregate execution lose the per-fill timing, which matters for wash-sale detection (the wash sale clock starts at each execution date, not at the order date) and for time-in-force enforcement (a partial-fill GTC order has different remaining-quantity logic than a full-fill).
3. Cross-account transfers (ACATS in-kind)
A customer transfers their full account from another custodian via ACATS. The receiving fintech must accept positions in-kind, preserving cost basis, holding period, and lot-level structure from the originating custodian. The transfer often arrives over multiple days as different security types settle.
Bug class: engines that treat ACATS transfers as new purchases reset the cost basis to current market, producing wrong tax math. The test corpus should include a household where the most recent activity is an ACATS transfer with structured originating-custodian basis data.
4. Wash-sale-triggering harvest plus repurchase
Customer realizes a $5,000 loss on Stock X. Within 30 days, customer (or spouse, or in another account) buys substantially identical Stock X. Wash sale fires, the loss is disallowed, the basis of the new lot increases by the disallowed amount, and the holding period of the new lot is extended.
Bug class: per-account wash-sale checking misses the cross-account triggers. ~6% of would-be-harvest opportunities in real-world households have cross-account wash-sale conflicts. Test corpora that include only single-account scenarios systematically miss this code path.
5. Corporate action — stock split (forward and reverse)
The issuer of Stock Y declares a 3-for-1 split. Each lot in the customer's account triples in share count and divides cost-basis-per-share by three. Reverse splits work the same way in reverse, and may produce fractional shares depending on the terms.
Bug class: engines that recompute lot share count at split time but forget to adjust cost-basis-per-share produce dramatically wrong tax math at subsequent sale. The test corpus should include positions that have undergone splits; the engine's handling must be exercised.
6. Corporate action — merger / spin-off / cash-and-stock
Stock A (owned by customer) merges with Stock B. The customer receives 0.5 shares of Stock B per Stock A share, plus $10/share in cash. The cash component is currently taxable boot; the stock component carries forward Stock A's basis at the appropriate ratio.
Bug class: engines that treat the entire merger consideration as taxable miss the tax-deferral on the stock portion. Conversely, engines that defer the cash boot mis-state current-year taxable gain. The test corpus must include merger scenarios with both pure-stock and cash-and-stock structures.
7. Cash dividend with reinvestment
Customer's holdings pay a $50 dividend, automatically reinvested into 1.234 additional shares at the current market price. The reinvestment creates a new lot at the reinvestment price; the original dividend is currently taxable as ordinary income (or qualified dividend, depending on holding period and security type).
Bug class: engines that reinvest dividends but forget to record the dividend as taxable income produce both wrong basis and wrong 1099-DIV totals at year end. Engines that record the dividend but fail to create the new lot produce wrong basis tracking on subsequent sales.
8. Margin call resulting in forced liquidation
Customer's margin balance falls below maintenance requirement. Broker issues margin call. Customer fails to meet call within deadline. Broker liquidates positions in customer's account to cover the deficit, typically using a "lowest-cost-basis-first" or "highest-loss-first" methodology.
Bug class: engines that don't model the forced-liquidation path entirely (assuming customers always meet calls) miss the tax consequences and the disposition records that flow from margin liquidations. The customer's tax filing in the affected year is wrong without these records.
9. Wire transfer in / out (no security movement)
Customer wires $50,000 into the account from an external bank. Or wires $50,000 out to a Treasury Direct purchase. The transaction is pure cash movement with no security side. The wire may carry beneficiary information that triggers AML monitoring rules.
Bug class: engines that treat all transactions as security trades try to find a security on a cash wire, or forget to update cash balance correctly. Pure-cash transactions need their own handling. The AML side is its own check — wire originator and beneficiary fields must be retained.
10. Currency conversion in a foreign-denominated account
Customer's foreign-currency account receives a dividend in EUR. The dividend converts to USD at the current spot rate for tax-reporting purposes. The basis of the underlying security is held in the original currency for foreign-tax-credit purposes.
Bug class: engines that don't track currency conversion produce wrong tax math (1099-DIV must be in USD; foreign tax credit eligibility depends on the original-currency tax). Engines that convert eagerly to USD lose the original-currency state needed for the FTC calculation.
11. ACH return / NSF / reversal
A customer-initiated ACH transfer from external bank arrives. Two days later, the originating bank returns the ACH (insufficient funds at source). The fintech must reverse the credit, potentially after the customer has already used the funds for other transactions, producing a cascading-reversal scenario.
Bug class: engines that don't model the ACH reversal path treat the original credit as final at posting. When the reversal arrives, the cascading effect on subsequent transactions isn't computed correctly. The test corpus should include an ACH-return scenario with downstream activity dependent on the returned funds.
12. Corporate action — Section 305 deemed dividend on PIK securities
A PIK (paid-in-kind) bond pays interest in additional bonds rather than cash. Under §305, the additional bonds are a taxable deemed dividend at issuance, even though no cash changed hands. The customer owes tax on income they didn't receive in cash.
Bug class: engines that don't recognize the §305 event produce wrong 1099 reporting and wrong basis. Customers receive surprise tax bills when their accountant identifies the missed income. This is a niche scenario but high-impact for the customers who hold PIK securities.
What the catalog implies for the test corpus
Each archetype represents a structurally distinct code path. A corpus that exercises only archetypes 1, 7, and the simple version of 5 covers the modal customer's modal transactions but misses the long-tail behaviors that trigger production incidents.
The recommended corpus contains, for each archetype:
- At least one example in current state (the household has the artifact in their current portfolio)
- At least one example in historical state (the household has experienced the archetype in the past, with the historical detail preserved)
- The structurally tricky variants (cross-account triggering for #4, both forward and reverse for #5, both pure-stock and cash-and-stock for #6, etc.)
A corpus calibrated against this catalog produces production-readiness coverage that test-fixture-only corpora can't match. Each archetype is the source of a known bug class; including it is the cheapest way to prevent that bug class from shipping.
The relationship to the catalog as a working document
The catalog isn't meant to be exhaustive — production environments encounter additional transaction shapes (option exercise, options assignment, REIT distribution character changes, qualified-vs-ordinary dividend reclassification, etc.). The right pattern is to treat the catalog as a starting set and expand it with each production incident: every incident that traces to a missing transaction archetype gets added, with its scenario seeded into the corpus, before the incident's remediation is considered complete.
This produces a self-improving test corpus that compounds value over time. The team that operates this discipline produces fewer customer-impacting incidents per quarter, and the incidents that do occur are increasingly novel rather than repeats of solved problems.
Key takeaways
- Most production fintech incidents that trace to test-data gaps fall into a structurally enumerable set of transaction archetypes. The set is curatable; the work is doing the curation.
- Cross-account wash-sale triggering (archetype #4) and ACATS in-kind basis preservation (archetype #3) are the two highest-frequency missing-archetype bug classes in our review of fintech incidents.
- Corporate-action handling (archetypes #5, #6, #12) is the most error-prone category. Each variant has its own basis-and-character math; engines that handle 'splits' may miss spin-offs, and vice versa.
- Pure-cash transactions (archetype #9) need their own code paths. Engines designed exclusively for security trades produce subtle bugs when they encounter cash-only transactions.
- Treat the catalog as a working document. Every production incident that traces to a missing archetype gets added, with the scenario seeded into the test corpus, before remediation is complete.
The compounding value of a curated test corpus is one of the under-recognized engineering investments in fintech. Twelve archetypes is a starting set — the corpus should expand with experience. The teams that maintain this discipline ship fewer incidents per quarter and recover faster from those that do occur.