MMT process and user journey

First Steps The right people Your MMT project team will sit at the very heart of your launch and will be responsible for creating all the required partnerships, putting in place the right capabilities and service offerings to make your MMT and mobile financial services business a real success. One of the most important issues to consider right from the outset is who within your organisation will be responsible for managing service implementation. Key to this is ensuring you have a dedicated in-house team with strong project management to manage the implementation and launch of mobile money services. Further senior level buy in and support is required to enable success. When setting up your project team, it is important to include representatives from all those in the value chain; marketing, product, technical, regulatory, pricing, procurement and billing. Crucially it is important to also ensure the team has resource with experience in financial services and banking. Defining Your Customer Service Offering Mobile operators can play a variety of roles in MMT according to their local situation specific strategy. As you move from bearer towards becoming a financial institution there is more complexity and commitment required from the mobile operator, but also more potential rewards in terms of customer ownership. In some examples, the MNO has delivered a MNO branded bank/banking application to the consumer, however the MNO has had to still partner with a bank for their financial license or processing capability or acquire a banking license and source bank processing capability. In some cases, the Bank has delivered a Bank branded mobile banking application to the consumer, however the bank has had to make use of, or partner with the MNO for its infrastructure to provision the application and for ongoing financial transactions. There is often a debate as to who owns the customer for a mobile financial service. The key is to create a win-win partnership for both parties, leveraging their respective capabilities and reach. Choosing the Right Model for You

Bearer Channel Only This model offers low MNO impact/involvement where a MNO only supports the bearer channel or normal consumer voice/data usage and the mobile banking application is built away from the MNO and does not require the MNO for provisioning or support. An example of this would be a JAVA application built by a vendor, where the download of the application is dependent on the network supporting packet data access (eg. GPRS or EDGE) but not necessarily facilitated by the MNO. This environment fosters an easy consumer churn as there is no lock-in to the MNO and no benefit to the MNO over any other network in the market. It is a fairly network agnostic environment. Bearer 1 Bearer Channel and Application Development This model is an example of fairly low network involvement is where the MNO is required to complete some of the application development due to the bearer channel supported. An example of this would be where the vendor/bank makes use of the MNOs hosted USSD2 gateway or IVR platform in the provisioning of the service. There is a dependency on the network to develop the USSD2 menus or the IVR voice flows. This environment assists in creating value for the MNO in the service offering, but is not much of a competitive differentiator as most MNOs would be able to offer similar solutions. Within this, SIM Application Provisioning requires a large amount of MNO involvement, but results in ownership of the application residing on the SIM, which is MNO real estate. This adds value to the consumers SIM and assists in prevention of Churn and perceived value from the MNO to the consumer. The MNO would need the application embedded in the SIM prior to shipping and/or have OTA technology in place to get the application onto the SIM. The MNO would also need data encryption on the SIM and integration into a financial institution for the processing of transactions.

Bank Integration and MNO with a Mobile Banking Hub This model is requires fairly high levels of integration and network involvement is where the network operator would facilitate the implementation of a Mobile Banking platform or Hub and offer the solution in a hosted environment to the banks in market. This would require integration into the banks, customer data repositories, financial switches, etc. The solution would also require auditing and certification. This model requires a high level of MNO involvement and also control over the application. This option gives value to the banks and to the MNO consumers and thus preventing churn and generating new revenue streams. MNO as a Financial Institution This is the highest level of MNO involvement in Mobile Banking or commerce. Where the MNO enters into a joint venture with a bank or obtains a licence to be a financial institution (eg. Emoney institution, bank or payment services provider). The MNO would own the entire value chain. This would be resource and technology heavy and will take time to implement. This level of involvement would require Banking hosts, switches, customer management systems, bearer channel development, audit trails, reporting; etc. It would add value to the consumer but may not be core to the networks business.bile Money Market MMT as a Mobile Money Market Catalyst By placing mobile operators at the heart of the programme, the MMT initiative has the potential to catalyse the whole mobile financial services market, incorporating mobile payments, mobile banking and mobile transfers. Mobile remittances may serve as a valuable catalyst of mcommerce and m-banking on a global scale, bringing social and economic development and driving CSR agendas. The enabling infrastructure for remote transactions of mobile payments, banking and transfers has significant synergies.

Remittances act as a catalyst in two ways. Firstly, as a driver of mWallet acquisition for consumers; consumers receive an alert advising that they have a remittance and need to sign up for a wallet. Secondly, by putting funds in the mWallet for use elsewhere.

