A Scaleable M-Commerce Solution WP

M-Commerce

White Paper

A Scalable M- Commerce Solution

2 Developing a Scalable m-commerce Solution – A TM Forum Initiative

Table of Contents

1. Introduction .................................................................................................................... 4

2. Business Model for m-commerce ....................................................................................... 6

3. M-Commerce Enterprise Framework .................................................................................. 7

3.1. M-Commerce Ecosystem ............................................................................................ 8

3.1.1. M-Commerce Transaction Process ........................................................................... 8

3.1.2. Stakeholders ......................................................................................................... 8

3.1.3. Fund Transfer Process within Home Network ............................................................ 9

3.1.4. Inter-Operator Fund Transfer Process .................................................................... 10

3.1.5. Regulatory Framework ......................................................................................... 11

3.1.6. Data Security Framework ...................................................................................... 11

3.1.7. Payment Processing Platform ................................................................................ 12

Core Payment Support Processes.................................................................................. 12

Core Payment Surrounding Processes ..................................................................... 14

4. M-commerce Technological Overview .............................................................................. 18

4.1. Tested M-commerce Technologies ............................................................................ 18

4.2. Technical Specification for Authentication Elements .................................................... 21

5. M-commerce Transaction Standards ........................................................................... 22

5.1. Transfer Account Procedure [TAP] ............................................................................. 22

5.2. TAP File Format ....................................................................................................... 23

5.3. TAP Elements and Adaptability for M-Commerce Transactions ............................ 24

6. Key Concerns and Issues.................................................................................................. 26

6.1. Regulatory Issues .................................................................................................... 26

6.2. Fair Trading Issues ................................................................................................... 26

6.3. Financial Issues ....................................................................................................... 27

6.4. Privacy Issues .......................................................................................................... 27

6.5. Security Issues ........................................................................................................ 27

6.6. Consumer Concerns and Behaviour ........................................................................... 27

6.7. Compliance............................................................................................................. 28

7. Revenue Assurance & Fraud Management ........................................................................ 29

7.1. Policies – Processes – Procedures .............................................................................. 29

7.2. Critical m-commerce Reconciliations ......................................................................... 30

7.3. Critical MIS, Revenue Assurance Reports, KPI’s and Dashboards ................................... 31


7.3.1. Dashboards ......................................................................................................... 31

8. Conclusion ..................................................................................................................... 33

9. Document Cross Reference ......................................................................................... 34

10. Glossary ..................................................................................................................... 35

11. 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


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 Internet-enabled 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.


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.

World’s 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


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 Mobile Operator

Centric Bank Centric

MNO / Bank Joint Venture

Independent Third Party

Solution

Banking System

High Infrastructure Requirement

Financial Switching Only

Some Required Not Required

Regulatory and License Constraints

High Regulatory and License Requirement

Low Impact

Banks typically facilitate regulatory compliance

No Impact

Brand MNO Brand Not Used MNO Brand Not Used

Churn Reduction

Definite reduction in churn

Reduction in Churn

Definite reduction in churn

No reduction in Churn as any MNO can offer the service

Distribution Chain for cash handling

MNO only Not Used MNO and Bank Not Used

Transactional Risk

All of the risk Some Half of the risk None

Cost Very High Some cost High Cost Marginal

Revenue Very High Good High Low

Examples

M-Pesa by Safaricom, GCASH by Globe telecom etc

Mobile Banking Facility Available for all banks

ZAP by Zain. PayPal, Visa, etc

Table 1: Comparision of different m-commerce Business Model


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


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, M-Commerce 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


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 HLR’s 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


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, m-commerce 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 m-commerce 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


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, m-commerce 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 spammer’s new opportunities for targeting subscribers via the messaging service. M-commerce concept would be rendered unworkable if vital messaging bearing technologies are compromised.


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 Encryption Standards Description

ANSI X9.8 Banking - Personal Identification Number Management and Security

ANSI X9.24 Financial Services Key Management Using the Data Encryption Algorithm

ANSI X9.42 Public Key Cryptography for the Financial Services Industry: Agreement of

Symmetric Keys Using Discrete Logarithm Cryptography

