Not affiliated with JPMorgan Chase.

Partner data room

What the partner gets, and what it never gets.

The partner receives the program insight it is contracted for, in days, as governed aggregates. It never receives a cardholder row. The fictional partner here is called Aurora.

The tension this solves

The partner owns the brand relationship; the bank owns the account and the regulated data. Neither can act alone after the card is issued. The data room has to let each side see exactly what it is contractually entitled to, fast enough to run the program, without ever handing the partner a copy of cardholder data.

One governed plane, two lenses

Internal teams and the partner read the same governed tables through different, database-enforced lenses. No copy is made for the partner.

one governed plane
One source of truth

One set of governed tables. No copies, no extracts; lineage by construction.

Issuer lensrows · masked by role and purpose

Analysts, data scientists and fraud teams: row-level access across the portfolio, masked by role and by purpose, every read logged.

Partner lensaggregates · k ≥ 25

The co-brand partner: contracted metrics by contracted dimensions, each tied to a contract clause. Any cell under 25 cardholders is suppressed by the database.

How much to share: the spectrum

Safest: aggregatesMost sensitive: event-level sharing
  1. 1Atlas ships this
    Contracted aggregates with small-cell suppression
  2. 2
    Co-marketing attribution on aggregates
  3. 3
    Overlap analysis in a clean room, no rows exchanged
  4. 4
    Event-level sharing for real-time offers

Act as the Partner Aurora analyst in Access controls. Ask for rows and the database returns none. Ask for spend by merchant and most cells come back suppressed.

Act as the partner

What the partner sees: the contracted catalogue

Every metric maps to a contract clause and a fixed set of breakdowns. Cells under 25 cardholders are suppressed, value and count both.

Approved spendclause 4.1

By category, region, segment, month, merchant, or program total.

Active cardholdersclause 4.2

By category, region, segment, month, merchant, or program total.

Spend per active cardholderclause 4.3

By category, region, segment, month, or program total.

Approval rateclause 4.4

By category, region, segment, month, or program total.

Redemption rateclause 5.1

By category, region, segment, month, or program total.

Points outstandingclause 5.2

By category, region, segment, month, or program total.

Disputesclause 6.2

By dispute reason, region, segment, month, or program total.

Disputed amountclause 6.3

By dispute reason, region, segment, month, or program total.

Seven data domains, and which lens each serves

Two of them are named products the partner co-owns: rewards liability and revenue-share settlement.

  • Spend and transactionsAggregates only

    Authorizations, settled transactions, merchant category, channel, recurring spend

    Used by partner reporting, marketing, finance

  • Accounts and cardholdersIssuer only

    Lifecycle, balances, credit line, status, tenure

    Used by risk, operations, servicing

  • Rewards and loyaltyAggregates plus liability share

    Points earned and redeemed, pre-bought currency liability, transfers

    Used by loyalty finance, partner

  • Credit and riskIssuer only

    Underwriting, delinquency, charge-off, fraud, exposure

    Used by risk, regulatory reporting

  • Partner economics and settlementShared, named product

    Revenue share, marketing-fund accruals, contract KPIs

    Used by partner finance, deal team

  • Marketing and acquisitionAggregates plus co-marketing

    Campaigns, application funnel, approvals, activation, attribution

    Used by marketing, partner

  • Servicing and disputesAggregates only

    Disputes, contacts, digital engagement

    Used by operations, customer experience

Rewards liability and revenue-share settlement are first-class, named products. They are what the deal team and partner finance argue about, so they are the first things to make trustworthy.

With the transaction function roughly break-even after rewards, analytics that grow engaged spend are where a co-brand program earns its keep. Speed of insight to the partner is part of the product.

Tokenization and rewards liability cut across every domain; neither belongs to one team.

Onboarding: partner number N+1 is configuration, not a build

The controls are reusable, so each new program adds rows of configuration against the same, already-tested policies.

  1. 1
    Register the program

    One program code and one partner persona. Name the data owner and the product manager accountable for the partner's data.

  2. 2
    Publish the data contract

    The metrics, dimensions, freshness SLA and contract clause behind each tile. The contract is the interface.

  3. 3
    Bind entitlements

    The partner persona gets aggregate-only access and its own program scope. The existing policies apply unchanged; nothing is re-implemented.

  4. 4
    Prove it before go-live

    The policy self-test runs every persona, purpose and data product against the database. Go-live is gated on it passing.

  5. 5
    Wire settlement and liability

    Instantiate the named revenue-share and rewards-liability products for the program.

  6. 6
    Sign off and go live

    The data owner signs off. The partner is live in days, with nothing partner-shaped copied out of the bank.

How success is measured

  • Days from signed agreement to first governed report
    10 business days

    Target. The differentiator against a bespoke build.

  • Partner metrics traceable to a contract clause
    100%

    Target. Every tile names its clause.

  • Cardholder-level rows delivered to the partner
    0

    Enforced by the database, and checked by the self-test.

  • Acquisition to activation funnel
    Program KPI

    Contracted aggregate.

  • Spend per active cardholder, redemption rate
    Program KPI

    Contracted aggregate.

  • Settlement accuracy and reconciliation time
    Operational

    Revenue-share reconciliation built into the settlement product.

Why this matters at issuer scale

The largest US issuers run many co-brand programs at once. Each program is a partner that wants its data.

$1.344T

JPMorgan Chase credit card purchase volume in 2024, the largest of any US issuer (Nilson Report).

$1.168T

American Express, second. Citi was third at $616.1B.

Chase co-brand programs include
AmazonUnitedSouthwestMarriott BonvoyHyattIHGDisneyBritish AirwaysAer LingusIberiaAeroplan
Three parties

Card network, issuer and brand. The brand is typically paid on card spend beyond its own stores or flights, so it wants to see how the program performs.

Where issuer profit comes from

The credit function earns most of card profitability (about 80%), fees about 15%, and the transaction function roughly breaks even or loses money once rewards are paid (Federal Reserve, 2022).

Installed base is the moat

Programs turn on the cardholder base and pre-bought loyalty currency, so moving a program between issuers is expensive.

Multi-issuer is real

Marriott runs co-brand cards with both Chase and American Express; a partner can compare issuers on how well each serves its data needs.

Sources and method

Live · enforced in the database Public · cited Synthetic · illustrative
  1. 01
    Nilson Report ranking of US credit card issuers - 2024 purchase volume: JPMorgan Chase $1.344T, American Express $1.168T, Citi $616.10B.www.globenewswire.com/news-release/2025/03/06/3038338/0/en/jp-morgan-tops-nilson-report-ranking-of-us-credit-card-issuers.html · as of published March 2025
  2. 02
    Federal Reserve, FEDS Notes: Credit Card Profitability - The credit function accounts for roughly 80% of card profitability and fees about 15%;www.federalreserve.gov/econres/notes/feds-notes/credit-card-profitability-20220909.html · as of September 2022
  3. 03
    Chase co-branded card catalogue - Current Chase co-brand programs, including Amazon, United, Southwest, Marriott Bonvoy, Hyatt, IHG, Disney, British Airways, Aer Lingus, Iberia and Aeroplan.creditcards.chase.com · as of September 2026
  4. 04
    JPMorgan Chase technology blog: the evolution of data mesh architecture - JPMorgan Chase's public description of its data mesh on AWS, with data shared in place rather than copied.www.jpmorganchase.com/about/technology/blog/evolution-of-data-mesh-architecture
Synthetic cardholder dataFictional partnerIllustrative model metricsCited market context