Integration as a Compounding Asset

A serial acquirer of independent advisory firms sells one thing: a common operating system for advice and private market access. It scales by acquiring firms in the $250M to $1.5B band against an ambition well beyond its current base.

Those two facts meet in one place. Every acquisition arrives on a different stack, and until that stack resolves, the acquired book cannot use the operating system the acquirer is selling.

I have run this from the inside. At Commas, acquired by Truepoint, I led the merger integration and trained more than fifty associates through the transition to new advisory processes. That experience shapes this more than anything else in my background.

The playbook covers what the platform does. This covers why it is worth building and what I would do first.

Integration cost is treated as overhead. It should be treated as an asset that appreciates.

The default is per-deal. Each acquisition is scoped, staffed, and executed as its own project, and cost per integration stays flat or rises as targets get more complex. Integration becomes a tax on inorganic growth.

The alternative is a connector library and a canonical data layer. Map a source system once and every future target running it integrates against work already done. Marginal integration time falls as coverage grows.

For one acquisition, not worth building. For fifteen to thirty, it is the difference between a growth model that scales and one that grinds.

There is independent support for this. Serial acquirers typically see cycle times compress 30 to 40 percent by the third transaction on a repeatable process. That compression is the return on building the system rather than staffing each deal.

Three consequences follow, and they are three arguments for the same investment.

• Cost falls. Days and dollars per integration decline as coverage grows.
• An asset forms. A connector serving one deal is a cost. The same connector serving six is infrastructure. That changes both the build-versus-buy answer and how the spend should be accounted for.
• Risk drops. Acquiring an RIA means inheriting their data map, vendor inventory, and access posture, along with the obligation to explain all three. A canonical layer with documented lineage produces that documentation as a byproduct rather than as a separate project.

The regulatory floor moved recently. 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. FINRA's 2026 oversight report added a standalone section on generative AI. Both assume a firm can say where client data lives, which systems and vendors touch it, and how any AI tool interacts with it.

For an acquirer, that obligation transfers at close, and it transfers in worse condition than the rest of the target's operations.

Every firm in the $250M to $1.5B band has advisors using AI. Some of it is sanctioned. Much of it is an advisor pasting meeting notes into a consumer chatbot, running a client email through a summarizer, or using a tool their vendor added without announcement. Each of those is a service provider relationship touching client data, and almost none of them are documented.

At close you acquire that exposure, including anything that already left the perimeter. Current diligence asks about custodians, CRM, and portfolio accounting. It does not ask which AI tools have touched client records, under what terms, or whether the data was retained for training.

Two implications.

• Add it to diligence. A short inventory of AI tools in use, sanctioned and shadow, with data handling terms. It costs almost nothing and it is the difference between inheriting a known exposure and an unknown one.
• Solve it structurally, not by policy. A firm-owned data warehouse with a governed AI layer means every model call runs through a logged, permissioned interface. Acquired advisors get a sanctioned tool that is better than what they were using, which is the only reliable way to end shadow usage. Whatever the tool is, the access is scoped and the call is recorded.

The work that makes a firm examinable is the same work that makes it AI-ready. Firms treating them as separate projects pay for the same thing twice.

Counsel owns how the rules apply. This is the environment underneath, so the answer can be produced when asked.

Usually framed as one decision. It is three.

Connectors: buy where they exist, build where they matter. Data aggregation vendors and iPaaS platforms cover parts of the advisor stack. Where a vendor connector is mature and the system is common, buy it. The connector is not a differentiator.

Where a system is common among targets and no good connector exists, build it, because that build is reusable across every future deal running it. The test is not whether it is cheaper today. It is how many prospective targets run the system.

Canonical model: always build, always own. This cannot be bought, because it encodes decisions specific to the firm. How households are defined. How cost basis is treated. How fee schedules resolve. What an account means across four portfolio accounting systems.

It is also the only layer that survives changing every other component. A firm that rents its canonical model has rented its data.

Presentation layer: build. Advisor, client, and internal experiences built on the canonical model can change without touching anything below them. This is where differentiation lives and where vendor lock-in costs the most.

The principle underneath all three: you cannot standardize on one vendor's ecosystem when every acquisition arrives on a different stack. Vendor independence is not a preference for a serial acquirer. It is the only structure under which acquisitions compose rather than accumulate.

The sequence depends on what already exists. This is the shape, not a plan.

Days 1 to 30. Establish the baseline. Inventory the current approach across completed and in-flight deals. Interview the people who ran the last two integrations, not the people who managed them. Build the source system inventory across the pipeline and the target market.

Instrument what is not measured today: days to full integration, cost in basis points of acquired AUM, retention through transition, NIGO rate, and time from close to first private markets allocation. None of the arguments here can be defended without these.

Days 31 to 60. Sequence the build. Rank unbuilt connectors by prevalence among prospective targets multiplied by days saved per deal. Decide build versus buy against that ranking rather than against the current deal.

Define the canonical model for the two entities that cause the most pain. Draft the standard playbook from what the last two integrations actually did, not from a template.

Days 61 to 90. Prove it on one deal. Run the next integration against the playbook with instrumentation live. Ship readiness scoring into diligence, even as a spreadsheet. One deal with real numbers beats a roadmap.

This is an outside-in view built from public materials. The four things most likely to be wrong:

• The connector economics may be smaller than modeled. Reuse assumes canonical mappings hold across firms running the same system. Configuration differences within a single vendor's product can eat much of that. The curve is real. Its slope is not knowable from outside.
• Parallel-track execution may account for more of the savings than connectors do. Firms running compliance, technology, and repapering simultaneously under one integration lead close far faster than firms running them sequentially, independent of tooling. If the acquirer already runs parallel tracks, the marginal return on connectors is lower than modeled. If it does not, that is the cheaper fix and it should come first.
• The acquirer may already have more of this than an outside view can see. If a playbook and data layer exist, the priority shifts from building to instrumenting and standardizing, which is a materially different ninety days.
• Diligence scoring may be organizationally harder than it is technically. Introducing a product-owned input into deal valuation requires the deal team to want it. That is a relationship problem, not a modeling problem.

The prototype has no authentication, no persistence, and no real integrations. Single-tenant, desktop only, fictional data. The AI plan generator runs on a cached response. The logic is specified but not wired to a live model, because a demo that can fail in front of a CTO is worth less than one that cannot.

With a real team, the first two things I would build are the instrumentation layer and the canonical model for two entities. Everything else is a view over those, and views are cheap once the foundation is right.