ACATS modeling — partial transfers, in-kind lots, and the settlement-window traps

ACATS — the Automated Customer Account Transfer Service, operated by DTCC — is the standardized rail that moves brokerage accounts between firms. The service handles roughly 9.5 million transfers per year, with a typical settlement window of 5–7 business days from initiation to completion. For a wealth-tech platform that handles new-account funding, account migration, or cross-firm consolidation, ACATS is one of the larger integration surfaces — and it's also the one where mock data most consistently hides bugs that production exposes within the first month.

This article walks through what the ACATS flow actually looks like, the edge cases (partial transfers, in-kind lots, fractional shares, transfer-during-corporate-action), the rejection codes your engine has to handle, and the synthetic-data shape needed to exercise the full flow.

The ACATS flow in one paragraph

A receiving firm initiates a transfer by sending an ACATS request to DTCC referencing the delivering firm's DTC number, the customer's account number, and the transfer scope (full or partial, with itemized assets if partial). DTCC routes the request to the delivering firm. The delivering firm has 24 hours (1 business day) to validate the request, accept it, or reject it with a code. If accepted, the transfer enters review (3 business days) during which the delivering firm prepares the assets for transfer. On settlement (typically T+5 to T+7), the assets move via DTC for securities (lot-level basis transferred) and via FedWire/ACH for cash. The customer's positions appear at the receiving firm with original acquisition dates and cost basis preserved.

The compressed version hides the failure modes. The full flow is:

1. T+0
   Request submitted (TIF)
   Receiving firm submits Transfer Initiation Form to DTCC. Delivering firm has 1 BD to validate.
2. T+1
   Validation / acceptance
   Delivering firm accepts (transfer proceeds) or rejects with one of ~20 standard codes. Common rejections: SSN/TIN mismatch, account type mismatch, insufficient assets, prior-pending transfer.
3. T+2 to T+4
   Review period
   Delivering firm prepares assets. During this window, the account is partially frozen — trades may be restricted, distributions still post to the delivering firm. Corporate actions during this window are the largest source of edge-case bugs.
4. T+5 to T+7
   Settlement
   DTC moves securities; cash moves via FedWire/ACH. Lot-level basis transferred via the receiving firm's CBRS (Cost Basis Reporting Service) interface. Receiving firm reflects positions in the customer's new account.
5. T+7+
   Post-settlement reconciliation
   Lot-level basis reconciliation can take additional days; some non-covered or pre-2011 lots may transfer with placeholder basis pending manual reconciliation.

Full vs. partial transfers

A full transfer moves every asset in the delivering account to the receiving firm; the delivering account is closed at settlement. A partial transfer moves a specified subset (specific positions, specified share counts, or specified dollar amounts) and leaves the delivering account open.

Partial transfers are the harder case to model because they introduce shape questions:

• By symbol or by lot? An ACATS partial-transfer request can specify "150 shares of VTI" without naming which lots. The delivering firm typically applies the same lot-relief method as a sale (FIFO by default, configurable). The platform initiating the transfer has to either (a) accept the delivering firm's lot selection, or (b) request specific-lot transfer if the delivering firm supports it.
• What about fractional shares? ACATS-DTC handles whole shares; fractional residuals are typically liquidated with cash sent separately. A partial transfer of "150 shares of VTI" from a position holding 150.34 shares produces 150 shares transferred plus a 0.34-share liquidation at the delivering firm with cash following the rest of the transfer.
• Cash component? Partial transfers can include cash, but the cash transfer is often gated on the security-transfer settlement; the cash arrives later than the securities.
• Corporate-action interaction? If a corporate action lands on a partially-transferred symbol during the settlement window, the action applies to the lots based on which firm holds them at the record date — which depends on the exact settlement timing.

In-kind lots and the basis-preservation contract

The most important property of an ACATS transfer is that securities move "in-kind" — the lots' acquisition dates, cost basis, and holding-period clocks all transfer with the shares. A 100-share lot of AAPL acquired 2018-05-15 at $42.50 transferred via ACATS retains its 2018-05-15 acquisition date and $42.50 basis at the receiving firm. Holding period continues; the 1-year-and-a-day mark for long-term capital gain treatment continues to count from 2018-05-15.

