Mobile Money: Seven considerations before you build an app

White Paper
Mobile Money:
Seven considerations
before you build
an app
January 2013
Share this White Paper
Contents
Introduction3
1.An app is not enough: understanding the mobile 4
money ecosystem
2.Build or buy: the pros and cons of off-the-peg apps
6
3.What your customers want: robust security plus ready access
8
4.The vault: understanding the secure element
10
5.What is a wallet? And is it what your customers need?
12
6.From the app backwards: minimising PCI exposure
14
7.How creativity can overcome standards conservatism
16
Next steps
17
2
Introduction
Money is inherently mobile, but it is only a recent innovation
that has seen money handled on a mobile phone. With the
rapid growth of the smartphone, it has become an obvious
advance for many companies to give their customers access
to services via their mobile device. From banking to bills,
purchasing to payments, apps are appearing to manage many
of the financial aspects of our daily lives.
Producing a successful, secure money application
is not a simple business. It’s not a feat that can be
achieved by a simple app developer working in
isolation. A successful mobile money app requires
the input and support of multiple suppliers and
stakeholders from across the mobile money
ecosystem. And it requires many different aspects
of design and technology to be addressed.
This white paper provides a guide to seven of
the key areas of successful mobile money app
development that Penrillian has come to
understand through extensive experience in the
space. It’s not an exhaustive checklist, but address
these key issues and you will be well on the way to
creating an application that is successful for your
business and appreciated by your customers.
‘Producing a successful,
secure money application is
not a simple business. It’s not
a feat that can be achieved
by a simple app developer
working in isolation.’
3
1.An App is not enough: understanding
the Mobile Money ecosystem
Think about the water that comes out of your tap. It has had a
pretty fantastic journey to get there. Just starting from the falling
raindrop, you have to consider a journey that takes in a river, a
reservoir, processing, pumping, miles of pipe and household
plumbing, plus the companies that own and operate these
various elements. Were it not for all this hidden effort, your tap
is going to deliver very little.
What is true for the tap is also true for mobile money
apps. If anything the mobile money ecosystem is
more complex than that which delivers fresh water.
Building a successful mobile money application
means navigating this ecosystem and ensuring
that all of the relevant parties work together. Or
having a partner who can do this on your behalf.
Some of the key parties and components to
consider include:
• N
etwork operator – Carries the traffic two and
from the phone, and usually has a primary billing
relationship with the phone owner
• S
IM provider – Controls the technology on
board the card that the operator uses to securely
govern access to the network
• S
ecure element – The location in which secure
payment data is stored on the device, be it part
of the handset, or the SIM, or a dedicated SD
card
• P
ayment cardlet (e.g. Mobile MasterCard
PayPass) – The underlying application logic
behind the making of a payment on the device
• T
rusted Service Manager (TSM) – A secure
delivery system connecting the Secure Element
to the service operator Card/Payment Provider
– the financial institution handling the
transactions and accounts
• S
ecurity Advisors and Authorities – A selection
of advisors and approvals will be required
before a mobile money service can be (safely)
launched
4
1. (Continued) An App is not enough:
understanding the Mobile Money ecosystem
In many cases while the interfaces between these
providers may be available in theory, in practice
much work is needed to make them communicate
effectively. For example, one issue Penrillian has
faced is that Application Programming Interfaces
(APIs) have often been constructed with the
desktop web in mind.
The differences between the desktop environment
and mobile in terms of browser capabilities,
connection speeds and reliability means these are
usually unsuitable for the mobile environment.
When you can’t demand a complete rebuild of a
partner’s infrastructure, you need to find ways to
negotiate between different standards with the
requisite level of performance and security.
‘When you can’t demand a
complete rebuild of a partner’s
infrastructure, you need to find
ways to negotiate between
different standards with the
requisite level of performance
and security.’
This is where a partner like Penrillian can help, but
the key message here is this: no one partner in this
ecosystem can deliver a successful mobile
application on their own. All parties must collaborate
effectively to meet the customer’s expectations.
‘In many cases while the
interfaces between these
providers may be available
in theory, in practice much
work is needed to make them
communicate effectively.’
5
2.Build or buy: the pros and cons of
off-the-peg apps
When shopping for a new suit, few people consider a tailor over
the high street these days. The upfront cost and production
time may be off-putting when set against the instant gratification
of an off-the-peg purchase.
But a tailored suit will always be a better fit to your
shape, can be adapted as that shape changes,
and will most likely be made from higher quality
materials. In the long term, the tailored suit can
prove to be better value.
The same rules apply when it comes to developing
new applications, particularly in the field of mobile
money. Off-the-peg applications are available,
provided by a third party with some elements of
the ecosystem already in place, and a skinnable
application that can have you up and running
quickly.
The next risk is security: a recent study by Leibniz
University in Hannover and Philipps University of
Marburg found more than a thousand Android
applications with serious security flaws out of a
sample of 13,000. 17% of the apps that used the
secure socket layer (SSL) standard had it wrongly
implemented, leading to significant security risks.
If your needs are fairly straightforward and match
the capabilities of the application available, then
this is a reasonable route forward. But it is not
without its risks: handing over this level of control to
a third party limits a number of your powers.
The first of these is the ability to make changes: if a
third party is catering for multiple customers on the
same platform, their development is always going
to be focused on the needs of the many, not your
needs specifically. Development can be slower
and more costly as a result.
‘17% of Android apps that
use SSL have it wrongly
implemented, leading to
significant security risks.’
6
2. (Continued) Build or buy: the pros and cons of
off-the-peg apps
The final issue to consider is lock-in: if it is not just
your app, but the entire supporting ecosystem that
is dependent on a third party, there is no opportunity
to chop and change components, or connect to
additional services without their say-so. As time
passes, it’s possible that your requirements and
the service on offer will drift further and further
apart. And all the while, you will be paying the
licence costs on the intellectual property retained
by the solution provider.
While the mobile money ecosystem is complex, it
is navigable. Off-the-peg solutions do have
benefits but in the long term, a bespoke platform
can offer significant financial and operational
advantages.
Consider the alternative. For one of the major
European network operators Penrillian constructed
an entirely bespoke application and gateway to
interface with the payment partner’s systems. The
delivery time was comparable with an off-the-shelf
solution, and calculated over the first two years of
the service’s life, so were the costs. The operator
now has its own intellectual property, and an app
and gateway that it controls. It can switch payment
providers or add other partners into the system on
its timetable, rather than lobbying a third party to
deliver.
‘...Penrillian constructed an
entirely bespoke application
and gateway to interface
with the payment partner’s
systems. The delivery time
was comparable with an
off-the-shelf solution, and
calculated over the first
two years of the service’s
life, so were the costs.’
7
3.What your customers want:
robust security plus ready access
When it comes to handling their money, consumers are rightly
concerned about security. But they will balance this concern
with usability: what good is mobile money if you can’t access it
when you need to? Striking this balance is a major challenge for
the app designer.
Consider the primary ways of paying before mobile
money: cash or card.
For small transactions cash is very convenient.
Grab a note or a handful of change and hand it over
and you’re done. There’s always the risk that you
might lose that cash (or have it stolen) but the
convenience means that we all keep a small
amount to hand most of the time. And we can tailor
our level of risk by choosing how much cash to
carry.
Mobile money applications need to offer users the
same gradations of security. For small transactions
we want the readiness of cash. For larger
transactions, the protected flexibility of a card. By
tiering security features such as maximum
transaction values and PIN confirmations, to match
the transaction value, it is possible to offer users a
well-structured balance between security and
usability.
The risks of the card are very different. If a card is
truly compromised the losses can be large but they
will usually be losses to the bank not us as
individuals. If cards are lost we can cancel them
remotely and fraudulent transactions can be
charged back. Cards are much more convenient
than large bundles of cash for larger transactions.
‘The risks of the card are very
different. If a card is truly
compromised the losses can
be large but they will usually
be losses to the bank not us
as individuals.’
8
3. (Continued) What your customers want:
robust security plus ready access
There is another aspect to security to consider, and
it is one that very much concerns users: personal
data. By their very nature, mobile money
applications collect a colossal amount of very
intimate detail about our personal lives. We don’t
just need to protect users’ money; we need to
protect the knowledge of how they spend it from
external access and improper use.
‘Cash is convenient, but cards are
more secure for large transactions.’
The GSM Association has produced guidelines on
privacy that address the issues associated with the
collection and retention of personal data by
applications, based on international data protection
law (http://www.gsma.com/publicpolicy/privacydesign-guidelines-for-mobile-applicationdevelopment/). Under these guidelines financial
transaction data falls under the strictest level of
control, since it arguably touches every aspect of a
person’s life, including their health (an area of
particular sensitivity).
Ensuring compliance with these guidelines, and
providing the appropriate level of security and
usability, comes down to careful design of the
whole application and supporting infrastructure.
‘The GSM Association has
produced guidelines on
privacy that address the issues
associated with the collection
and retention of personal
data by applications, based
on international data
protection law.’
9
4.The vault: understanding the
secure element
One opportunity for money applications on mobile devices is
the actual replacement of cash via Near Field Communication
(NFC)-enabled devices. There’s a great appeal in the simplicity
of swiping your phone over a terminal to pay for goods, and
managing the money available in your virtual wallet using the
phone’s interface.
For a start you would never need to go hunting for a
cash point again. But this simplicity of use needs to
be balanced against security, and so the NFC
architecture defines a means for keeping the
payment data secure.
The Secure Element typically runs as a native
application on a smartcard. These applications,
known as ‘Cardlets’, use the Java Card format
designed for very low powered computing devices.
The smartcard may be:
The ‘Secure Element’ is the smart vault on your
mobile device that handles this task. A dedicated
chip designed for the purpose of storing encrypted
card information and running secure applications,
the Secure Element sits apart from the rest of the
device, safe from the risks that users take with their
smartphones every day: open social networks,
untrusted websites and dodgy applications.
• B
uilt into a device – an approach that has been
taken by the likes of Samsung and Google with
their recent phones.
• Part of the SIM card – a relatively trusted
environment in its own right – adopted by some
mobile operators.
• A
standalone plugin card for the device in the
common SD card format.
‘The ‘Secure Element’ is the
smart vault on your mobile
device that handles this task.’
10
4. The vault:
understanding the secure element
The device interfaces with the Secure Element via
an API specific to the handset operating system,
and each takes a slightly different approach to
security. Android has the SmartCard API for
Android, secured via user permissions: an
application can only access the Secure Element if
the user explicitly gives it permission on installation.
By contrast, RIM’s Blackberry requires all
applications requiring smartcard access to be
‘signed’ with code keys requested from RIM by the
developer.
‘Secure NFC payments could
mean the end for cash points.’
The main thing to understand is that the smartcard
is distinct from the handset operating system, and
that access to it and the Cardlets running on it, is
protected. In this manner the Secure Element can
remain secure and trusted by the rest of the
payment ecosystem.
‘The device interfaces with
the Secure Element via an
API specific to the handset
operating system, and each
takes a slightly different
approach to security.
Android has the SmartCard
API for Android, secured
via user permissions: an
application can only access
the Secure Element if
the user explicitly gives it
permission on installation.’
11
5. What is a wallet? and is it what your
customers need?
When a new technology begins to displace an old one, it’s
tempting to use the old terminology to help familiarise people
with the new. Hence the term ‘wallet’ has become rather popular
when referring to mobile money. But what is a ‘wallet’ in digital
terms, and what should it be?
Both O2 and Google have called their mobile money
applications ‘Wallet’ but the two applications are
very different.
• O
2’s wallet relies on you, the user, loading money
onto O2’s own payment platform – essentially a
pre-pay card – before you can make payments.
This is a wallet in the pure cash sense: you are
effectively loading up your purse with cash from
your account before going out shopping.
• G
oogle’s Wallet is much more like the one in
your back pocket: it contains all of your different
accounts and cards, enabling you to select the
right one for each purchase. But it achieves this
through a little sleight of hand – all the
transactions actually take place through a single
MasterCard account created when you sign up
for the wallet, and are then rebilled to the relevant
card.
‘Not everyone is going to like
the idea of creating yet
another account, and
certainly not all of the major
card issuers are happy
at the prospect of being a
further step removed from
the transaction.’
12
5. (Continued) What is a wallet?
And is it what your customers need?
Not everyone is going to like the idea of creating yet
another account, and certainly not all of the major
card issuers are happy at the prospect of being a
further step removed from the transaction. It would
seem like the ideal wallet is one that securely
manages the various payment options at the user’s
disposal but allows each to natively make the
payment when it is selected. This adds convenience
and security, and unifies access to the underlying
hardware required to make NFC payments happen.
In technical terms this means controlling the
download and installation of new payment
applications and their associated Cardlets on the
Secure Element.
‘A true mobile wallet enables the
user to choose the right payment
card for each transaction.’
One example of such a wallet is the ISIS scheme in
the US (http://www.paywithisis.com).
It is this type of wallet that needs to be taken into
consideration when planning your mobile money
application. Consumers will continue to use
multiple methods of payment, and will expect their
payment applications to make it easy for them to
choose the right option at the right time. Your
application needs to be designed today to be
discoverable and manageable by a standardised
‘Wallet’. As standards for mobile wallets emerge,
you will need to keep pace by updating your app.
‘...the term ‘wallet’ has
become rather popular when
referring to mobile money. But
what is a ‘wallet’ in digital
terms, and what should it be?’
13
6.From the app backwards:
minimising PCI exposure
The payment industry is understandably strict about securing
the movement of money. The card schemes enforce control on
almost every aspect of the mobile money ecosystem, and part
of that control comes in the form of the Payment Card Industry
Data Security Standard or PCI DSS.
These six letters strike fear into the hearts of many
application developers. Horror stories of long,
expensive testing and approval processes and
worse, failures, abound. But PCI DSS does not
need to be burdensome. In fact its impact on a new
mobile money application can be minimised,
without compromising security.
Fundamentally, complying with PCI DSS means
avoiding the loss of account data – be it names,
addresses, numbers, or PIN codes – at any point.
So the more you can avoid the need to accept,
store and transmit account data, the less you will
need to do in order to achieve compliance.
To understand how, you need to understand in
basic terms what the standard is setting out to
avoid. The PCI Security Council defines three key
objectives with regards to securing mobile money
applications:
• Objective 1: Prevent account data from being
intercepted when entered into a mobile device
• Objective 2: Prevent account data from
compromise while processed or stored within
the mobile device
• Objective 3: Prevent account data from
interception upon transmission out of the
mobile device
‘...PCI DSS does not need to
be burdensome. In fact its
impact on a new mobile
money application can be
minimised, without
compromising security.’
14
6. (Continued) From the app backwards:
minimising PCI exposure
With regards to storing data, the Secure Element
provides much of the answer here. This highly
secure vault on the phone should contain every
piece of account data that we need to complete a
transaction. Everything else that is stored should
exist behind the walls of the web service with which
the application interacts – often already tested and
approved. So our focus needs to be on minimising
the entry and transmission of data.
This focus fits very well with the goals for any mobile
application: nobody wants to enter reams of data
on a small screen. And moving large amounts of
data back and forth over the airwaves is slow and
expensive. So ensuring that data entry and
transmission is minimised not only adds to the
security of the application, it adds to its efficiency
and performance.
Careful design can pare back the requirements for
data entry and transmission to a minimum, limiting
the opportunity for interception and capture. But
there is one more source of data that needs to be
addressed when protecting a mobile money
application, and it is one that is rarely considered:
error messages and error logs. Detailed error
messages explaining why an interaction with the
application, or the web services behind it, has
failed, are useful in development. But they are also
useful to those trying to crack the system.
Restricting these error messages and logs to a
bare minimum further reduces the opportunity for
attack.
Keep the flow and storage of data across the
application and its back end to an absolute
minimum, and you can also minimise the pain of
PCI compliance.
‘Detailed error messages
explaining why an interaction
with the application, or the
web services behind it, has
failed, are useful in development.
But they are also useful to
those trying to crack the
system. Restricting these error
messages and logs to a bare
minimum further reduces the
opportunity for attack.’
15
7.How creativity can overcome
standards conservatism
Unless you are an investment banker, it’s natural to be a little
conservative when dealing with other people’s money. That
natural conservatism can lead to very procedural thinking. If
there are standards: follow them. If something has been done
before that worked: do it again.
The problem with this approach is that while it is
‘safe’ it is likely to lead to unremarkable results. And
in a fresh, new, but already competitive market like
mobile money, remarkable is exactly what you
need to be. To be anything else is far from safe.
On this basis, standards need to be treated rather
like the rules of football. They have to be obeyed
but they leave plenty of opportunity for flair play, for
those that are capable.
‘... in a fresh, new, but already
competitive market like mobile
money, remarkable is exactly
what you need to be.’
16
Next steps
The smartphone will replace the physical wallet. As more
payment options and other smartcards for loyalty points and
travel move over to the mobile, the physical wallet will become
redundant. This presents an opportunity for companies to
establish patterns of consumer behaviour, as people choose
their new preferred payment options.
There are barriers to entering the market today but
as we have aimed to show with this paper, they are
far from insurmountable. And working with a
partner like Penrillian that knows the market space
intimately, it’s possible to overcome them rapidly at
reasonable cost.
Not only that: there is room for innovation. Few of
the true opportunities for mobile money have yet
been explored. Standards do not have to be seen
as restrictions: rather they just define the rules
within which creativity can take place. Off the peg
applications may tick the box today but they leave
little room for competitive advantage in the longer
term.
About Penrillian
Founded in 2000, Penrillian is now one of the
most experienced specialist mobile software
development companies in the world.
We develop bespoke software solutions and over
the years we have developed an impressive range
of applications and software for some of the
leading brands in mobile. For example:
If you’ve ever used a Vodafone data dongle,
purchased goods using your phone, bought 2-for-1
cinema tickets on Orange Wednesdays from a
BlackBerry, or managed a T-Mobile account from
a phone, chances are we created the software.
Nowadays, we are helping our customers remain
at the forefront of technology by creating the next
generation of secure mobile services and payment
apps for operators, banking, payment providers,
and financial services. Working with clients across
multiple business sectors, our software is helping
to engage users and drive revenue and retention.
If you are considering an
entry into the mobile
money market, talk to
Penrillian today on
44 (0) 1768 214400
17
Penrillian
Clint Mill
Cornmarket
Penrith
CA11 7HW
United Kingdom
Email: [email protected]
Tel: 44 (0) 1768 214400
Web: www.penrillian.com
© 2013 Penrillian mobile phone software developers - All rights reserved.
Follow us