Benefits of Network Tokenization

Benefits of Network Tokenization

Speakers: Sanjeev Sharma, Payments Legend, GoFundMe (formerly Broadcom, Visa, Meta)

Conference: Payment Village

YouTube: https://www.youtube.com/watch?v=TEtQczjPg90

Overview

In this insightful talk at Payment Village, Sanjeev Sharma, a payments legend with a distinguished career spanning Broadcom, Visa, Meta, and currently GoFundMe, delves into the transformative power of network tokenization in combating payment fraud. Sharma, who was instrumental in writing the initial specification for network tokens at Visa, provides a comprehensive overview of how this technology has fundamentally reshaped the landscape of digital payments, making transactions significantly more secure. He highlights that while many consumers may not explicitly know what a network token is, they have almost certainly used one through services like Apple Pay, Google Pay, or even Netflix.

The core of Sharma's presentation centers on the innovative ways network tokens address long-standing vulnerabilities in traditional card payments, particularly focusing on cross-domain fraud and same-domain fraud. By introducing dynamic, digitally controlled credentials that replace static Primary Account Numbers (PANs), network tokens not only mitigate the impact of data breaches but also enable a more flexible and robust security framework for both card-present and card-not-present transactions. This talk is essential for anyone involved in payment security, fraud prevention, or digital commerce, offering a deep dive into the mechanisms that underpin modern secure payment experiences.

Background

▶ Watch: Introduction to network tokens and common use cases (0:00)

To understand the profound impact of network tokenization, it's crucial to first categorize payment types and the associated fraud vectors that have historically plagued the industry. Payments are broadly divided into two domains: Card Present (CP) and Card Not Present (CNP). Card Present transactions occur when a physical card is presented at a point-of-sale terminal, typically involving dipping, tapping, or swiping. Card Not Present transactions encompass all online purchases, where the physical card is not present at the point of interaction.

Corresponding to these domains are two primary types of fraud. Cross-domain fraud is the most prevalent, accounting for approximately 70% of all payment fraud. This occurs when card information stolen from one domain (e.g., a physical restaurant transaction) is subsequently used fraudulently in another domain (e.g., an online purchase). A classic example involves a card being skimmed at a restaurant, with the stolen details then used for e-commerce transactions. The other category is same-domain fraud, where credentials stolen from a specific domain are used within that same domain. Historically, magnetic stripe cards were highly susceptible to same-domain fraud due to their static data, allowing criminals to skim card data and create cloned cards for in-store use.

Over time, the payment industry has introduced several mitigations to combat these fraud types. For Card Present transactions, the introduction of chip cards (EMV) marked a significant leap forward. Chip cards embed a cryptographic key, generating unique, dynamic data for each transaction. This innovation effectively eliminated same-domain fraud in the card-present world, as stolen transaction data could not be replayed. However, in regions where magnetic stripe cards are still prevalent, these vulnerabilities persist. For Card Not Present transactions, the industry has relied on a suite of technologies and services, including transaction monitoring, device fingerprinting, 3D Secure (3DS), and more recently, Passkeys. While these measures have helped to reduce CNP fraud, it remains a significant challenge, prompting the continuous search for more robust solutions.

Key Findings

▶ Watch: Explaining cross-domain fraud, the industry's biggest type (2:00)

Sanjeev Sharma highlights that network tokens emerged as a critical innovation to address the persistent fraud challenges, particularly in the CNP space and cross-domain scenarios. A network token is essentially a surrogate value for a customer's Primary Account Number (PAN). When a user adds a card to a digital wallet like Apple Pay or Google Pay, or registers it with a merchant for card-on-file transactions, the payment network (e.g., Visa, Mastercard, American Express) generates a unique network token. This token is digitally issued, meaning it is never printed on a physical card and its full value is typically not exposed to the user, only the last four digits for customer service purposes.

Crucially, network tokens maintain the same format as a traditional PAN (e.g., 16 digits for Visa/Mastercard, 15 for Amex). This design decision was deliberate, ensuring backward compatibility across the vast payment ecosystem, allowing merchants and issuers to adopt the technology without extensive system overhauls. A single PAN can have multiple network tokens associated with it; for instance, adding the same physical card to both Apple Pay and Google Pay will generate a distinct network token for each wallet. Conversely, one network token is strictly linked to one PAN.

When a transaction is initiated using a network token, the payment network performs a real-time mapping from the token back to the original PAN. This allows the issuing bank to process the transaction using its existing infrastructure, which is historically coded to handle PANs. This architecture significantly eased the adoption of network tokens, as it isolated the complexity of tokenization primarily within the network space, minimizing impact on banks and merchants.

