24 August 2017
Find out more

Setting a standard for mobile payments

07 October 2009  |  3298 views  |  0 Source: Neil Livingston, Consult Hyperion Fingers on smartphone keypad

Neil Livingston, a senior consultant with Consult Hyperion, discusses the latest developments from Payez Mobile, a not-for-profit association set up by banks and wireless operators in France to develop a common standard for mobile payments.

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.

Comments: (0)

Comment on this story (membership required)

Related blogs

Create a blog about this story (membership required)

Solution source

Search by company or single key word