Custodian-specific data quirks — Schwab, Fidelity, Pershing, BNY Mellon

Going custodian-direct — bypassing aggregators and integrating with custodians' own data feeds — is the path most institutional wealth-tech platforms take when fidelity matters more than breadth. The result is dramatically richer data: lot-level basis, full corporate-action history, distribution-character classification, account-level metadata that aggregators normalize away. The cost is that "custodian-direct" is not one integration. It's four to six separate integrations, each with its own conventions, failure modes, and operational quirks.

This article walks through the four custodians most US wealth-tech platforms have to handle: Schwab (post-TDA-merger), Fidelity (Wealth and Institutional), Pershing (BNY's clearing arm, the dominant RIA-clearing platform), and BNY Mellon's direct custody platform. The goal is to make the per-custodian quirks legible, so test data can model them.

The four custodians at a glance

Schwab — and the post-TDA reconciliation problem

Schwab's institutional platform absorbed TD Ameritrade Institutional in 2023, and the migration consolidated millions of RIA-managed accounts onto Schwab's NetX360 platform. The migration is largely complete but left specific data quirks that test data has to model:

Account-number renumbering. Most TDA accounts received new Schwab 8-digit account numbers; some retained legacy 9-digit numbers under specific circumstances. Platforms that cached account numbers from 2022 may have stale references; platforms that match across the migration boundary need to handle the renumbering map.

Lot-history transfer. TDA's CBRS-format lot data was migrated to Schwab's format. Most lots transferred cleanly; some non-covered lots (pre-2011 acquisitions) transferred with placeholder basis pending manual reconciliation. A subset of complex lots (long-dated options assignments, certain corporate-action histories) required manual recategorization. Test data for migrated accounts has to include both clean migrations and reconciliation-pending lots.

Statement-cycle quirk. Schwab issues monthly statements for accounts with activity in the month, quarterly otherwise. The boundary between "activity" and "no activity" is the source of edge-case bugs in platforms that assume monthly statements always exist.

API-rate-limit asymmetry. Schwab's NetX360 API has different rate limits for different endpoint categories; a platform that succeeds in test (low-volume) can hit limits in production (high-volume) on specific endpoints. Test data alone won't catch this; load testing is required, but the test corpus should be sized to support realistic load tests.

// Schwab post-TDA account record (canonical shape)
{
  "schwab_account_number": "82145678",
  "legacy_tda_account_number": "987654321",        // present for migrated accounts
  "migration_date": "2023-09-12",
  "account_type": "INDIVIDUAL_TAXABLE",
  "registration": "JOHN Q SMITH",
  "lot_reconciliation_status": "complete",         // or "pending_manual_review"
  "statement_frequency": "monthly_with_activity"
}

Fidelity — the FDX-native institutional path

Fidelity is one of the largest US custodians by accounts and a founding board member of the Financial Data Exchange. The institutional platform (WealthHub, formerly the institutional brokerage product) has the highest-fidelity FDX implementation among the major custodians. Test-data quirks:

Account-type taxonomy depth. Fidelity distinguishes account subtypes more granularly than aggregators do — e.g. "IRA" splits into Traditional, Roth, Inherited Traditional, Inherited Roth, SEP, SIMPLE, and Rollover, with tax-treatment differences across sub-types. Test data has to include the subtypes; platforms that flatten to a single "IRA" category will fail tax-engine tests.

Average-cost default for mutual funds. Fidelity defaults mutual-fund lots to average-cost basis (the default for mutual funds since the IRS allowed it). For equities, the default is FIFO. A platform that handles both has to know which method is in effect per security type per account, and the test data has to include both.

Statement vs. continuous-feed asymmetry. Fidelity provides both monthly statements (PDF and XML) and continuous-feed data via the WealthHub API. The two should agree but occasionally don't on edge cases (statement cutoff vs. trade-date timing). Test data has to support reconciliation between statement and feed.

Brokerage Link in 401(k)s. Fidelity's Brokerage Link feature within employer 401(k) plans creates accounts that look like brokerage accounts but live within retirement-plan accounting. The data feeds for these are in the institutional platform but with retirement-plan tax treatment. A test corpus that omits Brokerage Link accounts will fail on the first 401(k) participant who used the feature.

Pershing — the RIA clearing dominant

Pershing (a BNY Mellon subsidiary) is the dominant clearing platform for RIAs and introducing brokers. Most non-Schwab, non-Fidelity RIAs clear through Pershing or one of its smaller competitors (BNY Pershing Advisor Solutions, Apex, Goldman Sachs Custody Solutions). Pershing's NetX360 platform handles roughly 1,000+ introducing firms.

The introducing-broker layer. Pershing's data feeds are filtered through the introducing broker's own customizations. The same logical data point (e.g. account-level performance) might be reported differently by two RIAs both clearing through Pershing, because each RIA has its own NetX360 customization. Test data has to allow for introducing-broker-level configuration variability.

Statement-cycle for fee accounts. Pershing-cleared accounts with advisory fees typically get monthly statements; accounts with only transactional activity may get quarterly. The statement-cycle determination logic is at the introducing-broker level.

Cost-basis handling for legacy positions. Pershing has the longest tail of legacy non-covered positions (pre-2011 acquisitions still held in current accounts). Test data has to include positions with placeholder basis and the customer-supplied-basis flow that resolves them.

The sweep-vehicle ladder. Pershing supports an unusually broad set of cash sweep vehicles (multi-bank FDIC sweep, money-market, custom RIA sweep). Test data has to include the cash-sweep vehicle configuration as part of the account record.

BNY Mellon — direct custody for asset owners

BNY Mellon's direct custody platform (separate from Pershing's clearing platform) serves asset owners — pension funds, endowments, foundations, family offices — that hold assets directly with BNY rather than through a clearing relationship. The data shape is more institutional than retail/RIA: GIPS-aligned reporting, look-through for fund-of-funds, alternative-investment NAV handling, currency-overlay exposure for international holdings.