ANSI X9.52 Triple Data Encryption Algorithm Modes of Operation

ANSI X9.62 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.


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 company’s 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.


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


Customer cash in process Customer cash out process

a. Customer goes to an mSP Shop to purchase m-Money. Depending on the outlet this can be done using cash, cheque, debit card or other forms of payment.

b. The mSP Agent accepts payment from the customer and advises them on the additional charges for purchasing m-Money. These charges include the transaction fee and any government taxes.

c. If the customer wants m-Money that either exceed the daily limit or are not available they are advised at this point.

d. The mSP agent informs the customer that these charges can either be paid separately or deducted from the received funds. The customer then advised the mSP Agent of their preference.

e. The mSP agent calculates the total charges and advises the customer. Standard fraud checks are carried out at this stage; including validation of cash received.

f. Once the customer agrees, the mSP agent

books the sale in the POS and outputs a receipt for the transaction.

g. mSP Agent transfer the m-Money from the

Agent’s account to the customer’s 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 Agent’s account.

i. The customer receives an SMS from the mSP

system showing the transaction ID number, amount received, the sender’s name, and the balance after the transaction.

j. The mSP agent confirms completion of the

transaction to the customer and provides them with the transaction receipt.

a. Customer goes to an mSP Shop to withdraw m-Money.

b. The mSP agent confirms the amount to be withdrawn by the customer. At this stage the Agent need to confirm the identity of the customer and ensure they have not already exceeded the daily limit for withdrawing.

c. The mSP agent informs the customer that

these charges can either be paid separately or deducted from the received funds. The customer then advised the mSP Agent of their preference.

d. The mSP agent calculates the total charges

and advises the customer. Standard fraud checks are carried out at this stage; including customer withdraw history.

e. The mSP Agent requests the customer to

transfer m-Money to the shop account. Customer does this using their handset. Agent records transaction in POS.

f. 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. 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.

h. The mSP Agent hands to the customer the

funds and receipt for the transaction. Agent updates the reconciliations to reflect withdraw transaction.

Table 3: Customer Cash In\Out Process


Merchant cash in process Merchant cash out process

a. Dealer/Agent goes and deposits funds onto the mSP account. This can be done at any bank where mSP has a mSP Account. The Dealer/Agent needs to add their Name and Mobile Number on the deposit slip.

b. On receipt of the duly filled and signed individual consumer account registration form, the Shop Manager/Agent reviews & vets the application form ensuring that all mandatory fields are completed accurately and verifies the documentations against the originals and makes copies of the originals.

c. Shop Manager/Agent approves the request and enters detail into the shop phone or GUI to be captured into the mSP system. The customer is activated with Temporary status, which has limited functionality.

d. Shop Manager/Agent forwards the Application form & documents to the mSP Customer Care Team.

e. Shop Manager/Agent informs the customer that their registration was successful, the account has Temporary status until vetting/authentication process is completed.

f. MSP Customer Care Team confirms particulars captured by agent as viewed on the Web interface and matches them against those in the physical documents and also review the number of transactions.

g. Once feedback on successful vetting is received, search for the customer’s account using the appropriate search criteria, compare the information on the systems against the national 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.

a. Enterprise/Merchant/Dealer/Agent (EMDA) completes the funds withdraw form and forwards it to the Dealer/Agent Manager.

b. Dealer/Agent Manager verifies funds withdraw form and confirm if EMDA has indicated funds available.

c. mSP Stock controller receives funds withdraw form from Dealer/Agent Manager. On the funds withdraw form, there are details of the account mobile number and the account details of where the funds are to be transferred. This information is cross check against mSP records.

d. mSP Stock Controller then initiates the de-allocation of funds from the EMDA mSP virtual account. This step is validated by another team with Finance. Can be Revenue Assurance.

e. mSP Stock Controller instructs Treasury to transfer equivalent funds from the mSP settlement account to the EMDA account.

f. mSP Stock Controller confirms transaction to Dealer/Agent and files documentation to the effect.

Table 4: Merchant Cash In\Out Process


