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.
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.
| Data Relationship | Current Mechanism | With Snowflake Data Sharing |
|---|---|---|
| Custodian to RIA | Nightly FTP files (positions, transactions, account balances) | Live shared views updated intraday; RIA queries on demand |
| TAMP to advisor firm | Scheduled CSV drops per advisor; manual assembly by back office | Per-advisor share with row-level filtering; advisor queries their data directly |
| Sub-advisor to asset manager | Quarterly attribution data dumps via secure email or SFTP | Continuous share of composite performance and attribution; sub-advisor queries live |
| Fund admin to fund sponsor | Static NAV reports delivered by email; monthly reconciliation calls | Shared NAV and transaction tables; sponsor queries directly for any date range |
| RIA to home office | Manual aggregation reports submitted on a schedule | Home-office share with read access to consolidated household and AUM data |
| M&A diligence | Data room files, stale as of export date | 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.
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
| Dimension | FTP-Feed Model | Snowflake-Share Model |
|---|---|---|
| Data freshness | Stale to prior close or prior day; freshness constrained by export schedule | Current as of provider's last warehouse update; intraday freshness achievable |
| Ops cost | High — file ingestion, validation, reconciliation labor per relationship per cycle | Near zero — no ingestion pipeline; consumers query the provider's storage directly |
| Security model | File in transit encrypted; file at rest on consumer infrastructure of unknown security posture | Data never leaves provider's SOC 2 environment; consumer access governed by Snowflake RBAC |
| Reconciliation | Required every cycle; multiple FTE-hours per relationship per month | Eliminated — consumer reads the same data the provider operates from |
| Audit trail | File delivery logs only; no record of what consumer did with the data | Full query-level audit in Snowflake Access History; provider can see every consumer query |
| Revocation | Cannot revoke a file already delivered; requires legal or contractual remedies | Immediate — provider revokes share and consumer loses access within seconds |
| Column-level control | File contains all fields; recipient can read everything in the file | 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.
Native Share Consumption
Incoming Snowflake shares map directly into Milemarker's normalized data model without custom transformation code.
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.
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.
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.