This basis-preservation contract is mediated by the Cost Basis Reporting Service (CBRS), a separate DTCC service that the delivering firm uses to push lot-level basis to the receiving firm. CBRS handles "covered" lots (acquired after the relevant phase-in dates) automatically; "non-covered" lots may transfer with no basis information, requiring the customer to provide documentation.

Synthetic test data needs to reflect this:

// Lot before transfer (delivering firm)
{
  "lot_id": "DELIV-L-2018-05-15-AAPL-001",
  "account_id": "ACCT-DELIV-001",
  "symbol": "AAPL",
  "shares": 100,
  "acquisition_date": "2018-05-15",
  "cost_basis_per_share": 42.50,
  "covered_status": "covered",
  "holding_period": "long",
  "wash_sale_disallowed": 0.00
}

// Same lot after ACATS transfer (receiving firm)
{
  "lot_id": "RECV-L-2018-05-15-AAPL-001",   // new id at receiving firm
  "account_id": "ACCT-RECV-001",
  "symbol": "AAPL",
  "shares": 100,
  "acquisition_date": "2018-05-15",          // unchanged
  "cost_basis_per_share": 42.50,             // unchanged
  "covered_status": "covered",
  "holding_period": "long",                  // unchanged
  "wash_sale_disallowed": 0.00,
  "transfer_history": [
    {
      "from_account": "ACCT-DELIV-001",
      "from_lot_id": "DELIV-L-2018-05-15-AAPL-001",
      "transfer_date": "2025-09-12",
      "transfer_method": "ACATS",
      "cbrs_transmission": "received"
    }
  ]
}

A test corpus that re-clocks the holding period at the transfer date — or that loses the original acquisition_date and replaces it with the transfer date — has a bug that will surface as wrong long-term/short-term classification on the next sale. This bug is invisible in mock data that doesn't include transfers and shows up in production within the first ACATS-tested customer.

The corporate-action-during-settlement window

The settlement window — typically 5 to 7 business days — is the part of the ACATS flow that most engines underhandle. During this window, the delivering firm still holds the assets but the customer has initiated an outbound transfer; the receiving firm has expectation of receiving the assets but doesn't hold them yet. Corporate actions that land in this window have to be assigned to one firm or the other based on the record date.

Realistic edge cases:

• Quarterly dividend ex-dates during settlement. The dividend is paid by whoever holds the asset on the record date. If the record date falls before settlement, the delivering firm receives the cash and forwards it (typically as a separate cash transfer; sometimes as a journal entry on the delivering account that has to be reconciled separately). If after, the receiving firm gets it directly.
• Corporate-action ex-dates during settlement. A 2-for-1 split during the settlement window changes the share count of the in-flight transfer. The receiving firm has to handle the share-count change correctly even though it didn't hold the position at the ex-date.
• Mergers and tender offers. A cash-merger close during the settlement window converts the in-flight position to cash. The cash component then has to settle through the cash-transfer rail, which may or may not be on the same timeline as the original securities-transfer.

Synthetic data has to include households with at least some transfers that intersect with corporate-action ex-dates during settlement — and the test platform's logic for tracking distribution-in-transit, share-count-change-in-transit, and merger-cash-in-transit has to be exercised.

Rejection codes — the part most engines skip

ACATS rejections come back in roughly 20 standard codes. The most common, and the ones a platform has to handle gracefully:

A platform tested only against successful transfers will fail on the first rejection in production. The test corpus has to include households where the initial transfer attempt is rejected, the platform handles the rejection correctly, the customer resolves the issue, and a resubmission succeeds — all within the 96-month longitudinal window.

What synthetic data has to look like

The minimum-viable test corpus for an ACATS-aware platform:

Each test case requires its own household shape — and a corpus that ships only with the happy-path full-transfer case will fail on production within days.

How this shows up in our catalog

The institutional bundles in the WealthSynth catalog include households with realistic ACATS history: roughly 8% of households have at least one prior account transfer in the 96-month longitudinal window, with a mix of full and partial transfers, in-kind lots preserving acquisition dates, and a small number of historical rejection-and-resubmit sequences. The lot-level data carries the transfer_history field shown above for any lot that originated at a different firm.

For the broader integration context, see Aggregator & Custodian Integration. For the corporate-action handling that interacts with the settlement-window edge cases, see Modeling corporate actions in synthetic portfolios. For the lot-level basis representation that ACATS preserves, see Lot-level basis tracking data model.