Moving a book is two jobs, and only one of them is ours today.

Moving a book onto a new platform is two separate problems that get conflated constantly. One is moving records — who the accounts belong to, what the cost basis is, what happened in them historically. The other is moving assets, which is an ACATS transfer between regulated custodians. Interpose does the first with you today. It cannot do the second and will not before FINRA approval.

The first is also not a self-serve endpoint, and this page is not the “how to script your own migration” page you might be expecting. Bringing a book across is an assisted process we run with you during onboarding: you supply the position and lot export you already download from your custodian, we map it, we dry-run it, and we reconcile a pilot batch against your statements before anything else moves. What follows is what that actually involves, so you can scope your side of it.

What actually moves

How a migration runs

The import endpoints are real and they are the ones we drive. They are also operator-gated: they mint active brokerage accounts and append to the immutable transaction ledger, so they require a credential we issue rather than the advisor login your sandbox signup returns. A portal login or a self-serve API key gets 403 on every BaaS path in this section. That is deliberate, not a permissions gap to route around. The Portfolio Management import routes below accept an ordinary advisor login — they build portfolios and models rather than minting accounts or writing to the ledger.

Every one of them takes canonical JSON — one documented record shape, whatever your data came from. There is no CSV parser and no file-upload path, so converting the custodian export into that shape is the work, and it is the part where an engagement earns its keep. Batches run inline and come back with a job that is already terminal, so polling is optional; the errors endpoint returns per-row failures indexed against your submitted array.

dry_run          # true first, always — validates every record, persists nothing
idempotency_key  # mandatory in practice on accounts and lots; a bare re-run duplicates them
as_of_date       # your cutover date, on the tax-lot batch — see below

The Portfolio Management side

Your model library, portfolios and prior return series come across separately, on Portfolio Management's own import surface:

The repeated pm segment is real, not a typo. Those routes declare /v1/migration/pm/… on the service, and the proxy rewrites /api/v1/pm/… to /v1/… — so the pillar segment and the route's own segment both survive into the public path. The same thing happens on PM's WebSocket path.

Cost basis is the part that hurts

Account numbers and balances are easy to move. A client's acquisition dates and lot-level basis are what determine their tax bill, and a migration that approximates them creates a problem you will be explaining to clients for years. So the honest split:

Reconstructing lots from a real buy history is accurate. Anything else is an approximation, and if your export has no buy history for a position the only available move is to use average cost as the price and the cutover date as the acquisition date. If that is where you end up: flag every approximated lot so it is distinguishable from a real one, correct it before the position is sold, and tell the advisor which positions are affected. An extra week extracting real acquisition data from the incumbent is cheaper than all three.

What we cannot tell you in advance

Two things are genuinely unknown until we look at your export, and we would rather say so than guess. The first is whether your custodian gives you lot-level acquisition dates at all — some exports carry them, some carry only an average cost and a position-level open date, and which one you have decides how much of the work is data recovery rather than mapping. The second is wash-sale and covered/non-covered status: the import accepts is_covered and a wash-sale adjustment per lot, but it carries across what you send and does not reconstruct either from history. If your incumbent does not report them per lot, that gap comes across with the book, and closing it is a decision to make deliberately rather than a field to fill in.

Verification is yours, and it is not optional

There is no post-migration reconciliation endpoint, no checksum comparison and no completion event. The job record and its error list are the only feedback the platform gives you, so reconciliation is a step in the plan rather than a thing the software does. For every migrated account, against the incumbent's closing statement at cutover: cash balance, lot count, total cost basis, summed lot quantities against the position report, and transaction count.

Do that on ten accounts before four hundred. The cost of finding a mapping error at ten accounts is an afternoon; at four hundred it is a data-correction project with client statements attached to it.

Starting one

Tell us what you are moving from and roughly how many accounts, and we will tell you what your export needs to contain and what the sequencing looks like for your situation. It is a real conversation with a real answer; it is just not an API call. Ask us.