v. Accounting, Reporting & Reconciliation: Revenue Reporting, Local Operations Transaction reporting, Transaction settlement reports with other OpCo’s 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


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. Subscriber’s 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:

Table 5: m-commerce Technologies

• SIM based/dependant applications

• JAVA/J2ME

Client Side Technologies

• USSD2

• IVR

• SMS

• WAP

Server Side Technologies


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 bank’s 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 consumer’s 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.


In IVR, USSD2, and SMS based m-commerce channels, the consumer’s 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 consumer’s 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 m-commerce 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 MNO’s own developed application. Thus the consumer’s 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 MNO’s 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.


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 - Mobile PIN CID - Customer ID \ Merchant ID TID - Transaction ID TAC - Transaction Authorization Code

mPIN CID TID TAC

Min Code

Length 4 digits 9 digits 8 digits 4 digits

Max Code

Length 6 digits 9 digits 8 digits 6 digits

Code Type Integer Integer Integer Integer

Code Owner Subscriber Operator Operator Operator

Format

Description

As per the Regulatory

guidelines of the Central Banks for m-commerce by

different countries

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


guidelines of the Central Banks for m-commerce by

different countries


guidelines of the Central

Banks for m-commerce by

different countries

Definition

Stage

First mPIN would be defined by the Operator and then can be changed by

the Subscriber

CID would be defined by the

Operator at the time of 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

Life Cycle Lifetime Lifetime Lifetime Valid on for a Session of 24

hours

Modification mPIN can be

modified by the Subscriber

Can't be Modified

Can't be Modified Can't be Modified

Table 6: Technical Specification for Authentication Elements


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.


5.2. TAP File Format

Given below is the TAP File format as approved by GSMA:

Tag range Description

0-6 Reserved for TAP

7-8 In Use for both TAP and RAP


143 In Use for both TAP and RAP


238 In Use for both TAP and RAP


512-513 In Use for RAP

514 Reserved for RAP


529-531 Reserved for RAP


554-1023 Reserved for RAP

Table 7: TAP File Format

(This space has been intentionally left blank)


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 Conditions Description Adaptability for M-Commerce?

Data Transfer Mandatory

Yes

Transfer Batch Mandatory

Yes

Batch Control Information Mandatory

Consist of the Mobile Country Code (MCC) & Mobile Network Code

(MNC) of Sender & Receiver, timestamp, File

Sequence Number

Yes

Accounting Information Conditional

Yes

Taxation Conditional Consist of Tax Rate Code,

Tax Type, Tax Rate and Local Currency

May be

Currency Conversion Mandatory

Consist of Exchange Rate Code, Number of decimal places, Exchange Rate and

TAP decimal places

Yes

Network Information Mandatory

Yes

Coordinated Universal Time (UTC) Offset Information

Mandatory Consist of UTC Time Offset code and UTC Time Offset

Yes

Recording Entity Information Conditional Consist of Recording Entity

Code, Recording Entity Type and network Type

Yes

Called Number Analysis Mandatory Consist of Country Code and International Access

Code Yes

Call Event Details (1) Mandatory

Yes

Table 8: TAP Elements


Proposed format of the M-Commerce TAP file :

Field Name Conditions Description

CID of Sender Mandatory

Senders Basic Information Mandatory This would contain the TID, encrypted

mPIN, IMSI and MSISDN CID of Receivers Mandatory

Receivers Basic

Information Mandatory

This would contain the TID, encrypted mPIN, IMSI and MSISDN

Destination Conditional This would contain the nature of

address, timestamp, city in visited network, region in visited network

Location Information Mandatory

Network Location Mandatory This would contain recording Entity

Code, transaction reference, location area code, Cell Identity

Geographical Location Optional This would contain the Serving Billing Identifier, Serving location Description

Equipment Information Conditional This would contain the IMEI

Basic Service Mandatory This would contain the m-commerce

service available, services used, service code

Transaction Information Mandatory This would contain the Transaction

Type, Exchange Rate code, Transaction Amount

Tax Information Conditional This would contain the TAX Rate Code

and TAX Value Table 9: Recommended m-commerce Transaction CDR


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 m-commerce 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?


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 consumer’s experience (such as centre brand messaging around security).

