Side-by-Side Tokenization: Building Merchant Routing Choice into a New Debit Network

Tokenization Leads to a Network routing Paradox

Tokenization solved an important security and regulatory problem in digital payments: merchants no longer need to retain the underlying Primary Account Number (PAN) to support card-on-file (COF) transactions.

But it created another problem – routing control.

A merchant may have a debit card that can legitimately route over multiple enabled debit networks. Yet when the merchant stores a network token issued by a front-of-card network, that token may carry network or processing restrictions. The merchant therefore loses the ability to choose an alternate debit network for a subsequent digital tokenized transaction.

“The merchant has more security, but potentially less routing choice.” – Debashis Bhattacharyya

Side by Side Token – an Introduction

A side-by-side token architecture addresses that problem by allowing multiple network-specific tokens representing the same underlying payment account to coexist. It gives the merchant the ability to select the appropriate token and therefore the network route dynamically during transaction processing.

This concept is based on an important design principle that maintains three relationships –

1. Payment Identity – PAN and Account
2. Token Identity – Primary and Secondary tokens
3. Network Routing

PULSE’s Side-by-Side (SXS) Token Service is a real-world example of this model. PULSE describes SXS as enabling tokenized card-on-file debit transactions to be routed over PULSE or another participating unaffiliated debit network, with cryptogram validation and no change to the cardholder experience.

The objective of this article is not to reproduce PULSE’s implementation. Instead, it uses the publicly available patent disclosures as a reference architecture for how a new debit network could build its own side-by-side token capability.

The Problem – Tokenization dictating routing

Consider a consumer who has a debit card issued by Bank A.

That card supports:

• Network A: Front-of-card network
• Network B: An alternative debit network

A merchant stores the customer’s card for future purchases. Traditionally, the merchant token comes from the network.

Customer PAN -> Front of Card Token Service -> Merchant Token -> Merchant Card on File

For security reasons, that token may be restricted to transactions routed through the network that issued it. Hence, the transactions are always routed through Network A.

The Solution – Side by Side Token

The core idea of this solution is simple. Let us use the same scenario here as well. In this case, two tokens are generated and stored at the merchant. One for the front of card – A, and an additional for the Debit Network – Back of card – B.

Please note – they are co-existent but not interchangeable. They have their own Token PAN, token type, network association, lifecycle status, routing eligibility, relationship with the PAN and are independent of each other.

The merchant’s payment platform can then select the appropriate token according to its routing strategy as depicted in this diagram.

Reference Architecture

Functional and Token Workflow

Provisioning and Eligibility

1. Check Card eligibility for Secondary Tokenization. Currently it is done via BIN/account-range capability file but can be extended to product/issuer identifiers.
2. Provision the secondary token via the Debit Token Service. The token is sent to the merchant hiding the PAN as

{

“token”: “NDN_TOKEN_123456789”,

“token_type”: “SECONDARY”,

“network”: “NDN”,

“status”: “ACTIVE”,

“cryptogram_required”: true

}

The merchant saves this information in the database along with the primary token procured before from the Primary network.

3. The network also needs to support complete token lifecycle management. Events like Update, Suspend, Expire, Delete etc. need to be supported. The network can also provide Account Updater services to compliment the lifecycle management services. This will ensure issuers are able to send replacement tokens to merchants or processors to maintain uninterrupted COF relationship.
4. The network also should keep a log of the token requestor. This will ensure the network understands – who requested the token, associated merchant, applied use cases, network route and privileges of the requestor.

Merchant View, Routing and Processing

The merchant now has multiple payment credentials associated with the same customer payment account.

The customer is invisible to this information, as they see the last 4 digits in the token on screen at the merchant’s e-commerce portal.

The merchant needs to build a routing engine based on the rules and network preference that can take advantage of this capability. The idea is for the merchant to be able to choose between the two tokens to maximize profits and minimize costs both for themselves and the customer without degrading the customer experience. The routing engine can route based on many factors –

• Transaction Cost
• Authorization Performance and Approval %
• Network Reliability
• Preference of the merchant
• Other characteristics like recurring, CNP, amount, MCC, Issuer etc.

A simple NDN based transaction will look like this

The presence of a secondary token should not be the reason for routing through NDN. It should be based on rules owned and managed by the merchant.

Debit Network Enablement – Capabilities

The debit network needs to carefully design a monetization policy that incentivizes merchants for routing through them. This can be made lucrative through lower cost, flexibility, safety and performance.

The table below lists the capabilities required by the network for enablement. These can be prioritized by applying the MoSCoW principle.

Conclusion

The Side-by-Side token is a choice, and flexibility a merchant demands in today’s world. It empowers the merchant. It allows them to own and manage their routing mechanism and provide better services to their customers through low-cost routing options. The value is “One payment account can have multiple secure, lifecycle-managed network credentials, while the merchant retains the ability to choose the network route.”