Visa has updated its cloud-based payments specifications to include a requirement for issuers to migrate from alternate PANs to tokenization, NFC World has learned. Alternate PANs are used by most of the issuers that have deployed host card emulation (HCE) services to date, meaning those issuers will now need to migrate to a full tokenization solution.
The new specification also indicates that there will be a “sunset date” after which Visa will be terminating support for alternate PANs, NFC World understands, although the actual date is not currently known.
An alternate PAN is a 16-digit personal account number that links to the customer’s main account number. The first six digits of an alternate PAN — known as a BIN (bank identification number) — are the same as the first six digits of a customer’s personal account number found on their plastic card.
Tokenization is also based on a 16-digit number but the BIN needs to be from a specific allocated token BIN range, supplied on request by the card scheme.
“We will migrate alternate PANs to Visa Token Service,” Visa confirmed to NFC World. “We are beginning the process of transitioning from alternate PANs to VTS. Visa is committed to working with its clients to help transition their existing mobile wallet programs that feature alternate PANs to VTS.”
Bridging technology
“Alternate PAN was introduced as a bridging technology to support the enablement of issuer-created mobile wallet programs when VTS was not available,” the payment network explained. “It was restricted to a single use case — to enable NFC contactless transactions at the point of sale.
“Now that EMV tokenization is adopted as a global standard for secure digital payments and is gaining traction worldwide, we believe this is the right time to make VTS universally available across payment devices and use cases, helping our clients and partners enable new ways to pay.”
While Visa’s comments refer only to use of its own Visa Token Service, NFC World understands that the updated cloud-based payment specification also makes provision for issuers to use a third-party token service provider (TSP) or their own in-house tokenisation solution.
Next: Visit the NFCW Expo to find new suppliers and solutions
this is an impossible statement, or at least implies the wrong thing:
“NFC World understands that the updated cloud-based payment specification also makes provision for issuers to use a third-party token service provider (TSP) or their own in-house tokenisation solution.”
because visa is requiring this:
Tokenization is also based on a 16-digit number but the BIN needs to be from a specific allocated token BIN range, supplied on request “by the card scheme”.
(issuer cannot supply their own token BIN anymore…that seems problematic for the issuer to negotiate with an alternative path)
that would force the visa TSP to be used in some way (even if they let the bank ultimately do the PAN lookup service, but Visa is keeping a record of this)
wonder if the SEC will get involved. this could really hurt vendors of TSP systems like BellID (Rambus) and Sequent amongst others.
there is no technical advantage to this decision (or mandate).