Building Enterprise Grade Data Products for FSI — Moving from Strategy to Tactics

I’ve had the opportunity to work with financial services organisations closely and one thing is clear: the teams that win are the ones that can turn regulatory‑grade data into business insight quickly, while navigating complex cross‑functional teams (business, technology, risk, compliance) and an increasingly demanding regulatory environment.

In this post, we’ll look at how leaders in financial services orient themselves to deliver business value from data assets (the strategy) and how data contracts and AI‑assisted code generation can automate much of the engineering, accelerating value delivery (the tactics).

📁Code first? *Here it is!*

📰 Not a medium member? Use this friend link to read the article.

The Why: Breaking Down Barriers

In highly regulated industries like banking, insurance, lending, and wealth management, the stakes for getting data wrong are uniquely high. A mis‑priced loan, an undetected fraudulent claim, or an unsuitable investment recommendation isn’t just a missed opportunity — it can trigger regulatory breaches, financial losses, and reputational damage.

There’s also a hidden cost of slow delivery: not extracting value from data. When promising use cases stall for months, or never make it out of PowerPoint, organisations quietly lose revenue, efficiency, and customer trust.

Behind many of these issues sits a familiar pattern: critical data is scattered across teams, systems, and spreadsheets, so each function builds its own slightly different version of the truth. This is the classic data silo problem: over time, an organisation ends up with multiple versions of the truth, shadow IT pipelines that are hard to govern, and slower responses to change.

While these challenges are most acute in regulated industries, the pattern is universal. Any organisation that relies on trusted, explainable decisions — whether in retail, telecoms, or the public sector — can benefit from moving from scattered datasets to well‑defined, reusable data products.

Data products are what you get when you treat data as a reusable asset and deliberately enforce characteristics like ownership, quality, and clear purpose to improve user trust and reduce uncontrolled data proliferation. The process is Data as a Product (DaaP); the outcome is the data product itself.

Shifting to a Data as a Product (DaaP) model breaks helps organisations move from tactical data management to strategic, AI‑ready data assets by:

• Accelerating business insight safely. When teams can reliably build on shared products, new use cases can be delivered faster without rebuilding plumbing or creating new risk.
• Restoring trust in data. Critical domains — customers, policies, loans — become formally owned, governed data products with clear contracts, SLAs, and lineage.
• Lowering TCO and increasing ROI. Treating data as a product reduces duplicate work, simplifies compliance reporting, and links platform spend to measurable outcomes.

Having clarified why data products matter, the next question is straightforward:

What kind of strategy actually allows an organisation to design, own, and operate those products — especially in a regulated environment?

That brings us to the WHAT.

The What: Data & Social Strategy

Delivering trustworthy data products is not just a tooling decision. It’s the result of a deliberate strategy for:

• How data is shaped and structured — your Data Strategy
• How people work together around that data — your Social Strategy

Data Strategy: Designing Products, Not Just Pipelines

A modern data strategy defines how your organisation will turn raw data into reliable, reusable data products that serve specific business outcomes. This means deliberately treating assets like a Retail Customer 360 or a Credit Decisioning View as first‑class data products, not ad‑hoc datasets buried in projects.

A clear data strategy answers questions like:

• Which domains are mission‑critical for our business and regulatory obligations (customers, accounts, policies, claims, etc.)?
• For each domain, what is the canonical internal product we will expose, and what questions should it reliably answer? (For example: “Can we explain every declined credit application over the last seven years?”)
• How will we make sure each product is governed, secure, and auditable enough to satisfy regulators, internal audit, and customers?

Social Strategy: Multi‑Disciplinary Teams and Clear Accountability

If data strategy defines what you build, your social strategy defines who builds it and how they collaborate — the operating model.

In regulated industries, no single team can safely own something as sensitive as a Risk Factors or Suitability product in isolation. Credible products emerge when business, risk, compliance, and technology share responsibility.

In practice, this means creating a multi‑disciplinary data product team for each important domain, working within a simple RACI‑style model and owning the product end‑to‑end. You don’t need a perfect target‑state operating model on day one; starting with a lightweight RACI is often enough to guide ways of working.

You can download a simple RACI template from this repo.

By bringing decision‑makers and engineers together around a shared product and contract, organisations remove the ticket‑queue dynamic and turn data delivery into a predictable, iterative product roadmap — where data products live at the intersection of business expertise and technical capability, not in a central IT silo.

