With all the talk about Token Service Providers (TSP) and token requesting, I felt it was worth describing a bit more about the role of a "Token Requestor." The way the term is bandied about would lead most to believe that this is a single entity that works to pull temporary or dynamic transactional data from a master TSP for use on the mobile device, but you are about to find out it's a bit more complicated and the decision you make around this topic can have serious consequences in the future.
We all know that the current normalized TSPs or Master Token Service Provider services are the domain of the card networks - presently MasterCard, Visa and AMEX. I don't expect that role to change overnight or in the next year or for some banks, maybe ever. But if banks expect to be able to control their own destiny with the decision, they’ll need to understand some important differences about the term “Token Requestor.”
What’s really going on under the hood
Contrary to what some providers may tell you, “Token Requestor” isn’t a single entity but actually two separate roles which work in tandem. The goal of this article is to help readers understand the roles better because in reality the roles are as different as comparing apples and oranges (or more appropriately stated "service" and "consumer of service"). And more importantly, the selection of the roles dictate the end result of the service and in that, how “locked in” or “not locked in” you are to one provider.
Here is a high level diagram that depicts how tokens are issued to help better understand the 2 tiered roles of token requestors.
Let’s break down the "Token Requestor" blob we have above into two distinct roles before identifying the practical examples of entities that fill those roles.
Tier 1 token definition: The root token requested from the Token Service Provider which is static data for the life of the issued card. A Tier 1 token has the ability to be autonomous from the TSP and service individual transaction level Tier 2 token issuance because all data required to create many Tier 2 tokens are available in their respective parent Tier 1 token. So basically, the Tier 1 token is the creator for all Tier 2 tokens. It is a parent->children relationship.
The tier 1 role is that of being the primary service provider for individual cards and can be summarized by these tasks:
- Requesting the static token from the TSP which includes the tokenized PAN and the card master key
- Protecting the card master key
- Generating all Tier 2 tokens from the card master key
- Responding to service requests to receive new Tier 2 tokens
- Responding to issuer triggers for card life cycle events such as:
- card personalization
- card termination
- card disable
- card enable
Tier 2 token definition: The secondary or child token that is generated from the root or parent token and used for individual payment transactions. This token is considered limited use and is deemed "ok" to be housed in the mobile device application.
The Tier 2 role is to protect and deliver the tokenized payment information to the acquirer for individual transactions and can be summarized by these tasks:
- Requesting the dynamic token from the Tier 1 service
- Protecting the dynamic token
- Managing the lifecycle of the dynamic token
- Delivering the dynamic token to the acquirer when requested
Some practical examples of the token request process are listed below and include some current day entities who are performing those roles:
It is especially important to note in the diagram above how both the Master Token Service and Tier 1 Token Requestor are the same entity in some cases. THEY DO NOT HAVE TO BE AND THEY PROBABLY SHOULDN'T BE. For example both Visa and MasterCard offer the master TSP service but are also performing as a Tier 1 service requestor to their own TSP at the same time. That would mean that a service like we provide as a Tier 1 requestor consumes MasterCard or Visa TSP services, but then ALSO COMPETES directly with them as a Tier 1 requestor. Essentially, what some card networks have proposed greatly reduces your ability to chose competitive service offerings if your needs change in the future.
If this scenario makes you uncomfortable, you have reason to be concerned, the implications could be very costly to your mobile payments strategy in the long run.
The key business driver and need for a company like SimplyTapp in the Tier 1 Requestor role is that we offer a configuration option for the Master TSP services for each card brand which in turn can offer autonomy from the card networks similar to what Apple is able to do through Apple Pay (once they request a token from the networks, they run the service on that token through securing the token master key on the Secure Element). This helps maintain the existing card issuance relationship with the networks status quo when comparing to the existing issuance model of plastic.
Does the Tier 1 Token Requestor service you use allow you to configure or dictate the Master TSP?
See this chart:
| Your Tier 1 Requestor Service is: | You Can Configure and change the Master TSP mid-service | Switch From TSP without card by card migration |
|---|---|---|
| Visa | NO, use Visa TSP only | NO |
| MasterCard | NO, use MasterCard TSP only | NO |
| 3rd Party | Yes, use VISA, MC, or even your own later | YES |
So, the 3rd party Tier 1 Requestor service helps issuing customers with greater migration control. If an issuer has aspirations to run it's own TSP at some point, or select a different TSP, this is an important point NOT to miss.
If a group of cards has been issued through the TSP service to a Tier 1 Requestor, changing that Tier 1 requestor leads to a MIGRATION process rather than just a switch over of the entire card set. This further impacts the mobile application itself as it would be required to be a Tier 2 Requestor to possibly multiple Tier 1 requestors during the change over.
In the event the Tier 1 requestor offers TSP configuration, that configuration to use a different TSP can be changed very similar to a DNS registration which makes the switch overnight and designed not to impact anything downstream (no impact on Tier 2 requestor --mobile app--, or existing cards).
In the event the Tier 1 requestor DOES NOT offer a TSP configuration option, then the only way to move TSP would be to move Tier 1 requestor services, which has a dramatic impact downstream to the Tier 2 requestor / mobile app and also creates a migration switch rather than immediate.
The key question that needs to be asked:
Does your Tier 1 Token Requestor service offer independent configuration of the TSP master service?
If the answer is NO, then you are mostly likely locked-in for the long haul.
If the answer is YES, then you will have more flexibility to some day:
- Run your own or change to a different TSP.
- Negotiate better rates because there is no technical limitation to an immediate switch instead of a slow and resource consuming migration.
