Sleeve-level performance, model overlays, sub-advisory attribution — shared live with advisor firms via Snowflake.

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.

Legacy TAMP Architecture

✕Single Postgres + nightly batch extract jobs

✕Advisor firms always see yesterday's data

✕Multi-tenancy enforced only at application layer

✕Cross-firm analytics run on the same DB as advisor queries

✕Sub-advisor reconciliation done manually in spreadsheets

✕Billing computed by nightly batch, difficult to audit

Snowflake-Native TAMP

✓Live data in Snowflake, shares update in near real-time

✓Advisor firms query live data via Snowflake share

✓Multi-tenancy enforced at warehouse level via RBAC + row security

✓Separate virtual warehouses for internal vs. advisor workloads

✓Sub-advisor reconciliation automated via Snowflake joins

✓Billing calculated on-demand from structured Snowflake tables

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.

Snowflake Architecture Pattern

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.

1

Unified data model across all advisor firms

3

Virtual warehouse tiers: ingest, internal, advisor

0

Nightly extracts needed for advisor data access

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.

01

Sleeve-Level Position History

Every position recorded at the sleeve level with timestamp — enables precise period-over-period attribution without estimation.

02

Overlay Delta Tracking

Overlay modifications stored as separate records alongside base model allocations — reconstruct effective exposure at any date.

03

Benchmark Attribution

Model benchmark returns ingested alongside sleeve data — attribution calculated as a Snowflake join, not a spreadsheet formula.

04

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.

Process

• Legacy Sub-Advisor Reconciliation: Manual spreadsheet comparison, analyst-driven

• Snowflake-Native Reconciliation: Automated SQL join + exception flagging

Frequency

• Legacy Sub-Advisor Reconciliation: Daily or weekly batch, manually triggered

• Snowflake-Native Reconciliation: Triggered on data delivery, continuous

Onboarding new sub-advisor

• Legacy Sub-Advisor Reconciliation: 2–4 weeks to build custom reconciliation workflow

• Snowflake-Native Reconciliation: Days to map to standard schema + activate pipeline

Audit trail

• Legacy Sub-Advisor Reconciliation: Spreadsheet versions, fragile and difficult to audit

• Snowflake-Native Reconciliation: Full row-level history in Snowflake with timestamps

Scalability

• Legacy Sub-Advisor Reconciliation: Each new sub-advisor adds headcount requirement

• Snowflake-Native Reconciliation: 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.

Frequently Asked Questions

How does Snowflake handle multi-tenancy for a TAMP serving hundreds of advisor firms?

Snowflake supports multi-tenant TAMP architectures through a combination of row-level security policies, role-based access controls, and Snowflake's native data sharing. Each advisor firm's data is stored in shared tables partitioned by a firm identifier, with row-level access policies enforcing that a given firm's users can only query their own rows. The TAMP retains full visibility across all firms for internal analytics, billing, and compliance. Advisor firms access their own data slice through a read-only Snowflake share — no nightly extract, no portal login, just a live query against their portion of the TAMP's production data.

Is it safe for a TAMP to share live Snowflake data with advisor firms?

Yes. Snowflake's data sharing model is designed precisely for this use case. When a TAMP shares a Snowflake view with an advisor firm, that firm gets query access to only the rows explicitly included in the share — the TAMP's row-level security policies enforce this at the warehouse level, not just in the application. The advisor firm cannot see other firms' data, cannot modify data, and cannot extract data outside of what the TAMP permits. Snowflake maintains a full audit log of all queries against shared data.

How does Snowflake handle sleeve-level attribution for model portfolios?

Sleeve-level attribution in Snowflake requires a data model that tracks each sleeve as a distinct unit within a household account, with its own cost basis, performance history, and model assignment. Milemarker's TAMP data model includes this structure: sleeves are first-class entities, model overlays are tracked as separate layers, and attribution is calculated against the sleeve-level position history rather than at the account level. This enables TAMPs to report sleeve-level returns, attribution vs. model benchmark, and overlay impact without manual spreadsheet assembly.

How should a TAMP bill advisor firms for Snowflake access?

Snowflake costs for TAMPs are driven by compute (query volume) and storage (data size). For advisor-facing data shares, the querying compute is billed to the querying party — if an advisor firm runs queries against a TAMP's Snowflake share using their own Snowflake account, they pay for the compute. If the TAMP provides a portal or BI layer on top of the share, the TAMP's warehouse handles query compute. Storage costs scale with the total data volume across all advisor firms. Most TAMPs fold Snowflake infrastructure costs into their technology fee or platform fee structure rather than billing individual advisor firms directly.

How does Snowflake support sub-advisor reconciliation for TAMPs?

Sub-advisor reconciliation requires matching TAMP-level position and transaction records against sub-advisor-provided data, then attributing performance differences to timing, pricing, or allocation decisions. In Snowflake, this is a join problem: the TAMP's normalized position data and the sub-advisor's delivered data both land in Snowflake tables, and reconciliation logic runs as SQL queries or dbt models. Milemarker's TAMP data model includes pre-built reconciliation schemas that reduce sub-advisor onboarding from weeks to days.

Can a TAMP use Snowflake to power a model marketplace?

Yes. A model marketplace on Snowflake stores model definitions, asset allocations, and historical model returns as structured data in Snowflake tables. Advisor firms browsing the marketplace query model performance data from Snowflake in real time — not from a stale report PDF or a portal with a 30-day delay. When an advisor selects a model, the model assignment is written back to Snowflake and triggers the TAMP's overlay and rebalancing workflows. Snowflake's Marketplace product also supports sharing model data externally to third-party platforms.

What query performance can a TAMP expect when running cross-firm analytics on Snowflake?

Snowflake's query performance scales independently of data volume through virtual warehouse sizing. A TAMP running cross-firm AUM rollups, compliance sweeps, or billing calculations can use a dedicated virtual warehouse for these workloads — separate from the warehouse serving advisor-facing queries — so internal analytics do not impact advisor data access. Cross-firm queries across hundreds of advisor firms and millions of positions typically run in seconds to minutes on an appropriately sized Snowflake warehouse, compared to hours or overnight batch jobs on legacy on-prem databases.

How does Milemarker fit into a TAMP's Snowflake architecture?

Milemarker is Snowflake-native and multi-tenant by design, built specifically for the TAMP use case. Milemarker provides pre-built connectors for custodian feeds, CRM systems, and portfolio management tools — normalized into a TAMP-specific data model that includes sleeve structures, model overlays, and advisor-firm partitioning. The platform manages pipeline operations, data quality monitoring, and schema evolution, so the TAMP's team focuses on analytics and advisor service rather than data engineering.

RELATED RESOURCES

Pillar Snowflake for Financial Services & Wealth Management By Segment Snowflake for RIAs By Segment Snowflake for Broker-Dealers By Segment Snowflake for Family Offices Data Sharing Snowflake Data Sharing for Wealth Management Architecture Wealth Management Data Lakehouse

Related guides

Part of the Snowflake for Wealth series:

• Snowflake for Financial Services & Wealth Management

• Migrating from On-Prem to Snowflake

• Snowflake vs Databricks for Financial Services

• Snowflake Cortex for Financial Services. AI Where Your Data Already Lives.

• Snowflake for RIAs

• Implementing Snowflake at a Wealth Firm: 8 Weeks vs 18 Months