Visibly deliver best practice payment technology elements, such as transaction identifiers and effective repudiation management.


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, Anti-Money 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.


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


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. Control Control Details Type Frequency

01

mSP Settlement

Account

Reconciliation

Reconcile the mSP virtual

Account balance against the

mSP Bank Account

Detective Daily

02

mSP

Deposit/Withdra

w Verification

Verify that the actual amount

deposited or withdrawn

match virtual against real

Preventative Daily

03 mSP Transaction

Fee Reconciliation

Confirm that transactional

fees are charged. Detective Weekly

04 mSP Shop Cash

Reconciliation

Reconcile mSP Shop Cash

against mSP transactions for

shops

Detective Daily

05 mSP Shop Cash

Verification

Review Shop mSP Cash

reconciliations Detective Daily

06 mSP Account

Reconciliation

Reconcile mSP merchant

accounts Detective Daily

07 mSP Revenue

Verification

Verify reported mSP

revenues Detective Monthly

08

mSP

Reconciliation

Review

Review of all mSP

reconciliations; Sample

based

Detective Weekly

09 mSP Transaction

Review Review of all mSP allocations Detective Weekly

10 mSP User Review Review of the users and their

access rights Detective Monthly

11 mSP Log Review Review the mSP system logs

for fraud activity Detective Weekly

12 High Balance

Review

Review of accounts with

large balances or large

deposit/withdraw

Detective Weekly

13 KYC Verification

Review of subscriber

registration forms (sample

based)

Detective Monthly

14 Anti-Money

Laundering Ensure compliance with AML Preventative Monthly

Table 11: Controls & Reconciliations


7.3. Critical MIS, Revenue Assurance Reports, KPI’s and Dashboards

7.3.1. Dashboards

Executive Dashboard – Illustration Only

mCommerce For FY 2009

mCommerce Vs. Total Snapshot

Compare Reset Export

mCommerce Interactive Analysis

mCommerce Snapshot

0

50

100

150

Cr Dr P2P B2B B2C C2B

Transaction Charges

0 50 100 150 200 250 300

Temporary

Permanent

Dealer

Agent

Corporate

Merchant

Customer Volumes

0

50

100

150

200

250

Cr Dr P2P B2B B2C C2B

Transaction Volumes for Temporary

0

200

400

600

800

1000

1200

Temporary Permanent Dealer Agent Corporate Merchant

C2B

B2C

B2B

P2P

Dr

Cr

Subscribers

mCommerce

Total

12 M

72M

Revenue ($)

Total

mCommerce

.

14.5 M

8.5 B

ARPU ($)

mCommerce

.

Total

1.15

9.05

Figure 8: Executive Dashboard


mCommerce Financials

Metric FY 08 FY 09 FY 10

