Custodians, TAMPs, sub-advisors, fund admins — share live data without copying. The reconciliation work goes away.

Snowflake Data Sharing lets two Snowflake accounts share live, governed datasets without copying or moving data. The recipient sees a read-only view that is always current — no exports, no pipelines, no reconciliation against stale files.

This page is part of Milemarker's Snowflake cluster for financial services. See the Snowflake for Financial Services pillar for the full landscape, or jump to related capabilities: Cortex AI and Marketplace data.

Why Data Sharing Matters in Wealth Management

Wealth management runs on inter-firm data exchange. Custodians send position and transaction data to RIAs. TAMPs distribute portfolio data to their advisor networks. Sub-advisors receive model attribution from asset managers. Fund administrators feed NAV and holdings data to fund sponsors. In almost every case, that exchange still happens over FTP or SFTP — a protocol designed in 1971 that was never intended to carry the volume, frequency, or regulatory weight of modern financial data.

The FTP/SFTP Problem

FTP-based data delivery is not just inconvenient — it is structurally expensive. Every file drop creates a reconciliation obligation. The receiving firm must ingest the file, validate it, reconcile it against yesterday's file, flag discrepancies, and investigate exceptions. When the file arrives late, is formatted inconsistently, or contains data that doesn't match the receiving firm's records, a human being investigates. The same cycle repeats the next business day.

Industry estimates suggest that back-office teams at mid-size RIAs and TAMPs spend 15 to 25 hours per month per data relationship on file-based reconciliation. A firm with ten custodian or provider relationships spends 150 to 250 hours monthly on work that produces no analysis — it just gets data to a state where analysis can begin. That is the reconciliation tax.

Freshness as a Compliance Issue

File-based data is stale by definition. A file delivered at 7 AM reflects positions as of the prior business day's close. Any trades, corporate actions, or cash events that occur between that close and the time an analyst queries the data are invisible. For compliance monitoring, this lag is not just inconvenient — it means that a portfolio drifting outside its investment policy statement boundaries may not be detectable until the next day's file arrives. Snowflake Data Sharing eliminates that lag: shared data is current to whenever the provider last updated their warehouse, typically intraday.

0

Data copies created by a Snowflake share — the consumer reads from the provider's storage directly

Seconds

Latency between a provider update and consumer visibility — not hours or days

Instant

Share revocation — providers can remove access at any time with immediate effect

What Data Sharing Replaces

Nearly every inter-firm data relationship in wealth management is a candidate for replacement with a Snowflake share. The following are the highest-value substitutions.

Custodian to RIA

• Current Mechanism: Nightly FTP files (positions, transactions, account balances)

• With Snowflake Data Sharing: Live shared views updated intraday; RIA queries on demand

TAMP to advisor firm

• Current Mechanism: Scheduled CSV drops per advisor; manual assembly by back office

• With Snowflake Data Sharing: Per-advisor share with row-level filtering; advisor queries their data directly

Sub-advisor to asset manager

• Current Mechanism: Quarterly attribution data dumps via secure email or SFTP

• With Snowflake Data Sharing: Continuous share of composite performance and attribution; sub-advisor queries live

Fund admin to fund sponsor

• Current Mechanism: Static NAV reports delivered by email; monthly reconciliation calls

• With Snowflake Data Sharing: Shared NAV and transaction tables; sponsor queries directly for any date range

RIA to home office

• Current Mechanism: Manual aggregation reports submitted on a schedule

• With Snowflake Data Sharing: Home-office share with read access to consolidated household and AUM data

M &A diligence

• Current Mechanism: Data room files, stale as of export date

• With Snowflake Data Sharing: Time-limited share of live operational data; acquirer queries current state

How Snowflake Data Sharing Works in Practice

Snowflake Data Sharing is built on a single architectural insight: in a cloud object storage model, there is no technical reason to copy data when two accounts want to share it. If both accounts have permission to read the same storage location, the data can be made available without movement. Snowflake implements this through its shared metadata layer, which allows one account to grant another account access to specific objects in its storage.

Technical architecture

Provider grants. Consumer mounts. No movement.

The provider creates a Share object in their Snowflake account and adds database objects to it — tables, views, or secure views. They then grant the share to one or more consumer account identifiers. On the consumer side, the share appears as a read-only database that the consumer can query like any other database in their account. No data has been copied. The consumer's queries execute against the provider's storage.

For wealth management implementations, the recommended pattern is to share secure views rather than raw tables. Secure views allow the provider to enforce row-level filtering at the SQL layer — each consumer share surfaces only the rows that belong to that consumer's relationship. A custodian sharing to 200 RIAs does not create 200 separate shares; they create one share per consumer with the filtering logic embedded in the view definition.

RBAC at the Column Level

Snowflake's role-based access control extends to column masking within shares. A provider can share a view that includes sensitive fields — Social Security Numbers, account numbers, beneficiary information — while applying masking policies that render those columns as nulls or hashed values for the consumer. The consumer sees the data structure and can join against it, but cannot read the sensitive values. This makes Snowflake sharing usable for regulatory data that cannot be fully disclosed to counterparties.

