E - BANKING By Pritam Potnis Mahesh Narayan Why E-Banking
• Push - competing for deposits forces banks on-line
• Pull - customers are becoming more sophisticated, have more options and are demanding more services
Generally identified are the following four components:
Navigation refers to the websites ease-of-use.
Performance of the website is a technology-driven issue, ensuring that even a customer with a low-speed Internet connection can get information/conduct a transaction in a reasonable amount of time.
2) Contents & Services
Contents & Services comprises the information (stock quotes or market information), interactions (chat or calculation tools) and transactions (banking or brokerage) the customer can obtain or conduct on the website.
Interface for connecting the bank's legacy systems to handle online transactions;
Integration of the online products & services with the bank’s existing
4) Enabling Functions.
Include partner management, marketing, and quality assurance.
The industry has identified many categories that are
potentially dangerous or risky for E-Banking websites
Bank one provides users with a method to retrieve account
information via a standard web interface. While the customer is
presented a secure and encrypted page, the mechanics of the rest
of the system are implemented in such a manner that they make
easy the most typical attacks. The convenience that the system
provides the user is that it enables the user to store his account
number, which is usually a credit card or debit card number of the
account holder, on the local disk. By failing to de-select the option
“Save Access ID on this computer for future logins”, the user
allows the system to write account number information to cookie
files. In future transactions, this number is picked up from the file.
However, this presents a great deal of insecurity to the user
because the cookie is stored as a flat file.
Bank One Online puts Customer Account Information at Risk
This example talks about some of the problems associated
with secure socket layers or SSL. While it is true that to
break a 64-bit encryption it takes two days, and that SSL
implements a 128-bit encryption, an intruder does not have
to break the encryption to get your account information.
An intruder can replace the IP address of the bank with the IP of his
evil system in the DNS entry of the name server. When you type the
URL of the bank, the evil system returns its IP address to you and
also open a session with the bank at the same time. There is a
secure connection between user and the evil system, and between
evil system and the bank. The evil system forwards the bank page to
the user and the user page to the bank, and all the while, copies
critical user information to itself.
Verify that the payment system you implement (even when outsourcing) deletes temporary data files with payment records and that the outsourcing entity has strict security and privacy policies as well.
Make certain server log files do not inadvertently store customer payment information.
Immediately report any security breach or loss of computer systems to police.
Only ask customers for information that is absolutely necessary to complete the transaction.
Encrypt sensitive data, like credit card account data, in databases. Encrypting uses cryptographic methods to scramble data so that only an authorized application in possession of a special key can read the data.
§Manage encryption keys. This includes all key management best practices, including obsolescence of keys and re-issuance of keys.
Privacy and security policies are important
steps in protecting consumers from fraud.
Companies should have both privacy and
security policies to ensure that there are clear
rules to which the company and its employees
adhere and that consumers understand the
operations of a company with which they
choose to do business. Developing a good
analyze its own information practices.
Today’s banking and trading institutions realize that they must
graduate from online services to wireless services. They are also
realizing that inertia in these areas, i.e. a resistance to change may
result in large amount of losses to these institutions. Additionally,
wireless banking may become the need of the hour of the end
customer. Though this entails surmounting of many technological
impediments, it nevertheless is a potential way of things working in
Unlike online services, where the end user is connected to
the Internet through a standard TCP/IP connection from a PC, in a
wireless connection, there are many more challenges. In wireless
services, airwaves are the main carriers of data, and the physical
location is of paramount importance in ensuring good quality of
The Gomez research institute estimates that the number of people
using internet and wireless services will increase from 8 million in
1998 to 40 million in 2003. This presents vendors with a
tremendous opportunity for growth and business.
A research by Jupiter Communications says that approximately 140
million people in the U.S will be having non-PC wireless access by
2003, while there will be 155 million landline PC accesses. This
means that the non-PC access will grow to 65% of the wire line PC
access within the next three to four years.
According to Forrester research, approximately 120 million
Europeans already use mobile phones, exchanging more than two
billion wireless text messages each month. Forrester predicts that
by 2003, nearly one third of the population of Europe will be
accessing wireless services. 90 percent of the 50 e-commerce executives interviewed by Forrester plan to launch websites that
are wireless accessible.
A major banking institution claims that having an online
banking customer base of 3 million, which represents more
than 20 percent of its customer base, continues to sign up
approximately 130,000 people for online banking ever month.
Additionally, 750,000 people signed up for the bank’s
electronic billing and payment service, and the total dollar
value of payments processed grew by 36%.
GartnerGroup predicts that by 2004, 8 percent of new
applications for consumer use will permit access from mobile
clients. GartnerGroup also estimates that more than 60 million
employees worldwide working outside the traditional office
Data System Backend
The different kinds of equipment that qualify for listing under this category
are: Thin client devices, palm pilots, workpad, two way paging devices like
RIM, smart phones and WAP phones. Each of these devices uses their own
gateway to communicate with application servers. Since each device has its
own method of formatting and presenting data, the challenge for the
application server lies in sorting out these devices and sending data to
each of these devices in a manner compatible to their representation.
Connectivity, Coverage and Gateways:
The handheld device accesses a local cell tower that is responsible for
delivering local geographical coverage in a certain region. The coverage is
segregated into hexagonal boundaries. The cell tower transmits the data to
a base station. The base station transmits the data to a mobile switching
center, which links all the base stations.
The wireless application server is the workhorse of the whole
wireless system. This is the place where wireless data is controlled,
rules are set for data processing and configuration files are
executed. The application server ought to be open ended, so that it
can integrate with other systems. The most popular and prevalent
method of communicating with the backend systems is using XML.
Transcoding is the process of formatting data using XML, XSL style
sheets and DTD files. Formatting information or data in this
manner enables the user to view the data in a universal manner,
irrespective of the device used.
At the application server level, the handheld device ID and
the user ID are stored for verifying logins. Once a login
request is received, the application server will make a trip
to the database to verify the authenticity of the login. The
middleware database prepares and formats the data for the
device that requests the login. The application server will
also compare the registered device ID to the user ID for
When the handheld device initiates communication, pull
technology is employed, where data is pulled from the
application server to the handheld device. On the contrary,
when the application serve has a control over the handheld
device, push technology is employed, in which case the
application server pushes data to the handheld device
without waiting for the device’s consent
Double key secure authentication is most often used for
verifying access across different systems. This is where the
user will authenticate at two levels, the application server,
and also at the level of the financial system. Only when both
authentications agree is the user granted access. In a
double key secure scenario, all data paths traveled are
verified by using double key secure. Another popular
method authentication used is the Public-Private key
A trusted name with an ensured longevity.
The vendor must have tried and tested the product in the same or
in a related area of application.
The testing and quality assurance of the product must be done as
early as possible to ensure proper functionality. New and evolving
systems must be backward compatible with existing backend
Management of all entities such as user definitions, events,
requests, and updates must be tested thoroughly
The vendor must have experienced and adequate technical
Contingency planning must be in place
The system must be device and network independent. The
application should be fully configurable with customizable screens
using the standard APIs. The application server must lend itself to
faster development and deployment.
There should be development tools to enable you to make changes,
add services, or deploy applications are crucial.
Document all rules and procedures
Starting with high-level conceptual and visual design, set up the
application network as early as possible.
Run studies on bandwidth required to communicate between the
backend system and the middleware system and the gateways.
List the requirements and functionalities of users
Perform user analysis
Perform technical assessment
Hold frequent user group meetings
List business requirements
Define functional requirements
Use standard APIs, like OFX and XML API
Measure performance and process requirements
Develop a delivery plan
Test APIs and architectural designs of the applications. Integrate with
the data source directly.
Start with a pilot
Fix bugs and fine tune system performance
Implement a full scale rollout