Taking the example of Pakistan already mentioned, if each of the 7% of migrant worker population from Pakistan send money back to an average of 4-6 people each then very quickly almost half the population will be receiving and using mobile e-money. This critical mass will drive the ecosystem to support the domestic use of these funds for the community receiving them. Mobile remittances are an important but not sufficient element of successful uptake of e-money and mWallets. To be a compelling consumer proposition there has to be a critical mass of uses of funds from the wallet. The key competitive differentiator for local mWallets will be the combination of cash in and cash out channels and the network of merchants that accept the funds either as mobile payments or with a payment card associated with the mWallet.

Laying your foundations for MMT

Understanding the requirements The four major requirements to participate in MMT are described below.

mWallet The enabling technology required for the delivery of mobile financial services is a mobile wallet. An mWallet is essentially an aggregator of payment instruments. It is a data repository that houses consumer data sufficient to facilitate a financial transaction from a mobile handset, and the applicable intelligence to translate an instruction from a consumer through a mobile handset/bearer/application into a message that a financial institution can use to debit or credit bank accounts or payment instruments. An mWallet includes functionality such as: Authentication of the consumer Storage of billing and shipping addresses Storage of details of bank account, payment card, payment purse or any other payment instrument Storage of transaction history Integration to a bank, perhaps through a financial switch, for purchase, payments and transfers

Financial Service Provider A partnership with a bank aids in the delivery of financial services to the consumer through mobile by: Complying to each markets specific regulation in financial services Leveraging the connection to the global payments network Creating trust with the consumer that their money is within a bank Leveraging the core systems, resources and processes already in place at a bank Enabling a faster path to product delivery

Regulation The MMT initiative is a product of convergence of Mobile Network Operators and Financial Institutions offerings. The Financial Institutions regulatory environment is often unfamiliar to Mobile Network Operators. MNOs offering MMT services are likely to be exposed to some parts of compliance with Financial Institution regulation. This document will identify key challenges and steps to understand and address the regulatory environment are outlined. Remittance Service Provider The global remittance market has four processing environments that the Mobile Network Operator can choose to use: Global Processing Wholesale Remittance Providers Global Bank Newco

These are discussed in detail in the section covering the MNO Launching a Commercial Offering on the website (www.gsmworld.org/mmt).

Where do I get an mWallet? The MMT MNO can either buy an mWallet from an mWallet vendor or integrate into the hosted pilot platform provided by Accenture under the GSMA MMT Market Acceleration Programme. The GSMA MMT Team undertook a vendor analysis that looks at all of the available technologies in mobile financial services. The overview of this analysis and the list of vendors that are participating in the GSMA MMT Vendor Programme are covered below. The Vendor Analysis Completed in April 2007, with next iteration due in April 2008. the Analysis covered 58 respondents of which 23 were evaluated on work that HAD been done as apposed to what can be done. The key findings relevant to mass implementation of mWallets are: Avg. 50 staff at the top vendors Avg. capability of 2 implementations at a time spanning 3-9 months per implementation Each have bearer specific skill sets Each are geographically suited for implementations Due to the increasing demand many new vendors emerging

The role of the Mobile Banking Vendors The Mobile Banking environment requires both a Bank and a MNO to deliver a transactional or informational banking service to a consumer through the mobile phone. In this description, neither the bank, nor the MNO, can deliver the solution to the consumer in isolation. In some examples, the MNO has delivered a MNO branded bank/banking application to the consumer, however the MNO has had to still partner with a bank for their financial license or processing capability or acquire a banking license and source bank processing capability. In some cases, the Bank has delivered a Bank branded mobile banking application to the consumer, however the bank has had to make use of, or partner with the MNO for its infrastructure to provision the application and for ongoing financial transactions. Often times the debate as to who owns the customer for a mobile financial service is endless between the two parties. In all cases the Mobile Banking Vendor plays the pivotal role of integrating the bank and the MNO and technically delivering the application to the consumer. Vendor Analysis The vendor analysis has been completed for the purpose of providing MNOs with adequate information on what the vendor landscape looks like and what considerations should be taken into account when selecting a vendor. The analysis evaluates the following components: Geographic Fit Functionality Service Offering (Financial Transaction type) Bank Product Support Bearer Channel/Consumer Application Vendor Business Model ASP Licensing

Engineering Ability to Implement Implementation Status MNO Integration Bank Integration Complexity of implementation Technical Architecture options Wireless Application Service Providers Application Development Bank System support Additional components Audits/Certifications/Endorsements

Note, that as metioned above, all elements of the analysis were done on a have completed and launched basis as opposed to possible or in development or trial. Geographic Fit Assessing the vendors location, implementation, and representative foot print assists in establishing the likelihood of the vendor to be able to deliver the solution in your market. Geographic fit is defined as the actual Geographic presence (where the office is) and where the vendor has implemented their solution. It is advisable to also establish where the vendor has representation in the form of actual staff/partnerships that can adequately foster implementation as opposed to just representation in the form of sales offices. MULTIPLE MARKETS Bharti TeleSoft C-SAM Fundamo G-Cash GFG Jigrahak mCheck MiPay MobiComp Monitise Movensis mPay Mpesa mTranZact OBOPay PayBox PayM8 S1(Postilion) Simplus SMART Utiba Valista MIDDLE EAST EUROPE INC.UK SOUTH ASIA

ASIA PACIFIC

AFRICA

AMERICAS

Functionality The core functionality offered is the extension of a banks payment franchise to the mobile phone. This involves both the bank in the transaction offered, and the MNO in the mobile channel used to perform the transaction. Transactions While vendors support some transactions and not others, it is noted that if a vendor has implemented transactional banking services, they would typically be able to implement any financial transaction. The supported transactions are categorized as: Domestic Money Transfer International Money Transfer Transactional Banking Informational Banking Top Up Bill Payments Card Acquiring Ability to transfer money within a market Ability to transfer money to other markets Transactions that debit/credit an account Balance enquiries; mini statements Electronic re-load of airtime Utility or telco bill payments Mobile phone as a card accepting device

The key difference in supported transactions would relate to the banking product implemented. Support of card based banking products would mean that the vendor could typically process MasterCard or Visa Card type transactions. If the vendor has only implemented card based banking products they may have difficulty in implementing transactional banking services direct to a bank account. And the same applies for vendors that have not implemented card based services. If the vendor has implemented on card type payments they would probably also only be connected to a payment gateway or acquiring bank institution and thus be limited to process purchases. It is also noted that some vendors offer a proprietary purse or stored value system where there is no requirement for a bank account or bank integration. These solutions are subject to regulatory approval in each market and are not interoperable with the global payment systems. Channels: The mobile channel that the consumer will adopt is a key deciding factor on which vendor and which technology to support. The vendor analysis outlines what the vendor has implemented as opposed to what they can implement. The channels identified are: Client Side Server Side SIM based/dependant applications JAVA/J2ME USSD2 IVR SMS WAP

Each channel presents differing benefits and concerns and can have an affect market adoption and the security of the application. Ironically the best technical and most secure solution (SIM) also has the highest barriers to implementation. MNOs should adopt a multi-channel approach to allow consumer choice and manage the risks around application adoption, with a view to migrate the consumer as/when the market is saturated with the preferred technology. This should ensure speed of uptake and optimize user experience.

SIM based/dependant applications are more likely to be successful in new Telco markets where the SIM penetration is low and a roll out of the application is strategically aligned to the roll out of SIM cards in that specific market. In markets where SIM penetration is already at saturation, it is understood that the consumer would have to either swap their SIM for another SIM bearing the application, or have the application downloaded to their SIM from the network. This has proven to be a stumbling block in many markets where consumers do not take to solutions that require consumer intervention in getting the application. SIM based applications are however the most secure in that the data can be encrypted on the actual SIM card and be transported from the device to the bank in an encrypted format. SIM Based applications do offer the ability to prevent churn in that the consumer SIM is owned by the network, and if there is additional value to that SIM it is unlikely that the consumer would churn. This can be managed in the server side environment by provisioning exclusive services. Reference Vendors: SMART Philippines (SMART/GFG Group) CelPay DRC and Zambia(Fundamo) MTN Banking South Africa (Fundamo) ABSA Bank South Africa (Own Developed)

JAVA applications offer a higher level of aesthetic value for the user than SIM, but face the same accessibility problems in getting the application to the device. JAVA applications reside on the actual device and need to be downloaded by the consumer. This typically requires a GPRS connection to a network and knowledge of how to access the site from which the application needs to be downloaded. This application could pose an issue in the usability of the service if the consumer has not already configured GPRS on their phone. Once the consumer has the application on the phone they should not see any further problems. To alleviate the concerns around accessibility, MNOs could have the application pre-installed on handsets as they saturate the market. This would mean that the consumer would not be affected by the download or settings required to operate the application. It is believed that that the source from which you are downloading the application cannot be verified by the consumer and steps should be put in place not to make the application publicly available but rather facilitate a download process as part of registering for the service. There is not immediate lock in of the consumer to the MNO on JAVA as it can communicate across any network. It is also a concern, as with any client side application, that consumers would have to reload the application if the bank/MNO were to modify the application in any way. Reference Vendors: Multiple Bank and Telco UK (Monitise UK) C-SAM US (Web Reference) OBOPAY US (Web Reference) USSD2 is a channel that has been successfully used in mobile banking implementations as an alternative to menu driven SIM based applications, in markets where the bank or MNO do not believe that the consumer swap or download would affect the adoption rate. USSD2 does not offer the device level encryption of data and thus would require business rules and methodologies in protecting the consumers data. If the network supports USSD2, effectively each consumer can use the channel without affecting the SIM or the device.

10

USSD2 lacks in the aesthetic values that JAVA or WAP bring. The channel benefits in first-usage usability. Reference Vendors: Wizzit Bank South Africa (SimPlus) FNB South Africa (Own Developed) Equity Bank Kenya (mTranZact) IVR (interactive voice response) is DTMF tone entry in response to a voice based menu presented to the consumer. The most common channel for the consumer as the consumer knows how to make a call. The channel offers education on the phone in that the consumer can be instructed in their language. The channel has existed for many years as telephone banking and is thus not innovative or new to the banking world. It suits emerging markets or markets that do not have any other technology choice. The channel is seen to be expensive to the consumer that has to dial in to use the service at their going call tariff rate. IVR is supported by most vendors and is referenced by many sites across the world. IVR can be used by any consumer in the market and does not support any limitations or preventions of churn. Reference Vendors: Mascom Botswana (PayM8) SMS based applications may be the simplest form of mobile banking implementation. The solution is not intuitive and has no aesthetic value but is as simple as sending an SMS. SMS is used primarily as an informational banking tool as opposed to transactional banking. The reason being that transactional banking requires certain levels of security, and while SMS is encrypted using the standard GSM encryption across the air, it is stored in the sent items of the consumers handset, and possible stored in the open at the network and at the vendor. There are examples of Transactional banking implementations on SMS where the risk has been managed through limitations in transaction amounts and data transmission. SMS based solutions also do not support prevention of churn. Reference Vendors: Movensis SMSBank WAP based solutions offer aesthetic value and a similar experience to that of the internet. It is device dependant and requires a GPRS connection with the network. Consumers do not know how to browse on their mobile phones or have not configured GPRS. Typically used in segmented implementations targeted at a higher end consumer base with a higher end device and appetite for aesthetic value. Reference Vendors: C-SAM US NedBank South Africa (Own Developed) Vendor Business Models Two principle models emerged from the vendors: Application Service provider or hosted model, where the vendor owns and manages the infrastructure and banks or MNOs integrate into the infrastructure and share the services. This model has worked well in markets where the banks/MNOs do not want to invest too heavily into their own infrastructure. Examples of successful models ASP models would be Monitise in the UK, Simplus in South Africa, and mTranZact in Kenya. In these cases multiple banks and multiple MNOs use the same

11

infrastructure. The services are typically billed on a per-transaction, per-consumer, or monthly management fee basis. Licensing model, Most of the vendors prefer an outright licensing model that allows the MNO or bank or in-market consortium to own the technology for a licensing fee. The vendor typically becomes the development and maintenance house for the application. Examples would be Fundamo with MTN Banking, and Utiba in multiple market implementations. Some vendors offer both models where technically feasible. Some vendors insist on using single market hosting services which may pose communication and integration dependencies. Some vendors also offer the option of having a customised and once off application engineered for the MNO or Bank. Ability to Implement The actual implementation of a vendor should be cross referenced and is a major factor in evaluating some of the vendors in the list. Implementation status proves that the vendor has actually implemented and has proof of such implementations. It is especially beneficial if a vendor has a commercially viable implementation to show, or is cash flow positive as Mobile Banking is relatively new technology. Vendors without live implementations were excluded from the analysis. It is also worth noting if a vendor has done both a MNO and bank level integration as these are the two major components of an end to end system. MNO Integration Into the bearer channels (USSD2 Gateways; SMSC) For service provisioning (OTA Downloads etc) IN platform for direct load of purchased airtime Into bank switching or processing environments

Bank Integration