Governance Across the Share

Every query made against a shared dataset is logged in Snowflake's Access History. The provider can audit exactly which queries the consumer has run, which rows were accessed, and when. This audit trail is available without any configuration — it is a built-in capability of the Snowflake platform. For financial services firms subject to regulatory examination, this provides documentary evidence of data governance that FTP-based distribution cannot supply.

Listings and Private Listings

For providers who want to share data with a defined set of counterparties rather than the general public, Snowflake offers Private Listings. A TAMP or custodian can create a Private Listing of their data product — documenting the schema, the refresh cadence, and the terms of access — and distribute it to specific Snowflake accounts. This creates a structured, auditable distribution channel that replaces ad-hoc file-sharing arrangements. The broader Snowflake Marketplace is also an option for providers who want to reach the entire Snowflake ecosystem; see the Snowflake Marketplace for Financial Data page for detail on that option.

Real Wealth-Management Use Cases

Custodian to RIA

A major custodian shares intraday positions and settled transactions directly to an RIA's Snowflake warehouse. The RIA's portfolio management system reads from the share rather than waiting for an overnight file. Reconciliation exceptions drop to near zero because there is no file to misparse.

TAMP to Advisor Firm

A TAMP serving 300 advisory firms configures per-advisor Snowflake shares. Each advisor's analytics team connects their BI tool directly to their share and builds dashboards against live data. The TAMP's back office stops producing weekly data extracts for each relationship.

Sub-Advisor to Asset Manager

A sub-advisor managing model portfolios within a larger asset manager's lineup shares composite performance, attribution breakdowns, and daily risk metrics directly into the asset manager's Snowflake. Quarterly attribution reconciliation calls are replaced by live SQL queries against the share.

Fund Admin to Fund Sponsor

A fund administrator shares daily NAV calculations, subscription and redemption activity, and investor-level allocation data directly to the fund sponsor. The sponsor's finance team queries any date range on demand rather than requesting custom reports from the administrator.

RIA to Home Office

A large RIA enterprise shares consolidated household AUM, client demographics, and advisory relationship data to its home office for aggregated planning and compliance monitoring. Each affiliate sees only their own book; the home office sees everything. Row-level security in the shared view enforces the boundary.

M&A Due Diligence

An acquirer conducting diligence on a target RIA receives a time-limited Snowflake share of operational data — client counts, AUM by advisor, revenue by relationship — that reflects the current state of the business. The acquirer's analysts query live data rather than reviewing a data room of stale exports. The target revokes the share the moment diligence concludes.

FTP-Feed Model vs. Snowflake-Share Model

Data freshness

• FTP-Feed Model: Stale to prior close or prior day; freshness constrained by export schedule

• Snowflake-Share Model: Current as of provider's last warehouse update; intraday freshness achievable

Ops cost

• FTP-Feed Model: High — file ingestion, validation, reconciliation labor per relationship per cycle

• Snowflake-Share Model: Near zero — no ingestion pipeline; consumers query the provider's storage directly

Security model

• FTP-Feed Model: File in transit encrypted; file at rest on consumer infrastructure of unknown security posture

• Snowflake-Share Model: Data never leaves provider's SOC 2 environment; consumer access governed by Snowflake RBAC

Reconciliation

• FTP-Feed Model: Required every cycle; multiple FTE-hours per relationship per month

• Snowflake-Share Model: Eliminated — consumer reads the same data the provider operates from

Audit trail

• FTP-Feed Model: File delivery logs only; no record of what consumer did with the data

• Snowflake-Share Model: Full query-level audit in Snowflake Access History; provider can see every consumer query

Revocation

• FTP-Feed Model: Cannot revoke a file already delivered; requires legal or contractual remedies

• Snowflake-Share Model: Immediate — provider revokes share and consumer loses access within seconds

Column-level control

• FTP-Feed Model: File contains all fields; recipient can read everything in the file

• Snowflake-Share Model: Column masking policies can hide or hash sensitive fields while preserving joinable structure

Where Milemarker Fits

Milemarker's Snowflake-native data model is designed to consume shared datasets natively. When a custodian or TAMP shares data to a Milemarker-powered Snowflake account, the incoming share maps directly into Milemarker's normalized wealth management data model — accounts, households, positions, transactions, advisors — without a separate transformation layer. The firm does not need to write ingestion code for shared data any more than they need to write ingestion code for their own warehouse tables.

This matters operationally. Firms that use Milemarker's 130+ integration library to connect to custodians and portfolio systems typically use those integrations for the normalized structured data — the standardized version of whatever the source system produces. When a provider offers a Snowflake share directly, Milemarker can route that share into the same normalized layer, giving the firm one data model regardless of how the underlying data arrived.

Navigator and Shared Data

