part 1 of our 4 part series on mobile payments we touched upon
the interdependencies among the various stakeholders participating
in a mobile payments solution and the importance of integration
– even if there's no central integrator. To appreciate
why integration is such an important aspect of mobile payment
solutions, first let's understand the following technical roles
played in transacting mobile payments:
Credential Issuer – Traditionally, this
is the payment card issuer (such as the bank or retailer), but for
the purpose of mobile payments this is more specifically the
organization that issues personalized customer data used to
identify the customer and initiate payments (such as a credit card
number or pre-paid loyalty card number), which in many mobile
payment models must be loaded onto the smartphone.
Secure Element Manager (SEM) – This is
the party that "manages" access to the credential. In an
NFC-enabled smartphone, the SEM ensures that access to the
credential, which sits in the "secure element" (in some
models, this is a microSD card or SIM/UICC card), is only granted
to trusted third parties via secure protocols.
Trusted Service Manager (TSM) – This is
the party that communicates with the secure element manager to
"provision" (i.e., load) credentials onto the secure
element on behalf of the credential issuer. It's somewhat
analogous to the process that is required to load payment
credentials onto a payment card with a chip, except for mobile
payments this typically occurs wirelessly.
Mobile Payment App Developer – This is
the developer of applications on a smartphone that allow the user
to transact mobile payments. These applications take different
forms, depending on the manner in which the credential issuer
allows the user to transact payments. It must be user-friendly,
brand-savvy and integrated with the operating system, hardware and
other applications of the smartphone.
These are only some of the roles played in a mobile payment
solution and these roles can be played by a variety of
organizations and multiple roles can be played by one organization.
For example: a credential issuer can also be the app developer; the
SEM can also be the TSM; a mobile network operator or smartphone
manufacturer can be an SEM and an app developer. There are also the
payment networks (e.g., MasterCard, Visa, Amex), technology
powerhouses (e.g., Apple and Google) and regulators, to name a few,
all of which are working to define their roles.
Once you understand the various roles played in a mobile payment
solution, the next step is to understand the mobile payment
architecture flow and depending on how the stakeholders are
arranged, there are many different ways this can be accomplished.
Consider the following as an example:
The credential issuer provides a credential to the TSM, which is
granted access to the secure element by the SEM and loads the
credential onto the phone (or in some cases, a remote location).
The user opens the mobile payment app and initiates a payment with
the click of a button, and the credential is broadcasted to the
point of sale terminal.
Regardless of the selected arrangement, a successful solution is
ultimately one that is integrated seemlessly, where the user
understandably views mobile payments as a simple function unaware
of the precise functions that had to be executed in order to make a
Therein lies the challenge: how to accomplish a seamless mobile
payments solution when the stakeholders have different functions,
goals and risk tolerances and no one party bears responsibility for
the solution as a whole? For example: a credential issuer which
owns the relationship with the customer or is more customer facing
will be more concerned with seamless customer experience while the
TSM or SEM may be more concerned with delivery or performance of
its respective tasks and the risks associated with the
interdependencies between the two (and other stakeholders).
Consider the following risks associated with this rather
complex, interdependent, multi stakeholder technology solution:
poor customer experience, delays in solution implementation, costly
change orders, fraud and data security issues, uncertainty around
service levels and performance metrics and minimal or no
measurement of the success of the end to end solution.
part 3, we will provide helpful tips in managing these risks
and this rather complex and interdependent relationship prior to
entering into a contractual arrangement.
The content of this article is intended to provide a general
guide to the subject matter. Specialist advice should be sought
about your specific circumstances.
To print this article, all you need is to be registered on Mondaq.com.
Click to Login as an existing user or Register so you can print this article.
The Canadian Office of the Superintendent of Financial Institutions ("OSFI") recently ruled that a bank cannot promote comprehensive credit insurance ("CCI") within its Canadian branches under the Insurance Business (Banks and Bank Holdings Companies) Regulations (the "Regulations").
Register for Access and our Free Biweekly Alert for
This service is completely free. Access 250,000 archived articles from 100+ countries and get a personalised email twice a week covering developments (and yes, our lawyers like to think you’ve read our Disclaimer).