Gross Loss (in USD '000)252 144

RA Leakages (in USD '000)

Fraud Loss (in USD '000)

Savings (in USD '000)112.4 219.8

Gross Revenue (in USD '000)5670 8230 10

% of Gross Losses 4.44% 1.75%

% of Savings on Losses 1.98% 2.67%

RA/FM Dashboard – Illustration Only

Revenue Management’s Contribution

0 0.5 1 1.5 2 2.5

FY 09-10

Profit Recovered Revenues Averted Leakages

0 0.5 1 1.5 2 2.5 3

FY 10-11

EBITDA Avertable Leakages Non-Avertable Leakages

mCommerce Problem Areas

0

20

40

60

80

100

120

140

160

180

TEMPORARY MOBILE COMMERCE

AGENT CORPORATE DEALER MERCHANT

Provisioning Errors Billing Errors Subscription Fraud Usage Fraud Internal Fraud

By Segment In USD’00 | %of Leakage

mCommerce Problem Areas By Segment in USD’00

mCommerce Export

Figure 9: RA/FM Dashboard

Revenues(in '000 USD)

450

500

550

600

650

FY 08-09 FY 09-10 FY 10-11

100

150

200

250

300

Q1 Q2 Q3 Q4

Revenue FY 08-09 (in '000 USD)

050

100150200250300350400450

Q1 Q2 Q3 Q4

Number of transactions(in USD '000)

Value of transactions(in USD '000)

Service Unavailable Payments Not Received

Technical Issues Others

Number of Complaints Distribution

0 50 100

Q1

Q2

Q3

Q4

mCommerce Revenues mCommerce Transaction Analysis

Customer Complaints

FY 09-10

Coca Cola Dashboard – Illustration Only

mCommerce Export

Figure 10: Coca Cola Dashboard


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.


9. Document Cross Reference

Document Name

3GPP TS 29.002 Mobile Application Part (MAP) specification

3GPP TS 32.005 3G call and event data for the Circuit Switched (CS) domain

3GPP TS 32.015 GSM Call Event Data for the Packet Switched (PS) domain

3GPP TS 32.205 Charging data description for the Circuit Switched (CS) domain

3GPP TS 32.215 Charging data description for the Packet Switched (PS) domain

3GPP TS 32.298 Charging Data Record (CDR) Parameter Description CIBER Manual v2.0

GSMA PRD BA.08 Timescales For Data Transfer

GSMA PRD BA.11 Billing and Accounting Information - Treatment of Exchange rates

GSMA PRD BA.12 Transferred Account Procedure and Billing Information

GSMA PRD BA.27 Charging and Accounting Principles

GSMA PRD TD.13 TADIG Code Naming Conventions (GSM Infocentre database)

GSMA PRD TD.34 TAP Release Management Process

GSM TS 09.02 Mobile Application Part (MAP) specification

GSM TS 12.05 Event and call data

GSM TS 12.15 GPRS Charging

IETF RFC 1883 Internet Protocol Version 6 – Specification

IETF RFC 2373 IP Version 6 - Addressing Architecture

IETF RFC 2865 Remote Authentication Dial In User Service

IETF RFC 2866 RADIUS Accounting

IETF RFC 2869 RADIUS Extensions

IETF RFC 791 DARPA Internet Program - Protocol Specification (for IPv4)

ISO 3166-1 Codes for the representation of names of countries and their subdivisions

ISO 4217 Codes for the representation of currencies and funds

ISO 646 Information Processing - ISO 7-bit coded character set for information

interchange

ITU E.164 Principles criteria and procedures for the assignment and reclamation of

E.164 country codes and associated identification codes for groups of

countries

ITU-T Q.701 Functional description of the message transfer part (MTP) of Signaling

System No.7

E.212

The IMSI conforms to the ITU E.212 numbering standard. [Mobile Country

Code & Mobile Network Code]

Table 12: Document Cross Reference


10. Glossary

Term Meaning

3GPP Third Generation Partnership Project

AML Anti Money Laundering

AS Application Server

CDD Customer Due Diligence

CID Customer ID \ Merchant ID

EMDA Enterprise/Merchant/Dealer/Agent

ETSI European Telecommunications Standards Institute

GPRS General Packet Radio Service

GSM Global System for Mobiles

GSMA GSM Association

GUI Graphical User Interface

IMS IP Multimedia Subsystem

ISO International Standards Organization

KYC Know Your Customer

m-Money Mobile Money

MNO Mobile Network Operator

mPin Mobile PIN

mSP m-commerce Service Provider

NFC Near Field Communication

OpCo Local operations of mSP

OTA Over The Air

SE Secure Element

SIM Subscriber Identity Module

SIP Session Initiation Protocol

SMS Short Message Service

TAC Transaction Authorization Code

TAP Transfer Account Procedure

TID Transaction ID

TSM Trusted Services Manager

USSD Unstructured Supplementary Service Data

UTC Coordinated Universal Time

Table 13: Glossary


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 DoCoMo’s 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.


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 m-

payments would grow by 76% per year and represent 65% of the total transaction

volume in 2012.


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 Kenya’s $400.

Source: The Standard | Online Edition: Regulator gives M-Pesa a clean bill of health

http://www.via.ae/ViAInews_center.php

http://www.itu.int/ITU-D/ict/newslog/default,date,2008-07-14.aspx

http://www.visa-asia.com/ap/sea/mediacenter/mediacoverage/vol/190307.shtml

Documents

A Scaleable M-Commerce Solution WP