A TAMP is a multi-tenant data business. Advisor firms see only their own data; the TAMP sees everything — and needs a data layer powerful enough to handle both views simultaneously, at scale, without compromise.
A Turnkey Asset Management Program holds a unique position in the wealth management data ecosystem. Unlike an RIA that manages a single firm's data, a TAMP is managing data on behalf of dozens or hundreds of advisor firms simultaneously — each with their own accounts, sleeves, model assignments, and billing arrangements. The TAMP's internal team needs aggregate visibility across all firms. Each advisor firm needs isolated visibility into only their own data. Neither can compromise the other.
This multi-tenant data requirement — serve the whole and serve each part, with hard isolation — is precisely what Snowflake was built for. For the broader context of how Snowflake fits wealth management data infrastructure, see our Snowflake for Financial Services pillar.
Why TAMPs Need a Real Data Platform
Most TAMPs were built on legacy database architectures — a single Postgres or SQL Server instance, a reporting database fed by nightly batch jobs, and a set of advisor portals that pull from that reporting database. This architecture worked when a TAMP served twenty advisor firms. It breaks down at two hundred.
The Nightly Extract Problem
Legacy TAMP architectures rely on nightly extract jobs that pull position, performance, and billing data from the core system and push it to advisor-facing portals and reports. The result: advisor firms are always looking at yesterday's data. They cannot query live positions. They cannot run ad hoc performance analysis. They cannot access their own data programmatically. They are passengers in the TAMP's data workflow rather than active users of it.
Snowflake's data sharing model eliminates nightly extracts. Each advisor firm receives a live Snowflake share — a read-only view of their partition of the TAMP's production data. When the TAMP updates positions at 8 AM, the advisor firm's Snowflake queries reflect those positions at 8:01 AM. No extract job. No stale portal data. No manual report delivery.
The Multi-Tenant Isolation Challenge
Serving hundreds of advisor firms from a single database requires airtight data isolation. A TAMP cannot afford a query that accidentally returns another firm's account data. Legacy architectures address this through application-layer filtering — the portal software applies firm filters before showing data to users. This is fragile: a code change, a missed WHERE clause, or a misconfigured report template can expose one firm's data to another.
Snowflake enforces isolation at the warehouse level through row-level security policies and data sharing. A firm's Snowflake share physically cannot return rows for other firms — not because of application logic, but because of how the share is defined. This is a fundamentally more secure architecture than application-layer filtering. For more on Snowflake's data sharing model, see Snowflake Data Sharing for Wealth Management.
The TAMP Snowflake Architecture
A Snowflake-native TAMP architecture has three distinct layers: the ingestion layer, the multi-tenant data model, and the distribution layer. Each layer has a specific role and operates independently, which is what makes the architecture scalable.
Multi-Tenant Tables and RBAC by Firm
In a Snowflake TAMP architecture, accounts, positions, transactions, and performance records all live in shared tables with a firm_id partition column. Row-level security policies are defined in Snowflake to restrict query results based on the authenticated user's firm assignment. TAMP internal users see all rows. Advisor firm users — authenticated through Snowflake's role system — see only rows where firm_id matches their firm.
This approach is dramatically simpler than maintaining separate database schemas or separate tables per firm. Adding a new advisor firm is a configuration change — create a role, assign the firm RBAC policy, provision the Snowflake share — not a schema migration. TAMPs that previously needed weeks to onboard a new advisor firm to their data infrastructure can reduce that to hours.
Per-Firm Snowflake Shares
Snowflake's native data sharing allows the TAMP to provision a read-only share for each advisor firm. The share exposes a set of views — filtered to the firm's partition — that the advisor firm can query from their own Snowflake account or from any BI tool connected to Snowflake. The firm receives live data access without receiving a copy of the underlying data. If the TAMP revokes the share, access ends immediately.
Three Virtual Warehouses, One Data Layer
A well-architected TAMP Snowflake deployment uses three virtual warehouses: an ingestion warehouse (runs ETL pipelines from custodians and sub-advisors), an internal analytics warehouse (runs TAMP billing, compliance, and cross-firm reporting), and an advisor-share warehouse (serves advisor firm queries via Snowflake shares). Separating these workloads means advisor queries never compete with internal analytics, and heavy batch ingestion jobs never degrade query performance for either audience.
Sleeve-Level Attribution and Overlay Data
For TAMPs that manage model portfolios with sleeve structures, performance attribution at the sleeve level is the defining analytics challenge. Most TAMP reporting systems calculate performance at the account level and work backward to estimate sleeve-level contribution. This is a compromise — it produces approximate numbers, not precise attribution.
In Snowflake, sleeves are first-class entities in the data model. Each sleeve has its own position history, transaction log, and cost basis tracking. Performance attribution runs against actual sleeve-level data, not estimates. When a model overlay is applied — for example, a tax-loss harvesting overlay that modifies the underlying model positions — the overlay is tracked as a distinct layer in the data model, and attribution is calculated net of the overlay impact.
Model Overlay Tracking
A model marketplace TAMP maintains dozens or hundreds of model strategies, each potentially modified by firm-specific or account-specific overlays. Tracking these overlays in Snowflake means storing both the base model allocation and the overlay delta as separate records. Queries can then reconstruct the effective position at any point in time, report performance relative to the underlying model benchmark, and isolate the attribution impact of the overlay on overall returns.
This data structure enables analytics that legacy reporting systems cannot produce: which overlays are improving performance vs. dragging it, which advisor firms are most heavily using overlay customization, and which model strategies are performing best net of overlay impact across the entire book. For more on how Snowflake supports model marketplaces, see Snowflake Marketplace for Financial Data.
Sleeve-Level Position History
Every position recorded at the sleeve level with timestamp — enables precise period-over-period attribution without estimation.
Overlay Delta Tracking
Overlay modifications stored as separate records alongside base model allocations — reconstruct effective exposure at any date.
Benchmark Attribution
Model benchmark returns ingested alongside sleeve data — attribution calculated as a Snowflake join, not a spreadsheet formula.
Cross-Firm Sleeve Analytics
TAMP-internal queries can aggregate sleeve performance across all advisor firms — impossible with per-firm portal architecture.
Sharing Live Data With Advisor Firms
The most immediate operational benefit of Snowflake for a TAMP is the elimination of nightly extract workflows. Today, most TAMPs generate advisor-facing data through a batch process: positions and performance are calculated overnight, written to a reporting database or file system, and surfaced through a portal. Advisor firms log in to see a snapshot of yesterday's data.
Snowflake data sharing replaces this architecture. Each advisor firm receives a Snowflake share — a named, permissioned connection to a set of views in the TAMP's Snowflake account. Those views are live; they query the TAMP's production data in real time, filtered to the firm's partition. When a position updates, the firm's queries immediately reflect it. When the TAMP runs an intraday reconciliation, the advisor firm can see the reconciled data without waiting for a batch job to complete.
What the Advisor Firm Receives
An advisor firm connected to a TAMP via Snowflake share can query their own account data, position data, performance history, billing history, and model assignment history directly from Snowflake. They can connect Tableau, Power BI, Sigma, or any other BI tool to their Snowflake share and build their own analytics on top of the TAMP's data — without asking the TAMP to run custom reports or export data files. This is a meaningful upgrade in advisor firm autonomy and significantly reduces TAMP operational burden from custom report requests.
For advisor firms that are not Snowflake users themselves, the TAMP can front the share with a pre-built dashboard layer — Snowflake-connected Tableau or Sigma dashboards that present the firm's data in a structured interface. The share architecture is the same; the consumer of the share is the BI layer rather than the firm's own Snowflake account. See also: Snowflake for RIAs for how advisor firms use Snowflake on their end.
Model Marketplace + Overlay Data on Snowflake
A TAMP's model marketplace is both a product catalog and a data system. Models need to be discoverable, subscribable, and measurable — and the underlying performance data needs to be auditable. Snowflake handles all three dimensions.
Model Performance Data
Each model strategy in the marketplace has a performance history stored in Snowflake: daily NAV, time-weighted return, benchmark attribution, and risk metrics. When an advisor firm browses the marketplace, they query this performance data live from Snowflake — not from a PDF factsheet updated monthly. When a model's track record updates after market close, every advisor firm viewing that model's performance data sees the update immediately.
Model Assignment and Overlay Storage
When an advisor firm selects a model for a client account, that assignment is stored in Snowflake as a structured record: which model, which sleeve, effective date, override parameters, overlay rules. The TAMP's portfolio management system reads from this table to drive rebalancing. The TAMP's performance system reads from it to calculate benchmark-relative attribution. The TAMP's billing system reads from it to apply the correct management fee schedule. Snowflake becomes the operational record of truth for the model marketplace, not just a reporting database.
Snowflake's own Marketplace product also enables TAMPs to share model performance data externally — with Snowflake Marketplace, a TAMP can make curated model performance datasets available to third-party BI tools, fintech applications, or broker-dealer platforms without building a separate data distribution API.
Sub-Advisor Reconciliation
TAMPs that use sub-advisors for model management face a reconciliation challenge that compounds with each sub-advisor relationship. The sub-advisor manages positions and generates performance data according to their own systems and schedules. The TAMP must reconcile that data against its own position records, identify discrepancies, attribute them to timing or pricing differences, and produce a blended performance record for advisor firm reporting.
How Snowflake Handles Sub-Advisor Data
In a Snowflake-native architecture, sub-advisor data arrives through dedicated ingestion pipelines — typically SFTP file delivery or API connection — normalized into the TAMP's standard position and transaction schema. The sub-advisor's data lands in a staging table. Reconciliation logic runs as SQL transformations (or dbt models) that join the sub-advisor staging data against the TAMP's production position records, calculate variance by account and security, and flag discrepancies above a defined threshold for review.
This process runs on a schedule in Snowflake — triggered by the sub-advisor's data delivery, not by a manual analyst workflow. Reconciliation results are stored in Snowflake tables that feed exception dashboards for the TAMP's operations team. Sub-advisor reconciliation that previously required a dedicated analyst working through a custom spreadsheet process can run automatically, with the analyst reviewing only the flagged exceptions rather than the full reconciliation output.
| Dimension | Legacy Sub-Advisor Reconciliation | Snowflake-Native Reconciliation |
|---|---|---|
| Process | Manual spreadsheet comparison, analyst-driven | Automated SQL join + exception flagging |
| Frequency | Daily or weekly batch, manually triggered | Triggered on data delivery, continuous |
| Onboarding new sub-advisor | 2–4 weeks to build custom reconciliation workflow | Days to map to standard schema + activate pipeline |
| Audit trail | Spreadsheet versions, fragile and difficult to audit | Full row-level history in Snowflake with timestamps |
| Scalability | Each new sub-advisor adds headcount requirement | Each new sub-advisor adds configuration, not headcount |
Where Milemarker Fits
Milemarker is Snowflake-native and multi-tenant by design — it was built with the TAMP use case as a first-class requirement, not an afterthought. The Milemarker platform provides the ingestion layer, data model, and operational tooling that TAMPs need to run on Snowflake without building everything from scratch.
Pre-Built TAMP Data Model
Milemarker's TAMP data model includes first-class support for sleeves, model overlays, sub-advisor relationships, and advisor-firm partitioning. The schema is designed for Snowflake's row-level security and sharing architecture from the ground up — not adapted from a single-tenant model. TAMPs do not build the multi-tenant architecture; they configure it against Milemarker's pre-built model.
130+ Pre-Built Connectors
Milemarker's integration library includes pre-built connectors for the custodians, portfolio management systems, and CRMs that TAMPs and their advisor firms use: Schwab, Fidelity, Pershing, Altruist, Northern Trust, BNY Mellon, SS&C, Orion, Tamarac, Addepar, Black Diamond, Salesforce, Redtail, Wealthbox, and more. Adding a new custodian relationship or a new advisor firm's CRM is a configuration change, not a development project.
Milemarker augments the TAMP's existing technology stack rather than replacing it. Portfolio management systems, trading platforms, and advisor portals continue to operate as they do today — Milemarker adds the data layer underneath them, giving the TAMP a Snowflake-native foundation for analytics, advisor data sharing, and AI-ready data infrastructure. For a broader overview, see Data Platform for TAMPs. Implementation is faster than you expect — see Snowflake Implementation for Wealth Management for the full playbook.
Multi-Tenant Data Model
Advisor-firm partitioning and row-level security built in — not bolted on after the fact.
Live Advisor Sharing
Snowflake shares provisioned per advisor firm — replace nightly extracts with live data access.
Sleeve-Level Analytics
Sleeves as first-class entities in the data model — attribution runs against actual sleeve data, not account-level estimates.
Automated Reconciliation
Sub-advisor reconciliation logic runs on data delivery — analysts review exceptions, not full reconciliation output.