www.elsevier.com/locate/ecra

Electronic Commerce Research and Applications 7 (2008) 232–246

An open financial services architecture based on theuse of intelligent mobile devices

Apostolos Kousaridas *, George Parissis 1, Theodore Apostolopoulos 2

Computer and Communication Systems Laboratory, Department of Informatics, Athens University of Economics and Business,

76, Patission Street, 104 34 Athens, Greece

Received 16 September 2006; received in revised form 23 April 2007; accepted 25 April 2007Available online 6 May 2007

Abstract

The scope of this paper is to explore, analyze and develop a universal architecture that supports mobile payments and mobile banking,taking into consideration the third and the emerging fourth generation communication technologies. Interaction and cooperationbetween payment and banking systems, integration of existing technologies and exploitation of intelligent procedures provide the pros-pect to develop an open financial services architecture (OFSA), which satisfies requirements of all involved entities. A unified scenario isdesigned and a prototype is implemented to demonstrate the feasibility of the proposed architecture.� 2007 Elsevier B.V. All rights reserved.

Keywords: m-Payments; m-Banking; m-Financial services

1. Introduction

One of the most important steps in financial transac-tions is the use of a mobile device as a payment instrumentand as a way to consume banking services. The continuousevolution of wireless technology, in combination with thewidespread use of mobile devices, has paved the way forthe fast evolution of mobile commerce and mobile financialservices in particular. Although several architectures forthe provision of financial services have been proposed todate [1], user acceptance and satisfaction rates remainlow. Technological immaturity, early adoption of such ser-vices and users’ fear to use unmanned services are some ofthe facts that have limited the widespread use of mobilepayment and banking systems. We were motivated topropose a new architecture by the need for a universal

1567-4223/$ - see front matter � 2007 Elsevier B.V. All rights reserved.

doi:10.1016/j.elerap.2007.04.003

* Corresponding author. Tel.: +30 210 8203158; fax: +30 210 8203159.E-mail addresses: akousar@aueb.gr (A. Kousaridas), parissis@aueb.gr

(G. Parissis), tca@aueb.gr (T. Apostolopoulos).1 Tel.: +30 210 8203158; fax: +30 210 8203159.2 Tel.: +30 210 8203234; fax: +30 210 8214012.

solution, which will not be limited to specific transactionsand which will provide innovative, efficient and personal-ized financial services to the users, satisfying financial orga-nizations’ and merchants’ requirements.

The aim of this work is to develop an open financial ser-vices architecture that integrates the financial services,including payment and banking ones, based on two primarycapabilities: the use of computational resources of a trustedmobile device and the establishment of a user-controlled‘‘cooperation channel’’ with the customer’s bank. The pro-posed architecture is characterized as bank-centric, sincethe bank acts consultatively, informatively and protectivelyfor the end-user. Open technologies, in conjunction withstandardized interfaces, offer flexibility, adaptability andcontinuous extendibility to our architecture.

The remainder of this paper is organized as follows: Sec-tion 2 presents the related work, the communication tech-nologies that are involved and the existing technologicallimitations. In Section 3 the proposed architecture’s layeredview and its significant functional requirements are pre-sented along with the component’s description and theirinteractions. Section 4 deals with the implementation of a

A. Kousaridas et al. / Electronic Commerce Research and Applications 7 (2008) 232–246 233

prototype. An evaluation of our approach is also given.Finally, in Section 5 we conclude with key points andfuture research directives.

2. Problem analysis and related work

2.1. Related work

Various definitions exist as regards e-payments ande-banking. According to the Mobile Payment Forum defi-nition [2], ‘‘mobile payment is the process of two partiesexchanging financial value using a mobile device in returnfor goods or services‘‘. The customer-to-customer (C2C)mobile payments can be characterized as a special caseregarding the exchanging financial value parties, betterand more accurately defined in [3]. Electronic bankingusing a mobile device is regarded as a sophisticated wayto provide retail banking services and in comparison to tra-ditional procedures [4,5], has many advantages for bankingorganizations and customers. According to Pousttchi andSchurig [6], mobile banking is divided into two main cate-gories: mobile brokerage and account management proce-dures. Queue avoidance, immediacy, ease of use and lowcost are some of the advantages that mobile banking offers.These advantages improve the profile of financial organiza-tions by creating new business and marketing models. Atthe same time, we have to point out that any additionaldelivery channel has its own risk characteristics andlimitations.

Karnouskos [7] and Ondrus [8] have identified severaltypes of mobile payments considering the amount andthe type of the transaction, the location of the point of sale(POS) or the payee and the number of the involved parties.Furthermore, they illustrate various payment architecturesconsidering the means and the time of payment as well asthe security level.

When designing a mobile payments and mobile bankingarchitecture, it is necessary to take into account the follow-ing requirements [8–10]: support of every payment andbanking scenario, low cost for all entities (customer, mer-chant and banking organization), mobile device and plat-form independence, minimal cooperation among mobilenetwork operators (MNO) and financial organizations,open standards and programming languages, privacy, reli-ability and security, simplicity, efficiency, ease of use andintegration of legacy applications.

Zhang et al. [11] describe a biometrically enabled mobilepayments’ solution that uses Java smart card technologyembedded into the SIM card of a mobile phone, whichnot only stores critical information but also executes com-putations. The proposed solution is a MNO centric archi-tecture, where the MNO is responsible for distributingmerchants’ public keys and for settling e-purse transac-tions. The user buys a SIM card that contains a uniquekey for data encryption and authentication, which is asso-ciated with a bank account. Saxena et al. [12] considerphone as an Europay, MasterCard and VISA (EMV)

payment instrument, linked to a debit or a credit card bankaccount, through the use of a SIM-based security frame-work. SEMOPS [13] was developed in the context of aEuropean Union (EU) funded project and is regarded asone of the most advanced universal and open payment sys-tems. Recently, the second phase of SEMOPS (SEMOPSII) has been launched, in order to proceed with the marketvalidation of the SEMOPS service. Labrou et al. [14] pro-pose a wireless wallet that supports three types of financialtransactions: peer-to-peer, Web store front and physicalpoint of sale. Electronic wallet suggests a generic architec-ture and a new security protocol for the conduction ofsecure multi-party agreements. Mobile devices throughtheir wireless communication interfaces allow provisionof advanced financial services in isolated areas. This prob-lem was addressed by our research group in the context ofthe EU funded IST project, named STARFISH (STate ofthe ARt Financial Services for the inHabitants of isolatedareas) [15].

Apart from research initiatives, there are several com-mercial payment systems already in use. Mobile FeliCa[16] and Mobile Suica [17] are the two successful solutionsthat have been launched in the Asian market. Furthermore,Pay Pal [18], Pay Box [19], Mobipay [20], Nokia Wallet [21]and Vodafone’s m-pay bill [22], are also well-known com-mercial solutions. Finally, in order to present a completeview of mobile financial services’ environment we shouldpoint out the role of fora and standardization bodies, likeMobey Forum [23], Mobile Electronic Transactions [24]and PayCircle [25].