The lifecycle management of network tokens is entirely digital and programmatic. Tokens can be provisioned (created), deleted, or suspended. Only issuing banks have the authority to suspend a token, offering a powerful, instant control mechanism. This digital control is a stark contrast to physical cards; if a PAN is compromised, banks must physically mail a new card, a process that is both costly (around $20 per card) and susceptible to "friendly fraud" during delivery. With network tokens, banks can instantly delete or generate new digital credentials, drastically reducing response times and operational expenses. Token provisioning often requires strong authentication (e.g., 3DS, Passkeys) to ensure the legitimate cardholder is requesting the token, though exceptions exist for bulk tokenization by trusted merchants for card-on-file conversions.

Technical Deep Dive

▶ Watch: Chip cards and dynamic data's impact on in-store fraud (4:00)

The technical architecture of network tokens is designed to address fraud at its root, particularly the pervasive cross-domain and same-domain fraud.

Cross-Domain Fraud Elimination

One of the most significant benefits of network tokenization is its ability to virtually eliminate cross-domain fraud. When a network token is provisioned, the payment network binds it to a specific domain: either Card Present (CP) or Card Not Present (CNP). For example, a network token generated for a Google Pay wallet is typically bound to card-present transactions. If a malicious actor were to somehow steal this device-bound token and attempt to use it for an online (CNP) purchase, the transaction would be declined by the network because the token's domain restriction would be violated. This critical control mechanism immediately nullifies the largest source of payment fraud.

An important exception to this domain binding is Apple Pay tokens. Apple claims that its device security architecture, particularly the Secure Element, is robust enough to allow a single token to be used for both CP and CNP transactions. This trust in Apple's security model allows for greater flexibility for Apple Pay users.

Same-Domain Fraud Reduction

Network tokens also significantly reduce same-domain fraud by leveraging the advanced security measures pioneered by chip cards. Every transaction made with a network token generates unique, dynamic data, making it impossible to replay stolen transaction credentials. Even if a fraudster manages to intercept a network token and its associated dynamic data from a transaction, attempting to reuse that data for a subsequent transaction will fail. This mirrors the non-replayability feature of EMV chip cards, extending this critical security benefit to digital payments.

Credential Storage and Key Management

The method of storing the network token and its associated cryptographic key is central to its security model, varying based on the underlying platform:

• Apple Pay (iOS devices): Apple utilizes a Secure Element, a dedicated, tamper-resistant chip akin to a SIM card. This hardware component securely stores the network token and a static cryptographic key once the card is provisioned. The Secure Element is highly resistant to external attacks, and its operations are typically backed by biometric authentication (Face ID or Touch ID). Because of this robust hardware-backed security, banks are comfortable allowing Apple Pay tokens to be used for both CP and CNP transactions, as the key is deemed highly secure and non-extractable. The static key allows the device to generate dynamic transaction data for an indefinite number of transactions as long as the token is valid.

• Android Wallets: For Android devices, the approach to key storage has evolved. Historically, credentials could be stored in device memory, which is more volatile and potentially susceptible to software-based attacks compared to a Secure Element. While newer technologies like Secure Enclaves and secure memory spaces have emerged, they are still considered to have a higher potential for compromise than a dedicated hardware Secure Element. To mitigate this increased risk, payment networks and issuers implemented a system of dynamic key usage limits for Android-based tokens:
• Single-use keys: The key is valid for only one transaction, requiring a new key for each subsequent payment.
• Transaction count limits: The key might be valid for a specific number of transactions (e.g., 5 or 10) before a new key is required.
• Cumulative spend limits: The key's validity is tied to a monetary threshold (e.g., $1,000). Once this cumulative spend is reached, a new key must be provisioned.
• Time-to-live (TTL): Keys might expire after a set period (e.g., 10 days), regardless of usage.

These limits are decided by the issuing bank, often based on the cardholder's risk profile or the type of card (e.g., classic vs. premium). This approach manages the maximum potential damage if a key were compromised, allowing banks to adopt Android wallet tokenization with controlled risk. Sharma notes a practical trade-off: allowing multiple transactions per key improves user experience in situations with poor network connectivity (e.g., in a subway), preventing a valid transaction from failing due to an inability to refresh the key.

Card Not Present (CNP) Tokenization Enhancements

