Skip to main content
    Country/region [select]      Terms of use
     Home      Products      Services & solutions      Support & downloads      My account     

IBM : developerWorks : Wireless : Wireless articles
The future of wireless banking
PDF - 278KB e-mail it!
What are the components of a wireless system?
Managing data
Pushing or pulling data?
Wireless app services must be device- and network-independent
What about screen scraping?
Security, wireless banking, and trading
The challenge
Selecting the right application vendor
The road to a successful implementation
About the author
Rate this article
Related content:
Java technology and the wireless world
More wireless resources
Implementing wireless banking and financial systems

Rod Ghani (
Senior Consultant, IBM Global Services
July 2001

Wireless banking is a convenience we all want to take advantage of, and one that financial institutions are eager to have implemented as soon as possible. While the pressure to implement wireless banking services is great, and its development and implementation are challenging, care needs to be taken to avoid the potential risks.

Wireless banking is revolutionizing the financial industry. It's radically transforming both services and customer expectations in societies around the globe. End users are demanding access to their money and financial information anytime, anywhere. Financial institutions know they need to move quickly to capitalize on this new trend.

By the year 2003, the number of people accessing personal account information online will grow to 40 million -- five times the 1998 rate. And the gap between wireless and landline users is narrowing fast. 100 million U.S. residents will access the Web in 2003 using wireless devices. That's not far off the 155 million who will connect via the more traditional PC/landline route. In Europe, the situation will be even more marked, with 90% of companies surveyed planning sites accessible to the projected 219 million wireless users -- one-third of the European population.

Not every financial institution, though, will find it easy to keep pace with the changes demanded. There are connectivity issues, protocol challenges, and a constant flood of new devices onto the market. Large institutions may find keeping pace especially difficult. For data managers, the challenge will be to deliver data effectively across every platform, protocol, browser, and service provider. In the meantime, B2B, B2C, B2G, and B2E are now being recognized as vertical online markets, and wireless is about to subdivide them with new services targeting new user groups. And P2P (person-to-person) and P2A (person-to-anyone) are set to play major roles as well in the financial world.

The good news is that lowered networking costs, together with improvements in wireless devices and bandwidth utilization, have made today's wireless service costs justifiable, which would not have been a year ago. To ensure the long-term viability of the investment, open systems need to be constructed that use standard protocols. Successful wireless implementation means end users who can interact with data easily and safely, independent of the network operator or handheld device.

What are the components of a wireless system?

  • Handheld devices
  • Connectivity, coverage, and gateways
  • Middleware processing engine
  • Transcoding
  • API connection
  • Data system backend

Components of a wireless system

Handheld devices

  • Thin client devices, such as Palm, WorkPad, Ipaq
  • Two-way paging devices, like RIM
  • Smart phones, WAP phones
  • Others

There are several operating systems used with handheld devices:
- Windows CE: This is a light version of Windows, developed by Microsoft. It is installed on many PDA devices.
- Palm OS: Proprietary platform developed by 3COM. Due to the large market share held by the Palm Pilot, the most popular operating system on the market today. Supports some Java applications.
- Linux: Very promising for growth, open source base, Java-friendly, very efficient, can be installed on many PDA devices and even on smart phones.
- EPOC: Symbian consortium drove the development of this operating system mostly for smart phone devices used by Ericsson and Nokia. EPOC is one of the major operating systems on the market.

Each handheld device demands its own ways of communicating; each requires its own gateway to communicate to the application server. Varying screen sizes give rise to varying screen layouts. Different keyboards make use of different keystrokes and navigation options. The application server must sort this all out and send each handheld device its data in a format it can utilize.

Connectivity, coverage, and gateways
This section covers the basic components of wireless network architecture.

Starting from the end user side, the handheld device can be any device that is used to access a local cell tower. The cell tower is responsible for delivering local geographical coverage in a certain hexagonal region. The cell tower then sends its data on to a base station.

From the base station, the data is transferred to a mobile switching center. The switching center connects all base stations together. If the user is part of the geographical network, the network system will identify his information via Home Location Register (HLR). If he's from outside the network, Visitor Location Register (VLR) will be used to track the call. This is when users end up paying big bucks for roaming.

Once the call is initiated, the device signals its identity using its electronic Serial number (ESN) and Mobile Identity Number (MIN). This information is vital for the gateway to authenticate the user. The application server then prepares data to send back to the appropriate unit to be displayed.

Application server prepares data

A packet is a collection of data prepared for transmission in a specific way. There are two types of transmission: circuit switched and packet switched. Circuit switched transmission entails a dedicated circuit for communication between two dedicated devices. Its duration is the length of the entire call. Packet switching does not require a dedicated line between the sender and recipient. This method enables the data to be divided into a number of packets and to be sent to its intended destination using different paths.

Connectivity varies from one device to another, and from one service provider to another. The most challenging issue for the wireless systems is coverage. As end users sign up with a WSP (Wireless Service Provider), they may quickly realize the limitations of the packages offered. Due to limited coverage areas, it can seem as if itís always the right plan in the wrong place.

Wireless service plans vary in options as well as cost. Common protocols a WSP can support include GSM (huge in Europe but not big in the U.S. yet), CDPD, CDMA, and Ardis -- all of which are jockeying for position.

Service plans vary

Wireless middleware (application server engine)
The wireless application is the focal point of the wireless system. This is where the flow of data is controlled, rules are set, and configuration files are executed. The application software should be open system and easy to connect with. One of the most common methods of communicating with backend systems is by using XML API as the data delivery tool.

XML is used to extract and deliver data; XSL can perform the transformations, using the DTD files to execute the functions agreed on in the integration and design stage. Different handheld devices will have different screen templates. The application server should track the user's sign-in on the device being used in order for data to be presented correctly. The screen templates can be XML documents which conform to DTD files. The screen templates are used only to define screen layouts. They are device specific.

Transcoding -- is it magic?
Transcoding is the process of formatting the content (data) according to the handheld device request using XML, XSL style-sheets and DTD files. This method enables end users to access data universally regardless of device type.

Transcoding process

Once a request from a handheld device is initiated, the application server intercepts the request to identify the device type and capture the content. Using several logical processes, the application server engine processes the data into an XML document, which can be communicated to the backend system via the API connection. The result is then transcoded (processed) using XSL stylesheets and reformatted for the handheld device that made the initial request. The process can quickly get complex, depending on the number of handheld devices supported and the type of services offered by the financial institution. Therefore, products like IBMís WebSphere can be valuable tools to build a robust financial system in a short time. The WebSphere application server handles data dynamically and adapts it to the handheld device. It is also capable of running multiple applications and requests, and can be easily integrated into the backend system. The WebSphere engine selects the correct screen template, formats the data for the handheld device, and delivers the data requested. XSL is used for data transformation definitions, where the API will exchange messages between the backend system and the application server. XSL and XSLT stylesheets are mainly used to manage the presentation of the data, whereas XML handles the data itself.

Managing data
The application server can use common device characteristics to display the data. Using these standards helps productivity in development.

User IDs and handheld device IDs are stored in the database at the application server level. Once a login request is received, the application server accesses the database. The middleware database is used to prepare and format the data for the device requesting the login. The application server will also compare the registered device ID to the user ID for additional security verification. The application server communicates with the gateway server for the specific device that initiates the request. The gateway then pushes the information to the handheld device based on the connectivity platform being used (e.g., CDPD, SMS, Mobitex, or CDMA).

The application server must accommodate different handheld platforms such as thin-client devices (IP-based devices), two-way paging, SMS messaging, and smart phones. It must then deliver data formatted for that specific device, end-to-end, in a reliable and secure manner.

Accommodating different platforms

Pushing or pulling data?
Pull technology is when the handheld device initiates the communication using its gateway to request data. The data is then pulled from the application server down to the handheld device. Push technology is when the application server is in control over the handheld device. The application server makes basic content decisions and pushes data to the handheld device without waiting for the clientís request.

In either method, authentication must take place first. The gateway transfers the handheldís request to the application server (middleware). The application server then recognizes the device type according to its identifier. The information is sent to the backend system of the financial institution, using the API between the application server and the backend system. The application server receives the information from the backend system and reports it to the handheld unit. At this time, the data is formatted into screens appropriate to the device that requested the data. The data is passed back to the wireless server provider gateway, and then delivered to the handheld device.

Wireless application servers must be device- and network-independent
The wireless application server must be able to work with any of the networks offered by Wireless Application Providers. The application server should be:

  • Easy to install, configure, and expand with new services
  • Easy to integrate with other servers and back-end systems: Integration is one of the key steps for a successful implementation of the wireless project. The API of the institution's existing system must be reliable and secure.
  • The client application must be easy to install and customize, and add new handheld devices onto.

Open systems
The application server also must be an open system, using standard protocol to make it easy to add or change services, add or change devices, and apply customizations.

What about screen scraping?
Screen scraping is one method that cannot be recommended as a final solution. This is a technique by which screen content is captured and transferred to a wireless device. Itís always a short-term solution, due to the necessity of constantly updating the macro reader when fields are changed in the source document (Web site). This leaves more room for error. Screen scraping does have the advantage of quick implementation, when used appropriately for data presentation, in the proof of concept stage. But there is a temptation to use it more broadly which may stem from a common misconception -- that the wireless world is simply an extension to the Internet.

The most effective way to build a wireless application system is to connect into the back-end system, regardless of type. It might be a mainframe, a client server, or a even Web-based system, using a direct connection via an API.

Connecting to the back-end system

Security and wireless banking and trading
Security is a key issue in wireless banking. A recent study on wireless banking security uncovered worrisome statistics facing both wireless banking innovators and online banking establishments: 85% of respondents worry about online security, including when making credit card purchases. More than 90% were concerned about revealing personal information like social security numbers online. And their fears are not groundless: More than 90% of proprietary cryptography has been broken. Cell phone systems have been hacked. Wireless banking and trading is clearly a more attractive target for hackers than many other wireless services.

When data is flowing through a vulnerable environment, many of the available operating systems for phones and handheld devices offer little or no security. Most security violations occur within the financial institution or the service provider. Customizing wireless security is extremely difficult, especially given the limited computing power on handheld devices.

Wireless security

Double key secure authentication is one of the protection methods used to verify access across different systems. Double key secure means the user must authenticate two systems -- the application server (at the hosting service provider) and the financial institution. The transaction is authorized only when both locations agree.

Secure network architecture is achieved when all interaction points and data paths traveled are created using double secure keys. Itís been proven that this method can drastically reduce violations and system hacking internally and externally, because all three parties must agree.

One of the more common security systems used is PKI (Public Key Infrastructure), an encryption used for PDA and smart-phone security. PKI consists of two keys -- a public key and a private key -- used to authenticate the user and encrypt the data. In addition, the financial institution should utilize the system to monitor access logs and flag questionable connections on the application server.

Encryption is a tradeoff between speed and security. A good rule of thumb is to encrypt on a 32-bit CPU at the rate of 10 CPU clock cycles per byte. Look for the most compact software. It should run under 5,000 bytes of memory. Encryption can vary from one device to another, depending on the platform and the operating system. For additional protection, authentication can be implemented with user IDs and passwords.

The challenge
The implementation of wireless banking is demanding. There are constantly changing standards for APIs, gateways, security methods, screens, operating systems, and browsers. There are also varied capacities for the handheld devices themselves as well as differing bandwidth requirements.

Wireless banking can be risky, lengthy, and complicated to develop. APIs (interfaces) must be designed to connect to existing backend systems. Application servers must be able to accommodate all protocols and all devices. You never know which device the end user is going to use. Application servers must also be able to communicate with all gateways, such as WAP, GSM, two-way paging, etc.

Because wireless banking is still in an evolutionary stage, it's imperative to keep up with technological breakthroughs, new products, and development tools to ease the transition.

The wireless network must be both device- and network-independent. Most handheld devices have their own standards to deliver data over data channels. End users should be able to customize screens, alerts, notifications, and messaging services easily. The system should be able to send notices to users as necessary, regardless of device type. Scalability is a major issue. Selecting the right platform for the application server will dictate the tools available to work with. The wireless banking system must be an open system that can be reliably integrated with new gateways to the backend system. This is a challenge not many banking institutions should undertake on their own.

The next best thing is outsourcing the development of the project, the implementation, and the hosting. Using a third party to administer and host the system is a viable option.

Selecting the right application vendor
The vendor must have developed and installed wireless financial systems and should have a wide range of experience. Look for the following characteristics when choosing a vendor:

  • A trusted name and longevity
  • The vendor should have tested and used the product in a field specifically related to yours. For example, wireless trading is more demanding than wireless banking. Wireless trading is time-sensitive. Stocks, options, mutual funds, and bonds are all different services that require different tools to process orders. The system must be able to deliver data quickly and flawlessly to any handheld device. Wireless trading requires research capabilities. It's much more active in delivering user alerts like watch lists, quotes, and charts. Wireless trading may employ external systems to gather data. The point is, be specific when dealing with application vendors -- not all financial services are the same.
  • The testing and quality assurance stage must take place as early as possible to certify the systems. The application(s) must integrate fully into the backend system(s), regardless of device type or platform. Management of all user definitions, events, requests, updates, changes, and requirements must be tested thoroughly.
  • Application servers must include monitoring tools and protocol management of all requests.
  • A turnkey solution is an end-to-end solution. It goes from the backend system, where the data source resides, to the API connection, to the application server, to the WSP gateways, and then to the handheld units.
  • The vendor should have widely available resources and experienced programmers, systems architects, and project managers. Additional manpower must be available immediately if needed.
  • References and physical site visits are key in understanding the consulting, development, and hosting environment. The consulting company will be an extension of your business. This is the life link between you (your system) and the customers who will use your services.
  • Backup and catastrophe planning must be in place.
  • The wireless application system must be network- and device-independent. The application should be fully configurable with customizable screens using standard APIs. The wireless application server must be an open, modular architecture, to provide the user with the maximum flexibility and extensibility to ease development and deployment.
  • Development tools to enable you to make changes, add services, or deploy applications are crucial.

The road to a successful implementation
Remember, wireless users will not be able to multitask using handheld devices; therefore, easier navigation will play a major role in the success of the project. Itís crucial to test all usersí functionality thoroughly, no matter how tight the schedule is for implementation. Depending on the type of network to be implemented, the number of markup languages, and handheld devices to be supported, testing can be cumbersome and complex. It's always a good idea to use multiple software development tools to test for real-world users. The financial institution should make use of the following steps for implementation and testing:

  1. Documentation, documentation, documentation!! (in this order). Document all rules, procedures, and specifications.
  2. Set up the application network environment as early as possible. Start with high-level conceptual and visual design.
  3. Run traffic studies on bandwidth required to communicate between the backend system and the middleware system (application server) and gateways.
  4. List all user functions and requirements.
  5. Perform a user analysis.
  6. Perform a technical assessment.
  7. Hold user group meetings.
  8. List business requirements.
  9. Define functional requirements.
  10. Define the performance requirements of hardware and software.
  11. Use a standard API like MQ or OFX (common in the banking industry), or develop XML API, which is becoming more popular.
  12. Design business performance and process requirements.
  13. Develop a delivery plan.
  14. Build a proof of concept to test all system functions and requirements. Test APIs and architectural designs of the applications. Integrate with the data source (existing system) directly.
  15. Start with a pilot (limited users).
  16. Fix bugs and fine tune system performance.
  17. Implement the full-scale rollout.

The future of wireless banking is massive and aggressive in terms of requirements, demands, and support. The percentage of subscribers with Internet-ready handsets will quadruple over the next year. By the end of 2001, it is estimated that the number of wireless users will reach 128 million. The good news is, itís great for financial business, but we must be cautious about how we implement systems to deliver reliable service.

Wireless media is challenging -- many variables are not yet under control; coverage is a big hindrance; legacy systems with different topologies and different platforms make things even tougher. There will be more streamline markets demanding new ways of conducting transactions.

Wireless banking and trading is growing in leaps and bounds. Jupiter Research expects 18 million more people in the United States to become wireless subscribers this year, bringing the total number to 128 million. Moreover, the percentage of subscribers with Internet-ready wireless handsets will quadruple.

Despite millions of new users, the wireless market can expect some real challenges in the near future. "While penetration of wireless data services will gain momentum in 2001, a lack of substantial new technology deployments in the United States will stifle true innovation. Location-based services, high-speed networks, and highly sophisticated handsets will remain elusive in 2001." Wireless banking is security sensitive and it's essential to find the right balance between speed and encryption.

Accuracy, consistent availability, and reliability of services are key to a successful implementation and to the survivability of the financial institution. Geographical coverage is imperative to successful implementation. The confirmation of transactions is key in showing a level of commitment and accuracy to customers.

Wireless banking is highly dependent on bandwidth efficiency. The more efficient the bandwidth, the faster content is downloaded. End-user requirements are driving a demand for faster transmission and higher bandwidth capacity.

In order to offer an enterprise wireless solution, major consortiums must break political barriers and agree to a global communication format. They must arrive at a solution that allows access across platforms and networks regardless of device type, much like the Internet.

Financial institutions are between a rock and a hard place. They would like to extend their services to the wireless world, but they lack the resources and expertise to implement and deliver to their customers in a timely manner. Therefore, outsourcing can be a vital option for the following reasons:

  1. The financial institution can focus on its core business.
  2. Product offerings can be made in a timely manner and get to the wireless marketplace sooner.
  3. Outsourcing will help predict costs better and allow more accurate budget forecasting.
  4. Obtaining and using the latest technology. WebSphere middleware application server provides the following benefits and functionality:
    • The financial institution can extend the reach of its product to new markets in a much shorter time.
    • Communication with handheld devices can be done seamlessly to access data and applications.
    • Enhanced data transfer using the load balancing function can detect bandwidth capability and optimized data streams.
    • Reliable systems processing and commanding encryption.
    • Sophisticated monitoring tools
    • Development time is greatly reduced.
    • Scalable open architecture using XML and XSL standards
    • Integrates easily into backend systems like mainframes and client servers.
    • Unmatched product support
    • End-to-end solution

Wireless banking and trading must be a virtual and global solution. Competitive forces will shape the wireless banking industry and help deliver end users what they are asking for. Wireless banking will have to reach a global standard before it can unleash its greatest potential.


About the author

Rod has over 11 years of experience in systems integration and wireless consulting, including extensive background with integrating mission critical systems. He holds a Masters of Science in Business, focusing on business technology and wireless communication from Central Michigan University, and a Bachelor of Science in Electrical Engineering. Rod was issued a patent in wireless technology in May, 1999. He can be reached for questions at

PDF - 278KB e-mail it!
What do you think of this article?
Killer! (5) Good stuff (4) So-so; not bad (3) Needs work (2) Lame! (1)

  About IBM  |  Privacy  |  Terms of use  |  Contact