The core design
A governed environment for a new card partner
The worked design at the centre of this study. We onboard a new strategic co-brand partner - illustrated as “Partner Aurora,” a national retail/airline-class program - as a first-class data-product domain. Aurora is fictional; the market context that frames it is real and cited.
The scenario, grounded in the real market
- ›Chase is the #1 US card issuer by purchase volume - $1.344T in 2024.
- ›Ahead of Amex ($1.168T), Citi ($616B), Capital One ($610B), and Bank of America ($502B).
- ›Chase is the largest US co-brand card issuer.
- Tri-party deal
Network (Visa / Mastercard) + issuer (Chase) + brand. The brand gets a cut even on spend elsewhere.
- Issuer card P&L mix
The credit/interest function is the large majority of card profitability (~80%), with fees a smaller slice (~15%); the transaction/interchange function is roughly neutral-to-slightly-negative once rewards are netted out (Fed FEDS Note, 2022). Any finer split shown is illustrative.
- Installed base is the moat
Deals turn on installed base + prepurchased loyalty currency - huge capital to dislodge an incumbent.
- Multi-issuer is real
Marriott deliberately runs multi-issuer (Chase + Amex); partners can split portfolios.
The partner owns the customer interface; the bank owns the account and the regulated data - so neither side can act unilaterally post-issuance. Designing the environment = standing up a governed data-product domain that lets each side see exactly what it is contractually entitled to, in time to drive the program, with PII/entitlement controls and revenue-share settlement built in.
One source of truth, two entitled views
The heart of the design: a single governed plane forks into Chase-internal and partner-facing lenses - the exact masking the simulator proves.
One row-level-secured table. No copies, no extracts - lineage by construction.
Full, PII-governed view across all 7 product domains. Row scope = entire portfolio; masking by role + purpose.
Aggregated, de-identified, contractually scoped. Every partner-visible metric traces to a contract clause + a governed aggregate.
The partner_analyst_nova role already in the live RLS plane IS this partner-facing lens - row-scoped to partner data, PII masked, partner_reporting purpose. Switch to the Partner Aurora Analyst role in the live simulator and watch the rows scope and PII mask.
Open simulatorSeven curated data-product domains, instantiated for the partner
Each domain declares which lens it serves. Two are first-class, named, shared products.
| Domain | Contents | Consumers | Partner lens |
|---|---|---|---|
| Spend / transactions | Auths, settled txns, MCC/merchant, channel, geo, recurring / card-on-file | Partner reporting, marketing, finance | Aggregate only |
| Accounts & cardmember | Lifecycle, balances, credit line, status, tenure | Risk, ops, CRM | Chase-only |
| Rewards / loyaltynamed | Points/miles earned-burned, redemption, prepurchased-currency liability, transfers | Loyalty finance, partner | Aggregate + liability share |
| Credit & risk | Underwriting, delinquency, charge-off, fraud, exposure | Risk, regulatory | Chase-only |
| Partner economics / settlementnamed | Interchange share, revenue-share, marketing-fund accruals, contract KPIs | Partner finance, deal team | Shared, named product |
| Marketing / acquisition | Campaigns, app funnel, approval, activation, attribution, co-marketing | Marketing, partner | Aggregate + co-marketing |
| Servicing / ops | Disputes, calls, digital engagement | Ops, CX | Aggregate |
Onboarding runbook - time-to-value as the differentiator
A partner domain provisioned in days, not a bespoke quarter-long build.
Provision the partner domain; name a Data Owner and a Data Product Manager.
Schema, freshness SLA, lineage, plus versioned APIs - the contract is the interface.
Via governed tags. The partner lens is de-identified aggregates by construction, not by review.
Partner reporting mart provisioned against its SLA.
Instantiate the named settlement and rewards-liability products.
Office of the CDO signs off; the domain goes live - in days, not a bespoke quarter-long build.
Accountable for all card data created, provisioned, and consumed - the single point of data accountability for the portfolio.
Owns data-product strategy, backlog, and metrics; drives cloud migration and an API-first posture on AWS S3 + Snowflake + Databricks.
Role charters mirror JPMorgan's two publicly-posted Card roles (Data Owner VP; Card Analytics Data PM) - the closest public proxy for the mandate this environment serves. Chase does not publish its internal card data-platform topology; this runbook is a grounded reference design.
Partner reporting surface
A governed partner portal - program KPIs fed only from entitled aggregates, analogous to how Chase exposes governed reporting to commercial clients via Chase Connect.
Acquisition funnel · spend · engagement · redemption · co-marketing ROI - every tile traces to a governed aggregate, never a cardholder row. The same dashboard charts run filtered to the partner-visible aggregate set.
See the dashboardsPartner-environment success metrics
| Metric | Target | Note |
|---|---|---|
| Time-to-onboard a partner domain | Days (illustrative target) | The headline differentiator vs a bespoke quarter-long build. |
| Provable entitlement | 100% (target) | % of partner-visible metrics traceable to a contract clause + governed aggregate. |
| Acquisition → activation funnel | Program KPI | Surfaced to the partner from entitled aggregates only. |
| Spend per active / redemption rate | Program KPI | Aggregate, contractually scoped. |
| Co-marketing ROI | Program KPI | Attribution on entitled aggregates. |
| Settlement accuracy / reconciliation latency | Operational | Revenue-share reconciliation built into the settlement product. |
Sources & methodology
- 01
- 02
- 03
- 04
- 05