When people are hard pressed for time, the need for "anytime anywhere" banking gains utmost importance. Bearing this in mind, banks provide a novel service which gives retail customers account information and real-time transaction capabilities from their cell phones. In this article we understand a typical SMS banking setup

When people are hard pressed for time, the need for "anytime anywhere" banking
gains utmost importance. Bearing this in mind, banks provide a novel service
which gives retail customers account information and real-time transaction
capabilities from their cell phones. With SMS banking the following services
can be obtained:

• Get account balance details
• Request a cheque book
• Request last three transaction details
• Pay bills for electricity, mobile, insurance etc.

Part one of this two part series covers the SMS banking overview, the components
involved as well as the secure network architecture in SMS banking scenarios.

SMS Banking Overview

In order to avail the services mentioned above, a user subscribing to a wireless
carrier sends an SMS with a predefined code to the bulk service provider's
number.

The service provider forwards this message to the bank's mobile banking applications.
The mobile banking applications interface with the core banking servers (that
contain the user account information) that service the request made by the
user. The response is then sent by the mobile banking applications to the bulk
service provider who in turn forward it to the valid user via SMS.

There are two ways in which a bank can communicate with a customer using SMS:

1. In the first method the bank proactively sends data to customers in response
   to certain transactions. For e.g. account to account transfer, salary credit
   and some promotional messages. This data can be sent to the customer in two
   ways
   • E-mail to mobile (E2M) : In this method, the bank sends
     an email to the mobile banking application through a specific email address.
     This email may consist of the message content together with the mobile
     numbers of the customer. The mobile banking application in turn sends this
     message in a specific format (for e.g. XML tags are part of a HTTP GET
     message query string) to the service provider's application server. From
     hereon the information from the XML tags is extracted and sent as a SMS
     to the wireless carrier which in turn forwards this message to the customer.
   • Database to mobile (D2M) : Here a mobile banking application
     continuously polls the banks database server and whenever a relevant event
     happens, for e.g. an account to account transfer, it forwards the specific
     message to the service provider's application server. The message format
     may be the same as the one used in the E2M case. This message is then forwarded
     to the wireless carrier which in turn forwards this message to the customer.
2. In the second method the bank sends data in response to specific customer
   query such as account balance details. The customer first sends a pre-defined
   request code via SMS to the Bulk SMS service provider's registered mobile
   number. Depending on the message code, the bulk SMS provider forwards the
   SMS to a PULL application in the mobile banking server. The PULL application
   receives the request and forwards it to the core banking application for
   further processing. The core banking server then processes this message and
   sends the reply to the PULL application which in turn forwards in to the
   customer via the service provider. As in the above cases the request and
   the response for the PULL application may be a HTTP GET message with XML
   tags in the query string.

Secure Network Architecture for mobile banking applications

The following is a diagram shows a structural design for the mobile banking
scheme.

The 2-way SSL link between the service provider and between
the mobile banking application and the service provider and also between the
service provider and the wireless carrier ensures confidentiality of data.
The email message sent by the bank is PGP encrypted and signed in order to
ensure confidentiality and integrity of data.

The E2M component is placed in the mail server which
is present in the Internet Banking DMZ. It receives the email message from
the mail server which is then forwarded to the service provider in the specified
format over the SSL link. The D2M component in placed in the inner core-banking
segment as it continuously polls the banking database for event related triggers
as explained above. Finally the PULL component in placed in the Internet Banking
server as it receives the message from the bulk service provider through a
SSL link over the internet.

Summary

In this part of the SMS banking series we discussed the different components
in SMS banking and the secure network architecture including placement of the
different components in the infrastructure. In the concluding part of the series
we will look into the application security perspective in the mobile banking
application.