Atlas - Partner Data Room for Card Issuers: an independent product by Kaushal Khodifad

Atlas - Partner Data Room for Card Issuers is an independent product by Kaushal Khodifad in banking & payments. Give a co-brand partner program insight in days, without one cardholder row leaving the bank.

Give a co-brand partner program insight in days, without one cardholder row leaving the bank.

  • Postgres RLS and masked views
  • Live AI questions, no model-written SQL
  • Hash-chained access log
Open product

Independent work by Kaushal Khodifad on public and synthetic data. Where a real company is named, it anchors the domain only: this is not client work, and it is not affiliated with or endorsed by any company named.

A governed partner data room for card issuers, anchored on JPMorgan Chase's co-brand card business. The partner receives contracted aggregates, with any cell under 25 cardholders suppressed by the database. Analysts, models and an AI analyst get rows masked by role and purpose. Postgres enforces every rule on every path, a live self-test proves it for every persona and purpose, and every read lands in a hash-chained access log. Not affiliated with JPMorgan Chase; cardholder data is synthetic.

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.

All products