of 18

Mobile Money UK - Penrillian.com

Published on last month | Categories: Documents | Downloads: 5 | Comments: 0
209 views

Comments

Content

White Paper

Mobile Money: Seven considerations before you build an app January 2013

Share this White Paper

Contents Introduction

3

1.  An app is not not enough: enough: understanding understanding the the mobile money ecosystem

4

2. Build or buy: the pros and cons o o-the-peg apps

6

3. What your customers want want:: robust security plus ready access

8

4.  The vault vault:: understanding understanding the the secure secure element

10

5. What is a wallet? And is it what your customers need?

12

6. From 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 o the smartphone, it has become an obvious advance or many companies to give their customers access to services via their mobile device. From banking to bills, purchasing to payments, payments, apps are appearing to manage many o the nancial aspects o our daily lives. Producing a successul, secure money application is not a simple business. It’s not a eat that can be achieved by a simple app developer working in isolation. A successul mobile money app requires the input and support o multiple suppliers and stakeholders rom across the mobile money ecosystem. And it requires many dierent aspects o design and technology to be addressed.

This white paper provides a guide to seven o the key areas o successul 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 successul or your business and appreciated by your customers.

‘Producing a successul, secure money application is not a simple business. It’s It’s not a eat that can be achieved by a simple app developer working in isolation.’ 3

1. An App is not enough: understa understanding nding the Mobile Money ecosystem Think about the water that comes out o your tap. It has had a pretty antastic journey to get there. Just starting rom the alling raindrop, you have to consider a journey that takes in a river, a reservoir, processing, pumping, miles o pipe and household plumbing, plus the companies that own and operate these various elements. Were it not or all this hidden eort, your tap is going to deliver very little. What is true or the tap is also true or mobile money apps. I anything the mobile money ecosystem is more complex than that which delivers resh water. Building a successul mobile money application means navigating this ecosystem and ensuring that all o the relevant parties work together. Or having a partner who can c an do this on your behal.

Some o the key parties and components to consider include: • Networkoperator–Carries Networkoperator– Carries the trac two and rom the phone, and usually has a primary billing relationship with the phone owner • SIM pr prov ovid ider er – Controls the technology on board the card that the operator uses to securely govern access to the network • Secureelement–The Secureelement–The location in which secure payment data is stored on the device, be it part o the handset, or the SIM, or a dedicated SD card • Paym Paymen ent t ca card rdle let t (e (e.g .g. . Mo Mobi bile le Ma Mast ster erCa Card rd PayPa Pa yPass ss) ) – The underlying application logic behind the making o a payment on the device  A secu secure re • Trust rusted ed Servi Service ce Mana Manager ger (TSM) – – A delivery system connecting the Secure Element to the service operator Card/Payment Provider – the nancial institution handling the transactions and accounts • SecurityAdvisorsandAuthorities– A selection o advisors and approvals will be required beore a mobile money service can be (saely) launched

4

1. (Continued) An App is not enough: understanding the Mobile Money ecosystem

In many cases while the interaces between these providers may be available in theory, in practice much work is needed to make them communicate eectively. For example, one issue Penrillian has aced is that Application Programming Interaces (APIs) have oten been constructed with the desktop web in mind. The dierences between the desktop environment and mobile in terms o browser capabilities, connection speeds and reliability means these are usually unsuitable or the mobile environment. When you can’t demand a complete rebuild o a partner’s inrastructure, you need to nd ways to negotiate between dierent standards with the requisite level o perormance and security.

‘When you can’t demand a complete rebuild o a partner’s inrastructure,, you need inrastructure need to fnd ways to negotiate between dierent standards with the requisite level o perormance and secur security. ity.’’

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 successul mobile application on their own. All parties must collaborate eectively to meet the customer’s expectations.

‘In many cases while the interaces between these providers may be available in theory, in practice much work is needed to make them communicate eectively.’ 5