Network tokens extend dynamic data security to the CNP world, which traditionally relied on static PAN, expiration date, and CVV2. For CNP network tokens, the cryptographic key generally remains in the cloud with the payment network, rather than being provisioned to a device. When a merchant wishes to process a CNP transaction using a network token, they make a real-time request to the payment network to generate a cryptogram (dynamic data) for that specific transaction.

The network, using its securely stored key, generates this unique cryptogram and sends it back to the merchant. The merchant then submits the transaction with this cryptogram for approval. Upon receiving the transaction, the network verifies the cryptogram's validity and ensures that it was submitted by the same merchant who requested it. This dynamic cryptogram generation introduces a layer of non-replayability and transaction uniqueness previously absent in standard CNP transactions.

Additional security layers for network tokens in CNP include:

• Obfuscation: The actual network token value is never fully visible to the cardholder or the merchant, reducing the risk of manual theft or accidental exposure.
• Network-level API security: Every interaction with the network for provisioning a token or generating a cryptogram requires strong API key authentication and authorization. Only approved and vetted "token requestors" (merchants, wallets) can perform these operations, adding a critical layer of security at the network interface.

As a result of these combined controls, network tokens have demonstrated significant reductions in fraud. Sharma cites a Mastercard study indicating a more than 50% reduction in total fraud due to the implementation of network tokenization.

PAN vs. Network Token Comparison

The talk draws a clear comparison between traditional PAN-based payments and network token-based payments:

| Feature | PAN-based Payments | Network Token-based Payments |

| :---------------- | :-------------------------------------------------- | :---------------------------------------------------------- |

| Data Type | Static (PAN, CVV2, Expiration Date) | Dynamic (unique data per transaction) |

| Usage Scope | Works everywhere; same data across all merchants | Can be bound to a device, merchant, or single transaction |

| Breach Surface| High; same PAN stored at multiple places, widespread impact if breached | Low; token from one merchant cannot be used elsewhere; localized impact if breached |

| Lifecycle | Physical card mailing, slow replacement, high cost ($20/card) | Digital, instant deletion/generation, low cost, programmatic control |

The reduced breach surface is a critical advantage. If a merchant's database storing PANs is compromised, that PAN can be used anywhere. However, if a merchant's database storing network tokens is breached, those tokens are typically bound to that specific merchant or domain and cannot be used elsewhere, limiting the damage and simplifying remediation for banks.

Address Space and Future Considerations

A valid concern raised during the Q&A was the finite address space for 16-digit PANs. The rapid digital issuance and deletion of network tokens exacerbate this problem. Sharma acknowledges this, explaining that Visa, for instance, reclaimed unused 16-digit PAN blocks from banks to reallocate for token generation. Looking ahead, the industry is actively transitioning to 19-digit PANs and 8-digit Bank Identification Numbers (BINs) (up from the traditional 6-digit BINs). This expansion will significantly open up the address space, accommodating the growing demand for digital credentials.

Token Provisioning and PAN Association

The association between a PAN and a network token occurs during the provisioning process. When a user attempts to add a card to a wallet or merchant's file, the wallet/merchant communicates with the payment network and the issuing bank. The bank then makes a real-time decision: either instantly provision the token or require additional authentication from the cardholder. This authentication can involve a One-Time Password (OTP), a customer service call, or logging into the banking application, ensuring that the legitimate cardholder is authorizing the token's creation and association with their PAN.

Network Tokens vs. PSP-Specific Tokens

Sharma clarifies that network tokens differ from tokens offered by Payment Service Providers (PSPs) like Stripe, Adyen, or CyberSource. While PSPs also offer tokenization services, their tokens are typically closed-loop, meaning they only work within that specific PSP's ecosystem. Network tokens, in contrast, are open-loop and universally compatible across all PSPs and acquirers, providing greater flexibility and interoperability for merchants and cardholders.

Integration with Passkeys

Finally, Sharma addresses the relationship between network tokens and Passkeys. He notes that they are orthogonal concepts but can be used together to enhance security. Passkeys, as a strong authentication mechanism, can be integrated into the token provisioning flow. Instead of relying solely on OTPs or customer service calls, banks can leverage Passkeys to authenticate the user's identity when they request a new network token, thereby creating a more secure and seamless provisioning experience.

Demo / Proof of Concept

▶ Watch: Defining network tokens as a surrogate value of PAN (6:20)

This technical talk did not include a live demonstration or proof of concept. Sanjeev Sharma focused on explaining the architectural and operational benefits of network tokenization through conceptual diagrams and real-world examples of its impact on fraud reduction.

Defensive Implications

▶ Watch: Network token format, security, and multiple tokens per PAN (7:30)

