SYSTEM DESCRIPTION
M-commerce systems are a complex mix of mobile and banking architectures. Implementation models vary across providers with two key differences emerging: the bearer channel, either Short Messaging Service (SMS), Unstructured Supplementary Service Data (USSD) or SIM Toolkit; and the entity performing financial transaction management. The following diagram, Figure 1, provides an approximation of GCash’s and Wizzit’s system architectures.
Due to GSM’s widespread penetration, it is the network used for all m-commerce offerings in developing/transitional economies (infoDev 2006). The user’s first point of contact with the system is through the Mobile Station, their mobile phone, which manages SMS messages and USSD commands (Le Bodic 2003; Jacob 2007). The SIM card within the Mobile Station holds the International Mobile Subscriber Identity (IMSI) among other data (Le Bodic 2003). The Base Station Subsystem routes connections from the Mobile Station through to the Network Subsystem (Agrawal & Zeng 2006).
The Network Subsystem contains several components central to serving m-commerce requests. The Home Location Register contains all user data such as name, address, IMSI number and mobile phone number (Le Bodic 2003). To acquire the transaction’s data, GCash uses the SMS Centre to handle structured SMS message requests (Le Bodic 2003; Globe Telecom n.d.a), while Wizzit uses the USSD Centre to handle USSD sessions (Deans 2005; Demartini 2007). The SMS and USSD Gateways interface with external systems, such as a Partner Bank.
GCash handles the account transaction management (Transaction Manager), while Wizzit uses a Partner Bank’s infrastructure (Williams & Torma 2007). The Financial Sector Networks and Distribution Agents are the existing networks used to facilitate transfers, including banks, transfer services and financial clearing houses (Mortimer-Schutts 2007). Typical transaction request data, routing through the system to the transaction management entity, include: the transaction type, the user’s PIN, an amount (for credit, debit or transfer), and recipient mobile phone or bank account number (Globe Telecom n.d.a; Wizzit Bank n.d.).
The architecture can be seen as following a client-server model whereby the Mobile Stations act as thin clients linked to servers of the Network Subsystem. In turn, a client-server model exists between the SMS/USSD Centre as the client to the serving transaction management entity.
PROCESS SUPPORT
The key household processes supported by m-commerce systems are operational level and hard processes: a remittance transfer, a payment to a merchant, and the receipt and repayment of a microfinance loan (Ivatury & Pickens 2006; RBAP n.d.). These are financial transactions and are all generalized and treated as money transfers by the systems. To describe how m-commerce systems support these processes, Heeks’ (2007a) Capture Input Process Store Output Decision Action (CIPSODA) model will be applied to Figure 1 to describe a money transfer process.
Applying CIPSODA, the Mobile Station would first capture the data needed for the transfer request from the sender. In the case that GCash’s system is used, this will be in the form of the sender writing an SMS message (Globe Telecom n.d.a). In Wizzit’s case, this will occur through a session with the USSD Centre (Deans 2005; Demartini 2007). Second, the captured data is sent through the system as input to the transaction management entity, either Gcash’s Transaction Manager or Wizzit’s Partner Bank. Third, the transaction management entity processes the input as a money transfer request. It goes through the necessary processing such as error checking the input, debiting the sender’s account and crediting the recipient’s account. Fourth, the altered sender and recipient account balances are stored in the transaction management entity’s Data Store. Fifth, notifications in the form of an SMS message or as a USSD notification are output via the SMS and USSD Centres to both the sender’s and the recipient’s Mobile Stations. Lastly, decisions and actions related to household budgeting and expenses are made based on account balance information.
Remittance transfers follow the same transfer process, however for international transfers, the data capture and input will originate from an agent partner of the service (Soriano & Barbin 2006). A payment to a merchant follows the described process, with the sender as the customer and the recipient as the merchant. For microfinance loans, the loan is sent by the lending institution using the described process and repayments by the lender are again money transfers to the lending institution.
BENEFITS
M-commerce benefits are at several levels, the most significant ones from the household’s perspective are at the level of processes. Applying Heeks’ (2007c) Organisational Processes Benefits Model to the core m-commerce process, the money transfer, process outputs can be shown as being cheaper and quicker. By introducing basic banking processes to GCash’s and Wizzit’s target markets, the ‘unbanked’ households, there are new processes related to money savings and management (Adewumi et al. 2007).
Cheaper and Quicker Money Transfers
To demonstrate improvements, a process descriptions of a domestic long-distance remittance transfer from the point of view of the user household previous to m-commerce and with m-commerce is considered (Adewumi et al. 2007). The analysis is applicable to microfinance loans and repayments where the microfinance institution is remote to the money sender. Money transfers are hard processes, therefore analysis will consider direct and indirect costs and transaction speeds.
A remittance transfer outside of an m-commerce system can be accomplished by two main processes: informally via physical cash delivery or formally via banking or money transfer networks. The informal option involves a trusted acquaintance physically travelling to the recipient, with this individual taking a portion of the transfer (Batchelor 2005; Donner 2007; The Economist 2006). The risk of loss or theft of the cash is additionally considered a cost in this case (Adewumni et al. 2007). Figures estimating the costs of the formal option vary: 2003 Gamos estimates demonstrate average costs of 12 per cent, while 2005 United Nations figures show them at 20 per cent if considering loss due to fraud (Donner 2007; The Economist 2006). Transfer times to the recipient vary, they depend on the service used and the distance the recipient must travel to collect the remittance (PBI n.d.).
Considering the in-network remittance transfer with m-commerce, the costs from the sender’s cash deposit to the recipient’s cash withdrawal demonstrate are lower: GCash’s costs are 1 per cent plus the SMS message cost, while Wizzit’s are between £0.21-0.36 plus the USSD session cost (Globe Telecom n.d.b; Wizzit Bank n.d.). Process times are also shortened with m-commerce: the recipient’s account is immediately credited. Given that both GCash and Wizzit have partnered with agents outside of the traditional banking infrastructure (Williams & Torma 2007), travel distances to access the received amount as cash are reduced.
New Banking Processes
Given the lack of banking infrastructure such as branches and ATMs in low-population, rural areas and high banking fees (Mendes et al. 2007; Pickens & Richardson 2007), bank accounts were previously not accessible to low-income households. M-commerce systems are enabling new banking processes through accessible infrastructure and lower costs. By introducing the use of a bank account, money can now be stored in electronic form, be deposited and withdrawn through system agents and account balances can be checked. These most basic banking processes provide financial asset management which is less vulnerable to risks compared to cash, and provide for more systematized financial asset management (Adewumi et al. 2007).
PROBLEMS
The key potential implementation and use problems of this information system are seen through Heeks’ (2007b) Contextualized Structural Model of Information Systems, or ‘Onion Ring Model’, in Figure 2. Within the broader environment, an implementation problem is the set of regulations governing financial sectors which may prevent the use of m-commerce by low income households. A use problem is the technical infrastructure needed for users to make full use of the system at the community level. The third problem is at the security of transactions found at the technology level.
Regulatory Environment
In both the Philippines and in South Africa, Globe and Wizzit have successfully managed to implement systems for low-income households working within regulatory requirements. However, anti-money laundering regulations have created significant barriers for the poor to access banking services through several requirements: multiple proofs of identification and proof of address to open an account (Gardiol et al. 2005). Wizzit has leveraged regulation exemptions in South Africa through imposing account and transaction limits enabling the use of an account without these requirements (Williams & Torma 2007) while Globe has imposed similar limits (infoDev 2006). Ambiguous or unstable regulatory environments may be considerable implementation barriers in other countries (Porteous 2006).
Availability of Infrastructure
The use of m-commerce can be problematic when key community infrastructure, the agents through which cash can be deposited
