Disclaimer: Independent educational project. Not affiliated with JPMorgan Chase. Built by Kaushal Khodifad. Data from public sources; figures are estimates.return to portfolio
Disclaimer: Independent educational project. Not affiliated with JPMorgan Chase.

Strategy · Partner environment & model risk

Make governed card data a product every team can trust.

The north star: a new co-brand partner reaches analytics go-live in weeks, not quarters - with row-, column-, and purpose-level entitlements enforced by construction, and ML that carries its own governance. Atlas is how a Card D&A team onboards Partner Aurora as a first-class data-product domain without ever loosening the controls.

01

Treat data as a product: owned, contracted, discoverable, SLA-governed - not a pile of tables behind a ticket queue.

02

Entitlements are the platform, not a feature. Row scope, purpose, masking, and audit are designed in from day one.

03

A partner reaches go-live in weeks because the controls are reusable, not rebuilt per engagement.

04

Every model is accountable to a monitored business metric and an SR 11-7 lifecycle, or it doesn't ship.

Build vs buy - where this pattern honestly sits

The mechanism here - row policies + column masking + purpose tags + audit - is deliberately commodity: Immuta, Databricks Unity Catalog, and Snowflake Horizon all ship versions of it. The defensible part for an issuer is not the mechanism; it's the co-brand semantics packaged on top. Positioning is qualitative and illustrative - no vendor pricing is quoted because none was independently verified.

Buy: policy-plane platforms
Immuta-class governance layers

Policy orchestration across engines (Snowflake, Databricks, warehouse mix). Strongest when the estate is multi-engine and policy count is large. You still have to model co-brand partners, purposes, and audit semantics yourself - the platform gives you enforcement primitives, not your data-sharing agreement.

Native: engine-built controls
Unity Catalog ABAC · Snowflake Horizon

Row filters and masking native to the lakehouse/warehouse - no extra vendor, rides the existing engine bill. The natural default for a single-engine estate. Same gap: partner row-scope and purpose-as-access-dimension are YOUR semantics to define and test.

This artifact: the thin issuer layer
What Atlas actually demonstrates

The layer an issuer builds EITHER way: co-brand partner scope as a first-class row dimension, purpose as a queryable access dimension, masking tied to role capability, audit-by-default - expressed in ~250 lines of committed SQL (src/lib/atlas/sql/0002-0003). The recommendation it encodes: buy the generic policy plane, build the co-brand semantics, and keep them small enough to review.

The unit that matters: marginal cost of co-brand partner N+1

structural argument · no measured dollars

An issuer with a large co-brand book onboards partners repeatedly. The fundable case for a governed plane is not year-one ROI - it's that partner onboarding flips from a per-partner build to a per-partner configuration, while the reviewable control surface stays constant instead of growing with every extract.

Cost driver, per new partnerBespoke extract environmentGoverned-domain pattern (this artifact)
Data plumbingNew pipelines + a partner-shaped copy of the dataZero new copies - share in place; one partner_scope value on existing products
Row / column controlsRe-implemented and re-reviewed per extractOne entitlement_roles row; the same committed policies (0002) apply unchanged
Security & audit reviewA NEW surface to review; extracts keep leaking after handoffThe reviewed surface is constant (~250 lines of SQL in this repo); audit-by-default
Ongoing liabilityEvery extract is standing PII exposure with its own lifecycleRevoke = delete one role row; nothing partner-shaped persists to clean up

Deliberately no invented dollar figures: engineering-cost and vendor-price claims here would be unverifiable. The demonstrable claim is the shape of the cost curve - in this repo, “onboard Partner Aurora” is literally one role row (0004) plus one scope value (0005), against an unchanged, committed policy set (0002-0003).

Roadmap

Now / Next / Later - the partner-onboarding path, with explicit sequencing.

Now3

this quarter - partner go-live path

Ingestion● in progress
Partner Nova ingestion + bronze/silver

Land Nova authorizations into the bronze lake; conform to silver. Stand up partner row-scope entitlements.

Entitlements● in progress
Entitlements MVP + audit

Real RLS row-scope + purpose-based access + PII masking + full audit on Tier-1 products.

Gold Products
Partner reporting mart + SLA

Row-filtered Nova reporting mart with freshness/availability SLAs for partner delivery.

Next3

1-2 quarters - productize & automate

Gold Products
card_transactions_gold data product

Curated, contracted, lineage-tracked flagship product for analysts + DS.

ML
Real-time fraud model to production

Promote fraud-detection-xgb with monitoring + drift triggers + adverse-action reason codes.

Gen-AI
NL-to-SQL self-serve (governed)

Natural-language querying that respects entitlements; SELECT-only, audited.

Later3

self-serve & governed gen-AI

Gold Products
Self-serve semantic layer

Governed metrics layer so every team computes the same KPI the same way.

Gen-AI
Analyst copilot + auto exec narratives

RAG over the data dictionary; automated executive readouts from KPI state.

Governance
Cross-border data-residency controls

Purpose + residency entitlements for the Bengaluru team accessing US card data.

↑ Independent educational project by Kaushal Khodifad. JPMorgan Chase is a real company in the card data & analytics space; this design and the underlying prototype were built by Kaushal as a portfolio study. Not affiliated with, endorsed by, or representative of JPMorgan Chase's actual product. Data is from public sources. Figures are estimates.

Return to portfolioOpen the live demo