Look-through reporting. BNY's direct custody data feeds support full look-through for fund-of-funds holdings — a position in a multi-strategy fund-of-funds gets unpacked to the underlying fund holdings, which in turn unpack to position-level for separately-managed sub-portfolios. This is the data path institutional reporting platforms consume; mock data without look-through cannot exercise the fund-of-funds attribution logic.

Alternative-investment NAV. Private-fund holdings get quarterly NAVs; some holdings are reported with as-of dates that lag by 30-90 days. Test data has to include alternative-investment positions with stale NAV timing — the lag is real and engines that assume same-period valuation will break.

Multi-currency exposure. BNY's institutional clients commonly hold multi-currency portfolios with overlay hedging strategies. The data feeds include both base-currency and local-currency valuations, with separate fields for the overlay-hedge P&L. Test data has to include the multi-currency layer; a single-currency mock corpus can't exercise the FX-attribution code path.

What test data has to model

Per-custodian, the realistic synthetic corpus has to include:

A test corpus that includes only one custodian's shape can be useful for that custodian's integration testing but cannot exercise the cross-custodian aggregation logic that institutional platforms ultimately need.

How this shows up in our catalog

The institutional and HNW bundles in the WealthSynth catalog ship with a custodian field per account drawn from the realistic distribution above (~40% Schwab post-TDA, ~30% Fidelity, ~20% Pershing-cleared via various RIAs, ~5% BNY direct, ~5% other). Per-custodian field shapes are projected through the canonical household JSON, so the same household has the same underlying lots represented through each custodian's expected schema. The cross-custodian households (HNW with 3+ custodians) are deliberately weighted into the upper-tier bundles.

For the broader integration context, see Aggregator & Custodian Integration. For the reconciliation problem when multiple feeds populate the same household, see Reconciling aggregator output with custodian source-of-truth. For the ACATS flow that moves accounts between these custodians, see ACATS modeling.