The concept of tokenisation
We are currently observing a rapid digitisation of payment methods with the availability of services on a variety of personal terminals, such as Smartphones and connected objects.
This trend is particularly supported and promoted by global payment players, most importantly by international payment schemes like Visa, Mastercard and UnionPay International.
In order to ensure security and payment data privacy, these players suggested generalising the use of the tokenisation concept. This concept was notably presented and detailed in a 2014 EMVCo specification, updated in 2017. The main payment schemes in the world published their own specifications for mobile payment services, referred to as “Cloud-based payments”, implementing tokenisation.
In card payment systems, in compliance with EMVCo standards, each card is identified by a Primary Account Number (PAN). According to EMVCo, tokenisation consists in replacing physical card’s PAN by a “non-sensitive” identifier, for a particular use, which will be provisioned in the target terminal. For instance, when a user, client of a bank, wishes to digitise their payment card within a “Wallet” type mobile payment application, the Wallet provider would need to request a token from a Token Service Provider (TSP) and to provision this token in its app. More precisely, the token, in EMVCo’s term, isn’t a simple identifier considered as a PAN alias, but a complete card profile containing security data among other things.
Organisation of the tokenisation ecosystem at a global scale
EMVCo has defined the Token Service Provider (TSP) role and gave it a central position in the tokenisation structure, as shown in the diagram below.
Then, a Token Requestor (TR) wishing to digitise a payment card for a certain use case must refer to a TSP to do so.
Let’s take two examples:
- The TR is a retail bank that wishes to offer a proximity mobile payment service within its application. When one of its customers wishes to activate this service, the bank must send a tokenisation request for the customer’s payment card to a TSP. Then it shall provision the token within the bank’s app.
- The TR is an online merchant wishing to provide for its customer the ability to save their payment card, so they can use it again on the website for future shopping (Card-On-File service). When a customer decides to register its payment card on the website, the online merchant must address to a TSP a request of tokenisation for the customer’s payment card, to then store the token within its database.
The TSP holds a central role, notably for the following reasons:
- It is responsible for the database, namely the Token Vault, saving the correspondence between the payment cards and the associated tokens.
- When a payment transaction using is triggered the token, the TSP operates in the authorisation cycle prior to the card issuer, in order to validate certain security data (cryptograms created from TSP-provisioned keys within the token profile) before transmitting the “detokenized” authorisation to the card issuer.
Therefore, we see that the TSP plays an important role by holding sensitive data (card – token correspondence) and by operating systematically in each transaction involving tokens.
Issues of sovereignty and control for the issuers and the national payment networks
In theory, the TSP role can be played by different type of actors in the card payment ecosystem. In practice, the large payment networks positioned themselves to play this role. First of all, international payment networks, such as Visa and Mastercard, have built tokenisation services within their infrastructure. Considering their global footprint, they implemented a large range of services helping the TRs (issuing banks, merchants…) to deploy their services in a simple and « universal » way. As an example, to illustrate global TSPs value proposition: the global mobile payment Wallets (G-Pay, Apple Pay, Samsung Pay etc.) are connected to international networks’ TSPs as TR’s. Therefore, the issuers that are members of these networks, and already using their services to issue physical cards, can request their TSP services so they can instantly benefit from card digitisation in these Wallets.
In response to these comprehensive offers from the international network, the domestic players can organise to build local TSPs, accessible to issuers from the country concerned. These procedures are mainly observed in countries with a strong card payment history, with an interbanking network and a well-established domestic payment scheme, this is the case of France for example. We also notice “domestic tokenisation Hub” projects in countries where card payment systems are more recent, such as Saudi Arabia, where the decision of having a local TSP seems to be more related to issues of sovereignty and control of the sensitive data on national soil.
In face of this offer and the variety of choices, TRs will have to choose solutions allowing them to maintain a decent level of control of the value proposition offered to their customers. This seems to be a particularly critical issue for issuing banks. Indeed, card holder data control traditionally represents a priority for issuers. Likewise, the dependence on third parties in the payment authorisation cycle is considered to be a sensitive subject.
For an issuer, selecting one or multiple TSPs to use for such and such service represents a strategic choice, which is not simply a combination of technical and financial criteria. This is what we call “the token “sourcing” strategy”. To illustrate this, let’s take another example, the one of an issuing bank operating in a country with a national payment scheme and also using international payment schemes, such as Visa or Mastercard ; this bank issues “co-branded” cards, meaning that it allows to use the domestic payment network of payment in the country concerned, and the international payment network for payments performed abroad. When it comes to digitising this card to offer a mobile payment service, this issuing bank will have to define its tokenisation strategy. It could decide for instance, to reproduce the “co-branding” notion in the digital world, and in this case would need to source a token with the TSP proposed by the national network and to source another token with the TSP of the international payment network.
A necessary control by token users (Token Requestors)
A new generation of offers has emerged, allowing token users to have simplified access to all the tokenisation related functionalities:
- Preparation of required data for tokenisation requests ;
- Tokens “sourcing” with available TSPs respectively to the pre-defined strategy ;
- In certain cases, token provisioning with payment applications ;
- Token lifecycle management in order to facilitate and ensure reliability of the actions related to loss or theft, renewal, etc.
These are TR-types platforms, pooling TSPs accesses, and proposing a simple integration for issuers and merchants, via programming interfaces (APIs).
It’s within this context that our ReadyToTap Payment solution positions itself. Today, this solution allows various type of issuers – retail banks, neobanks, prepaid card issuers, etc. – to benefit from a large range of functionalities offered by the major TSPs on the market, with flexibility and ease of implementation.
