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, KPIs and Dashboards ................................... 31

3
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

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

5
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

6
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

7
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

8
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

9
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

10
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

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

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

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

14
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

15
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
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. The customer receives an SMS from the mSP
system showing the transaction ID number,
amount received, the senders 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

16
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 customers 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

17
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

18
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:

Table 5: m-commerce Technologies

SIM based/dependant applications
JAVA/J2ME
Client Side Technologies
USSD2
IVR
SMS
WAP
Server Side Technologies

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

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

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

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

23

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)

24
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

25

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

26
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?

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

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

29
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

30
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

31
7.3. Critical MIS, Revenue Assurance Reports, KPIs 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

32
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 Managements 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 USD00 | %of Leakage
mCommerce Problem Areas By Segment in USD00
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)
0
50
100
150
200
250
300
350
400
450
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

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

34
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

35
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

36
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.
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 Kenyas $400.
Source: The Standard | Online Edition: Regulator gives M-Pesa a clean bill of health

A Scaleable M-Commerce Solution WP

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A Scaleable M-Commerce Solution WP

Uploaded by

Copyright:

Available Formats

M-Commerce

You might also like