Strategy
Product specOwner: Card Data Products
The partner data room
One governed domain per co-brand program, serving the partner contracted aggregates and serving internal teams masked rows, from the same tables.
Problem
Every co-brand partner wants program insight: acquisition, spend, redemption, disputes. Today each request becomes a bespoke extract, each extract is a new copy of cardholder data with its own review, and the controls are re-implemented slightly differently every time. Onboarding the next partner, Aurora here, the old way would take a quarter and add one more way to leak.
Users
| Persona | Job to be done | Needs |
|---|---|---|
| Partner Aurora analyst | Run the program on facts | Contracted metrics, fresh daily, with the clause behind each |
| Fraud analyst | Investigate suspected fraud | All rows including fraud; clear contact data under Fraud Prevention only |
| Data scientist | Build fraud and attrition models | Tokenized features, fraud labels under Fraud Prevention |
| Marketing analyst | Segment and target | Spend behaviour without fraud detail; contact data masked |
| Audit and model risk | Independent review | Every purpose, masked by default, a verifiable access log |
Goals and non-goals
Goals
- A new partner live in days, as configuration.
- Zero cardholder rows delivered to any partner.
- One set of rules for screens, APIs and AI.
- Every access provable to an examiner.
Non-goals
- Real-time authorization serving; that stays on the switch.
- Storing clear card numbers, ever.
- A new BI tool; partners get governed data, not dashboards we maintain.
- Event-level sharing in the first release.
Requirements
- P0The partner persona receives contracted aggregates only. No cardholder-level row reaches it by any path: screen, API or AI.
- P0Any aggregate cell under 25 distinct cardholders is suppressed in the database, value and count both.
- P0A purpose not granted to a persona returns nothing, for every table. Contact data unmasks only for a role and purpose that allow it.
- P0Card numbers are stored masked to the last four digits, and no persona ever sees more.
- P0Every read writes a hash-chained access-log row with persona, purpose, outcome and row count.
- P1Each partner metric carries a contract clause and a fixed set of breakdowns; the partner's tiles show the clause.
- P1A governed AI analyst: verified questions first, model-drafted specs validated against the semantic layer, run on masked views only.
- P1A policy self-test for every persona, purpose and data product gates every release and every partner go-live.
- P2Time-bound unmask exceptions with approval, and identity-bound personas from SSO claims.
Success measures
| Measure | Target |
|---|---|
| Days from signed agreement to first governed report | 10 business days |
| Cardholder rows delivered to partners | 0 |
| Partner metrics traceable to a clause | 100% |
| Questions answered from verified queries | 70% |
| Partner report SLA adherence | 99.5% |
| Governed query latency, p95 | under 5 seconds |
Risks and trade-offs
- Governance against speed. Mask by default with a fast, time-bound unmask request, rather than gating every query.
- Suppression against usefulness. k = 25 hides merchant-level cells for a mid-sized program. That is the point; the contract offers category-level cuts instead.
- Policy performance at scale. Policy checks are evaluated once per query, and program scope is indexed.
- Partner relationship risk. Co-brand programs are won and lost on servicing and data. SLAs and scope are contractual, not best-effort.
Rollout
- 1. Entitlements enforced in the database for the fact tables, with the self-test.
- 2. Partner aggregate catalogue and suppression; partner acceptance testing against the contract.
- 3. Governed AI analyst for internal teams; verified questions first.
- 4. Identity-bound personas and unmask exceptions; retire per-analyst extracts.