Integration Operating Playbook
How instrumentation changes six decisions in an RIA acquisition.
Brandon Bennett · August 2026
What I built
A working prototype of an integration platform for a firm that acquires RIAs, plus this document and a short memo.
The prototype covers four acquisitions at different stages: one complete, one mid-integration, one signed pre-close, one in diligence. It has a firm workspace with eight workstreams, dependencies, and risk flags. A connector library and canonical data model. An AI plan generator that builds a tailored integration plan from a target's profile. Screens for integration economics, diligence readiness, and data lineage.
Everything is built from public materials. All firm names, advisors, and client data are fictional. Financial and regulatory terminology is real and worth checking.
Why I built it
The workstreams in an RIA integration are known, and you have run them. What is usually missing is the data to sequence them, price them, and prove them. Most integration work is tracked in spreadsheets that die with the deal, which means each acquisition starts closer to zero than it should.
The argument is that integration is not overhead. Built once and instrumented, it is an asset that appreciates with every deal. For a firm making one acquisition that is not worth building. For a firm making fifteen to thirty, it is the difference between a growth model that scales and one that grinds.
How to read this
Six sections, one per decision in a deal, from pricing a target through proving the integration happened. Each follows the same structure: the decision, what is usually visible when you make it, what the platform shows instead, and what changes as a result.
Each section names the screen it maps to. You can read this alongside the prototype or on its own.
Figures are from sample data and illustrative. The structure is the argument. The numbers need your completed deals to calibrate.
1.Pricing a target
The decision: what to offer, and what integration will cost.
What is usually visible: AUM, revenue, advisor count, book quality. Integration cost is a post-close discovery, absorbed as a cost of doing business.
What the platform shows: a readiness score per target, derived from source system coverage against the existing connector library. Custom build days, integration cost, and cost expressed in basis points of acquired AUM.
What changes: two targets of identical size do not cost the same to integrate. In the sample, the spread between highest and lowest readiness is 38 days and $111,000, roughly 0.9 basis points of acquired AUM. That is a number the deal team can price rather than absorb.
It also reframes some spend. A connector built for a target that seven other prospects also run is not a deal cost. It is platform investment that happens to be triggered by this deal.
2.Building the plan
The decision: what this specific integration requires, and how long it takes.
What is usually visible: the standard playbook, adjusted by whoever ran the last one, in a spreadsheet.
What the platform shows: a generated plan that diffs the target's profile against the standard baseline. Source systems, custodian, structure, and book profile in. Tailored task list, effort estimate, gap analysis, and stated assumptions out. Every generated task is tagged so playbook baseline stays distinguishable from tailored addition.
What changes: the plan starts from institutional memory rather than the last person's memory. The gaps are explicit and reviewable before work starts, rather than surfacing in week six.
The model states confidence and assumptions. Low confidence on a thin profile is more useful than a plan that sounds certain.
3.Running the integration
The decision: what is actually at risk this week.
What is usually visible: percent complete by workstream, which tells you almost nothing. A workstream at 60 percent with its critical dependency blocked is in worse shape than one at 20 percent running clean.
What the platform shows: dependency-aware status. Blocked tasks with what blocks them. Critical path on the timeline. Risk flags tied to specific tasks rather than floating as commentary.
What changes: in the sample mid-integration firm, one blocked task, custodian master account approval, threatens the target date while four workstreams show healthy percentages. That is invisible on a status report and obvious on a dependency map.
Worth instrumenting specifically, because they are the largest recoverable delays:
- NIGO rejection rate, which runs 15 to 20 percent on manually completed forms at three to five business days per cycle
- Signature collection aging, which adds two to three weeks when unowned
- Consent response rate tracked weekly against close
4.Converting the book
The decision: when the acquisition starts producing private markets revenue.
What is usually visible: the deal model's synergy assumption, revisited at the annual review.
What the platform shows: accreditation status across the acquired book, eligible AUM, current allocation against target sleeve by advisor, implied allocation, and the contribution that represents against modeled synergy. Plus advisors not yet certified on the products.
What changes: the gap between the deal model and reality becomes visible in month two rather than month twelve.
Two things surface consistently:
- Accreditation data is the constraint, not advisor willingness. Acquired books arrive with large unverified populations. In the sample diligence-stage firm, half the households have unknown status. Applying the verified population's eligibility rate to the unverified one roughly doubles the eligible book. That is a data exercise that can start before close.
- Certification gates everything. Advisors who have never allocated to private markets do not start because a sleeve target exists.
Worth tracking as a first-class metric: time from close to first funded subscription. It connects integration speed to revenue and almost nobody measures it.
5.Sequencing the build
The decision: which connector to build next.
What is usually visible: whatever the current deal needs.
What the platform shows: connector coverage by category, unbuilt connectors ranked by prospective targets running each system multiplied by days saved per deal, and the resulting economics across the acquisition history.
What changes: the build order stops being deal-driven and becomes portfolio-driven. A connector serving one deal is a cost. The same connector serving six is infrastructure.
The compounding is measurable. Across the sample, days saved per acquisition grow from 25 to 56 as coverage builds. Extended across twenty integrations at current coverage, that is roughly 780 days.
Two caveats worth stating. Reuse assumes canonical mappings hold across firms running the same system, and configuration differences can eat part of that. And parallel-track execution accounts for a meaningful share of the reduction independent of connectors. The curve is real. Its exact slope needs your own completed deals to calibrate.
6.Proving it happened
The decision: can the firm explain where acquired client data lives, which systems touch it, and how any AI tool interacts with it.
What is usually visible: a documentation project, run separately, after the fact. Diligence covers custodians, CRM, and portfolio accounting. It rarely covers which AI tools advisors have been using with client records.
What the platform shows: documentation readiness per firm. Data map completeness, vendor inventory status, systems holding client data, access audit coverage, and days to examinable.
What changes: mapping every source system into the canonical model already records where each field originated, how it was transformed, and which system holds the authoritative copy. That record is the data map. Connector configuration is the service provider inventory. Credential sets are the access record.
The documentation accumulates as a byproduct of integration rather than being reconstructed afterward. An acquired book is examinable at close instead of nine months later.
The inherited exposure. Amended Regulation S-P reached its compliance date for smaller advisory firms in June 2026, requiring documented data mapping, service provider oversight, and incident response records. That obligation transfers at close.
Every target has advisors using AI, and much of it is unsanctioned: meeting notes pasted into a consumer chatbot, client emails run through a summarizer, a tool a vendor added without announcement. Each is a service provider relationship touching client data. Almost none are documented, and you cannot oversee what you have not inventoried.
Two responses. Add an AI tool inventory to diligence, sanctioned and shadow, with data handling terms. Then solve it structurally: a governed AI layer means every model call is scoped, permissioned, and logged, and acquired advisors get a sanctioned tool better than what they were using. That is the only reliable way to end shadow usage.
Counsel owns how the rules apply. This is the environment underneath, so the answer can be produced when asked.
What to measure
Completion percentage is not a metric. These are:
| Metric | Why |
|---|---|
| Days to full integration | The baseline everything else moves |
| Integration cost in bps of AUM | Comparable across deal sizes |
| NIGO rate | Largest recoverable delay in custodial |
| Client retention 90 days post-cutover | Where transition damage shows |
| Advisor retention at 12 months | Where deal thesis damage shows |
| Connector reuse rate | Whether the platform is compounding |
| Time to first allocation | Connects integration speed to revenue |
Most integration teams track the first one. Few track the last one.
Architecture underneath
Source systems feed integration pipes. Pipes land in a firm-owned data warehouse on a canonical model. Applications read from the warehouse. The AI layer reads and writes alongside them and is interchangeable.
The reason this matters for a serial acquirer: you cannot standardize on one vendor's ecosystem when every acquisition arrives on a different stack. The canonical model is the only layer that survives changing everything else. A firm that rents it has rented its data.
Most interactions run through the AI layer. Certified, repeatable, and regulatory outputs query the warehouse directly, because those need to be reproducible.