Kaushal Khodifad - Project Atlas - Chase Card Data & Analytics case study.

Case study by Kaushal Khodifad on Project Atlas - Chase Card Data & Analytics in the Analytics & Data space. A Chase Card data-product platform - data lake → curated products → entitlements → ML pipelines → GenAI, with a live Postgres-RLS governance simulator.

A Chase Card data-product platform - data lake → curated products → entitlements → ML pipelines → GenAI, with a live Postgres-RLS governance simulator.

A governed, entitlements-first card data-product platform for a co-brand card program. The centerpiece is a real Postgres Row Level Security access simulator - switch role and purpose and watch the database itself re-scope rows and mask PII, live. Plus NL-to-SQL under the same RLS, dashboards on 50k synthetic transactions, SR 11-7 model cards, and a full strategy portal.

The problem

A card issuer stands up a co-brand program with a new retail partner. The partner's analysts need real transaction data, the issuer cannot let them see the whole book, and every access has to survive an audit. Project Atlas is the governed, cloud-native analytics-and-ML environment that makes that safe, built end-to-end. It is an independent concept study in the card data domain, not affiliated with or endorsed by JPMorgan Chase: the partner is fictionalized as "Partner Nova" and all data is synthetic, so nothing claims non-public facts.

What it demonstrates

Atlas is a working data-product platform on real infrastructure (Supabase Postgres), not a slide deck:

  • Entitlements simulator - the centerpiece. Switch role and purpose and watch real Postgres Row Level Security re-scope the data live: a Partner Nova analyst sees ~10,000 of 50,000 rows, confirmed-fraud detail unlocks only under a Fraud Prevention purpose, and account tokens / PII mask per role. The actual RLS policy SQL is shown beside the live row count, and every access is written to an audit log.
  • NL-to-SQL console. Plain-English questions become governed SQL that runs under the same RLS - SELECT-only, schema-locked, with the guardrails demonstrated (try asking it to delete something).
  • Data-product catalog with field-level data contracts (PII/PAN flags, allowed roles, purpose), lineage, and entitlement-scoped previews.
  • Dashboards over 50k synthetic transactions - spend by MCC, approval and fraud rates, attrition by tenure, rewards liability.
  • ML model cards for fraud and attrition models with SR 11-7 lifecycle stage, SHAP drivers, disaggregated fairness metrics, and a dollar-impact outcome.
  • Strategy portal - vision and principles, a Now/Next/Later roadmap, a flagship PRD, a JIRA-style sprint board, an AI-generated executive readout, a KPI metrics tree, and an SR 11-7 governance register.

The hard part, done for real

The entitlements are enforced by genuine Postgres RLS on the anon role - no login, nothing faked in application code. Policies read transaction-local settings that SECURITY INVOKER functions set, so the public demo enforces row-scope, purpose, and column-masking exactly the way a bank would. PAN is tokenized at rest (last-4 only) even for privileged roles. All data is synthetic; no real cardholder data, no clear PAN.

Stack

Next.js / Supabase Postgres + Row Level Security / OpenRouter / Recharts.

Tech stack
Next.jsSupabase PostgresRow Level SecurityOpenRouterRecharts