Why financial institutions, insurers, and healthcare platforms are shifting compute inside the data perimeter to end vendor data sprawl.
For Chief Risk Officers, CISOs, and Data Architects at enterprise banks, insurance carriers, and healthcare systems, deploying customer engagement technology has historically been a high-stakes exercise in risk management. A retail bank launching a predictive churn campaign across 5 million account holders must resolve identity matches, run scoring models, and trigger targeted offers. However, in heavily regulated industries governed by GDPR, HIPAA, CCPA, and strict banking secrecy laws, moving 5 million raw customer records into external SaaS platforms presents massive compliance hurdles.
Every raw record leaving the secure perimeter expands the attack surface, triggers vendor audit liabilities, requires complex deletion guarantees, and risks violating data residency boundaries. Modern enterprise data platforms are undergoing a structural architectural evolution to solve this exact bottleneck. To understand where the market is moving, we must examine the three fundamental architectural paradigms powering Customer Data Platforms (CDPs) today.
The regulated reality. In highly regulated markets, the primary cause of delayed or abandoned MarTech and CDP implementations is not technical feature gaps — it is the security and compliance review of third-party raw data replication.
The three architectural paradigms: a data and perimeter perspective
1. Traditional SaaS CDP (extract and load model) — high-risk boundary
Mechanics: Under the legacy SaaS approach, customer data is periodically extracted via ETL pipelines or REST APIs from the bank’s core data warehouse (for example, Snowflake, BigQuery, or Databricks) and copied over the public network into the vendor’s multi-tenant cloud storage.
Compute and storage: Identity resolution, segmentation rules, and AI scoring run entirely on the vendor’s proprietary infrastructure, operating on their replicated copy of the database.
Privacy impact: Two complete copies of the dataset now exist. Compliance teams must enforce encryption-in-transit, zero-trust network access, strict vendor audit agreements, vendor SOC 2 verification, and complex cascade-deletion mechanisms when a customer exercises a “right to be forgotten.”
2. Zero-copy data sharing and federation — medium-risk boundary
Mechanics: Spearheaded by major enterprise platforms, zero-copy eliminates physical data duplication. The bank maintains storage control and provisions a secure, read-only data-share view directly to the vendor’s account.
Compute and storage: The physical data remains in the bank’s warehouse storage layers. However, when segmentation or scoring runs, the vendor’s external Snowflake or cloud account executes queries against the shared view.
Privacy impact: Raw data is no longer duplicated into vendor databases. However, because an external account executes queries across the perimeter, compliance teams must still review cross-account data access boundaries, egress points, and query log exposures.
3. Native-app CDP (in-warehouse execution) — zero-egress boundary
Mechanics: Leveraging modern ecosystems like the Snowflake Native App Framework or Databricks Clean Rooms, the vendor’s application logic (compiled code, containerized models, and SQL routines) is installed directly inside the bank’s account perimeter from a marketplace.
Compute and storage: The entire process — identity matching, churn scoring, and audience creation — executes using the bank’s own compute resources (for example, virtual warehouses or Snowpark Container Services) directly against local tables in place.
Privacy impact: Zero raw data leaves the bank’s perimeter. The vendor owns and operates the app’s code logic but cannot view, export, or query the underlying raw customer data. The external vendor account has zero read access. Only the final, consent-filtered target list (for example, hashed IDs for activation) is pushed to outbound execution endpoints such as email or ad gateways.
Technical comparison matrix
Major vendor ecosystem landscape
Understanding how the major enterprise players align across these architectural models is critical for technology procurement.
Salesforce and Adobe: the zero-copy federation giants
Enterprise platforms like Salesforce Data Cloud and Adobe Experience Platform (AEP) have invested heavily in zero-copy data sharing bridges. They allow a bank to connect its Snowflake or Databricks environment without performing traditional batch ETL exports. The trade-off: while raw records are not permanently moved into Adobe or Salesforce storage buckets, their processing engines still query the warehouse from external accounts. For many financial and healthcare compliance boards, granting external tenant accounts live read access to PII views still requires rigorous cross-border privacy assessments.
Composable CDPs: the SQL and in-warehouse builders
Vendors like Hightouch, Census, MessageGears, and RudderStack pioneered the “warehouse-native” movement. They operate by generating native SQL models that execute directly inside the data warehouse, avoiding external storage altogether and leveraging existing data modeling (dbt, SQL) built by internal data teams.
Marketplace native apps: the zero-egress perimeter
Platforms such as Zeotap (for CDP and identity), Senzing and LiveRamp (for identity resolution), and InfoSum / Habu (for data clean rooms) represent the purest execution of the native-app pattern. By packaging their intellectual property as Snowflake Native Apps or Snowpark containers, these vendors bring their software to the data rather than dragging the data to their software.
Architectural takeaway for CISOs and data architects
The choice between zero-copy data federation and native applications comes down to the strictness of the data perimeter:
- If the risk framework allows controlled cross-account query access, zero-copy federation (Salesforce, Adobe) provides seamless integration into multi-cloud marketing suites.
- If the regulatory environment (for example, core banking PII or HIPAA PHI) mandates zero external account access and complete compute containment, the native-app CDP model (Zeotap, composable native stacks) is fast becoming the mandatory design pattern for enterprise deployments.
Frequently asked questions
Native-App CDP — FAQ
Is a native-app CDP the same as a composable or warehouse-native CDP?
No, though both keep processing close to the data. A composable or warehouse-native CDP generates SQL that the customer's own data team runs in the warehouse (for example Hightouch or Census). A native-app CDP installs the vendor's packaged, compiled application inside the customer's account through the Snowflake Native App Framework or Snowpark, so the vendor's code runs on the customer's compute without the vendor gaining read access to raw data.
If no raw data leaves the warehouse, how does a native-app CDP activate audiences?
Only the final, consent-filtered output leaves the perimeter, not the underlying records. The app builds the target audience in place and pushes a minimal payload, typically hashed identifiers or channel keys, to outbound endpoints such as email platforms or ad gateways. Raw customer attributes remain inside the tenant throughout the process.
Does the native-app model work on Databricks, or only Snowflake?
It is not Snowflake-specific. The pattern is implemented through the Snowflake Native App Framework and Snowpark Container Services on Snowflake, and through Databricks Clean Rooms on the Databricks side. The common requirement is a platform that can execute vendor-supplied code against local tables without granting the vendor read access to the raw data.
What are the trade-offs of a native-app CDP?
Constraining what the vendor can see also constrains some conventional SaaS conveniences. Cross-customer benchmarking, vendor-side data enrichment, and fully managed hosting are harder when the vendor never touches raw data or operates outside the tenant. Organisations without a governed cloud data warehouse, or those wanting a turnkey managed service, may still find a packaged or zero-copy approach a better fit.
Is a native-app CDP faster to deploy than a traditional CDP?
Typically, because the data already resides where the compute runs. Traditional deployments spend much of their timeline building and security-reviewing the extract pipelines that move data to the vendor, and the native-app model removes that step, so implementation tends to compress. The remaining work is data modelling and configuration rather than data movement, though timelines still vary by organisation.
