March 23, 2015
Most of the payments industry pundits agree that the Mobile Network Operators (MNOs) lost relevance in the payments space, after which Apple Pay was launched and Google acquired SoftCard, going on to release the Host Card Emulation (HCE) framework. The original NFC mobile payments ecosystem that the MNOs were pushing forward was awkwardly complex to start with. The setup required running expensive Trusted Service Managers (TSMs). MNOs needed to negotiate complex contracts with card issuers and payment networks. MNOs wanted to charge each card issuer for the real estate inside the SIM card. Things were further complicated by the fact that the ownership and control of the mobile phone’s ubiquitous SIM SE was very unclear. Technically the SIM is owned by the MNOs, but it is the card issuer who traditionally has the ownership of the payment card chip. Who would now own the SIM, which should host the GSM applet plus multiple EMV applets from multiple card issuers? This complexity at some point jeopardized the future of NFC itself.
Apple Pay visibly simplified and even eliminated most of these complexities, breathing new life and hope into the NFC ecosystem. Apple fully owns and controls the iPhone 6 embedded SE which comes preloaded with single generic EMV payment applet instances, per supporting payment brand (no need for an instance per issuer anymore). Consumers who own payment cards from the issuers supporting Apple Pay individually choose which of their payment cards they want to enroll into the Apple Pay wallet. To get on board, card issuers only need to support the tokenization framework, which is enforced by the traditional payment brands they already have relationships with. Instead of real card numbers (PAN), only the tokens are provisioned into the iPhone SE when cards are added. No need for sophisticated TSMs anymore. Definitely cheaper, simpler and better. As a consequence, the contracts negotiated are much simpler as well, enabling quicker rollout and implementation.
The MultiProxyEMVPay SIM Card must be activated before it can be used. Activation securely links an existing generic ProxyEMVPay instance from the MultiProxyEMVPay SIM Card to one of the customer’s real payment cards having the compatible brand. Participating MNOs can offer their own mobile activation app or use a mobile activation app from a ProxyEMVPay certified 3rd party provider. Activation process follows standard ProxyEMVPay flow and includes
Depending on the brand of the payment card that the customer chose to link, the activation server (acting also as Token Requestor at this time) requests from the corresponding payment network’s TSP to replace NULL PAN, which is currently linked to that brand’s generic ProxyEMVPay token instance inside MultiProxyEMVPay SIM. Meanwhile, the real PAN data of the compatible card is being linked and its defined usage parameters are being updated.
The activation process is fully finalized when the mobile activation app updates the standard contactless/NFC PPSE directory file inside the MultiProxyEMVPay SIM, setting the highest priority for the AID of the payment brand’s applet whose static token has last been linked to the compatible payment card PAN. That ensures that the POS contactless kernel automatically selects that applet, during NFC transactions, until the customer explicitly links a different payment brand’s card. My understanding is that a similar PPSE adjustment is likely happening when the consumer selects the preferred payment card in the Apple Pay wallet for payment. To further streamline and speed up the whole activation procedure, the MNOs can also enable customers to preload multiple card data into the ‘wallet’ in advance on their secure server, and then just pick (similar to Apple Pay) which one of those preloaded cards will be ‘linked’ to the brand-compatible static token inside ,as part of the activation process (without need to enter card data during activation).
Once the specific ProxyEMVPay instance inside the MultiProxyEMPay SIM Card is successfully activated on the NFC capable phone, it can be normally used for mobile payments, as long as all of the ProxyEMVPay instance usage parameters are within their predefined usage limits (the usage limits are checked by the payment network’s TSP as part of the de-tokenization request processing). Similar to Apple Pay and to the plastic ProxyEMVPay Card, the MultiProxyEMVPay SIM Card never reveals the underlined payment card PAN to merchants. Since all tokens and 3DES keys are provisioned upfront and stored inside the real SIM secure element, when the MultiProxyEMVPay SIM Card is manufactured, there is no need for sophisticated TSP infrastructure and OTA provisioning during phone usage. That arguably makes the whole setup simpler and more secure than the HCE based implementations. All payments made with ‘active’ MultiProxyEMVPay SIM cards are authorized against the account behind the linked/underlying card PAN and are shown on the statement of the underlying payment card.
As with simple ProxyEMVPay cards, whenever usage limits exceed the predefined values, the linkage between currently ‘active’ ProxyEMVPay token instances and underlying payment card PANs shall be terminated inside the corresponding payment scheme TSP Token Vault and that brand’s token linked to NULL PAN inside corresponding brand’s TSP, effectively inactivating the ProxyEMVPay instance inside MultyProxyEMVPay SIM Card.
MNOs should seriously consider using MultiProxyEMVPay SIM Cards since it can significantly simplify the NFC ecosystem. They can even potentially negotiate similar ‘piece of the interchange’ type deals with underlying card issuers (as Apple Pay did), since the ProxyEMVPay concept allows them to bring significant additional/new transaction volume to the card issuers through: