White Paper

M-Commerce

A Scalable M- Commerce Solution

Table of Contents
1. 2. 3. Introduction .................................................................................................................... 4 Business Model for m-commerce ....................................................................................... 6 M-Commerce Enterprise Framework .................................................................................. 7 3.1. 3.1.1. 3.1.2. 3.1.3. 3.1.4. 3.1.5. 3.1.6. 3.1.7. 4. M-Commerce Ecosystem ............................................................................................ 8 M-Commerce Transaction Process ........................................................................... 8 Stakeholders ......................................................................................................... 8 Fund Transfer Process within Home Network ............................................................ 9 Inter-Operator Fund Transfer Process .................................................................... 10 Regulatory Framework ......................................................................................... 11 Data Security Framework...................................................................................... 11 Payment Processing Platform ................................................................................ 12

Core Payment Support Processes.................................................................................. 12 Core Payment Surrounding Processes ..................................................................... 14 M-commerce Technological Overview .............................................................................. 18

4.1. 4.2. 5.

Tested M-commerce Technologies ............................................................................ 18 Technical Specification for Authentication Elements.................................................... 21

M-commerce Transaction Standards ........................................................................... 22 5.1. 5.2. 5.3. Transfer Account Procedure [TAP]............................................................................. 22 TAP File Format ....................................................................................................... 23 TAP Elements and Adaptability for M-Commerce Transactions ............................ 24

6.

Key Concerns and Issues.................................................................................................. 26 6.1. 6.2. 6.3. 6.4. 6.5. 6.6. 6.7. Regulatory Issues .................................................................................................... 26 Fair Trading Issues ................................................................................................... 26 Financial Issues ....................................................................................................... 27 Privacy Issues .......................................................................................................... 27 Security Issues ........................................................................................................ 27 Consumer Concerns and Behaviour ........................................................................... 27 Compliance............................................................................................................. 28

7.

Revenue Assurance & Fraud Management ........................................................................ 29 7.1. 7.2. 7.3. Policies Processes Procedures.............................................................................. 29 Critical m-commerce Reconciliations ......................................................................... 30 Critical MIS, Revenue Assurance Reports, KPIs and Dashboards ................................... 31

Developing a Scalable m-commerce Solution A TM Forum Initiative

7.3.1. 8. 9. 10. 11.

Dashboards ......................................................................................................... 31

Conclusion ..................................................................................................................... 33 Document Cross Reference ......................................................................................... 34 Glossary ..................................................................................................................... 35 Quick Facts................................................................................................................. 36

List of Figures
Figure 1: m-commerce Milestones ........................................................................................ 5 Figure 2: m-commerce Enterprise Framework ...................................................................... 7 Figure 3: Fund Transfer Process within Home Network ....................................................... 9 Figure 4: Inter-Operator Fund Transfer Process.................................................................. 10 Figure 5: Unencrypted data over an encrypted fixed communication link ............................ 19 Figure 6: Unencrypted data over an encrypted GSM communication layer ......................... 19 Figure 7: Encrypted data over an encrypted fixed link ......................................................... 20 Figure 8: Executive Dashboard ........................................................................................... 31 Figure 9: RA/FM Dashboard ............................................................................................... 32 Figure 10: Coca Cola Dashboard ........................................................................................ 32

Developing a Scalable m-commerce Solution A TM Forum Initiative

1. Introduction

The proliferation of mobile Internet devices is creating an unparalleled opportunity for eCommerce to leverage the benefits of mobility. Mobile commerce, commonly referred to as m-commerce, is the ability to purchase goods anywhere through a wireless Internetenabled device. Mobile Commerce has been defined as follows: "Mobile Commerce is any transaction, involving the transfer of ownership or rights to use goods and services, which is initiated and/or completed by using mobile access to computer-mediated networks with the help of an electronic device. There are few, yet very visible and successful experiences of m-commerce in developing countries, which suggest that m-commerce services would have great potential for the unbanked population. It is all set be the next revenue generator for operator, banks and everyone involved in the eco system. Combined market for all types of mobile payment is expected to reach $600 billion globally by 2013. The m-commerce market currently includes: Peer to peer money transactions (both locally and internationally via remittances); Accessing cash and purchasing goods and Paying bills and paying back loans / micro loans. M-Banking Initial growth of m-commerce was in the through content download and M-banking but with time this model has changed and there are several m-commerce services available today with huge potential for revenue and comfort. It has brought about a change in the current existing m-commerce ecosystem.

Developing a Scalable m-commerce Solution A TM Forum Initiative

M-commerce is next generation's eCommerce with enhanced connectivity and wider reach. It provides the opportunity to tap the customer anytime anywhere. There are 3 billion more mobile subscribers than internet user so this gives a wider reach to sellers and service providers and more connectivity to consumers. Worlds first m-commerce System was launched in the year 2000 since then it had undergone a lot of changes. Some of the key milestones and development that were observed in m-commerce are

Figure 1: m-commerce Milestones

Developing a Scalable m-commerce Solution A TM Forum Initiative

2. Business Model for m-commerce

There are various business models of m-commerce which are adopted around the world. Each solution has its unique value proposition and risk exposure. Given below is a brief overview of some of the solutions historically adopted around the world: Solution Banking System Regulatory and License Constraints Brand Churn Reduction Distribution Chain for cash handling Transactional Risk Cost Revenue Mobile Operator Centric High Infrastructure Requirement High Regulatory and License Requirement MNO Brand Definite reduction in churn MNO only Bank Centric Financial Switching Only MNO / Bank Joint Venture Some Required Banks typically facilitate regulatory compliance MNO Brand Definite reduction in churn MNO and Bank Independent Third Party Solution Not Required

Low Impact

No Impact

Not Used Reduction in Churn

Not Used No reduction in Churn as any MNO can offer the service Not Used

Not Used

All of the risk Very High Very High M-Pesa by Safaricom, GCASH by Globe telecom etc

Some Some cost Good

Half of the risk High Cost High

None Marginal Low

Examples

Mobile Banking Facility Available ZAP by Zain. for all banks

PayPal, Visa, etc

Table 1: Comparision of different m-commerce Business Model

Developing a Scalable m-commerce Solution A TM Forum Initiative

3. M-Commerce Enterprise Framework

As part of the TM Forum Catalyst program initiative and after comparison across various models and solution platforms available, following has been suggested as a Framework to facilitate smooth execution of M-Commerce transactions. The subsequent sections will elaborate on the critical aspects of each of the constituents:

Figure 2: m-commerce Enterprise Framework

Developing a Scalable m-commerce Solution A TM Forum Initiative

3.1. M-Commerce Ecosystem

A scalable m-Commerce solution should have a robust ecosystem which comprehends a number of intricate elements including: a transparent Transaction Process covering all the critical Stakeholders with a quick feedback, clearing, settlement and risk management process; a progressive Regulatory Framework and a strong and pro-active Data Security Framework 3.1.1. M-Commerce Transaction Process

M-Commerce transaction process involves transfer of money or value of a transaction through a secured channel from one mobile subscriber to another irrespective of whether the two subscribers are in the same network or belong to the same country. Accordingly, MCommerce transactions are expected to be seamless and have the following critical components: Authorization The Subscriber sends a transaction request to his own MNO. The MNO verifies with the subscriber, almost instantly, that the mPIN, CID and transaction amount are valid, and then transaction is processed. Transfer After the transaction is authorized, the transaction is transferred as per a pre-agreed protocol, to the recipient (who may be within the same MNO network, cross operator or even cross border, as has been envisaged). Clearing and settlement A cross operator transaction clearing and settlement happens in batches, through the Clearing and Settlement House and thus sender/customer account is either debited or credited as the case may be. Until such arrangement is formalized between multiple operators, two or more operators can through bilateral agreements and protocols clear and settle the transaction traffic.

3.1.2.

Stakeholders

Following are the key stakeholders in the execution of the m-commerce transaction and settlement: Subscribers Mobile Networks Operators (MNO) Merchants Retailers Banks Micro Finance Institutions Service Industries and Utilities Government

Developing a Scalable m-commerce Solution A TM Forum Initiative

Apart from the aforementioned, there are other parties that support in the execution and settlement of the transactions at various points in time. Some form an integral part of the key stakeholders: Mobile Device Databases Billing Systems Text Messaging Services Hardware/Software Design Mobile Payments Brand Recognition Distribution Control Web Site Development And Hosting Web Site Performance Monitoring Fulfillment Management Online Marketing Order Processing And Delivery

3.1.3.

Fund Transfer Process within Home Network

The transaction process could vary depending on whether the subscribers are within the home network or not. Following is a brief description of the transaction and fund flow: For m-commerce service an application similar to an m-commerce server is needed, which can interact with IN for passing Debit as well as Credit command/ticket for any transaction. This Sever should be compatible with other network elements like MSC and IN. As HLRs currently used by operator does not have any feature like VALIDATION of m-commerce services, hence either HLR needs to be updated or the m-commerce Application Server should be capable of validation of service. Again IN needs to be upgraded for such service.

Figure 3: Fund Transfer Process within Home Network

Developing a Scalable m-commerce Solution A TM Forum Initiative

How does it work? Step 1: A-number sends a USSD to a destination code. Step 2: The content of this USSD are CID to be credited, Self mPin, Denomination of Transaction Step 3: All validation for this service are done at m-commerce Application server level and not at HLR level Step 4: Once the transaction is validated at m-commerce Application level, mcommerce server passes a command on IN for debit and credit of balance from both respective account of Customer and Merchant 3.1.4. Inter-Operator Fund Transfer Process For any cross operator transaction, similar arrangements should be there at both the operators end. All systems should be compatible to each other at both end. For Secure Transfer of Message (mPIN, TAC and other secret info between mcommerce Application Server of Cross Operator) current SS7 signaling will be sufficient hence operators can opt any of the following IP Secure Signaling MPLS secure layered architecture VPN (Virtual Private Network) Once these arrangements are done and services commence, operators can settle their account as per agreed SLA

Figure 4: Inter-Operator Fund Transfer Process

Developing a Scalable m-commerce Solution A TM Forum Initiative

10

How does it work? Step 1: Customer sends an USSD to Operator A. Step 2: The content of this USSD are CID to be credited, Self mPin, Denomination of Transaction Step 3: All validation for this service are done at m-commerce Application server level and not at HLR level Step 4: Once the transaction is validated at m-commerce Application level, mcommerce server passes a command on IN for debit and credit of balance from both respective account of Customer and Merchant

3.1.5.

Regulatory Framework

Regulation is seen as an enabler and limiting factor for an environment. The inherent structure is such that there is an organizational body (government, standardization body, industry grouping) that controls in a form and/or usage of certain technological artifacts. The limits of the controlled domain can be given by the technology or by a geographic region or both. Although mobile commerce (m-commerce) is a relatively new area, there are rules and regulations to consider, especially if you want to offer services for micro-payments. The more a mobile operator becomes involved in the provision of financial services, the heavier will be the burden of financial regulation. The first level of financial regulation is Anti-Money Laundering (AML) compliance, which generally becomes applicable when the mobile operator becomes involved in cash handling at the consumer interface. A strong agent network needs to be setup in adherence with regulation that state that the Know Your Customer (KYC) & Customer Due Diligence (CDD) which in most countries can be performed by financial agents needs to be adhered by. The next level of regulation applying to mobile operators is prudential regulation. Prudential regulation becomes applicable when risks increase for the involvement of the mobile operator in the financial transaction, for consumers and for the wider financial system. Regulators have to set up standards for operators who wish to offer m-payment facilities to their users. With a system for companies who allow for mobile payments to be registered with government regulations, so that consumers know they can get a refund if a service is not delivered as promised 3.1.6. Data Security Framework

As operators open up interconnection points, and support new interfaces for message submission from applications, there is an increased risk of security breach, giving fraudsters and spammers new opportunities for targeting subscribers via the messaging service. M-commerce concept would be rendered unworkable if vital messaging bearing technologies are compromised.

Developing a Scalable m-commerce Solution A TM Forum Initiative

11

A robust Data Security Framework ensures that a range of undesirable messages that seek to attack or defraud subscribers or network infrastructure. Such a framework should ideally stop spoofed and faked messages that are impossible to bill, ensuring that network bandwidth is freed up for revenue generating traffic. A robust Data Security Framework should provide a two-stage mechanism to detect Spam messages: Spam Traps: Detect Spam activity and log a record of it in either the Candidate list or the Active list. These lists are placeholders for storing copies of detected Spam activity. Spam Filters: Subsequent messages that match the messages in the Candidate or Active list can then be filtered out using specific Spam filters that use the messages in these lists. Encryption Standards: All data transferred through the network should be encrypted. The following are the encryption standards generally deployed in the industry:
Encryption Standards ANSI X9.8 ANSI X9.24 ANSI X9.42 Encryption Standards Description Banking - Personal Identification Number Management and Security Financial Services Key Management Using the Data Encryption Algorithm Public Key Cryptography for the Financial Services Industry: Agreement of Symmetric Keys Using Discrete Logarithm Cryptography ANSI X9.52 ANSI X9.62 Triple Data Encryption Algorithm Modes of Operation Public Key Cryptography for the Financial Services Industry : The Elliptic Curve Digital Signature Algorithm (ECDSA) ANSI X9.63 Public Key Cryptography for the Financial Services Industry, Key Agreement and Key Transport Using Elliptic Curve Cryptography Table 2: Encryption Standards

3.1.7.

Payment Processing Platform

Core Payment Support Processes Core Payment Support Processes are the chain of activities that ensure smooth delivery of value in terms of products, services, support, and information. Following are some of the core support processes: i. Funding, Clearing & Settlement: Two or more operators can commence transacting through specific agreements and protocols governing timelines and mode for settlement. A model similar to that being used to settle roaming transactions can be initiated where in a Clearing and settlement House is used as an in intermediary to facilitate both Data Clearing and Financial Clearing. A Clearing & Settlement House stands between two operators and its purpose is to reduce the risks. It facilitates enhanced decision making through comprehensive financial, marketing and statistical reporting, while improving revenue assurance through extensive data checking and fraud detection. 12

Developing a Scalable m-commerce Solution A TM Forum Initiative

Minimizes resources required to handle funding, exchange of traffic and settlement; Reduces communication charges through alternative data clearing solutions; Includes fraud/high usage monitoring management. A Clearing House reduces the settlement risks by offsetting transactions between multiple counterparties, by requiring collateral deposits, by providing independent valuation of transaction and collateral, by monitoring the credit worthiness of the clearing firms, and in many cases, by providing a "guarantee fund" that can be used to cover losses that exceed a defaulting clearing firm's collateral on deposit. ii. Risk & Revenue Management: Support to handle the following critical issues associated with M-Commerce transactions: Excess payment to the vendor There is an increased risk of excess / short settlement for transactions of M-Commerce in the absence of transaction/ amount based reconciliation between the merchant/service provider system and the in-house systems. Payment for failed transaction - In the absence of transaction authentication process, amount may be paid for failed transaction at the payment gateway. System Failure A possible system error or link failure may allow payment to be made to the merchant despite the balance being insufficient in the mobile wallet. Weak IT Security Control for m-commerce Server - Weak security controls can lead to unauthorized access to the server and fraudulent money transfer. Internal Fraud - Money can be transferred by internal employees having access to M-commerce server to make bill payments, third party transfer etc. Money Laundering Issues In the absence of a robust KYC verification and transaction exchange protocols and reconciliation in place, there is an increased risk of illegally-obtained money being transferred / routed for unauthorized / illegal transactions.

iii. Customer Care Support: Customer service is normally an integral part of a companys customer value proposition. Customer service may be provided through tele-support, web-support or through pre-configured IVRs. The customer at the end should have an enjoyable and comfortable experience in using the service.

Developing a Scalable m-commerce Solution A TM Forum Initiative

13

Core Payment Surrounding Processes Following processes are key to a secured and unified transaction execution, exchange and reconciliation: i. Client Identification & Authentication: Customer identification is based on MSISDN number of mobile phone device. Authentication is performed based on account PIN that is entered by a customer. End-to-end encryption is assured, providing that PIN is transferred towards issuer in a secure manner. ii. Network & Interface Platform Network & Interface Platform is crucial for communicating across networks, and makes it possible for the subscribers of two different operators to communicate with each other. It is essential for extending the scope and efficiency of the telecom network, and is especially important for new operators entering the market who normally use the existing facilities of another operator for providing these services. Network & Interface Platform involves a linking up of one telecom operator to the infrastructure facilities of another. iii. Database Management Platform All the mSP transactions are sent to the destination code. The data is Hexadecimal Encoded for security concerns. The Security server decodes the details of the transactions. The transaction then automatically imported to the m-commerce Application Platform where the mSP customer account is debited or credited as the case may be. The Action reflects in the Database. The Revenue Assurance & Fraud Management has access to the details from the m-commerce application server and the Database. iv. Transaction Process: This includes procedures for initiation, execution and exchange m-commerce Service Provider (mSP) related traffic. Transaction process for mobile Money (m-Money) can be defined as: Payment for goods and services Customer Cash IN Process Customer Cash Out Process Merchant Cash IN Process Merchant Cash Out Process

Developing a Scalable m-commerce Solution A TM Forum Initiative

14

Customer cash in process

Customer cash out process

a. Customer goes to an mSP Shop to purchase a. Customer goes to an mSP Shop to withdraw m-Money. Depending on the outlet this can m-Money. be done using cash, cheque, debit card or other forms of payment. b. The mSP agent confirms the amount to be withdrawn by the customer. At this stage b. The mSP Agent accepts payment from the the Agent need to confirm the identity of customer and advises them on the the customer and ensure they have not additional charges for purchasing m-Money. already exceeded the daily limit for These charges include the transaction fee withdrawing. and any government taxes. c. The mSP agent informs the customer that c. If the customer wants m-Money that either these charges can either be paid separately exceed the daily limit or are not available or deducted from the received funds. The they are advised at this point. customer then advised the mSP Agent of their preference. d. The mSP agent informs the customer that these charges can either be paid separately d. The mSP agent calculates the total charges or deducted from the received funds. The and advises the customer. Standard fraud customer then advised the mSP Agent of checks are carried out at this stage; their preference. including customer withdraw history. e. The mSP agent calculates the total charges e. The mSP Agent requests the customer to and advises the customer. Standard fraud transfer m-Money to the shop account. checks are carried out at this stage; Customer does this using their handset. including validation of cash received. Agent records transaction in POS. f. Once the customer agrees, the mSP agent f. books the sale in the POS and outputs a receipt for the transaction. mSP Agent receives confirmation of fund transfer via SMS from mSP system. The SMS contains information on the transaction ID, Senders number, amount received and the current balance after the transaction.

g. mSP Agent transfer the m-Money from the Agents account to the customers account h. Once the Agent has sent the funds, the Agent receives an SMS from the mSP system showing the transaction identification number, amount sent, the number sent to and the balance of the Agents account. i.

g. Customer receives confirmation of the fund transfer via SMS from the mSP system. The SMS contains information on the transaction ID, name of receiver, amount sent and the current balance after the transaction.

The customer receives an SMS from the mSP h. The mSP Agent hands to the customer the system showing the transaction ID number, funds and receipt for the transaction. Agent amount received, the senders name, and updates the reconciliations to reflect the balance after the transaction. withdraw transaction. The mSP agent confirms completion of the transaction to the customer and provides them with the transaction receipt.
Table 3: Customer Cash In\Out Process

j.

Developing a Scalable m-commerce Solution A TM Forum Initiative

15

Merchant cash in process

Merchant cash out process

a. Dealer/Agent goes and deposits funds onto the mSP a. Enterprise/Merchant/Dealer/Agent account. This can be done at any bank where mSP (EMDA) completes the funds has a mSP Account. The Dealer/Agent needs to add withdraw form and forwards it to their Name and Mobile Number on the deposit slip. the Dealer/Agent Manager. b. On receipt of the duly filled and signed individual b. Dealer/Agent Manager verifies consumer account registration form, the Shop funds withdraw form and confirm if Manager/Agent reviews & vets the application form EMDA has indicated funds ensuring that all mandatory fields are completed available. accurately and verifies the documentations against the originals and makes copies of the originals. c. mSP Stock controller receives funds c. Shop Manager/Agent approves the request and withdraw form from Dealer/Agent enters detail into the shop phone or GUI to be Manager. On the funds withdraw captured into the mSP system. The customer is form, there are details of the activated with Temporary status, which has limited account mobile number and the functionality. account details of where the funds are to be transferred. This d. Shop Manager/Agent forwards the Application form information is cross check against & documents to the mSP Customer Care Team. mSP records. e. Shop Manager/Agent informs the customer that d. mSP Stock Controller then initiates their registration was successful, the account has the de-allocation of funds from the Temporary status until vetting/authentication EMDA mSP virtual account. This process is completed. step is validated by another team with Finance. Can be Revenue f. MSP Customer Care Team confirms particulars Assurance. captured by agent as viewed on the Web interface and matches them against those in the physical e. mSP Stock Controller instructs documents and also review the number of Treasury to transfer equivalent transactions. funds from the mSP settlement account to the EMDA account. g. Once feedback on successful vetting is received, search for the customers account using the f. mSP Stock Controller confirms appropriate search criteria, compare the transaction to Dealer/Agent and information on the systems against the national files documentation to the effect. identity card, update personal information appropriately an contact information (on ID Type, indicate customers identity number, update account type from Temp to m-commerce.) This updates the account with full functionality. h. Upon successful activation of the account, the Customer will then receive an SMS welcome message confirming successful creation of virtual account.
Table 4: Merchant Cash In\Out Process

Developing a Scalable m-commerce Solution A TM Forum Initiative

16

v. Accounting, Reporting & Reconciliation: Revenue Reporting, Local Operations Transaction reporting, Transaction settlement reports with other OpCos are carried out on a daily basis or as per a pre-agreed frequency. Critical reconciliations need to be carried out with regular frequency to ensure timely and accurate accounting and settlement. Some of the reconciliations are given below: Deposit / Withdrawal reconciliation Shop Cash Reconciliation and withdrawal reconciliation Transaction fee reconciliation User Log reconciliation vs. User Ids activated Settlement account reconciliation with dealers, merchants, other operators and customers

Developing a Scalable m-commerce Solution A TM Forum Initiative

17

4. M-commerce Technological Overview

A M-commerce transaction is any type of business transaction of an economic value that is conducted using a mobile terminal that communicates through Mobile Network Operators. Trust and Security play a vital role in m-commerce Transaction. Subscribers sensitive data should be kept on a server and not on the handset. For this subscribers should be provided with a secured interface and trustworthy m-commerce Applications.

4.1.

Tested M-commerce Technologies

The mobile channel that the operator will adopt is a key deciding factor on which technology to support. The technologies identified for m-commerce transaction are:
Client Side Technologies SIM based/dependant applications JAVA/J2ME Server Side Technologies USSD2 IVR SMS WAP
Table 5: m-commerce Technologies

Developing a Scalable m-commerce Solution A TM Forum Initiative

18

Each technology presents differing benefits and concerns and can have an effect on market adoption and the security of the application. 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. SMS based m-commerce Solution Data Security SMS based m-commerce solution is deemed to be the least secure. This is due to the number of points that the SMS data is available to others in a clear or unencrypted format. A consumer would initiate a transaction by sending an SMS to the bank using the banks SMS short code as a terminating address.

Figure 5: Unencrypted data over an encrypted fixed communication link

The SMS would be automatically stored on the handset and be available to anyone that looks at the consumers phone. The SMS would then pass through the encrypted GSM communication channel, through the base stations and terminate at the mobile network operator, where it is typically stored unencrypted. IVR, USSD based m-commerce Solution Data Security IVR, being a voice call, is protected by both the encrypted GSM communication layer as well as the GSM protection of the subscriber identity of the consumer and it is carried across the mobile networks. Only the entries that the consumer has keyed into their phone are stored. USSD2 is similar to IVR from a secured data security perspective, in that, it opens a single session between the device and the USSD2 application at the network operator. In other words the transaction is completed while the session is open and is not stored for subsequent completion.

Figure 6: Unencrypted data over an encrypted GSM communication layer

The end-to-end transaction flow is across the encrypted GSM communication layer and the subscriber identity is also hidden. The data can also be encrypted as soon as it terminates at the USSD2 gateway sitting at the network operators, thus preventing any internal risk of misuse of data. Therefore the only risk is that the data carried within the communication layer is not itself encrypted. If someone were to be able to break the GSM encryption, they would have access to the data.

Developing a Scalable m-commerce Solution A TM Forum Initiative

19

In IVR, USSD2, and SMS based m-commerce channels, the consumers sensitive data is typically kept on a server and not on the handset. This data is encrypted. The data entered into the handset is limited to authentication of the consumer and the transaction instruction from the consumer. J2ME, WAP and STK Based m-commerce Solution Data Security WAP allows for a GPRS session to be opened between the handset web browser and the web application at the MNO. This session is protected once again by the encrypted GSM communication layer and then can be further protected by encryption of the actual m-commerce website that is being accessed. This makes WAP transactions open to similar threats as internet banking, yet further secured in that the MNO can establish that the session has been initiated by the consumers SIM.

Figure 7: Encrypted data over an encrypted fixed link

J2ME uses the same bearer channel as WAP. However J2ME applications can have additional security around the application that is resident on the handset. Thus the data entered into the J2ME application can be encrypted at that point and sent across the GPRS channel as described above. It would only be decrypted at the MNO processor. J2ME is however open to certain attacks in that the consumer needs to establish that the application is being downloaded from the correct source and that the source is not that of a malicious attempt to copy the banks application in order to obtain sensitive data from the consumer. The SIM Application Toolkit (commonly referred to as STK) is the most secure method of mcommerce transactions. STK is a standard of the GSM system which enables the SIM to initiate actions which can be used for various value added services. The STK consists of a set of commands programmed into the SIM card which define how the SIM should interact directly with the outside world and initiates commands independently of the handset and the network. This enables the SIM to build up an interactive exchange between a network application and the end user, and access or control access to the network. The SIM also gives commands to the handset, such as display menu and ask for user input. STK can have an m-commerce application login password so that the subscribers feel secured while using the m-commerce services. It allows the MNO to load its own encryption keys onto the SIM card with the MNOs own developed application. Thus the consumers data can be stored on the SIM Card and the consumer can be authenticated on the handset prior to having to carry any data across the mobile network. The data is also encrypted prior to leaving the handset and only decrypted using the MNOs encryption keys within the Intelligent Node (IN) of the MNO. Recommended Technology for m-commerce Using STK as client side technology and USSD2 or WAP as the server side technology secured transmission of subscriber encrypted data over an encrypted fixed line can be performed.

Developing a Scalable m-commerce Solution A TM Forum Initiative

20

4.2. Technical Specification for Authentication Elements

The following m-commerce Transaction Authentication Elements should be used to mitigate the gaps in the m-commerce security environment mPin CID TID TAC Mobile PIN Customer ID \ Merchant ID Transaction ID Transaction Authorization Code

mPIN Min Code Length Max Code Length Code Type Code Owner 4 digits 6 digits Integer Subscriber

CID 9 digits 9 digits Integer Operator A Prefix of 3 digit for mobile country code and 3 digit for mobile network code as per the GSMA standards followed by the 9 digits CID

TID 8 digits 8 digits Integer Operator

TAC 4 digits 6 digits Integer Operator

Format Description

As per the Regulatory guidelines of the Central Banks for m-commerce by different countries

As per the Regulatory guidelines of the Central Banks for m-commerce by different countries

As per the Regulatory guidelines of the Central Banks for mcommerce by different countries

Definition Stage

First mPIN would CID would be be defined by the defined by the Operator and then Operator at can be changed by the time of the Subscriber Registration

TID would be defined by the Operator of the subscriber who initiates the transaction

TAC would be defined by the Operator of the subscriber who initiates the transaction Valid on for a Session of 24 hours Can't be Modified

Life Cycle

Lifetime mPIN can be modified by the Subscriber

Lifetime

Lifetime

Modification

Can't be Modified

Can't be Modified

Table 6: Technical Specification for Authentication Elements

Developing a Scalable m-commerce Solution A TM Forum Initiative

21

5. M-commerce Transaction Standards

Transaction standards and protocols are critical to facilitate smooth exchange of data and financial transactions across operators. Lack of a uniform and effective transaction protocol could result in an increased risk of data and revenue loss for the MNO. To offer wider acceptability and quick execution, standards currently operational and effective across operators can be adopted and modified to incorporate M-commerce transactions. One of the most popular and highly effective transaction standard rolled out by GSMA can be used. Data can, accordingly, be exchanged using the TAP file format. The formats can be modified and linked to any changes made by GSMA. As on date, the file format operational is the TAP 3.11. This can be extended to cover relevant fields required for M-Commerce eg: specific fields for TID, CID, TAC etc.

5.1.

Transfer Account Procedure [TAP]

It is a mechanism by which operators exchange roaming billing information (CDRs). This is how roaming partners are able to bill each other for the use of networks and services through a standard process. This TAP file can also be used for m-commerce transaction information between the operator either through bilateral settlements or through a clearing and settlement house model.

Developing a Scalable m-commerce Solution A TM Forum Initiative

22

5.2.

TAP File Format

Given below is the TAP File format as approved by GSMA: Tag range 0-6 7-8 9-142 143 144-237 238 239-511 512-513 514 515-528 529-531 532-553 554-1023 Description Reserved for TAP In Use for both TAP and RAP Reserved for TAP In Use for both TAP and RAP Reserved for TAP In Use for both TAP and RAP Reserved for TAP In Use for RAP Reserved for RAP In Use for RAP Reserved for RAP In Use for RAP Reserved for RAP
Table 7: TAP File Format

(This space has been intentionally left blank)

Developing a Scalable m-commerce Solution A TM Forum Initiative

23

5.3.

TAP Elements and Adaptability for M-Commerce Transactions

The Element in TAP format that can be used for m-commerce transaction is: Field Name Data Transfer Transfer Batch Conditions Mandatory Mandatory Consist of the Mobile Country Code (MCC) & Mobile Network Code (MNC) of Sender & Receiver, timestamp, File Sequence Number Consist of Tax Rate Code, Tax Type, Tax Rate and Local Currency Consist of Exchange Rate Code, Number of decimal places, Exchange Rate and TAP decimal places Consist of UTC Time Offset code and UTC Time Offset Consist of Recording Entity Code, Recording Entity Type and network Type Consist of Country Code and International Access Code Description Adaptability for M-Commerce? Yes Yes

Batch Control Information

Mandatory

Yes

Accounting Information Taxation

Conditional Conditional

Yes May be

Currency Conversion Network Information Coordinated Universal Time (UTC) Offset Information Recording Entity Information

Mandatory Mandatory Mandatory Conditional

Yes Yes Yes Yes

Called Number Analysis Call Event Details (1)

Mandatory Mandatory

Yes Yes

Table 8: TAP Elements

Developing a Scalable m-commerce Solution A TM Forum Initiative

24

Proposed format of the M-Commerce TAP file :

Field Name CID of Sender Senders Basic Information CID of Receivers Receivers Basic Information Destination Location Information Network Location Geographical Location Equipment Information Basic Service

Conditions Mandatory Mandatory Mandatory Mandatory Conditional Mandatory Mandatory Optional Conditional Mandatory

Description This would contain the TID, encrypted mPIN, IMSI and MSISDN This would contain the TID, encrypted mPIN, IMSI and MSISDN This would contain the nature of address, timestamp, city in visited network, region in visited network This would contain recording Entity Code, transaction reference, location area code, Cell Identity This would contain the Serving Billing Identifier, Serving location Description This would contain the IMEI This would contain the m-commerce service available, services used, service code This would contain the Transaction Type, Exchange Rate code, Transaction Amount This would contain the TAX Rate Code and TAX Value

Transaction Information Tax Information

Mandatory Conditional

Table 9: Recommended m-commerce Transaction CDR

Developing a Scalable m-commerce Solution A TM Forum Initiative

25

6. Key Concerns and Issues

6.1.

Regulatory Issues
Only banks which are licensed, supervised and have a physical presence are permitted to offer mobile payment services The services should be restricted to only to bank accounts/ credit card accounts which are KYC/AML compliant. All the transaction should be in a single currency. Know Your Customer (KYC) and Anti Money Laundering (AML) as prescribed from time to time would be would be applicable to customers opting for mcommerce service.

6.2.

Fair Trading Issues

How will m-commerce service providers ensure that consumers have access to required information (e.g. terms and conditions of the transaction) and prove that consumers have agreed to such terms and conditions? Who will be responsible for providing information to a consumer about a product? Will there be some liability on the carriage service provider or will it be up to the supplier/service provider to provide this information? There exists a regulatory framework within Australia at both the Commonwealth and State and Territory level prohibiting misleading representations. Should legislation also provide for minimum information that should be disclosed to consumers at the time of making a purchase?

Developing a Scalable m-commerce Solution A TM Forum Initiative

26

Are current arrangements for the resolution of consumer complaints appropriate and adequate to deal with issues likely to arise from m-commerce? What options are available and suitable to hear and resolve consumer complaints in relation to m-commerce services?

6.3.

Financial Issues
Is the self-regulatory framework that has been developed adequate to deal with increasing electronic trade, both online and using m-commerce? What regulatory protections could be considered to improve consumer protection in electronic purchasing and payments?

6.4.

Privacy Issues
What additional protections need to be put into place to protect consumers from receiving commercial advertising on their phones? How does Australian privacy legislation protect wireless information exchange? Will current privacy legislation protect consumers from their information being shared between service providers?

6.5.

Security Issues
Should government have a role in implementing minimum security requirements for m-commerce transactions? What protections will be in place for a consumer if a mobile phone with commerce capabilities is lost? Who will liable? Should there be mandated levels of disclosure from companies involved in electronic transactions about the sorts of security systems used? How well will current content laws apply to the increasing use of mobile phones to access and transmit inappropriate content?

6.6.

Consumer Concerns and Behaviour

The leading concern amongst consumers regarding mobile payments is insecurity.

Delivering mobile alerts and information services to consumers in the first instance to develop channel trust. Provide and communicate service guarantees and real-time customer care processes (such as immediate remote service suspension). Reinforce safety and security within the aesthetics and syntax of the consumers experience (such as centre brand messaging around security). Visibly deliver best practice payment technology elements, such as transaction identifiers and effective repudiation management.

Developing a Scalable m-commerce Solution A TM Forum Initiative

27

6.7.

Compliance
National, international and regulating industry bodies already have an interest in payment systems and services, and are becoming more engaged and prescriptive in the compliance requirements for providers of mobile payment services. International examples in this context include PCI Data Security Standard, AntiMoney Laundering (including Suspicious Activity Reporting (SAR)), Basel II (internal and external fraud provisions) and Know Your Customer legislation and guidelines. The employment of industry best practice and use of banking grade architectural principles upfront in the design and deployment of mobile payment solutions will assist financial institutions to reduce the cost and time-to-market impact of their compliance requirements as they apply to mobile payments.

Developing a Scalable m-commerce Solution A TM Forum Initiative

28

7. Revenue Assurance & Fraud Management

This section details all the controls for Finance, Revenue Assurance and Fraud that need to be implemented to ensure best practice for the m-commerce management.

7.1.

Policies Processes Procedures

This 3P provides a framework to ensure effective monitoring of m-commerce transaction. It includes: Monitoring of fund transfers made by shops. Reviewing access logs to ensure compliance with IT Policies. Monitoring high usage by subscribers/ enterprises and corporate Monitoring compliance with KYC norms

Table 10: Policies - Processes - Procedures

Developing a Scalable m-commerce Solution A TM Forum Initiative

29

7.2.

Critical m-commerce Reconciliations

Below is the list of controls that need to be implemented within the operation to ensure best practice with regards to revenue assurance and fraud prevention.
Sr. No. 01 Control mSP Settlement Account Reconciliation mSP Deposit/Withdra w Verification mSP Transaction Fee Reconciliation mSP Shop Cash Reconciliation mSP Shop Cash Verification mSP Account Reconciliation mSP Revenue Verification mSP Reconciliation Review mSP Transaction Review mSP User Review mSP Log Review High Balance Review Control Details Reconcile the mSP virtual Account balance against the mSP Bank Account Verify that the actual amount deposited or withdrawn match virtual against real Confirm that transactional fees are charged. Reconcile mSP Shop Cash against mSP transactions for shops Review Shop mSP Cash reconciliations Reconcile mSP merchant accounts Verify reported mSP revenues Review of all mSP reconciliations; Sample based Review of all mSP allocations Review of the users and their access rights Review the mSP system logs for fraud activity Review of accounts with large balances or large deposit/withdraw Review of subscriber registration forms (sample based) Ensure compliance with AML
Table 11: Controls & Reconciliations

Type Detective

Frequency Daily

02

Preventative

Daily

03

Detective

Weekly

04

Detective

Daily

05 06 07

Detective Detective Detective

Daily Daily Monthly

08

Detective

Weekly

09 10 11

Detective Detective Detective

Weekly Monthly Weekly

12

Detective

Weekly

13

KYC Verification Anti-Money Laundering

Detective

Monthly

14

Preventative

Monthly

Developing a Scalable m-commerce Solution A TM Forum Initiative

30

7.3.
7.3.1.

Critical MIS, Revenue Assurance Reports, KPIs and Dashboards

Dashboards
Executive Dashboard Illustration Only

mCommerce For FY 2009

Compare

Reset

Exp ort

mCommerce Vs. Total Snap shot Subscribers Revenue ($) ARPU ($)

mCommerce Interactive Analysis Transaction Charg es 150

mCommerce

12 M

14.5 M mCommerce
.

mCommerce .

1.15

100 50

0
Cr Dr P2P B2B B2C C2B

72M
Total mCommerce Snap shot
1200

8.5 B
Total

9.05
Total
Merchant Corporate Agent

Customer Volumes

Dealer
Permanent C2B Temporary 0 50 100 150 200 250 300

1000
800

B2C
B2B P2P

600
400

Dr
Cr

Transaction Volumes for Temp orary

200
0 Temporary Permanent Dealer Agent Corporate Merchant

250 200 150 100 50 0 Cr Dr P2P B2B B2C C2B

Figure 8: Executive Dashboard

Developing a Scalable m-commerce Solution A TM Forum Initiative

31

RA/FM Dashboard Illustration Only

mCommerce

Exp ort

mCommerce Financials

Metric Gross Loss (in USD '000) RA Leakages (in USD '000)
Fraud Loss (in USD '000) Savings (in USD '000) Gross Revenue (in USD '000) % of Gross Losses % of Savings on Losses mCommerce Prob lem Areas By Segment In USD00 | %of Leakage mCommerce Prob lem Areas By Seg ment in USD00 FY 09-10 Revenue Manag ements Contrib ution

FY 08
252

FY 09
144

FY 10

112.4 5670
4.44% 1.98%

219.8 8230
1.75% 2.67%

10

180 160
140 120

0.5 Profit

1 Recovered Revenues

1.5

2.5

100 80
60 40

Averted Leakages

20 0 TEMPORARY
Provisioning Errors

FY 10-11

MOBILE COMMERCE
Billing Errors

AGENT

CORPORATE

DEALER

MERCHANT
Internal Fraud

Subscription Fraud

Usage Fraud

0 EBITDA

0.5

1 Avertable Leakages

1.5

2.5

Non-Avertable Leakages

Figure 9: RA/FM Dashboard

Coca Cola Dashboard Illustration Only

mCommerce

Exp ort

mCommerce Revenues

mCommerce Transaction

Analysis

Revenues(in '000 USD)

FY 09-10

650
600

550
500

450 400 350 300 250 200 150 100 50 0 Q1 FY 08-09 FY 09-10 FY 10-11
Customer Comp laints Revenue FY 08 -09 (in '000 USD)
Number of Complaints Distribution

Number of transactions (in USD '000)

Value of transactions (in USD '000)

450

Q2

Q3

Q4

300
Q4

250
Q3

200

Q2 Service Unavailable Payments Not Received

150
100

Q1

Technical Issues

Others

Q1

Q2

Q3

Q4

50

100

Figure 10: Coca Cola Dashboard

Developing a Scalable m-commerce Solution A TM Forum Initiative

32

8. Conclusion

The need and utility for M-Commerce is increasing, which is evident in the number of implementations around the world and the level of interest and discussion around the technology and its implementation. Cross operator and Cross border solutions are expected to take commercial transactions to a new high. The challenge lies in the initiatives shown by operators to quickly adopt to this change and integrate solutions using a common framework. These documents are suggestive and indicative solutions that could be adopted by operators around the world. This document is only suggestive of the minimum level of standards, protocols and platforms that operators can adopt.

Developing a Scalable m-commerce Solution A TM Forum Initiative

33

9. Document Cross Reference

Document 3GPP TS 29.002 3GPP TS 32.005 3GPP TS 32.015 3GPP TS 32.205 3GPP TS 32.215 3GPP TS 32.298 GSMA PRD BA.08 GSMA PRD BA.11 GSMA PRD BA.12 GSMA PRD BA.27 GSMA PRD TD.13 GSMA PRD TD.34 GSM TS 09.02 GSM TS 12.05 GSM TS 12.15 IETF RFC 1883 IETF RFC 2373 IETF RFC 2865 IETF RFC 2866 IETF RFC 2869 IETF RFC 791 ISO 3166-1 ISO 4217 ISO 646 ITU E.164 Name Mobile Application Part (MAP) specification 3G call and event data for the Circuit Switched (CS) domain GSM Call Event Data for the Packet Switched (PS) domain Charging data description for the Circuit Switched (CS) domain Charging data description for the Packet Switched (PS) domain Charging Data Record (CDR) Parameter Description CIBER Manual v2.0 Timescales For Data Transfer Billing and Accounting Information - Treatment of Exchange rates Transferred Account Procedure and Billing Information Charging and Accounting Principles TADIG Code Naming Conventions (GSM Infocentre database) TAP Release Management Process Mobile Application Part (MAP) specification Event and call data GPRS Charging Internet Protocol Version 6 Specification IP Version 6 - Addressing Architecture Remote Authentication Dial In User Service RADIUS Accounting RADIUS Extensions DARPA Internet Program - Protocol Specification (for IPv4) Codes for the representation of names of countries and their subdivisions Codes for the representation of currencies and funds Information Processing - ISO 7-bit coded character set for information interchange Principles criteria and procedures for the assignment and reclamation of E.164 country codes and associated identification codes for groups of countries Functional description of the message transfer part (MTP) of Signaling System No.7 The IMSI conforms to the ITU E.212 numbering standard. [Mobile Country Code & Mobile Network Code]
Table 12: Document Cross Reference

ITU-T Q.701 E.212

Developing a Scalable m-commerce Solution A TM Forum Initiative

34

10. Glossary
Term 3GPP AML AS CDD CID EMDA ETSI GPRS GSM GSMA GUI IMS ISO KYC m-Money MNO mPin mSP NFC OpCo OTA SE SIM SIP SMS TAC TAP TID TSM USSD UTC Third Generation Partnership Project Anti Money Laundering Application Server Customer Due Diligence Customer ID \ Merchant ID Enterprise/Merchant/Dealer/Agent European Telecommunications Standards Institute General Packet Radio Service Global System for Mobiles GSM Association Graphical User Interface IP Multimedia Subsystem International Standards Organization Know Your Customer Mobile Money Mobile Network Operator Mobile PIN m-commerce Service Provider Near Field Communication Local operations of mSP Over The Air Secure Element Subscriber Identity Module Session Initiation Protocol Short Message Service Transaction Authorization Code Transfer Account Procedure Transaction ID Trusted Services Manager Unstructured Supplementary Service Data Coordinated Universal Time
Table 13: Glossary

Meaning

Developing a Scalable m-commerce Solution A TM Forum Initiative

35

11. Quick Facts

1. In early 2006 DoCoMo unveiled a new service allowing customers to use their handsets to pay for goods and services such as groceries and taxis. The DCMX credit service was expected to generate annual sales of up to 100 billion ($912 million) by 2009. By December 2006, NTT DoCoMos DCMX service had about one million subscribers. Source: Industry Briefs (Nov. 1-6, 2009) - ViA Instant Access http://www.via.ae/ViAInews_center.php 2. Around 43 million consumers worldwide used m-payment services in 2008, with the Asia/Pacific region accounting for approximately 85% of the world total. In 2009 there were around 75 million m-payments users worldwide, and it is forecast that by 2012 around 190 million consumers will be making mobile payments worldwide. Source: ICT Statistics Newslog www.itu.int/ITU-D/ict/newslog/default,date,2009-03-09.aspx 3. In 2008, the ticketing segment is expected to account for around 40% of the global transaction value in 2013 as consumers make m-payments for rail, air and bus tickets and also for tickets to sports and entertainment events. Regionally, Western Europe and the Far East are expected to represent around 60% market share of the gross transaction value by 2013. Source: ICT Statistics Newslog http://www.itu.int/ITU-D/ict/newslog/default,date,2008-07-14.aspx 4. m-payment transaction volume in developed markets would grow by 56% each year and would account for around 35% of the total transaction volume of payments in 2012. The emerging markets would grow even faster with a prediction that mpayments would grow by 76% per year and represent 65% of the total transaction volume in 2012. Source: ICT Statistics Newslog www.itu.int/ITU-D/ict/newslog/default,date,2008-04-23.aspx 5. Japanese consumers spend over $800 million each year using their mobiles for contactless payments, including prepaid travel tickets. Source: Visa OnLine Industry News http://www.visa-asia.com/ap/sea/mediacenter/mediacoverage/vol/190307.shtml 6. In Kenya the average M-PESA user currently sends transactions totaling $33 per month through the system. This results in a transaction value of around $400 each per year, based on six million users and transactions totaling $200 million per month. Given that Kenya is a poor country, a worldwide average of $674 per year sounds plausible compared to Kenyas $400. Source: The Standard | Online Edition: Regulator gives M-Pesa a clean bill of health

Developing a Scalable m-commerce Solution A TM Forum Initiative

36