2.2. 3G/4G communication systems and short range wireless

technologies

The third (3G) [26] and fourth generation (4G) orbeyond 3G communication technologies, in combinationwith short range wireless technologies, like Bluetooth[27], RFID [28], IrDA [29] and NFC [30], constitute thetechnological background for the development of e-bank-ing and e-payment systems, using mobile devices. Thesetechnologies influence the service provisioning contextand pose constraints in the development of such systems.

2G and 2.5G [26] are still the most widely used commu-nication systems in the world. Their main features, namelyvoice, Short Message Service (SMS), as well as the WirelessApplication Protocol (WAP), have shaped the majority ofthe proposed systems [19,20]. 3G systems [26] came to over-come the limitations and inefficiencies of the previous ones.A 3G wireless network supports numerous heterogeneouslinks, providing high data transmission rates and guaran-teed quality of service (QoS). Almost anywhere connec-tions provided by a multi-mode mobile device, increasethe value and usability of mobile financial services. Person-alized and location-based services are some of the mainenhancements in 3G systems.

Research community is currently studying the fourthgeneration (4G) mobile network communications [31]. 4G

234 A. Kousaridas et al. / Electronic Commerce Research and Applications 7 (2008) 232–246

will offer advanced services as well as higher reliability,security and higher data rates with adaptive interfaces.The key features of the emerging 4G networks are ubiqui-tous computing, integration of different wireless communi-cation technology capabilities, continuous and always bestconnections, seamless handovers, and all-IP networkinfrastructure.

One of the most important short range wireless technol-ogies, which is expected to play significant role in the futuremobile payment and banking systems, is near-field commu-nication (NFC). According to the NFC Forum directivesand standardization initiatives [30], an NFC Forum devicecan operate both as a contactless smart card as well as areader of NFC-compatible tags, enabling simple and fastdata transfer between NFC devices. Bluetooth and IrDAare alternative short range technologies that are able tosupport local or peer-to-peer payments [32].

2.3. Technology limitations vs. m-financial systems

acceptance

After studying the related work and aspects, we havededuced several reasons that may have caused the obso-lesce of existing architectures. Several architectures havetried to deploy software and hardware that could not –by their nature – satisfy basic requirements mentioned inSection 2.1. More specifically, many architectures weredesigned on top of low-speed 2G networks, which are notpacket-based. The first mobile banking systems were eitherbased on SMS service or were developed using WAP 1.0.

Fig. 1. Mobile financial services context

As a result, only some fundamental services, such asaccount checking, were offered. Although 2.5G systemshave upgraded mobile banking services through WAP 2.0and XHTML browsers, they have not offered any substan-tial advancement in mobile payments area.

Technological immaturity, in combination with earlyadoption, usually leads a system to limited adoption andconsequently to rapid decline in value. Something similarhas happened in the field of mobile financial services. Thereare many proposed architectures, which in many cases havenot met the prospective acceptance. These architectureswere based on the available technologies, which were notenough evolved. Interoperability, handovers, continuousand uninterrupted connections are issues that researchcommunity should deal with, in order to achieve wide useof mobile payment and banking applications.

3. The proposed open financial services architecture (OFSA)

In this section we describe a viable and robust architec-ture, which provides the user with the ability to use theirmobile phone as a mobile wallet, to initiate, activate andconfirm financial services, including payment and banktransactions.

3.1. OFSA layered view

Fig. 1 depicts the way we conceptualize the environ-ment, within which the described architecture is defined.The upper Transaction-related layers present the main

and OFSA functional requirements.

A. Kousaridas et al. / Electronic Commerce Research and Applications 7 (2008) 232–246 235

Financial Transaction types, as well as the Means of Pay-ment that the proposed architecture should support. Thethree lower levels present a plethora of Security, SoftwareEngineering and Communication Technologies that areavailable for the design and the development of mobile sys-tems. Each technological option presents advantages, but italso sets constraints. At this point, it should be mentionedthat the components of the technology layers evolve con-tinuously, providing advanced features and satisfying newrequirements. Open Financial Services Architecture is ableto support this evolution due to its open approach. Finally,OFSA Functional Requirements’ vertical plane presentssignificant features that are introduced in our architecture:trust among the involved parties (Customer, Merchant andBanking Organization), openness, intelligence3 introducedin the mobile device, technology integration as well as bankand payment service integration. We believe that the inte-gration of the components that constitute the abovedescribed layers, in conjunction with the key functionalrequirements, leads to the design of a universal system.

OFSA describes a system which is capable of managingfinancial services, including bank services and payments,through a mobile device, and offers an implementation ofthe so called Universal Mobile Payment System (UMPS)[10].

Interaction and cooperation between payment andbanking systems as well as integration of existing technol-ogies provide us with the ability to achieve simplicity andusability, universality, interoperability, security, trust, pri-vacy and integration of legacy applications. End-to-endopenness and the intelligence that is introduced in themobile device are key points of our architecture.

The proposed architecture is characterized as open,since it deploys open standards for key interfaces withinthe system and among the involved entities. This approachcan lead to a more competitive environment, where manyplayers with different roles can co-exist. The entities thatparticipate in an open architecture should assure theirsmooth collaboration, via some trust mechanism or busi-ness agreements.

The mobile device needs to make decisions and supportuser’s actions based on user’s requirements and profile(e.g., payment method). These decisions are critical for effi-cient transaction management. However, decision makingis a complicated procedure, considering the different typesof transactions and requirements. The decision componentdoes not replace the bank’s decision support system (DSS),since it acts in a supplementary manner, based on previousknowledge, user’s preferences or even banks’ DSS propos-als. Mobile devices’ intelligence should be increased, byimproving decision making and support systems through

3 Intelligence is a term that is used to describe software applications andtechnologies for gathering, storing, analyzing and providing access to datathat help devices make better business decisions. Activities like decisionsupport, query and reporting, statistical analysis and data mining arefundamental intelligent processes.

a continuous learning process, using knowledge developedfrom previous transactions.

We have decided on a component-oriented architecturebased on the following design criteria: software engineeringdesign principles, decoupling of technological issues frombusiness logic and facilitating the extendibility of the sys-tem. Any new business application can be implementedusing either existing or future technological infrastructures,while new technologies can be deployed without affectingthe existing business applications. For example, in a fullyimplemented system, introducing a new communicationtechnology such as NFC (which is a continuously evolvingtechnology) does not require any fundamental changes inthe system. Minor changes in the Local CommunicationComponent would be sufficient. Further decompositionof technology and business components supports expan-sion capabilities, as far as new technologies and new busi-ness models are concerned, enhancing OFSA openness.For instance, if an alternative security scheme (e.g., fromKerberos to PKI) is required by the bank, only minorchanges in the Security Component will be necessary.