The widespread adoption of network tokenization presents significant defensive implications for all stakeholders in the payment ecosystem:

1. For Merchants:

• Reduce Breach Impact: Merchants should prioritize implementing network tokenization for card-on-file storage, especially for CNP transactions. This significantly reduces the impact of a data breach, as stolen tokens are typically bound to the specific merchant and cannot be easily reused elsewhere.
• Enhance Transaction Security: By leveraging dynamic cryptograms generated by the network for CNP transactions, merchants can add a critical layer of security that static PAN data lacks, reducing their fraud liability.
• Improve Customer Experience: Secure digital payments foster greater customer trust and can lead to smoother checkout experiences, particularly when integrated with digital wallets.

1. For Banks and Issuers:

• Proactive Fraud Management: Banks should actively promote and utilize network tokenization. The ability to instantly suspend or delete compromised digital tokens, without the cost and delay of physical card reissuance, is a powerful tool for fraud prevention and customer service.
• Granular Risk Control: Implement and fine-tune dynamic key usage limits for tokens provisioned on platforms like Android, based on cardholder risk profiles. This allows for controlled risk exposure while maintaining usability.
• Strengthen Provisioning Authentication: Integrate robust authentication methods like 3D Secure and Passkeys into the token provisioning process to ensure only legitimate cardholders activate new tokens.

1. For Consumers:

• Adopt Digital Wallets: Consumers should be encouraged to use digital wallets (Apple Pay, Google Pay) and tokenized card-on-file services. These methods offer superior security compared to manually entering static card details or using physical cards that are susceptible to skimming.
• Awareness: Understanding the benefits of network tokens can empower consumers to make more secure payment choices and appreciate the underlying security mechanisms protecting their transactions.

1. For Payment Networks and Industry Standards Bodies:

• Continued Innovation: Continue to evolve network token specifications to address emerging threats and expand functionality, such as the transition to 19-digit PANs and 8-digit BINs to ensure long-term scalability.
• Promote Adoption: Drive wider adoption of network tokenization across all payment channels and geographies, ensuring consistent security standards.

In essence, the overarching defensive implication is to reduce reliance on static, easily compromisable PAN data and embrace dynamic, digitally controlled credentials that are inherently more resilient to modern fraud techniques.

Key Takeaways

• Comprehensive Fraud Mitigation: Network tokens fundamentally reduce both cross-domain fraud (by binding tokens to specific domains like Card Present or Card Not Present) and same-domain fraud (by generating unique, dynamic data for each transaction, preventing replay attacks, similar to EMV chip cards).
• Digital Control and Cost Efficiency: Unlike physical PANs, network tokens are digitally issued and managed, allowing for instant provisioning, suspension, or deletion. This significantly reduces the operational costs and time associated with reissuing physical cards after a breach, saving banks approximately $20 per card.
• Platform-Specific Security Architectures: The security implementation of network tokens varies by platform. Apple Pay leverages a Secure Element for robust, hardware-backed key storage, allowing static cryptographic keys. Android wallets often use device memory, necessitating dynamic, limited-use keys (e.g., single-use, transaction limits, spend limits, or time-to-live) to manage risk.
• Enhanced CNP Security: Network tokenization extends dynamic data protection to Card Not Present (CNP) transactions, where the key remains in the cloud. Merchants request a real-time cryptogram for each transaction, providing a unique, non-replayable value that significantly improves CNP security.
• Open-Loop Interoperability and Ecosystem Impact: Network tokens are "open-loop," meaning they are compatible across all Payment Service Providers (PSPs), unlike proprietary PSP-specific tokens. They also integrate with strong authentication methods like 3D Secure and Passkeys during provisioning, further bolstering security. This holistic approach has led to reported fraud reductions of over 50% (Mastercard study).
• Scalability and Future-Proofing: The payment industry is proactively addressing the finite address space of 16-digit PANs by transitioning to 19-digit PANs and 8-digit Bank Identification Numbers (BINs) to accommodate the growing volume of digital credentials and ensure the long-term viability of tokenization.

About the Speaker(s)

Sanjeev Sharma is a highly respected figure in the payments industry, recognized as a "payments legend" by the conference host. His extensive career spans leading technology and financial companies, including Broadcom, Visa, Meta, and currently GoFundMe. Sharma played a pivotal role at Visa, where he was part of the foundational team responsible for writing the first line of the network token specification and overseeing its subsequent deployment. This unique firsthand experience in developing and implementing such a critical payment security technology underscores his deep expertise and authority on the subject of network tokenization.