2. Build or buy: the pros pros and cons o  o  o-the-peg apps When shopping or a new suit, ew people consider a tailor over the high street these days. The upront cost and production time may be o-putting when set against the instant graticatio gratication n o an o-t o-the-peg he-peg purchase. But a tailored suit will always be a better t to your shape, can be adapted as that shape changes, and will most likely be made rom 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 eld o mobile money. O-the-peg applications are available, provided by a third party with some elements o 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 o Marburg ound more than a thousand Android applications with serious security faws out o a sample o 13,000. 17% o the apps that used the secure socket layer (SSL) standard had it wrongly implemented, leading to signicant security risks.

I your needs are airly straightorward and match the capabilities o the application available, then this is a reasonable route orward. But it is not without its risks: handing over this level o control to a third party limits a number o your powers. The rst o these is the ability to make changes: i a third party is catering c atering or multiple customers on the same platorm, their development is always going to be ocused on the needs o the many, not your needs specically. Development can be slower and more costly as a result.

‘17% o Android apps that use SSL have it wrongly implemented, leading to signifcant security security risks. risks.’’ 6

2. (Continued) Build or buy: the pros and cons of off-the-peg apps

The nal issue to consider is lock-in: i it is not just your app, but the entire supporting ecosystem e cosystem 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 oer will drit urther and urther apart. And all the while, you will be paying the licence costs on the intellectual property retained by the solution provider provider..

While the mobile money ecosystem is complex, it is navigable. O-the-peg solutions do have benets but in the long term, a bespoke platorm can oer signicant nancial and operational advantages.

Consider the alternative. For one o the major European Europea n network operators Penrillian constructed construc ted an entirely bespoke application and gateway to interace with the payment partner’s systems. The delivery time was comparable with an o-the-shel o -the-shel solution, and calculated over the rst two years o the service’s lie, 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 par tners into the system on its timetable, rather than lobbying a third party to deliver.

‘...Penrillian constructed an entirely bespoke application and gateway to to interace interace with the payment partner’ par tner’s s systems. The delivery time was comparable with an o-the-shel o-t he-shel solution, and calculated over the frst two years o the service’s lie, so were the costs.’ 7

3. What your customers want 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 i you can’t can’t access it when you need to? Striking this balance is a major challenge ch allenge or the app designer. Consider the primary ways o paying beore mobile money: cash or card. For small transactions cash is very convenient. Grab a note or a handul o 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 o the time. And A nd we can tailor our level o risk by choosing how much cash to carry.

Mobile money applications need to oer users the same gradations o security. For small transactions we want the readiness o cash. For larger transactions, the protected fexibility o a card. By tiering security eatures such as maximum transaction values and PIN conrmations, to match the transaction value, it is possible to oer users a well-structured balance between security and usability.

The risks o the card are very dierent. I a card is truly compromised the losses can be large but they will usually be losses to the bank not us as individuals. I cards are lost we can cancel them remotely and raudulent transactions can be charged back. Cards are much more convenient than large bundles o cash or larger transactions.

‘The risks o the card are very dierent. I 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 o very intimate detail about our personal lives. We don’t  justt need to pro  jus protect tect user users’ s’ mon money; ey; we need to protect the knowledge o how they spend it rom external access and improper use.

‘Cash is convenient, but cards are more secure or large large transactions.’ transactions.’