Bank integrations are highly complex and time consuming considering the levels of security and standardisation that needs to be complied with. Technical Architecture Options Mobile Banking Vendors play one or more of the following 4 roles: Wireless Application Service Providers (WASPS) This is where they facilitate the communication or transport layer of the banking service. i.e. Carry the instruction to/from the consumer and not any levels of integration into the actual bank. These vendors are referred to as Wireless Application Service Providers. Application Developers The vendor would provide the skills to develop the actual application that resides on the consumers phone or interfaces with the consumer. This would be the WAP Site, JAVA Application, USSD2 Gateway and Menu flow; SMS Gateway; or SIM Application. Bank System Support The vendor would house a financial switch and intelligence to integrate or support the bank system. The vendor would thus be able to translate the instruction from the consumer and submit it in a transaction format that the bank would accept. The vendor would thus have complied with several security requirements; audits; or certifications. Additional Components The vendor would be able to offer additional components such as customer management systems; card management systems; reconciliation or settlement systems; reporting functions; etc.

12

Audits, Certification and Endorsements The Banking environment is filled with audits and certifications and it is suggested that the Vendor rd chosen also undergoes some form of 3 party audit. Examples of these audits/assessments can be found through MasterCard or Visa Vendor Programs and through Global PCI compliance.

13

Partnering with a Bank This section is taken from work undertaken by Andrew Lake and Associates. Partnering with a Financial Institution Before partnering with a Financial Institution it is important to have defined your Customer Service Offering and understand the value proposition for both parties. By doing so the choice of partnership model becomes clearer.

14

If additional revenue only is the key driver then considering supplying communications services to the existing financial players can meet this requirement. This strategy does not require access to a Banking License and as discussed in the Defining your Customer Experience section does not offer as large a revenue stream. Many countries do regulate the money exchanges, but requirements are generally far less stringent. If additional revenue and reducing churn are key drivers then a different partnership is required. In this case a bond needs to be formed between the customers SIM, MSISDN and an underlying pool of funds. Further this requires access to a banking license and access to payments linkages to move money into and out of the pool. To achieve this, one option is to acquire a banking license, however, this is expensive with capitalization requirement is $100s of millions in some countries. Further skills would need to be bought out of the banks and new payments linkages would be required. The other option available is to set up a strong strategic partnership with a Financial Institution. The key models were discussed earlier but are outlined below: Understanding the Right Model for you Bearer Channel Only This model has a low MNO impact/involvement where a MNO only supports the bearer channel or normal consumer voice/data usage and the mobile banking application is built away from the MNO and does not require the MNO for provisioning or support. An example of this would be a JAVA application built by a vendor, where the download of the application is dependent on the network supporting packet data access (eg. GPRS or EDGE) but not necessarily facilitated by the MNO. This environment fosters an easy consumer churn as there is no lock-in to the MNO and no benefit to the MNO over any other network in the market. It is a fairly network agnostic environment. Bearer Channel and Application Development An example of fairly low network involvement is where the MNO is required to complete some of the application development due to the bearer channel supported. An example of this would be where the vendor/bank makes use of the MNOs hosted USSD2 gateway or IVR platform in the provisioning of the service. There is a dependency on the network to develop the USSD2 menus or the IVR voice flows. This environment assists in creating value for the MNO in the service offering, but is not much of a competitive differentiator as most MNOs would be able to offer similar solutions. SIM Application Provisioning requires a large amount of MNO involvement, but results in ownership of the application residing on the SIM, which is MNO real estate. This adds value to the consumers SIM and assists in prevention of Churn and perceived value from the MNO to the consumer. The MNO would need the application embedded in the SIM prior to shipping and/or have OTA technology in place to get the application onto the SIM. The MNO would also need data encryption on the SIM and integration into a financial institution for the processing of transactions. Bank Integration and MNO with a Mobile Banking Hub An example of fairly high levels of integration and network involvement is where the network operator would facilitate the implementation of a Mobile Banking platform or Hub and offer the solution in a hosted environment to the banks in market. This would require integration into the banks, customer data repositories, financial switches, etc.The solution would also require auditing and certification. This requires a high level of MNO involvement and also control over the application. This option gives value to the banks and to the MNO consumers and thus preventing churn and generating new revenue streams. MNO as a Financial Institution

15

This is the highest level of MNO involvement in Mobile Banking or commerce. Where the MNO enters into a joint venture with a bank or obtains a licence to be a financial institution (eg. Emoney institution, bank or payment services provider). The MNO would own the entire value chain. This would be resource and technology heavy and will take time to implement. This level of involvement would require Banking hosts, switches, customer management systems, bearer channel development, audit trails, reporting; etc. It would add value to the consumer but may not be core to the networks business.

16