3.2. OFSA functional requirements

Considering the technological environment, theinvolved entities’ requirements, the already proposed archi-tectures and the aforementioned systems’ acceptance fac-tors, we can proceed with outlining the features of theproposed architecture. The composition of functionalrequirements for the development of an open mobile finan-cial services’ architecture, taking into account the prerequi-sites for wide acceptance and the potential risks, isconsidered as a very complicated task.

The prime principle of our architecture that defines thecontext in which we set its functional requirements is thetrust factor built between user and banking organizationand between user and her mobile device. Traditionally,people trust financial organizations, since they offer secu-rity and guarantees to every transaction and have builtthe necessary reputation. For that reason, our architectureis designed to be bank-centric, since we believe that thiswould be a factor that favors wide user acceptance. Usingthe term bank-centric, we illustrate the role of the bank asthe main control and coordination point in every financialtransaction.

Furthermore, we regard system integration as a signifi-cant functional requirement that is taken into consider-ation in OFSA design. In the majority of the proposedarchitectures, e-payment and e-banking systems operateas two separate applications for the end-user. We considerintegration of payment and banking systems as necessary,especially for ubiquitous computing environments, wheretransaction procedures are complicated. It is not a simpleintegration of the corresponding applications, but an inte-gration of business layer procedures. 3G and emerging 4Gcommunication technologies create new potential for finan-cial systems development and, at the same time, they offer

Fig. 2. Intelligent mobile device interfaces.

236 A. Kousaridas et al. / Electronic Commerce Research and Applications 7 (2008) 232–246

innovative, ubiquitous and pervasive services that affect therequirements both quantitatively and qualitatively [33].The technology integration factor was taken into seriousconsideration when designing the proposed architecture,as well as when integrating financial transactions to onedevice, which provides unified management. Technologyintegration involves the unification of various technologiessupporting same functionality, through the deployment ofdiscrete components. For example, communication tech-nologies such as UMTS, Wi-Fi and WiMAX are groupedtogether and managed by the Remote CommunicationComponent, through a unified way.

OFSA architecture does not only focus on user orientedrequirements but also takes into account financial organiza-tions’ ones. Thus, one of the main architecture’s functionalrequirements is the exploitation of current infrastructure

and software, which decreases system’s development costand allows easy adoption. We satisfy this requirement byusing the Web services technology. Another requirementset by financial organizations, and satisfied in the proposedarchitecture, is the capability to provide personalized ser-

vices. This capability increases a user’s utility and, in parallel,enables banking organizations to adapt their services,according to a user’s profile, needs and characteristics, thusincreasing their profit.

Security is one of the most important requirements thatinvolved entities set. In such systems, where crucial dataare transferred and payment transactions are taking place,security mechanisms as well as secure communication pro-tocols must be implemented in every stakeholder. Thus wehave faced security as an end-to-end issue. Security, as arequirement, is the provision of confidentiality, integrity,authentication, authorization, assurance and non-repudia-tion in every transaction. Critical data involved in financialtransactions must be stored securely in the mobile device orin the bank’s storage infrastructure. Smart cards, embed-ded or external, are security elements that ensure securestorage of information, so that non-authenticated applica-tions or users cannot retrieve and use this information.They also provide a secure environment for computationalprocess execution. One important issue is to define theactors who can store information in these security elementsand the information category that each actor is responsiblefor. For instance, the device’s owner can load electroniccoins on the smart card through an ATM. On the otherhand, certificates and private keys for asymmetric encryp-tion of bank transactions are exclusively loaded by thebanking organization.

The above-mentioned information can be stored eitherin the USIM or in a NFC chip. As mentioned in Section2.2, the main advantage of NFC chips, which have threedifferent operation modes [30], is that they can even workwhen a mobile device is deactivated (e.g., due to a powershortage). In this case, an NFC chip can operate as a con-tact-less smart card, independently from the mobile device,supporting specific operations like the execution of mobilepayments.

3.3. OFSA component analysis and interaction

Component-based design of OFSA offers extensibilitycharacteristics and enables developers to introduceadvanced functionality and services or improve existingones. Before we proceed with the architecture components’detailed analysis, we present an overall view (Fig. 2), whichfocuses on the mobile device side and the interfaces that thelatter exports to other entities, including banking organiza-tions, points of sale, smart cards and peer mobile devices.

Fig. 3 presents the components that constitute OFSA onthe side of the mobile device. These components interactwith each other and with the bank and POS OFSA entitiesthrough internal and external open interfaces, respectively.

The User Interface Component is responsible for thepresentation of the information to the user, through a ser-ies of displays and interactions. When designing OFSA, wetried to separate the presentation layer from the businessand application logic, thus OFSA is able to support multi-ple mobile devices in terms of input and output capabilities.This component is also responsible for the interactionsbetween user and application, offering techniques and soft-ware tools that facilitate information entering. Accordingto the user’s actions, it sends signals to the Control Compo-nent through the corresponding ‘Control Interface’, whichcoordinates the necessary procedures. On the other hand,its exposed ‘Presentation Interface’ is used in order to pres-ent the appropriate information with the suitable format.

The Control Component undertakes the coordination ofthe procedures and the internal interaction of components.It also allocates received messages to the appropriate inter-nal component. Local and Remote Communication Com-ponents forward received messages to the ControlComponent, through the ‘Control Interface’. Further on,the Control Component dispatches each message and trig-gers the appropriate component, as regards the next proce-dure. In sequence, the Control Component is also triggeredby the other components, through the same interface. Final

Fig. 3. OFSA – intelligent mobile device components view.

A. Kousaridas et al. / Electronic Commerce Research and Applications 7 (2008) 232–246 237

actions for the Control Component might be the trigger ofthe User Interface Component to present some informa-tion, the request to the Local or Remote CommunicationComponents to transmit messages to other OFSA partsor the execution of an internal procedure. For instance, ifthe Remote Communication Component has received anencrypted message from the issuer, this message is trans-mitted to the Control Component. The former decryptsthe message first by utilizing Security Component mecha-nisms, and then identifies that it is an alert message. There-after it informs the user about a suspicious account change.Finally, the Control Component immediately notifies the‘User Interface’ to present the message at the device screen.

The Decision Component is responsible for decisionmaking on the client side. This component introduces intel-ligence to the device, which is aware of its owner‘s prefer-ences and generally the environment that the user isplaced in. It consists of two subsystems; a local DSS andan agent that communicates with the bank’s DSS. It isresponsible for the decision making when the applicationmust consider various requirements or parameters, in order

