Mobile Money UK - Penrillian.com
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 successul, 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 successul mobile money app requires the input and support o multiple suppliers and stakeholders rom across the mobile money ecosystem. And it requires many dierent aspects o design and technology to be addressed.
This white paper provides a guide to seven o the key areas o successul 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 successul or your business and appreciated by your customers.
‘Producing a successul, 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 eort, 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 successul 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: • Networkoperator–Carries Networkoperator– Carries the trac 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 • Secureelement–The Secureelement–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 • SecurityAdvisorsandAuthorities– A selection o advisors and approvals will be required beore a mobile money service can be (saely) launched
4
1. (Continued) An App is not enough: understanding the Mobile Money ecosystem
In many cases while the interaces between these providers may be available in theory, in practice much work is needed to make them communicate eectively. For example, one issue Penrillian has aced is that Application Programming Interaces (APIs) have oten been constructed with the desktop web in mind. The dierences 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 inrastructure, you need to nd ways to negotiate between dierent standards with the requisite level o perormance and security.
‘When you can’t demand a complete rebuild o a partner’s inrastructure,, you need inrastructure need to fnd ways to negotiate between dierent standards with the requisite level o perormance 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 successul mobile application on their own. All parties must collaborate eectively to meet the customer’s expectations.
‘In many cases while the interaces between these providers may be available in theory, in practice much work is needed to make them communicate eectively.’ 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 upront cost and production time may be o-putting when set against the instant graticatio gratication 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 signicant security risks.
I your needs are airly straightorward 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 platorm, their development is always going to be ocused on the needs o the many, not your needs specically. 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 oer will drit 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 benets but in the long term, a bespoke platorm can oer signicant 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 interace 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 lie, 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 interace interace 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 lie, 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 beore mobile money: cash or card. For small transactions cash is very convenient. Grab a note or a handul 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 oer 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 conrmations, to match the transaction value, it is possible to oer users a well-structured balance between security and usability.
The risks o the card are very dierent. 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 dierent. 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 lie, 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 careul design o the whole application and supporting inrastructure.
‘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 interace. 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 denes 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 inormation and running secure applications, the Secure Element sits apart rom the rest o the device, sae 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. • Astandalon Astandaloneplugi eplugincardforthedevi ncardforthedeviceinthe ceinthe 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 interaces with the Secure Element via an API specic to the handset operating system, and each takes a slightly dierent 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 interaces 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 dierent 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 reerring 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 dierent. • O2’s wallet relies on you, the user, loading money onto O2’s own payment platorm – essentially a pre-pay card – beore you can make payments. This is a wallet in the pure cash sense: you are eectively loading up your purse with cash rom your account beore going out shopping. s hopping. • Google Google’s ’s Wa Walle llet t is ismuc much h mor more e lik like e the one in your back pocket: it contains all o your dierent 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 unies 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 reerring 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 enorce 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 denes 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 – oten 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 eciency and perormance.
Careul 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 useul in development. But they are also useul 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 useul in development. But they are also useul 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 beore that worked: do it again. The problem with this approach is that while it is ‘sae’ 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 sae. s ae.
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 preerred 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 dene 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 sotware development companies in the world. We develop bespoke sotware solutions and over the years we have developed an impressive range o applications and sotware or some o the leading brands in mobile. For example: example: I you’ve ever used a Vodaone 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 sotware. Nowadays, we are helping our customers remain at the oreront 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 sotware 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
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 successul, 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 successul mobile money app requires the input and support o multiple suppliers and stakeholders rom across the mobile money ecosystem. And it requires many dierent aspects o design and technology to be addressed.
This white paper provides a guide to seven o the key areas o successul 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 successul or your business and appreciated by your customers.
‘Producing a successul, 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 eort, 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 successul 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: • Networkoperator–Carries Networkoperator– Carries the trac 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 • Secureelement–The Secureelement–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 • SecurityAdvisorsandAuthorities– A selection o advisors and approvals will be required beore a mobile money service can be (saely) launched
4
1. (Continued) An App is not enough: understanding the Mobile Money ecosystem
In many cases while the interaces between these providers may be available in theory, in practice much work is needed to make them communicate eectively. For example, one issue Penrillian has aced is that Application Programming Interaces (APIs) have oten been constructed with the desktop web in mind. The dierences 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 inrastructure, you need to nd ways to negotiate between dierent standards with the requisite level o perormance and security.
‘When you can’t demand a complete rebuild o a partner’s inrastructure,, you need inrastructure need to fnd ways to negotiate between dierent standards with the requisite level o perormance 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 successul mobile application on their own. All parties must collaborate eectively to meet the customer’s expectations.
‘In many cases while the interaces between these providers may be available in theory, in practice much work is needed to make them communicate eectively.’ 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 upront cost and production time may be o-putting when set against the instant graticatio gratication 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 signicant security risks.
I your needs are airly straightorward 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 platorm, their development is always going to be ocused on the needs o the many, not your needs specically. 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 oer will drit 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 benets but in the long term, a bespoke platorm can oer signicant 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 interace 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 lie, 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 interace interace 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 lie, 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 beore mobile money: cash or card. For small transactions cash is very convenient. Grab a note or a handul 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 oer 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 conrmations, to match the transaction value, it is possible to oer users a well-structured balance between security and usability.
The risks o the card are very dierent. 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 dierent. 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 lie, 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 careul design o the whole application and supporting inrastructure.
‘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 interace. 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 denes 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 inormation and running secure applications, the Secure Element sits apart rom the rest o the device, sae 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. • Astandalon Astandaloneplugi eplugincardforthedevi ncardforthedeviceinthe ceinthe 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 interaces with the Secure Element via an API specic to the handset operating system, and each takes a slightly dierent 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 interaces 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 dierent 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 reerring 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 dierent. • O2’s wallet relies on you, the user, loading money onto O2’s own payment platorm – essentially a pre-pay card – beore you can make payments. This is a wallet in the pure cash sense: you are eectively loading up your purse with cash rom your account beore going out shopping. s hopping. • Google Google’s ’s Wa Walle llet t is ismuc much h mor more e lik like e the one in your back pocket: it contains all o your dierent 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 unies 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 reerring 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 enorce 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 denes 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 – oten 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 eciency and perormance.
Careul 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 useul in development. But they are also useul 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 useul in development. But they are also useul 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 beore that worked: do it again. The problem with this approach is that while it is ‘sae’ 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 sae. s ae.
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 preerred 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 dene 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 sotware development companies in the world. We develop bespoke sotware solutions and over the years we have developed an impressive range o applications and sotware or some o the leading brands in mobile. For example: example: I you’ve ever used a Vodaone 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 sotware. Nowadays, we are helping our customers remain at the oreront 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 sotware 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
