More on Payez Mobile

[Dave Birch] I’ve been particularly interested in the French national NFC payments “experiment”, not just because of the practical insight it delivers but also because it is a laboratory for co-ordinated specification development involving both bank and mobile operators. For many of our customers, this bank-operator interface is an important driver and/or barrier in their medium-term strategy, so it’s important to understand it.

AEPM, the Association Européenne Payez Mobile, has updated the technical specifications for Payez Mobile, the NFC solution developed by the leading French banks and mobile operators that has been on test in the French towns of Caen and Strasbourg since November 2007. The new Version 2.1 of the Payez Mobile specification incorporates the latest GlobalPlatform specifications and follows the signing of a Memorandum of Understanding between AEPM and GlobalPlatform in July.

[From Payez Mobile updates NFC specifications • Near Field Communications World]

Since I think these specifications are important, I asked my colleague Neil Livingston (who has been leading some of our work in this area) if he could provide a more detailed introduction to the specifications for blog readers, and he has kindly provided the overview that follows. If you’re interested in understanding how NFC is evolving in the payments space, it’s well worth you taking a few minutes to read through.

[Neil Livingston] In May this year, the AEPM (Association Européenne Payez Mobile) published version 2.0 of the specifications which underpin the Payez Mobile field trials running in Caen and Strasbourg in France. A point release update to version 2.1 was subsequently released in July. The AEPM is an association which was setup in 2008 in order to “promote and accelerate the deployment of contactless mobile payment in Europe” (source: Payez Mobile website) through the development and publication of supporting specifications, which are published in three “sets”:

• Set 1 of its specifications are freely available from the association website and cover the functional and technical aspects of the Handset, Secure Element, payment applications, user interface, etc., including service delivery and management and payment processing.

• Set 2 (security guidelines and configurations) and Set 3 (specifics for Visa and MasterCard implementations) are available under license.

The Association comprises eleven group members (all French) including four mobile operators and seven banks. In fact, you must be either an operator or a bank to join. While currently comprising only French members, the AEPM has ambitions for its specifications to be adopted more widely across Europe.

The reason to study this initiative is that it appears to be one of the first (if not the first) comprehensive applications of the various (and necessary) building-block specifications for mobile NFC payments, as developed by other industry fora, and it defines that the Secure Element (required for secure storage of payment applications, keys and data) resides in the SIM (or “UICC”, in the general sense).

It builds on ETSI SCP specifications, including the much discussed Single Wire Protocol and Host Controller Interface specifications (that provide the physical and logical link between the contactless interface and the UICC), and the latest GlobalPlatform Card specifications, including Amendment A, a recent draft of Amendment C, plus the UICC Configuration specification. And, of course, it cites EMVCo specifications as well, underpinning its support of Visa and MasterCard specifications. So, proof indeed that the vast specifications effort across the globe is coming together to support mobile NFC services.

Some of the potential problems which have been facing consumer usability of mobile NFC payments are tackled in the AEPM specifications, through their adoption of GlobalPlatform concepts. In particular, issues related to application priority and selection are addressed using the Contactless Registry Service (CRS) concept from GlobalPlatform (Amendment C), which gives the user the means to control application priority and availability. The Contactless Registry Event Listener (CREL) concept from GlobalPlatform implements Payez Mobile’s business logic of allowing only one application to be active on the contactless interface at any time.

The AEPM specifications introduce the concept of a companion application to a payment application, whereby the companion provides the interface to the payment application from the outside world (from the user, the POS, the remote bank servers, etc.). I understand that this is intended to allow existing Visa and MasterCard payment applications (subject to minor alterations) to work with Payez Mobile, limiting the re-work required on those payment applications, speeding up time to deployment and, potentially, limiting the effort for re-certification.

The functions provided by the companion include Personal Code entry and management, access to a Transaction Log, activation and deactivation of the payment application at the contactless interface, providing payment application status information to the bank’s user interface and POS emulation, for the purpose of delivering Issuer Scripting and conducting counter resets.

Incidentally, “Personal Code” is the AEPM’s chosen term for the “PIN”-like passcode used to authorise the user, e.g. to authorise a payment or reset the internal offline payments counters.

Another interesting aspect of the AEPM specifications is the architecture models for provisioning and management and how these map onto the evolving view of what a Trusted Service Manager (TSM) is. The much discussed GSMA model for mobile payments typically sees a single TSM acting between a bank and an operator. The AEPM architectures break out the range of possible TSM responsibilities into several roles which are split across the bank and operator domains enabling “multi-TSM” implementations in which a bank has, for example, its preferred TSM, responsible, typically, for Bank SSD management, Bank MMI management, physical data preparation, etc., whereas the operator could have a different TSM responsible for SSD lifecycle, token provision, management of OTA platform, etc., and in which the bank and operator interact through their respective TSMs. This is potentially, we feel, a more pragmatic option than the single TSM model.

Looking ahead, it will be interesting to see whether the companion application model survives, or whether the payment schemes will close the gaps between their existing payment application specifications and what is required to make mobile NFC payments work, and to see whether the AEPM specifications manage to break out of France.

These opinions are our own (we think) and presented solely in our capacity as interested members of the general public [posted with ecto]