to make a financial transaction. For instance, when a userbuys a product from a physical POS, this componentshould propose the appropriate payment method, consider-ing the means that are accepted by the merchant. Themobile device DSS, in cooperation with the correspondingcomponent of the bank, is able to provide personalized ser-vices. For example, urgent messages alert the user for unu-sual or suspicious transactions. Moreover, statisticalreports help the user to efficiently use her mobile phoneas a personal consultant. The decision making could bepotentially extended using sophisticated techniques, likeartificial intelligence algorithms. For thin mobile devicessimple rules that are defined by the issuer and the userare considered as adequate.

The Payment Component includes the necessary algo-rithms for account or credit card-based payments as wellas algorithms for digital cash transactions. The aforemen-tioned methods provide all kind of payment means thatthe user selects to activate, offering the device with theability to execute peer-to-peer money transfers and mobilepayments remotely to a virtual POS or locally to a physical

238 A. Kousaridas et al. / Electronic Commerce Research and Applications 7 (2008) 232–246

POS. The open approach of OFSA allows the implementa-tion of various payment schemes (e.g., VISA 3D-Secure,MasterCard SPA). Through the ‘Payment Interface’, theControl Component calls the appropriate functions inorder to initiate the payment procedure, taking intoaccount the Decision Component’s proposal regardingthe specific transaction. According to the type of the trans-action and the payment scheme, the mobile device PaymentComponent interacts with the respective components onthe side of the issuer (Payment Services Component), thePOS (Transaction Settlement Component) or a peer mobiledevice (Payment Component).

The Banking Component undertakes control of theapplication, when transactions with the banking organiza-tion should take place. Accounting and personal informa-tion, bank transfers, investments and application formsare some of the services that user can experience throughthis component. As mentioned above, one key point ofthe proposed architecture is the interaction and coopera-tion of payment and banking subsystems. OFSA achievesintegration of these two subsystems, by allowing theirintra-communication. A purchase from an unmannedPOS through a bank transfer is a representative example.The Banking Component cooperates with the respectiveComponent (Banking Services) on the side of the bank(issuer).

The Trust Mechanism is introduced in order to increaseconsumers’ and merchants’ confidence, protecting themfrom users that are not legal and fair. Establishment oftrust enables user and merchant to transact even withoutthe intervention of administrators, who authorize thesetransactions. During a payment transaction, the paymentscheme that is used provides the first level of confidenceamong the involved parties. The bank (Acquirer) guaran-ties that the payee (merchant) will receive the money fromthe payer and the transaction can conclude successfully. Inaddition, the trust mechanism could be used to inform andprotect the involved parties about other aspects of thetransaction, such as low quality products and services orfraudulent payments. In the context of electronic pay-ments, many trust theories are based on the history ofthe transactions that each entity (mobile device user,POS) has conducted, but only several trust metrics havebeen introduced to date [34]. The type and value of thetransaction may specify the trust level that the involvedentities demand. A trusted third-party (TTP) could be usedto provide trust and ensure that the involved – in a pay-ment transaction – entities, are not malicious. The role ofthe TTP could be assigned to the financial organizationor to an external, well known and trusted organization.TTP is informed by mobile device’s Trust Mechanismabout negative behavior that an entity had, affecting itstrustworthiness.

Furthermore, the Trust Mechanism should be able tolocally collect information about entities that have, forexample, frequent transactions. The presence of this com-ponent becomes more important in the case of peer-to-peer

payments. The Decision Component, through the defined‘Trust Interface’, requests a response about the reputationthat a peer entity or a POS has. The Trust Component cancommunicate with the corresponding mechanism on theside of the TTP and evaluate the trust level of the respectiveentity.

The Local Communication Component handles commu-nication between physical POS and the mobile device orbetween peer mobile devices. Payment messages can bephysically transmitted via various air interfaces such asBluetooth, IrDA or NFC, depending on the hardwareand software features of the mobile device. This compo-nent implements Bluetooth, IrDA or other short rangetechnologies APIs. It retrieves messages that arrive fromthe corresponding short range interface and forwards themto the Control Component. The ‘Transfer Interface’ definesoperations for the transmission of messages to the POS orpeer entities that use short range wireless technologies. Thiscomponent communicates with the corresponding compo-nent of other peer mobile devices and with the MobileDevice Communication Component on the side of themerchant.

The Remote Communication Component controls themobile device’s communication, when a remote transac-tion, such as the provision of a retail banking service andor an Internet payment, is taking place. Communicationtechnologies involved in such transactions are UMTS,Wi-Fi and WiMAX. The OFSA modular design permitsthe introduction of new technologies if needed, withoutthe interference of other components. This componenthas also undertaken Web services management, includingtransmission and reception of SOAP messages, by utilizingXML parsers for XML message composition and decom-position. This component cooperates with the correspond-ing Mobile Device Communication Component, on theside of the issuer and the merchant, in case of mobile pay-ments. The ‘Transfer Interface’ defines operations for thetransmission of banking service messages to the issuerand messages in case of remote mobile payments (e.g., anonline Internet shop).

The Synchronization Agent handles all synchronizationactions between the mobile device and the bank server.It consists of the Synchronization and the Update Subcom-ponents. The first one allows mobile device and bank tocooperate, in order to periodically synchronize their com-mon data (e.g., transaction history files, e-receipts) and alsoprovides the mobile device with a back up storage place.A secondary repository provides additional security andan alternative way for the user to access information andservices (e.g., through a web browser). Furthermore,through the ‘Synchronize Interface’, the Control Compo-nent may request transmission of e-receipts that are storedlocally in the remote database of the issuer. Moreover, theControl Component through the ‘Request Updates Inter-face’ (Update Subcomponent) is able to request updatesabout components that the bank is authorized to handle.The Update Subcomponent contains an agent for the over

A. Kousaridas et al. / Electronic Commerce Research and Applications 7 (2008) 232–246 239

the air (OTA) download and management of OFSA com-ponents. For instance, the bank is able to update the Pay-ment Component by adding a new payment scheme or theBanking Component by including a new bank service. Fur-thermore, a new security scheme or feature can be down-loaded. The Synchronization Agent collaborates with theRemote Management Component, on the side of theissuer, which has the ability to initiate an updateprocedure.

The Smart Card Management Component implementsthe mechanisms that manage and control smart cards,either external or embedded into the mobile device. The lat-ter may interact with various types of smart cards, exploit-ing their capabilities. Each smart card type is handled bythe corresponding subcomponent: the USIM Subcompo-nent undertakes to communicate with USIM and utilizeits exported functions. The NFC Subcomponent managesthe NFC chip [30] and the External Smart Card Subcom-ponent handles external smart cards, in case that themobile device incorporates the relative reader. The SmartCard Management Component is responsible for the retrie-val of information that is stored in the smart card as well asfor the call of functions, which are exclusively executed bythe smart card microprocessor. The ‘Retrieve Data Inter-face’ defines the operations for the insertion, retrieval andupdate of data stored in the smart card. Furthermore,the ‘Execute Interface’ defines operations that are executedin the smart card, such as encryption/decryption of sensi-tive data, secure logon and authentication of users. TheControl and Security Components are the only compo-nents that can directly communicate with this interface.

