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