# Emerging Payments: Domain Primer
**Prepared by:** Chris Otten (Emerging Payments, Synchrony)
**Purpose:** A working knowledge base for my Synchrony AI agent. This is the domain context that does not live cleanly in any one Confluence page yet: how our card products actually work, why tokenization is hard for part of our book, where the wallet and agentic-commerce industry is heading, and the open ideas I am carrying. Use it as background context when you help me draft, analyze, or plan in the Emerging Payments space.
**Last updated:** 2026-06-18
> **How to read this:** Sections 1 through 4 are durable domain knowledge that does not change quickly. Section 5 is industry context captured at the Fiserv Issuing client event (Omaha, June 2026); treat specific figures and names there as approximate, since they were heard in large rooms, while the product mechanics and trends are high confidence. Section 6 is my own open ideas, flagged as unvalidated.
---
## 1. The role and the train
- **Train:** Emerging Payments. We serve Synchrony's dual card and co-brand accounts, and we own the digital wallet and provisioning side of the house.
- **Scope:** the train runs the platforms that get a Synchrony account into a digital wallet (Apple Pay, Google Pay, and increasingly others), plus the access and management layers around that.
- **Operating model:** scaled agile. The four leadership roles around a train are Product Owner, Product Manager, Architect, and Run Train Engineer. My lane is leading the Product Owners and carrying vision where it is needed.
The single most important thing to understand about our domain is the next section: not all Synchrony cards are equally able to reach a digital wallet, and the reason is structural.
---
## 2. The Synchrony card-product model and the tokenization reality
This is the core domain knowledge. "Tokenization" here means getting a card provisioned into a third-party wallet (Apple Pay / Google Pay) by issuing a network token for it. Whether we can do that cleanly depends entirely on the product type and its BIN structure.
| Product | Network side? | BIN / client ID structure | Tokenization reality |
|---|---|---|---|
| **Co-branded** | Yes, 100% on network | Standard network BIN | Easy. Already a network card; tokenizes and works in wallets cleanly. |
| **Dual card** (e.g. TJX, JCPenney) | Yes, has a network side AND a private-label side | Its own unique BIN + client ID | Tokenizable. The private-label portion is in-store only, but the unique BIN is what lets the card provision into a wallet. |
| **True private label** (e.g. Ashley Furniture and deferred-interest / "discount" merchants) | No network component at all | Thousands of merchants pooled under ONE client ID across a few BIN structures | Nearly impossible. You cannot carve BIN capacity per merchant, so you cannot cleanly tokenize an individual merchant's cards. This is the real tokenization struggle. |
**The rule that generalizes:** unique BIN means tokenizable; pooled BIN means stuck.
**The Lowe's anomaly:** Lowe's is technically private-label-only (the network card was never switched on), but it has its OWN unique BIN structure. That unique BIN is the entire reason Lowe's could be tokenized and put into the wallet. So I treat Lowe's like a dual card. It is the clearest proof of the rule above.
**Why the pooled-BIN limit will not be fixed soon:** it is the product of decades of account-setup decisions. Re-architecting the pooled true-private-label structure to give each merchant its own BIN capacity would be a massive undertaking, and nobody is willing to fund it. Treat it as structurally locked, not a near-term roadmap item.
**Why it matters:** the tokenization wall on true private label is the structural reason a large slice of Synchrony's book cannot reach Apple/Google Pay today. That is directly relevant to the wallet and provisioning roadmap and to anything touching the Synchrony Pay vision.
**A clarification habit worth keeping:** when an industry presenter or a partner says "private label," it is worth asking whether they mean the dual-card type (TJX) or the true-private-label type (Ashley Furniture). The wallet and tokenization implications are opposite, and the word gets used loosely.
---
## 3. The wallet-provisioning platform map
The train owns four platforms, organized by function. Knowing which platform owns which job is useful context when triaging a request or drafting a status update.
- **Tokenization and Digital Wallet Services**: the backend APIs and services connecting our processor to Google and Apple to provision Synchrony accounts into digital wallets. Backend only.
- **Provisioning Operations (Kanban)**: the operational coordination layer: submitting configuration paperwork to the processor / Apple / Google, following up on configs, and verifying client enablement. No dev resources; it is coordination work.
- **Card Access**: our homegrown provisioning front door. A QR code or SMS short-code entry point leads to authentication and a landing page where the user adds the card to Apple Wallet or Google Pay. It also handles a temporary shopping pass for in-store checkout when the user has no wallet yet.
- **Digital Wallet Access Manager**: downstream of Card Access. Once authenticated, the user lands here to add, remove, rename, or freeze wallets.
Adjacent context: there is a separate private-label ecommerce checkout platform (UniFi) that handles online checkout for Synchrony private-label cards. It is not part of Emerging Payments today, but it is the natural other half of a multi-channel Synchrony Pay story.
---
## 4. The Synchrony Pay vision (multi-channel)
The strategic idea the train orbits is a Synchrony-branded payment experience that works across more than one channel: in-store, over the phone, and in chat, not only inside a third-party wallet. The tokenization reality in Section 2 is why this matters: for the part of our book that cannot reach Apple/Google Pay, an issuer-controlled, multi-channel pay experience is the alternative path to being present at the point of sale. Section 5's Paze discussion is the industry's version of the same bet.
---
## 5. Industry context (Fiserv Issuing client event, Omaha, June 2026)
Captured across a full day of Fiserv Issuing product sessions. Figures and names are approximate; mechanics and trends are high confidence.
### 5.1 Paze, the issuer-led wallet
- **What it is:** an FI-branded wallet built by Early Warning Services (the bank consortium behind Zelle) that deliberately routes around Apple/Google Pay. (Note the spelling: **Paze**, not "Pace.")
- **The premise:** only about 10% of cardholders bother to load a card into a third-party wallet. Paze targets the other ~90%, people who trust their financial institution and would use a wallet embedded in their bank's app. Cards auto-enroll with no manual provisioning step.
- **The pitch to issuers:** it avoids wallet-provisioning fraud and avoids the "Apple tax" (Apple's per-transaction basis points on credit).
- **Public grounding:** today Paze is EWS's online-checkout wallet, already live and offered by Bank of America, Capital One, Chase, PNC, Truist, U.S. Bank, Wells Fargo, and (as of early 2026) Citi, with 200M+ enrolled cards. The in-store / everyday-spend framing was the Fiserv roadmap extension as presented on stage; worth confirming scope before citing externally.
- **My read:** Paze is a genuine strategic alternative to the "get our cards into Apple/Google Pay" path. It is the inverse bet: build an issuer wallet so you do not have to provision into someone else's. Emerging Payments evaluated Paze roughly a year ago and set it aside for bandwidth, not for lack of merit. The point now is to be able to name and re-evaluate the option, and to revisit when capacity allows.
### 5.2 Digital-wallet provisioning roadmap (as presented)
- Samsung Wallet support and quick-provisioning into the Amazon wallet land between the mid-year and fall releases.
- Quick-provisioning for virtual cards is targeted for early 2027.
- Full tokenization/detokenization and card-lifecycle ("hard-load") management were described as table stakes.
- The processor now works directly with Apple on a frontline basis, so Apple mandates and registration changes reach the processor first.
### 5.3 Agentic commerce: where the market is and how an issuer gets ready
The panels described the market as "the first half of the first inning." Live agentic-commerce volume is still tiny and in a testing phase. Two broad AI strategies were contrasted: one large AI provider partnered with a card network and is oriented toward owning the end-customer checkout; another is going B2B, opening APIs and betting on agent-to-agent negotiation between businesses. Issuers were described as caught in the middle with the least clear direction.
**Fiserv's "three ways an issuer gets ready" (a useful readiness skeleton):**
1. **Be in the wallet.** Some agentic checkout runs off the wallet, so cards (including private-label and gift cards) need tokens issued so they work.
2. **Redirects.** Discovery happens in the AI app, then the agent redirects to the merchant site/app for checkout. Most issuers are already covered here.
3. **Connectivity rails.** Build rails through processors to route to label cards, gift cards, and other programs for an agent-to-agent future.
Open questions in the room: liability when transactions are fully agent-to-agent, and data sovereignty (nobody wants agents harvesting transaction data to train competing models). Standards are still forming. The merchant-advisory line was: "Engage now. Do not let agentic commerce be something that happens to you."
**Why Synchrony is differently positioned:** we are heavily private-label and we sit close to our retail merchants. The argument that "an issuer who is also close to the merchant can integrate inventory and intent" is more true for us than for most issuers in the room.
### 5.4 The Walmart case and the "rotisserie chicken" model (my thesis)
I am skeptical that *consumer* agentic checkout takes off the way the hype suggests, and the Walmart case is the live proof.
- Walmart launched ChatGPT Instant Checkout (~200K products) in October 2025 and pulled it a few months later.
- The publicly stated reasons (disclosed by a Walmart executive in March 2026): in-chat purchases converted at roughly a third the rate of click-throughs to Walmart.com, and the AI provider's scraping of retail sites left customers seeing stale prices and out-of-stock items at checkout.
- My read is that the stated reasons are real but not the whole story. You do not spend effort to remove something already built and running unless you learned something you disliked. My bet is they learned there was no cross-sell or upsell in the agentic channel.
- **The tell that this is about owning the relationship:** Walmart did not abandon AI shopping. They replaced the third party's checkout with their *own* agent (Sparky), embedded as a plugin in both ChatGPT and Gemini, so they stay findable inside the models while keeping the customer, cart, and checkout on Walmart's own rails.
**The mental model:** a Costco rotisserie chicken is a roughly $5 loss leader parked at the back of the store on purpose, because the walk past everything else grows the basket and pays for the loss. Naive agentic commerce is like wheeling that chicken into the parking lot with a drive-through: the customer gets exactly what they asked for, and the store loses every impulse buy that justified the deal. The better model, the one merchants actually want, is to be discoverable inside the LLMs (the new SEO) but bring the customer back to their own brand, where the merchant's own AI agent can cross-sell and delight. Lowe's already does a version of this well: its on-site agent notices you are buying drywall and asks whether you have mud and tape.
**The implication for an issuer:** the relationship, not the transaction, is the prize. Our value is strongest where we help a merchant stay findable and keep the customer, not where we help disintermediate the merchant from their own basket.
### 5.5 Fraud trends and the AI threat landscape
Framing from Fiserv's fraud leadership: "trust is your currency," and false declines erode trust as much as fraud does (roughly 1 in 6 consumers had a false decline in the last six months, and a meaningful share will stop using a card after a single false decline).
- **The fastest-growing wallet attack: man-in-the-middle token-provisioning fraud.** An attacker intercepts the one-time passcode mid-provisioning and loads the victim's card into the attacker's wallet. At Synchrony this routes to the credit-risk team, not the provisioning/tokenization owners.
- **First-party fraud** (the customer disputes a legitimate charge) is now roughly a third of all claims and the most prevalent fraud type worldwide, with a generational shift in attitudes flagged as the leading indicator. Treat the specific survey-style percentages cautiously until the deck arrives.
- **AI for good:** dramatically faster fraud detection and investigation. Custom-model upload (issuers running their own models inside the fraud platform) is becoming standard.
### 5.6 AI governance and the mainframe-modernization pattern
Three different Fiserv leaders independently described the same architecture: build a governed knowledge base / context layer, then let AI agents work against it, with a human always in the loop. The headline example was applying AI to a core-platform rewrite (tens of millions of lines of decades-old code), feeding the entire codebase plus every doc and incident record into a knowledge graph that acts as the governance and context layer, which then feeds code-generation models.
- **The pattern is the takeaway:** control the inputs, build the context layer, build agents, keep humans validating. Human-in-the-loop is non-negotiable (they cited a model that, lacking controls, deleted an entire file structure because it decided the files "must not be necessary").
- **Calibration caveat:** the productivity figures (large percentages of AI-generated stories, code, and tests; hundreds of thousands of hours saved) were presented on stage to a room of Fiserv's own clients. Informally, several Fiserv employees downplayed it and said they had not yet seen much benefit in their own work. Anchor on the *pattern*, not the specific savings numbers.
- **My read:** Fiserv looks ahead of where we are on internal AI adoption, and a large part of the gap is likely tooling-access policy: they appear to let engineers use broadly-available tools where we are more restrictive. The "context layer, then agents, with a human in the loop" pattern is the responsible blueprint and is worth holding up internally. The internal prerequisite for us is data readiness: the institutional-memory pattern only works if our own knowledge is machine-readable, and today a lot of it lives in Atlassian/Confluence/Jira and needs cleanup first. That data-readiness work sits with the agile team and our Synchrony-side agents.
### 5.7 Transaction Classification Service
A new self-service capability that reclassifies a transaction after authorization (merchandise vs. cash) based on new network guidance for account-funding transactions. It is the first real risk-based-pricing lever (for example, repricing cardholders maxing cards on crypto or funding multiple P2P accounts). Self-service, tied to the processor's pricing system, with MVP on one network first and the others following.
### 5.8 Office Transformation and the Product Solutions / Development split
The processor restructured its core-platform org into a "front door" (Product Solutions: a diagnostic intake that gets past the customer's stated prescription to the true desired outcome, producing a written solution document) and an execution arm (Product Development). Every request resolves three ways: meet it with something that exists, something on the roadmap, or build something new. Solution documents live in a queryable repository, and every new feature ships with a document purpose-built for a language model to read and serve to frontline support ("scale the framework, not the headcount").
An issuer in the room made the key ask: the processor should proactively tell issuers "if you want to leverage X later, do Y now," so issuers are not forced into their own multi-year prep projects.
**My read:** two things. First, it is worth getting Emerging Payments early visibility into the Office-Transformation dependency mapping, so we can see what to prepare for versus wait for, rather than getting surprised by a multi-year prep requirement later. Second, the LLM-as-institutional-memory pattern is exactly where we want to go, and it depends on our own knowledge being machine-readable first (see 5.6).
---
## 6. Open product ideas (mine, unvalidated)
These are my own ideas, flagged as not yet validated. Treat them as thinking to develop, not committed direction.
- **De-tokenization outside the BIN.** Tokenizing pooled-BIN true private label is not on the processor's roadmap. A possible ask: have the processor provide a token with a de-tokenization method that lives *outside* the BIN structure, decoupling the token from per-BIN capacity. If that worked, it could be the unlock for the part of our book that is structurally stuck today (Section 2). Unvalidated; a "maybe we raise this to them" item.
- **Instructive (smart) OTP.** A cheap mitigation for man-in-the-middle provisioning fraud (5.5): make our OTPs instructive rather than bare codes. For example, "It looks like you're adding your card to Apple Pay. Here's your code. If this wasn't you, do not share it." Context in the message tips the user off mid-attack. This belongs to the credit-risk team's lane.
---
## 7. Quick glossary
- **BIN**: Bank Identification Number; the leading digits that identify the issuer/product. Whether a product has its own unique BIN or is pooled with others is the hinge for tokenization.
- **Tokenization**: issuing a network token so a card can be provisioned into a digital wallet.
- **De-tokenization**: resolving a token back to the underlying account; today tied to the BIN structure.
- **Provisioning**: the act of loading a card into a wallet.
- **Co-branded / dual card / true private label**: Synchrony's three product types; see Section 2.
- **Paze**: Early Warning Services' issuer-led wallet; see 5.1.
- **Agentic commerce**: purchases initiated or completed by an AI agent on the user's behalf; see 5.3 and 5.4.
- **Office**: the processor's core issuing platform; "Office Transformation" is its multi-year modernization (5.8).
---
*Prepared as a domain note for my Synchrony agent. Product mechanics and trends are high confidence; specific figures and names from the June 2026 client event are approximate and should be reconciled against the official deck if one is shared.*