The GSM Association has produced guidelines on privacy that address the issues associated asso ciated with the collection and retention o personal data by applications, based on international data protection law (http:/ (http://www.gsma.com/ /www.gsma.com/publicpolicy/privac publicpolicy/privacyydesign-guidelines-for-mobile-applicationdevelopment/  ). Und Under er thes these e gui guidel deline ines s na nanci ncial al transaction data alls under the strictest level o control, since it arguably touches every aspect o a person’s lie, including their health (an area o particular sensitivity). Ensuring compliance with these guidelines, and providing the appropriate level o security and usability, comes down to careul design o the whole application and supporting inrastructure.

‘The GSM Association has produced guidelines on privacy that address the issues associated with the collection and retention o personal data by applications, based on international data protection law.’ 9

4. The vault vault:: understanding the secure element One opportunity or money applications on mobile devices is the actual replacement o cash via Near Field Communication (NFC)-enabled (NFC )-enabled devices. There’ There’s a great appeal in the simplicity o swiping your phone over a terminal to pay or goods, and managing the money available in your virtual wallet using the phone’s interace. For a start you would never never need to go hunting or a cash point again. But this simplicity o use needs nee ds to be balanced against security, and so the NFC architecture denes a means or 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 ormat designed or 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 or the purpose o storing encrypted card inormation and running secure applications, the Secure Element sits apart rom the rest o the device, sae rom the risks that users use rs take with their smartphones every day: open social networks, untrusted websites and dodgy applications.

• Built into a device – an approach that has been taken by the likes o 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standalon  Astandaloneplugi eplugincardforthedevi ncardforthedeviceinthe ceinthe common SD card ormat.

‘The ‘Secure Element’ is the smart vault on your mobile device that handles this task.’ task.’ 10

4. The vault: understanding the secure element

The device interaces with the Secure Element via an API specic to the handset operating system, and each takes a slightly dierent approach to security. Android has the SmartCard API or  Android  Andr oid,, secu secured red via user perm permiss ission ions: s: an application can only access the Secure Element i 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 rom RIM by the developer.

‘Secure NFC payments could mean the end or cash points.’

The main thing to understand is that the smartcard smar tcard is distinct rom 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 o the payment ecosystem.

‘The device interaces with the Secure Element via an  APII sp  AP spec ecif ifc c to the ha hand ndse sett operating system, system, and each takes a slightly dierent approach to security. security.  Andr  An droi oid d ha has s the Sm Smart artCa Carrd  APII or An  AP And droi oid d, se secu curred via user permissions: an application can only access the Secure Element i  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 amiliarise people with the new. new. Hence the term ‘wallet’ has become beco me rather popular when reerring to mobile money. But what is a ‘wallet’ in digital terms, and what should it be be? ? Both O2 and Google have called their mobile money applications ‘Wallet’ but the two applications are very dierent. • O2’s wallet relies on you, the user, loading money onto O2’s own payment platorm – essentially a pre-pay card – beore you can make payments. This is a wallet in the pure cash sense: you are eectively loading up your purse with cash rom your account beore going out shopping. s hopping. • Google Google’s ’s Wa Walle llet t is ismuc much h mor more e lik like e the one in your back pocket: it contains all o your dierent accounts and cards, enabling you to select the right one or each purchase. But it achieves this through a little sleight o hand – all the transactions actually take place through a single MasterCard account created when you sign up or the wallet, and are then rebilled to the relevant card.

‘Not everyone is going to like the idea o creating yet another account, and certainly not all o the major card issuers are happy at the prospect o being a urther step removed rom the transaction.’ 12

5. (Continued) What is a wallet?  And  An d is it wh what at yo your ur cu cust stom omer ers s ne need ed? ?

Not everyone is going to like the idea o creating yet another account, and certainly not all o the major card issuers are happy at the prospect o being a urther step removed rom 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 unies access to the underlying hardware required to make NFC payments happen. In technical terms this means controlling the download and installation o new payment applications and their associated Cardlets on the Secure Element.

‘A true mobile wallet enables the user to choose the right payment card or each transaction.’

One example o such a wallet is the ISIS scheme in the US ( http://www.paywithisis.com http://www.paywithisis.com ). It is this type o wallet that needs to be taken into consideration when planning your mobile money application. Consumers will continue to use multiple methods o payment, and will expect their payment applications to make it easy or 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 or mobile wallets emerge, you will need to keep pace by updating your app.

‘...the term ‘wallet’ has become rather popular when reerring to mobile money money.. But what is a ‘wallet’ in digital terms, and what should it be?’ 13

6. From From the app back backwards wards:: minimising PCI exposure The payment industry is understandably strict about securing the movement o money. money. The card schemes sc hemes enorce control contro l on almost every aspect o the mobile money ecosystem, ecosystem, and part o that control comes in the orm o the Payment Payment Card Industry Data Security Standard or PCI DSS. These six letters strike ear into the hearts o many application developers. Horror stories o long, expensive testing and approval processes and worse, ailures, abound. But PCI DSS does not need to be burdensome. In act its impact on a new mobile money application can be minimised, without compromising security securit y.

Fundamentally, complying with PCI DSS means avoiding the loss o 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 denes three key objectives with regards to securing mobile money applications: • Objective 1: Prevent account data rom being intercepted when entered into a mobile device • Objective 2: Prevent account data rom compromise while processed or stored within the mobile device • Objective 3: Prevent account data rom interception upon transmission out o the mobile device

‘...PCI DSS does not need to be burdensome. In act 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 o the answer here. This highly secure vault on the phone should contain every piece o account data that we need to complete a transaction. Everything else that is stored should exist behind the walls o the web service with which the application interacts – oten already tested and approved. So our ocus needs to be on minimising the entry and transmission o data. This ocus ts very ver y well with the goals or any mobile application: nobody wants to enter reams o data on a small screen. And moving large amounts o data back and orth over the airwaves is slow and expensive. So ensuring that data entry and transmission is minimised not only adds to the security o the application, it adds to its eciency and perormance.

Careul design can pare back the requirements or data entry and transmission to a minimum, limiting the opportunity or interception and capture. But there is one more source o 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 ailed, are useul in development. But they are also useul to those trying to crack the system. Restricting these error messages and logs to a bare minimum urther reduces the opportunity or attack. Keep the fow and storage o data across the application and its back end to an absolute minimum, and you can also minimise the pain o PCI compliance.

‘Detailed error messages explaining why an interaction with the application, or the web services behind it, it, has ailed, are useul in development. But they are also useul to those trying to crack the system. Restricting these error messages and logs to a bare minimum urther reduces the opportunity or attack.’ attack.’ 15

7. How creati creativi vitty ca can n 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. I there are standards: ollow them. I something has been done beore that worked: do it again. The problem with this approach is that while it is ‘sae’ it is likely to lead to unremarkable results. And in a resh, new new,, but already a lready competitive market like mobile money, remarkable is exactly what you need to be. To be anything else is ar rom sae. s ae.

On this basis, standards need to be treated rather like the rules o ootball. They have to be obeyed but they leave plenty o opportunity opportunit y or fair play, or those that are capable.

‘... in a resh, new, but already competitive market like mobile money,, remarkable 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 or loyalty points and travel move over to the mobile, the physical wallet will become redundant. This presents an opportunity or companies to establish patterns o consumer behaviour, as people choose their new preerred payment options. There are barriers to entering the market today but as we have aimed to show with this paper, they are ar rom insurmountable. And working with a partner like Penrillian that knows the market space intimately,, it’s possible to overcome them rapidly at intimately reasonable cost. Not only that: there is room or innovation. Few o the true opportunities or mobile money have yet been explored. Standards do not have to be seen as restrictions: rather they just dene the rules within which creativity can take place. O the peg applications may tick the box today but they leave little room or competitive advantage in the longer term.

 About  Abo ut Pen Penrilli rillian an Founded in 2000, Penrillian is now one o the most experienced specialist mobile sotware development companies in the world. We develop bespoke sotware solutions and over the years we have developed an impressive range o applications and sotware or some o the leading brands in mobile. For example: example: I you’ve ever used a Vodaone data dongle, purchased goods goo ds using your phone, bought 2-or 2-or--1 cinema tickets on Orange Wednesdays rom a BlackBerry, or managed a T-Mobile account rom a phone, chances are we created the sotware. Nowadays, we are helping our customers remain at the oreront o technology by creating the next generation o secure mobile services and payment apps or operators, banking, payment providers, and nancial services. service s. Working with clients across multiple business sectors, our sotware is helping to engage users and a nd drive revenue and retention.

I 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  T el:: 44 (0) 1768 214400 Web: www.penrillian.com © 2013 2013 Penrillian mobile phone software developers - All A ll rights reserved. reser ved.

Follow us

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close