The Security Component includes the mechanisms thatare necessary for user’s local authentication proceduresand for assuring secure communication between the mobiledevice and the bank as well as between the mobile device andthe POS. The Control Component is able to call the‘Authenticate/Authorize’ and ‘Encrypt/Decrypt Data’Interfaces acting as an intermediate between the rest of com-ponents and the security one. Internet applications ensurecommunication security using Secure Socket Layer (SSL),Transport Layer Security or Wireless TLS (WTLS) for wire-less communications. PKI infrastructure and several secureXML protocols, like XML digital signatures, XML encryp-tion and Web services security protocol family, are some ofthe alternative popular security approaches [35].

Communication with the banking organization (issuer)is usually implemented using a specific and predefined secu-rity mechanism. The user should be authenticated to accessthe banking organization when she wants to make a pay-ment through the issuer or to use a bank service. Furtheron, data transmission should be confidential. The mobiledevice may transact with several POS or peer mobiledevices, which may implement different security schemes.This makes security issues complex, since these types ofcommunication require minimum exchange of crucialinformation. The OFSA security component integratesthe security schemes that the issuer or any other stake-

holder requires, in order to provide the entities that partic-ipate in a transaction with a secure interface.

Fig. 4 presents the OFSA Components on the side of thebanking organization, which operates either as an issuer oran acquirer, or both. OFSA is designed to exploit financialorganizations’ legacy applications and to support currentand ongoing financial procedures. OFSA is designed tooperate on top of current financial information systems,without requiring banks to change their fundamental pro-cedures and their expensive infrastructures.

Mobile Device and Merchant Communication Compo-

nents provide the mechanisms for communication betweenthe bank and the mobile device and the merchant, respec-tively. These components export a ‘Transfer Interface’,which is used by the Control Component, in order to trans-mit data. Mobile Device and Merchant CommunicationComponents interact with the Remote CommunicationComponent on the side of the mobile device and with theBank (Acquirer) Communication Component on the sideof the POS, correspondingly.

The Control Component coordinates the communicationamong the components and the sequence of the proceduresduring a financial transaction. The functionality of thiscomponent is similar with the above described ControlComponent on the side of the mobile device. The Decision

Component acts as an intermediary between the bank’sDSS and OFSA. XML adapters can be used so as to enablethe Decision Component to export the available decisionsupport services of the bank. They provide informationto the corresponding Decision Component on the mobiledevice or on the merchant side, facilitating their decisionmaking procedures (e.g., suggestions and potential threats).

The Security Component undertakes merchants’ andmobile device’s authentication and authorization to theacquirer and to the issuer, respectively. It also providesmechanisms for data confidentiality. This componentcooperates with the corresponding Security Componenton the POS and on the mobile device side. The Bank Ser-vices Component includes the necessary procedures for thesettlement of bank transactions after user’s request. Thiscomponent cooperates with the core bank information sys-tem. For instance, in case of a bank transfer, Bank ServicesComponent, following Control Component’s signal, for-wards the request to the appropriate module of the corebank information system. The Payments Services Compo-

nent is responsible for the transfer of money from the payerto the payee and for the settlement of the payment orders.It includes the payment schemes that the issuer supportsand also allows the implementation of new or extendedpayment models, as the one which is described in the sce-nario section.

Trust Mechanisms provide bank with the ability to cre-ate a trust network, where customers and merchants willbe protected from unfaithful entities, while fair users willbe identified and have more profitable services and prod-ucts. The bank may operate as a trusted third-party(TTP) and thus it can be informed by POS or mobile

Fig. 4. OFSA – banking organization components view.

240 A. Kousaridas et al. / Electronic Commerce Research and Applications 7 (2008) 232–246

devices about fraudulent events. Finally, the Remote Man-

agement Component includes all these functions that enablethe bank to manage and control OFSA procedures on themerchant or on the mobile device side, to provide updatesand to share information.

The last two components as well as the Decision one arekey points for implementing the cooperation channelbetween the bank and the mobile device. The Trust Mech-anism is utilized by the decision making mechanism, whilethe Remote Management procedures are triggered by theControl Component through the ‘Update Interface’, afteran internal bank decision or after a mobile device’s request(Synchronization Agent).

Fig. 5 depicts OFSA on the merchant side that can beeither virtual, (e.g., Web store front) or physical (e.g., vend-ing machine). The Mobile Device Communication Compo-

nent is responsible for the communication between thePOS side of OFSA and the mobile device during a pur-chase. The Bank (Acquirer) Communication Component isresponsible for the POS communication with the bank(Acquirer), so as to settle a payment or to provide valueadded services. These two components contain the neces-

sary software mechanisms for messages’ reception andtransmission, using the communication technologies thatthe POS supports. The Control Component utilizes their‘Transmit Interfaces’, in order to send messages to themobile device or to the acquirer.

The Merchant Configuration Component provides anexternal interface that enables merchants to manipulatetheir POS, by modifying various transactions’ parameters(e.g., product prices). The Control Component, as describedabove, is triggered through the ‘Control Interface’ by therest OFSA components, in order to coordinate the interac-tions among the components in the context of a paymenttransaction.

The Decision Component, which is signaled through the‘Decide Interface’ by the Control Component, evolves POSfunctionality, making its decision process more intelligent.For instance, the ability to adapt parameters of the trans-action, like the price or the discount, according to pur-chase’s context, user’s transaction history and the level oftrust is an example of decision making on the POS side.

The collaboration of the Decision Component and theTrust Mechanism, through the ‘Trust Interface’, enables

Fig. 5. OFSA – merchant components view.

A. Kousaridas et al. / Electronic Commerce Research and Applications 7 (2008) 232–246 241

the POS to check the level of clients’ confidence. The Trust

Mechanism cooperates with the respective component onthe side of the trusted third-party banking organizationand, apart from checking transacted entities confidencelevel, has also the ability to inform the TTP about mali-cious transactions or clients.

The Transaction Settlement Component, which is trig-gered by the Control Component through the ‘PaymentInterface’, cooperates with its acquirer Payment ServicesComponent and with the mobile device Payment Compo-nent, so as to settle a pending payment. Finally the Security

Component through its exported ‘Authenticate/Authorize’and Encrypt/Decrypt Data’ Interfaces provides POS withthe ability to secure the communication with the mobiledevice and its acquirer.

4. Mobile payment scenario using OFSA prototype

4.1. Scenario description and transaction flow

In this section, we describe a sophisticated financialservice scenario where payment and banking services are

combined and a home-grown payment scheme is deployed.Throughout the scenario description, we have attempted toillustrate the inter-component interactions, as well as theirinternal functionality.