Milemarker Navigator — the AI agent layer that runs inside Snowflake — can operate over shared datasets the same way it operates over natively ingested data. An advisor at Flat Iron Wealth, for example, whose TAMP distributes portfolio data via Snowflake share, can ask Navigator a natural-language question about their client portfolios and get an answer drawn from the live shared data, not a cached extract. The AI agents in wealth management use case is only viable if the underlying data is current — which is exactly what data sharing provides.

01

Native Share Consumption

Incoming Snowflake shares map directly into Milemarker's normalized data model without custom transformation code.

02

Share Configuration

Milemarker assists firms in configuring outbound shares to advisors, sub-advisors, or home offices as a platform capability, not a custom engineering engagement.

03

RBAC Implementation

Row-level security and column masking policies are configured as part of Milemarker's data model deployment, covering both natively ingested data and incoming shares.

04

AI Over Shared Data

Navigator AI agents can query shared datasets using the same governance framework as the firm's own data — no separate pipeline or copy required.

Milemarker's role is The Infrastructure for Wealth — providing the layer that makes Snowflake immediately productive for wealth management analytics, whether data arrives from native integrations, shared views, or Marketplace datasets. Learn more at the Snowflake for Financial Services overview or explore Snowflake for TAMPs and Snowflake for RIAs.

Frequently Asked Questions

Is Snowflake Data Sharing secure for financial services firms?

Yes. Snowflake Data Sharing does not copy or move data — the consumer account queries data that physically remains in the provider's Snowflake account. All access is governed by Snowflake's role-based access control (RBAC), enforced at the column and row level. Providers retain full control and can revoke access at any time. Audit logs capture every query made against a shared dataset. Snowflake maintains SOC 2 Type II certification and supports encryption at rest and in transit, making it appropriate for regulated financial data under GLBA, SEC, and FINRA requirements.

Who pays for compute when querying a Snowflake share?

The consumer pays for compute when they query the shared data. The provider pays only for storage. This billing model means that sharing data at scale does not create an unbounded cost for the provider — each consumer's queries consume that consumer's own Snowflake credits. Storage costs remain with the provider's account, so the cost of sharing is proportional to data volume, not to how frequently consumers query.

How does versioning work with Snowflake Data Sharing?

Snowflake Data Sharing surfaces the live, current state of the shared objects. Consumers always see the most recent data; there is no file-based versioning. Providers who need historical states can use Snowflake Time Travel to query prior snapshots, and can expose historical data through shared views if needed. The absence of file versioning is an advantage: the reconciliation overhead caused by different parties holding different file versions disappears entirely.

Can the data provider revoke a share after granting it?

Yes. The provider retains full control and can revoke or modify a share at any time. Revocation is immediate — the consumer loses access as soon as the provider removes the grant. Providers can also modify the share to add or remove objects, adjust row-level filters, or change column-level access grants without any action required from the consumer. This makes Snowflake Data Sharing significantly more controllable than file-based distribution, where a sent file cannot be recalled.

What is the latency of shared data — how current is it?

Shared data reflects the provider's current data state, with latency measured in seconds to minutes depending on how the provider's pipelines are structured. If the provider updates daily, consumers see daily data. If the provider runs near-real-time pipelines, consumers see near-real-time data. The share itself introduces no additional latency — consumers are querying the provider's storage directly, not a copy.

Does the consumer need a Snowflake account to receive a share?

For direct account-to-account sharing, yes — the consumer needs their own Snowflake account. For broader distribution, Snowflake offers Reader Accounts, which the provider creates and administers on behalf of consumers who don't have Snowflake accounts. Reader Accounts allow firms to extend data access to advisors or partners not yet on Snowflake, with the provider managing the account and paying for that consumer's compute.

What types of data relationships in wealth management benefit most from Snowflake sharing?

The highest-value use cases are those with frequent, high-volume data exchange between firms: custodian-to-RIA account data, TAMP-to-advisor portfolio data, sub-advisor-to-asset-manager model performance, fund-admin-to-fund-sponsor NAV and transaction data, and home-office-to-affiliate reporting. Any relationship where data currently travels as FTP files, scheduled CSV drops, or PDF reports is a candidate for replacement with a live Snowflake share.

Can Snowflake Data Sharing work across cloud providers or regions?

Yes. Snowflake supports cross-cloud and cross-region sharing through its replication and data sharing features. A provider on AWS us-east-1 can share data with a consumer on Azure eastus2, for example. There may be additional latency and storage replication costs for cross-region shares, but the consumer experience is identical — they query a share in their region that reflects the provider's current data.

RELATED RESOURCES

Pillar Snowflake for Financial Services & Wealth Management Capability Snowflake Cortex for Financial Services: AI Where Your Data Already Lives Capability The Snowflake Marketplace for Financial Data: What's Actually Useful Segment Snowflake for TAMPs Segment Snowflake for RIAs Cross-Cluster AI-Ready Data for Wealth Management Cross-Cluster Wealth Management Data Platform Implementation Snowflake Implementation for Wealth Management

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