Security of Alternative Delivery Channels in Banking

Electronic channels (internet, mobile devices, etc.) are an expanding medium, and financial institutions are seeking to provide customer service through these channels as a means of gaining a competitive advantage over competitors who are slow to accept the medium. With this in mind, the focus of this chapter addresses information security and assurance in an inherently insecure channel.


Statistics are provided to illustrate the speed with which the Internet has been adopted by customers, and that the most lucrative (wealthy) customers are among the most active users. As a result, providing service through the Internet channel is requisite - it is no longer so much an advantage to offer it as a disadvantage not to support customer demand for service though the channel, in spite of the inherent problems with security and information assurance.


The author goes into some detail about what "web baking" entails - to skip a lot of granular detail, it simply means that customers are enabled to use their own computer (or other networked device) to conduct any business with a bank that is accessible via other channels (branch office, mail), with a global network of ATMs substituting for tellers in the (increasingly) uncommon event of a need for hard currency.

Banks typically use a combination of a Web site that is developed in-house as well as using vendors to provision services to clients. Typically, ATM and credit card services are networked (and have been for many years) whereas account services (application and servicing of cash accounts and loans) is handled in-house. The difference can be seamless for the user, who can use various service with the sense they are dealing only with their bank.

A distinction is drawn between the transactional and non-transactional content of bank sites. Seems self-evident by the very names, so I'll skip the details, except to note that "transaction" deals with a financial transaction, not necessarily an information exchange (hence a page that is interactive is not "transactional" unless the result is a financial transaction).

When it comes to vendors, there are a wide array of service and solution providers, the chief difference being that a solution provider sells a product to the bank for its internal use and a service provider license its services to the bank and provides ongoing support (EN: the distinction is much more hazy than the author lets on - but let's accept his working definitions for the duration of this article).

Because all bank operations are highly similar (a credit card, auto loan, or mortgage "works" the same way at most banks), one solution can be developed by a third-party for use by many, which carries economies of scale. It also facilitates transactions among banks, given that their back-end systems are largely the same (e.g., customers of one bank can use the ATM operated by another).

The need for interoperability requires more than common products, but standards that will facilitate information flow across companies and channels. Thus far, banks have been supportive of common standards, as interoperability provides the flexibility demanded by customers (an attempt by a bank to create a proprietary system will not lock down customers ,but will run them off to competitors that are more open).


Financial institutions, more so than any other kind of business, have been an attractive target to thieves, and are increasingly cautious of being targeted for political reasons (terrorist or government attacks to disrupt a nation's economy). As a result, banks have been at the forefront of physical security and "should" maintain this posture in the Internet channel.

EN: the author uses "should" and I quite agree - presently, security is often foisted onto third parties, such as merchants that accept credit cards rather than the banks that issue them, and there seems to be a general sense that the banks have been less proactive than they might be due to the shift in liability to other parties.

Even so, there have been relatively few incidents (of note, a "slammer" worm that launced a DOS attack on the Bank of America ATM network and a bit of carelessness on the part of Barclay's that enabled an unauthorized person to use the "back" button to gain access to the account of another user on a public terminal).

Security and Privacy Issues

The need for system security for financial institutions should be self-evident, but the author rattles on a bit anyway. He presents some statistics that don't seem to make much sense out of context - half a billion in financial loss due to computerized banking (no clear basis for how that number was calculated, or an indication of what it includes, or how it compares to other kinds of loss by banks).

Customers are well-shielded against financial losses due to fraud and theft. Bank accounts are insured up to $200K and customers are liable only for the first $50 in fraudulent credit card charges. However, non-adopters of Internet banking express concerns that are more related to privacy than security: the desire to keep information about their account balances and spending habits private - protected from unauthorized access, as well as against misuse by parties who are authorized to have access.


Authentication relates to the assurance of the identity of a person as a means to prevent fraud (an impostor conducting financial business with another person's account, opening an account under another person's name, or opening an account under an entirely fabricated name). The "faceless" and anonymous nature of the channel facilitates this kind of activity.

In a sense, there are two instances in which authentication is necessary:

The use of a four-digit numeric PIN for debit and credit card transactions has long been accepted by consumers. And while it has been largely sufficient when coupled with the requirement to present a physical artifact (the card itself), it is laughably insufficient in the digital medium, where the security of a physical artifact cannot be relied upon.

The author lists a number of authentication methods (username, password, PIN code, smart cards, biometrics, personal data, etc.), and while he doesn't do into much detail, he recommends the use of multi-factor methods to provide a stronger defense.

Access Control

Another issue is access control within the organization - limiting access to financial data about customers and the ability to perform transactions to employees whose job functions require it. This provides a defense against embezzlement and insider fraud, and protects the privacy of the customer.


Non-repudiation refers to the need to parties involved in a transaction to abide by the terms of the transaction - for example, for a customer to honor the terms of a loan, for the bank to honor checks (or charges) authorized by the customer. This is a defense against false claims that a transaction was not authorized or not valid.

Much of this goes back to authentication - the need to identify the person responsible for a transaction - but it also depends on having valid support as evidence the transactions was authorized (a signed credit card receipt). The author doesn't provide a clear answer for this, just a quick mention of tagging transactions with date, time, and IP address and possibly requiring verification codes or digital signatures.


Integrity means maintaining the data consistency, ensuring that a request is received (and executed) as intended, without alteration.

Protection against unintentional alteration is largely a technical issue - ensuring the data is collected, transmitted, received, and stored in a manner that ensures fidelity.

Intentional alteration is more a matter of traceability: the ability to follow a transaction on its journey from customer to bank, knowing (by means of authentication) each party or system that had access to it in transit, and being able to trace any alteration to its source.


Financial data is considered to be among the most sensitive personal data, and banks are expected (and legally required) to ensure that only those individuals with a functional need to know have access to account and transaction data.

This is best achieved by access control, as well as the use of masking or substituting data in certain situations (providing a transaction code, rather than a card number, to be stored in a database)

General Threats

The author goes into various amounts of detail about security concerns that are not strictly related to financial services and banking, and that do not have any "special" concerns for this industry:

The financial services industry needs to be concerned about all of these issues, but there's nothing particular or idiomatic to banking as opposed to any other organization or industry.