A user wants to buy a product from an unmanned Blue-tooth-enabled POS, using her intelligent mobile device. Theuser selects the desired product, by physically interactingwith the POS. The POS provides several ways for the pay-ment including e-coins, bank transfers and credit or debitcards. The user, taking into account the bank’s and themobile device’s suggestion, selects to pay through her debitcard and initiates the payment procedure using her PIN.After payment is completed, the user takes the product thatshe has bought and the e-receipt that proves the conductedfinancial transaction. Fig. 6 depicts the interactions amongentities and the sequence of messages which are necessaryfor the aforementioned transaction.

The user selects the desired product (step 1) and holdsher mobile device near merchant’s Bluetooth interface, inorder to initiate the transaction. The POS through the‘Mobile Device Communication Component’ transmitstransaction’s information to the mobile device (step 2),

Fig. 6. ‘‘Unmanned POS m-payment’’ scenario: UML message sequence.

242 A. Kousaridas et al. / Electronic Commerce Research and Applications 7 (2008) 232–246

including: Transaction’s unique ID, Transaction’s Time-stamp, Product’s Information and POS Information(Fig. 7).4

The ‘Local Communication Component’ on the mobiledevice side receives the transaction’s data, which are for-warded to the ‘Control Component’. The latter identifiesthe type of the transaction and coordinates the next steps.First of all, transaction’s information is presented to theuser through the ‘User Interface’. The user checks its valid-ity and accepts the purchase. Before payment’s initiation,the ‘Control Component’ requires user’s local authentica-tion. The user inserts her PIN (step 3) at the appropriateform of the User Interface and thereafter the ‘Security

Component’ undertakes the local authentication procedure.This component triggers the ‘Smart Card Management

Component’ to call the corresponding function at the smartcard so as to authenticate the user (steps 4–6). Upon theuser’s authentication, the ‘Security Component’ informsthe ‘Control Component’, which in sequence requests the‘Decision Component‘ to identify the most appropriate pay-

4 An XML schema can be viewed as a directed graph where the verticescorrespond to elements or attributes and the edges represent containment(parent–child) relationships. The vertices are labeled with the name of theelement/attribute. The edges have an additional multiplicity label that ispresented using the asterisk (*) symbol [36].

ment method (step 7). The mobile device ‘Decision Compo-

nent’ requests bank’s suggestion (bank’s ‘Decision

Component’) via ‘Remote Communication Component’ and‘Mobile Device Communication Component’. After theuser’s authentication by the bank (steps 8 and 9), themobile device transmits the encrypted transaction’s infor-mation (Fig. 8). The bank, taking into account the amountof the transaction, the user’s transactions history, heraccount balances and her preferences, proposes the appro-priate payment method (Fig. 9) for the specific transaction(steps 10 and 11).

After receiving the bank’s suggestion of a paymentmethod, the mobile device’s ‘Decision Component’ filtersand gives final verification for the payment method’s valid-ity (step 12), the user selects the payment method (in thiscase her debit card) and initiates the payment procedure(step 13).

The mobile device via the ‘Local Communication Com-ponent’ informs the POS (‘Mobile Device CommunicationComponent’) about the selected payment method (step 14).In the sequence, the mobile device’s ‘Payment Component’completes the payment procedure by interacting with thePOS (‘Transaction Settlement Component’), taking intoaccount the payment scheme that the merchant uses. Forthis specific scenario, the POS uses an e-payment scheme,where the payment is accomplished via the customer’s

Fig. 7. Transaction’s information transmitted from the POS – XML message.

Fig. 8. Mobile device proposal request – XML message.

Fig. 9. Proposal response from the bank – XML message.

A. Kousaridas et al. / Electronic Commerce Research and Applications 7 (2008) 232–246 243

issuer bank and POS acquirer bank. The POS asynchro-nously informs its acquirer that a payment is pending.The transaction is identified through the generated uniqueID number (step 15) that is sent by the POS (TransactionID). The mobile device ‘Payment Component’, via the ‘Con-

trol Component’, requests and retrieves the debit card infor-mation, which has been encrypted and stored in the smartcard (‘Smart Card Management Component’) (steps 16–18).The mobile device communicates with the issuing bank,and over UMTS or Wi-Fi communication network,requests issuer (‘Payment Services’ Component) to chargethe debit account (step 19). The issuer processes the request(step 20) and confirms or not – in real time – the pendingtransaction to the POS acquirer (step 21), which in turninforms the POS if the customer is accepted or not (step24). The actual financial settlement is taking place accord-ing to mutually agreed business rules. After acquirer’s

confirmation (step 22) the issuer informs the mobile device(‘Payment Component’) that the transaction has success-fully concluded (step 23). Finally, the POS delivers theproduct (step 25) and the corresponding electronic receipt(step 26) to the mobile device.

4.2. Prototype outline

We have implemented an OFSA prototype, whichfocuses on the mobile device side and on the cooperationchannels that this device can accommodate with other enti-ties, including banking organization, POS, smart card andpeer mobile devices, as depicted in Fig. 7. We have success-fully tested the aforementioned unmanned POS m-paymentscenario in a semi-emulation environment [37]. For the pur-pose of the scenario, we have implemented a virtual bankand a virtual vending machine (Point of Sale). Fig. 7 illus-trates the involved entities and the mapping of the maintechnologies that have been selected. The mobile deviceapplication has been implemented using the smart clientmodel, and specifically the Java 2 Micro Edition (J2ME)programming language. We have used the Sun Java Wire-less Toolkit to emulate the mobile phone (see Fig. 10).

Mobile Web services [38] is the technology that has beenused for the implementation of communication among themobile device, the POS and the bank application server.

Fig. 10. OFSA implementation: system view.

244 A. Kousaridas et al. / Electronic Commerce Research and Applications 7 (2008) 232–246

Web Service Description Language (WSDL) and XMLSchema Definition (XSD) files describe the operationsand the services that the banking organization and thePOS offer to the mobile device as well as the messagesand data types, exchanged between these entities. Financialservices are invoked over the WWW using Simple ObjectAccess Protocol (SOAP) messages, which are XML-based,and are used for the implementation of communicationbetween the involved entities. JSR 172 Web services API(WSA) [39] allows a J2ME-enabled mobile device torequest Web services, by providing XML parsing capabili-ties using Simple API for XML (SAX2) and XML-basedRemote Procedure Call using JAX-RPC. Further on, onthe bank and POS sides, an Apache Axis server is usedfor Web services provision and execution. Regardingpeer-to-peer communication, Bluetooth technology is usedand more specifically the JSR-82 API [40], which providesBluetooth capabilities to J2ME-enabled devices.

Critical information is stored and operations are exe-cuted in Java Card USIM, where Java Card applets are