The (Not So) Secret Formula: People + Process + Technology = Trustworthy Products

When you put these pieces together — a clear data strategy and a practical social strategy — you get a simple progression

People (multi‑disciplinary teams) following clear processes (ownership, contracts, lifecycle) on the right technology produce trustworthy, reusable data products.

The obvious next question is: what does that lifecycle look like when a banking or insurance team sits down to build a real data product? To answer that, we’ll shift from strategy to tactics and walk through a concrete lifecycle you can apply on a modern data platform, like Snowflake.

The How: Lifecycle for FSI Data Products

Building high‑quality, AI‑ready data products requires a disciplined, iterative approach. The Data Product Blueprint guides organisations through a five-stage lifecycle: Discover, Design, Deliver, Operate, and Refine. This lifecycle is the “missing middle” between your strategy and your code. It gives multi‑disciplinary teams a shared map for taking an idea from slideware to a governed, AI‑ready product.

Data Product Blueprint

In this section, we’ll show how to implement that lifecycle using Retail Customer Churn Risk data product. You can find an end-to-end example here: https://github.com/srini86/data-products-lifecycle-fsi-example.

1. Discover: Start from the Business Event

Discovery begins with a business or regulatory trigger, not a table or a model. For our example, Retail Customer Churn Risk — that event might be a rising churn in current accounts.

The multi‑disciplinary team then works backwards from this event to capture:

• The problem statement
• The target users (e.g., retention team, underwriters, collections)
• The key KPIs (e.g., churn rate, loss ratio, NPL rate, complaint volume)
• Candidate data product (e.g., “Retail Customer Churn Risk Product”)

From a process point of view, you can use event storming or a simple one‑page canvas to capture this: intent, stakeholders, and measures of success. It stays business‑friendly on purpose — the goal is alignment, not technical design.

Data Product Canvas Example - Retail Churn Risk Data Product

Once that intent and the requirements are clear, the team can move to the second phase: turning it into something engineers and platforms can execute.

2. Design: Codifying Business Value

Design is where the business need becomes a data contract — a shared, human‑readable and machine‑readable specification of the product. It’s the point where your socio‑technical strategy becomes tangible: the business language from Discover is translated into artefacts that engineers and the platform can work with consistently.

For a regulated organisation, this is crucial. The data contract is what allows Risk, Finance, Compliance, and Technology to agree on what the product is, how it behaves, and what guarantees it offers before a single line of code is deployed.

Building on the discovery canvas, the data product team defines:

• Business context — the problem being solved, who will use the product, and the KPIs that define success.
• Scope and schema — the key sources, the main entities and fields to expose, and any critical data quality rules or PII flags.
• Non‑functional requirements — SLAs for freshness and availability, access and classification, plus retention, masking, and audit expectations.

This is encoded as a data contract — often in YAML or a similar format — that can be read by both humans and tooling. In the context of the data platform, data contract becomes the blueprint for creating objects (schemas, tables, views), defining tags and policies for security and governance and generating transformation logic.

Data Contract automates the creation of objects

For the Retail Customer Churn Risk product, this contract captures the agreed business problem, the churn‑risk attributes to expose, and the SLAs the team is committing to — sample below — you can download the full data contract here.

# DATA CONTRACT: Retail Customer Churn Risk
apiVersion: v1
kind: DataContract
metadata:
  name: retail-customer-churn-risk
  version: "1.0.0"

spec:
  owner: { team: "Retail Customer Analytics", email: "alex.morgan@bank.com" }
  sources: [CUSTOMERS, ACCOUNTS, TRANSACTIONS, ...]  # 5 RAW tables
  destination: RETAIL_BANKING_DB.DATA_PRODUCTS.RETAIL_CUSTOMER_CHURN_RISK

  schema:  # Key columns
    - customer_id: { type: string, constraints: [required, unique] }
    - churn_risk_score: { type: integer, range: [0, 100] }
    - risk_tier: { values: [LOW, MEDIUM, HIGH, CRITICAL] }
    # ... 6 more columns with PII masking, derivations

  quality: { freshness: "24 hours", completeness: "100%", uniqueness: "customer_id" }
  sla: { availability: "99.5%", refresh: "Daily 6AM UTC" }
  access: { roles: [retention_analyst, branch_manager], masking: "PII masked" }
  compliance: [FCA Consumer Duty, GDPR]

3. Deliver: Automation and Democratisation

With the data contract agreed, the Deliver phase is about making it real: turning specifications into running pipelines and consumable products.

The goal of Deliver is simple: producers should be able to deliver data products quickly, any authorised consumer should be able to find the product, understand what it offers, and start building on it without creating yet another copy.

Because the contract is machine‑readable, much of this can be templated or automated: table definitions, tags, views, and even the business logic can be derived directly from the contract rather than hand‑crafted for each new product.

To make this real, we’ll use a simple reference pipeline that treats the data contract as the blueprint and uses AI to generate the code. The contract defines the business rules, schema, and policies; a Streamlit app powered by Snowflake Cortex reads that contract and auto‑generates dbt model code and other artefacts, so engineers aren’t hand‑coding every new product. This is what turns Deliver into automation and acceleration rather than another bespoke project — and you can try the full example yourself using the code here.

Automated data pipeline

The key components of the solution are:

Automation via data contracts and AI‑assisted code generation. The data contract captures business rules, schema definitions, and masking policies, and acts as the blueprint for the final data product. The pipeline simply responds to contract changes, creating or updating schemas, tables, tags, and models based on what the contract declares.

In the past, I built rule‑based parsers to unpack contracts and generate scripts for these objects. The idea is the same today, but AI makes the code‑generation step much easier. As a principle, I use AI where interpretation is needed (natural language → code), and templates where outputs are structured and predictable.

In the example pipeline, a Streamlit app powered by Snowflake Cortex auto‑generates dbt model code from the contract, dramatically accelerating development while embedding best practices into the pipeline. In a production setup, this can be wired into CI so that contract changes trigger code updates and pull requests — keeping the contract as the single source of truth.

Unified serving layer with Semantic Views. A solid semantic model translates raw data into business‑understandable metrics and entities. Historically this lived inside BI tools; now platforms like Snowflake bring semantic modelling directly onto the data platform.

This establishes a unified serving layer that captures critical business logic and taxonomy in one place, ensuring consistency for all consumers — whether they are running BI reports, operational dashboards, or feeding an AI/ML model.

For our Retail Customer Churn Risk product, the semantic view exposes the risk tier, eligibility flags, and key metrics as queryable dimensions, enabling teams to ask questions like: “Show me high‑risk customers in the South East region.”

CREATE OR REPLACE SEMANTIC VIEW retail_customer_churn_risk_sv
TABLES (
    churn AS DATA_PRODUCTS.RETAIL_CUSTOMER_CHURN_RISK PRIMARY KEY (customer_id)
  )
DIMENSIONS (
    -- Customer attributes
    churn.customer_id AS customer_id,
    churn.customer_name AS customer_name,
    churn.customer_segment AS customer_segment,
    churn.region AS region,

---- more attributess

    -- Time
    churn.data_as_of_date AS data_as_of_date,
    churn.model_version AS model_version
  )
  METRICS (
    customer_count AS COUNT(churn.customer_id)
);

Delivery through the Internal Marketplace / Data Catalog. To truly democratise access, finished data products are published to a data catalog and made available for discovery. As a rule of thumb, it’s better to let teams discover all products at the metadata level by default, and govern data access by design. The catalog makes high‑quality, trusted products easy to find, request, and use across the organisation.

For our Retail Customer Churn Risk product, the finished data product — abstracted by the semantic view — is published on Snowflake’s Internal Marketplace for intra‑organisation consumption.

CREATE LISTING IF NOT EXISTS retail_customer_churn_risk
  FOR SHARE retail_churn_risk_share
  AS
$$
title: Retail Customer Churn Risk
description: |
  Daily churn risk scores for retail banking customers.
  Features: Risk Score (0-100), Risk Tier, Primary Risk Driver, Recommended Intervention.
organization_profile: INTERNAL
organization_targets:
  access:
  - account: YOUR_ACCOUNT_NAME
  discovery:
  - account: YOUR_ACCOUNT_NAME
locations:
  access_regions:
  - name: ALL
approver_contact: your.email@company.com
support_contact: your.email@company.com
$$
DISTRIBUTION = ORGANIZATION;

A note on types of data products: the example above represents a consumer‑aligned data product — close to a specific analytics or decisioning need — where AI‑generated code provides a fast, opinionated starting point that teams can refine. The same contract‑driven pattern applied to source‑aligned data products can offer near‑full automation, because this layer typically involves standard transformations (schema alignment, data integrity checks, field‑name standardisation) that are easy to capture once in a pipeline and then reuse across your portfolio.

