SMS Banking

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.

Fig 1: Mobile banking architecture

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.

In the above diagram 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 following diagram shows the recommended placement of the SMS banking components in the banking infrastructure.

In the above diagram, 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.