implemented using Java card platform [41]. For the com-munication between the mobile device and the smart cardwe have used the ‘‘Security and Trust Services’’ API(SATSA) [42]. Moreover we have tested the integrationof the mobile device and Kerberos [43], which has beenused for user’s authentication and authorization. TheKey Distribution Center (KDC) consists of the Authenti-cation Center for user’s authentication and the TicketGranting Server (TGS). The latter issues tickets for thecommunication between the bank application server andthe mobile device.

More information with regard to the prototype, thedefined WSDL and XSD files, as well as screenshots andimplementation details, is available at the OFSA imple-mentation Web site [37].

4.3. OFSA discussion and evaluation

The prime OFSA feature is the integration of paymentand banking systems as well as the establishment of a

A. Kousaridas et al. / Electronic Commerce Research and Applications 7 (2008) 232–246 245

cooperation channel between the mobile device and thebank. The majority of systems which have been proposedto date [7] consider mobile payment and banking systems,as two independent applications. SEMOPS [13] is regardedas one of the most successful initiatives, since openness,universality and standardized interfaces are its main advan-tages. OFSA adopts the integration of several paymentmeans (e.g., e-coins and credit or debit cards) in a singlemobile device, as described in [14] and SEMOPS. Further-more we propose the integration of payment and bankingsystems. We believe that this integration as well as thecooperation channel between the bank and the mobiledevice are crucial factors, which increase the trust levelbetween involved entities and facilitate banks to providepersonalized services.

Furthermore, we defined OFSA to be bank-centric. Itintroduces intelligence in the mobile device and deploysthe exported banks’ business intelligence and decision sup-port services. The mobile device’s rule-based DecisionComponent operates consultatively on behalf of the user,proposing specific services or actions according to her pro-file, preferences and history of transactions.

Moreover, most of the proposed systems are based onspecific payment schemes [7]. OFSA, however, is not boundto any payment model, since the mobile device ‘PaymentComponent’ is extensible to support any payment model.The Over the Air download mechanism allows a mobiledevice to download payment schemes and services fromthe issuer.

Hardware, operating system and programming languageindependence have been key requirements in the design ofOFSA. Service oriented architecture, which is implementedwith Web services, supports language independence andassures the desired platform interoperability and openness.

Many of the up-to-date commercial systems are basedon SMS, voice or WWW [7]. On the other hand, OFSAas well as [11,14], adopt the smart client model for develop-ing applications on the mobile device side. The main fea-tures of the smart client model are mobile deviceautonomy, extendibility and facilitation of mobile deviceresources’ control. Furthermore, offline browsing, whichis supported by the smart client model, enables user toaccess mobile financial services while avoiding continuousinteraction with the remote server.

Moreover, regarding security issues, Zhang et al. [11]propose the usage of the USIM card in order to implementuser authentication or encryption/decryption of transmit-ted messages. OFSA supports information storage, likeelectronic receipts and transactions’ history file, on aremote repository, which could be either on the issuer sideor on a trusted third-party. It also supports critical infor-mation storage (e.g., PIN, or credit and debit card informa-tion) on portable smart cards. Thus, the user has the abilityto access her information from various devices and loca-tions, which are considered as secure.

Storing information in the handset and especially inthe NFC chip is an alternative for securing crucial data.

The GSM Association (GSMA) [44], the global trade asso-ciation for mobile network operators, is participating in theNFC initiative to encourage common specifications inimplementing NFC technology in mobile phones.

On the other hand, the transmission of personal data tothe issuer and the cooperation channel itself may raise pri-vacy issues. In order to overcome these issues, mechanismsfor the provision of anonymity must be provided. Further-more, in many cases, only MNOs are authorized to loadand install applications in the USIM card. This means thatthere is a need for cooperation between the bank and theMNO. Additionally, the cost that arises when data trans-mission occurs from the bank to the mobile device and viceversa is an issue that should be taken into account in thecooperative relationship between MNOs and banks. Aninnovative business solution that combines banking activi-ties with mobile telephony is the Mobile Virtual NetworkOperator (MVNO) service, which is owned by bankingorganizations. This model allows the MVNO to controlthe USIM card and to use various pricing policies. Finally,while OFSA can be easily implemented for a virtual POS,the upgrade of physical vending machines is consideredas a more complex and costly aspect, since these machinesare mainly hardware-based.

During the prototype implementation and testing pro-cess [37], we have pointed out some important aspects thatare worth mentioning. Firstly, the development technolo-gies (e.g., programming languages-J2ME, wireless tool-kits) for mobile device applications are still immatureenough to create a stable and ready for production pro-ject. A lot of interoperability and compatibility issues arisebetween the different versions of the above products. Fur-thermore, introducing advanced functionality to a mobileenvironment, which supports limited computational andnetwork resources, is not always a trivial procedure. Inthe case of OFSA, maintaining the component design onthe mobile device side has been a difficult task, especiallyregarding the security mechanisms. These are still in aprimitive state.

5. Conclusion

In the present paper, we have identified the mainrequirements that mobile financial systems should satisfyand we have discussed the main reasons that caused alow-level of user acceptance of already developed systems.We have described an Open Financial Services Architec-ture which satisfies the involved entities’ requirementsand provides innovative features. Technology integration,platform independence, openness, intelligence and trustamong involved parties are OFSA’s main characteristics.Furthermore, OFSA proposes payment and banking sys-tems integration as well as the establishment of a coopera-tion channel between the mobile device and the bankingorganization. The described scenario and the correspond-ing implemented prototype support OFSA’s presentationand demonstrate its feasibility.

246 A. Kousaridas et al. / Electronic Commerce Research and Applications 7 (2008) 232–246

Our ongoing work includes further testing the imple-mented prototype and extending its functionality. The finalprototype implementation should be benchmarked to eval-uate OFSA and assess its performance. For that reason, weintend to thoroughly investigate potential quantitative andqualitative criteria and metrics.

Acknowledgements

We thank Mrs. Kefala for her helpful comments and hercontribution during the editing phase. Furthermore, wealso wish to thank the E-Commerce Research and Applica-tions m-payments special issue editors, Robert J. Kauff-man, Stamatis Karnouskos, Elaine Lawrence and KeyPousttchi as well as the anonymous reviewers for their con-structive suggestions and comments during the whole revi-sion process.

References

[1] ePayments Systems Observatory, http://epso.intrasoft.lu (accessed14.04.07).

[2] Mobile Payments Forum, http://www.mobilepaymentforum.org(accessed 14.04.07).

[3] K. Turowski, K. Pousttchi, Mobile Commerce: Basics and Tech-niques (Mobile Commerce: Grundlagen und Techniken), Springer,2470 Heidelberg, Germany, 2004.

[4] A. Herzberg, Payments and banking with mobile personal devices,Communications of the ACM 46 (5) (2003) 53–58.