4. Operate: Observability and Measurement

Once data products are live, the work shifts from building to running them well. Operate is about making sure each product continues to meet its contract in the real world, with platform teams, product owners, and governance functions working together to keep products healthy, trustworthy, and valuable.

In regulated industries, this phase is crucial. The team focuses on three aspects:

• Reliability — Are freshness and availability SLAs being met? Are there failed loads, late runs, or unexpected gaps?
• Quality and compliance — Are key data quality rules holding (for example, value ranges, uniqueness, completeness)? Are access controls, masking, and classifications correctly applied? Can we explain lineage end‑to‑end?
• Adoption and impact — Who is using the product, and how? Which models, dashboards, and processes depend on it? Are the agreed KPIs actually improving over time?

On Snowflake, much of this can be monitored directly from usage telemetry, tags, and account views, with alerts and dashboards built on top. Contract‑driven pipelines make this easier, because expectations (SLAs, quality rules) are codified once in the contract and then enforced and monitored consistently. An example of data quality monitoring is shown below.

-- Monitor contract-defined quality expectations
SELECT 
    expectation_name,
    CASE status 
        WHEN 'PASSED' THEN '✅ PASSED'
        WHEN 'FAILED' THEN '❌ FAILED'
        ELSE '⚠️ ' || status
    END AS status,
    metric_name,
    metric_value,
    measurement_time
FROM SNOWFLAKE.LOCAL.DATA_QUALITY_MONITORING_EXPECTATION_STATUS
WHERE table_name = 'RETAIL_CUSTOMER_CHURN_RISK'
ORDER BY measurement_time DESC, expectation_name
LIMIT 10;

5. Refine: Feedback and Evolution

No data product is ever truly “finished”. Refine is the phase where feedback loops turn operational experience and business outcomes into improvements — or, sometimes, controlled retirement.

Typical triggers for refinement include:

• New or changing regulatory requirements
• Shifts in business strategy (for example, focusing on a new customer segment)
• Evidence that additional features would materially improve performance
• Low adoption, indicating that the product is no longer meeting a real need

Refinement can mean:

• Enhancing a product (adding attributes, tightening SLAs, improving documentation)
• Splitting or merging products (for example, separating SME churn from retail churn, or combining several narrow products into a broader lifecycle view)
• Retiring products that have been superseded, while preserving an auditable archive

Each change should flow back through the lifecycle: update the data contract, communicate with consumers, and adjust monitoring so the new version is measured appropriately. With contract‑driven automation, many of the code and structure changes can then be generated automatically from the updated contract.

Example — Retail Customer Churn Risk

After six months in production, telemetry and business feedback show new needs: prioritising high‑value customers, spotting early product downgrades. The team adds a small set of new fields (CLV, downgrade flags, vulnerability and confidence indicators) to the data contract, regenerates the pipeline from it, and rolls out the enhanced product without breaking existing dashboards.

This is the Refine loop in action: real-world feedback flows back into the contract, the contract regenerates the code, and the product improves — all while maintaining governance and backward compatibility.

Summing It Up: Make Data Products the Foundation of Your AI Strategy

If there’s one message to take away from this post, it’s this:

Stop hand‑crafting every data product. Start automating from the contract, and let AI do the heavy lifting on code and tests.

The pattern we’ve walked through is simple:

• Capture the intent, structure, and guarantees of each product in a data contract.
• Use automation and AI‑assisted code generation to turn that contract into schemas, models, policies, and tests.
• Plug this into a clear lifecycle (Discover → Design → Deliver → Operate → Refine) so that changing the contract regenerates the product, instead of triggering yet another bespoke engineering effort.

Done well, this turns use cases like Retail Customer Churn Risk from quarter‑long projects into something you can iterate on in days or weeks. Engineers spend less time on boilerplate and plumbing, and more time improving models, features, and business outcomes — with automation and AI quietly doing more of the work each time.

If you’re wondering where to start, pick one high‑value use case, define a data contract for it, and run it through this lifecycle with the sample pipeline. From there, let automation — and a little help from AI — do more of the work each time.

For a strategy‑focused view on data products, checkout https://medium.com/@trevor.eastabrook/a-socio-technical-strategy-to-empower-business-decisions-cf0905d341d7

Note: The opinions in the post are my own and do not reflect those of my employer, Snowflake Inc.