[5] N. Mallat, M. Rossi, V.P. Tuunainen, Mobile banking services,Communications of the ACM 47 (5) (2004) 42–46.

[6] K. Pousttchi, M. Schurig, Assessment of today’s mobile bankingapplications from the view of customer requirements, in: R. Sprague(Ed.), Proceedings of the 37th Annual Hawaii International Confer-ence on System Sciences, Big Island, HI, IEEE Computer SocietyPress, Los Alamitos, CA, 2004, pp. 1–10.

[7] S. Karnouskos, Mobile payment: a journey through exiting proce-dures and standardization initiatives, IEEE Communications Surveysand Tutorials 6 (4) (2004) 44–66.

[8] J. Ondrus, Mobile Payments: a tool kit for a better understanding ofthe market, Licence Thesis, HEC School of Business, University ofLausanne, 2003. http://www.hec.unil.ch/jondrus/papers/Ondrus-licence-mpayment.pdf (accessed 14.04.07).

[9] A. Zmijewska, E. Lawrence, R. Steele, Towards understanding offactors influencing user acceptance of mobile payment systems, in:Proceedings of the IADIS International Conference on WWW/Internet, Madrid, 2004.

[10] K. Pousttchi, An analysis of the mobile payment problem in Europe,in: C. Branki, R. Unland, G. Wanner (Eds.), MultikonferenzWirtschaftsinformatik (MKWI) 2004, Universitat Duisburg-Essen,March 9–11, 2004, Band 3: Mobile Business Systems, Mobile andCollaborative Business, Techniques and Applications for MobileCommerce (TAMoCO), Essen, 2004, Germany, pp. 260–268.

[11] Q. Zhang, K. Mayes, K. Markantonakis, A user-centric m-paymentsolution, in: Proceedings of the Second International Conference onMobile Technology, Applications and Systems (IEEE MobilityConference), UK, 2005.

[12] A. Saxena, M.L. Das, A. Gupta, MMPS: a versatile mobile-to-mobilepayment system, in: Proceedings of the International Conference onMobile Business (ICMB), Hyderabad, India, 2005, pp. 400–405.

[13] A. Ramfos, S. Karnouskos, A. Vilmos, B. Csik, P. Hoepner, N.Venetakis, SEMOPS: paying with mobile personal devices, in:Proceedings of Fourth IFIP Conference on e-Commerce, e-Business,and e-Government, Toulouse, France, August 2004.

[14] Y. Labrou, J. Agre, L. Ji, J. Molina, W.-I. Chen, Wireless wallet, in:The First Annual International Conference on Mobile and Ubiqui-tous Systems: Networking and Services, UK, 2004, pp. 32–41.

[15] STARFISH, http://starfish.ccslab.aueb.gr (accessed 14.04.07).[16] Mobile FeliCa, http://www.felicanetworks.co.jp/index.html (accessed

14.04.07).[17] Mobile Suica, www.jreast.co.jp/mobilesuica (accessed 14.04.07).[18] Pay Pal, http://www.paypal.com (accessed 14.04.07).[19] Paybox, http://www1.paybox.com (accessed 14.04.07).[20] Mobipay, http://www.mobipay.com (accessed 14.04.07).[21] Nokia Wallet, http://www.forum.nokia.com/info/sw.nokia.com/id/

37ae0410-6e97-4f23-9a8a-c23ba7c0fd25/Wallet_Release_2_0_en.pdf.html (accessed 14.04.07).

[22] Vodafone’s m-pay bill, http://www.vodafone.co.uk/mpay (accessed14.04.07).

[23] Mobey Forum, http://www.mobeyforum.org/index.php (accessed14.04.07).

[24] Mobile Electronic Transactions, http://www.mobiletransaction.org(accessed 14.04.07).

[25] PayCircle, http://www.paycircle.org (accessed 14.04.07).[26] 3rd Generation Partnership Project (3GPP), http://www.3gpp.org

(accessed 14.04.07).[27] The Official Bluetooth Wireless Info Site, http://www.bluetooth.com

(accessed 14.04.07).[28] Draft ISO/IEC 14443 standards, http://wg8.de/sd1.html (accessed

14.04.07).[29] Infrared Data Association – IrDA, http://www.irda.org (accessed

14.04.07).[30] NFC Forum, http://www.nfc-forum.org (accessed 14.04.07).[31] H. Ekstrom, A. Furuskar, J. Karlsson, M. Meyer, S. Parkvall, J.

Torsner, M. Wahlqvist, Technical solutions for the 3G long-termevolution, IEEE Communications Magazine 44 (3) (2006) 38–45.

[32] J.J. Chen, A. Carl, Short-range wireless technologies with mobilepayments systems, in: Proceedings of the 6th International Confer-ence on Electronic Commerce (ICEC), Delft, The Netherlands, 2004,pp. 649–656.

[33] P. Boddupalli, F. Al-Bin-Ali, N. Davies, A. Friday, O. Storz, M. Wu,Payment support in ubiquitous computing environments, in: Pro-ceedings of the 5th IEEE Workshop on Mobile Computing Systems &Applications, Tucson , USA, 2003, pp. 110–120.

[34] D.W. Manchala, E-commerce trust metrics and models, IEEEInternet Computing 4 (2) (2000) 36–44.

[35] J. Long, M.J. Yuan, A.B. Whinston, Securing a new era of financialservices, IEEE Computer Society 5 (4) (2003) 15–21.

[36] R. Krishnamurthy, V.T. Chakaravarthy, R. Kaushik, J.F. Naughton,Recursive XML schemas, recursive XML queries, and relationalstorage: XML-to-SQL query translation, in: Proceedings of the 20thInternational Conference on Data Engineering, Madison, WI, 2004,pp. 42–53.

[37] OFSA Prototype, http://www.ccslab.aueb.gr/ofsa/Readme.htm(accessed 14.04.07).

[38] T. Pilioura, A. Tsalgatidou, S. Hadjiefthymiades, Scenarios of usingWeb services in M-Commerce, ACM SIGecom Exchanges 3 (4)(2003) 28–36.

[39] JSR 172: J2ME Web Services APIs (WSA), http://java.sun.com/products/wsa (accessed 14.04.07).

[40] JSR 82: Java APIs for Bluetooth, http://jcp.org/en/jsr/detail?id=82(accessed 14.04.07).

[41] Java Card� 2.2 Platform Specification, http://java.sun.com/prod-ucts/javacard (accessed 14.04.07).

[42] JSR 177: Security and Trust Services API for J2ME (SATSA), http://java.sun.com/products/satsa (accessed 14.04.07).

[43] F. Khan, Securing Java Card applications, Part 2: Integrating JavaCard into J2ME applications (December 13, 2005), http://www-128.ibm.com/developerworks/library/wi-satsa2/index.html (accessed14.04.07).

[44] GSM Association (GSMA), http://www.gsmworld.com (accessed14.04.07).