<-Return To Hitlist 
Legal Issues in Internet Banking and E-Commerce

Legal Issues in Internet Banking and E-Commerce

by Denise McBurnie, Freehill Hollingdale & Page

Released June 1997

1. Introduction

This paper outlines some of the legal issues involved in the provision of banking services over the Internet. The focus here is on the possible exposure of banks and other financial institutions who use the Internet. This paper cannot explore all the possible risks which a financial institution may encounter. Instead, the paper will address some examples of possible risks and the legal mechanisms available for minimising and managing these risks.

Many lawyers and others find it difficult to understand and apply the legal issues involved in the complex and ever-changing technology which is used to deliver Internet banking services. It is not possible to attempt to explain or critique this technology here. What this paper will attempt to do is to compare the differences between transactions which occur over the Internet and traditional electronic and paper-based transactions with which we are more familiar.

So what are some of these differences involved in Internet banking? One of the most crucial features of the Internet is that communications are inherently insecure. A message sent from one computer to another may pass through a number of intermediate Internet Service Providers' or telecommunications carriers' facilities. In theory, there is nothing to stop these organisations from storing any information which they pass on along the network.

Practically, this means that an unencrypted message sent along the Internet has the security of a post card - an unknown number of people potentially have unrestricted access to its contents. The sheer volume of information carried via the Internet does provide some means of protection, since it is impractical to examine the contents of all messages.

Another consequence of the distributed nature of the Internet is that there may be many parties involved in the complete execution of an Internet banking transaction, and these parties could be located anywhere in the world. In a standard banking transaction, such as an over-the-counter transaction, only two parties are involved - the customer and the financial institution. Even in more complex transactions, such as a purchase made using the EFTPOS system, all of the parties are easily identifiable - principally, the merchant, the customer, one or more banks and one or more telecommunications carriers would also be involved because transactions are conducted electronically using the standard telephone system.

2. Defining technical standards and allocation of responsibility for network performance

Before analysing the technology and the responsibilities of the various parties who may be involved in an Internet banking transaction, it would be useful to describe some of the transactions that are encompassed within the term "Internet banking".

One Internet banking service that is provided already is access to account information, specifically balances and statements. Advance Bank has been offering this service for around a year, and the Commonwealth Bank has recently introduced its own Internet banking service.

Another service which could be provided by a bank or other financial institution is the transfer of funds between accounts belonging to one customer. A logical extension of this is to allow the transfer of funds between accounts belonging to different people - a service currently offered by the phone banking facilities of several banks.

But the full implications of Internet banking will only be realised when consumers are provided with electronic commerce capabilities - the ability to make purchases from merchants without any pre-existing arrangement, using credit or debit cards, or even "e-cash" - currency which can be exchanged electronically but which is not linked to a particular account.

Electronic commerce appears to be quickly gaining consumer acceptance. For example, it has been possible for quite some time now to book a hotel in New York from a computer in Melbourne by filling in a form on a World Wide Web site set up by a company in the Bahamas (where, according to the company, the regulations are sufficiently flexible to allow it to operate). The form asks for the requested booking dates and a credit card number. The credit card number is sent in plain text over the Internet.

Clearly such transactions carry some risk. These are just some of the issues that arise in this situation:

The merchant does not know whether the credit card number it has been provided with is genuine. Supposedly, this is not a serious problem because the services may not be provided until some time after the credit card authorisation is obtained.

Although the credit card number could be genuine, it is possible that the details on the card have been stolen. Whenever a credit card is used, all of the details on the card are recorded by the merchant. It is not unreasonable to suppose that some employees of merchants would use the card details for their own purposes. In such a case, the hotel booking company would probably bear the risk if it provides accommodation before the fraud is discovered.

The cardholder has no assurance that the merchant is genuine - that it is authorised to accept and process credit card numbers.

The credit card number could be intercepted in its passage over the Internet.

Several technical standards have been proposed to deal with these problems. One standard which has been implemented with a significant degree of support is SET - the Secure Electronic Transactions specifications. SET attempts to achieve several goals:

To allow a sender to be sure that the content of an electronic transaction can only be read by the intended recipient

To allow a recipient to be sure that the message was prepared by the sender and was not tampered with since leaving the sender's computer (through the use of electronic signatures).

To allow, through the use of electronic certificates and centralised Certification Authorities (eg: Australia Post), a consumer and a merchant to verify each other's identity.

To enable authorisation of funds without releasing information to parties who have no need to know that information. For example, a cardholder's financial institution would know that the cardholder wants a particular amount of money to go to a particular merchant, but the financial institution would not know what goods the customer is buying. Similarly, a merchant would know what goods are being purchased by a consumer, and that the financial institution authorises the expenditure, without knowing all details of the cardholder's account.

SET relies on public key cryptography: a system where every party has a pair of keys - a private key that is only known to that person and a public key that is distributed as widely as necessary. The parties who would have one or more pairs of keys would be cardholders, card issuers, merchants, banks and the certification authorities.

The information presented above shows the possible complexity of Internet banking transactions. Obviously, the liabilities and responsibilities of all of these parties needs to be considered when looking at the legal impact of Internet banking.

To analyse some of these responsibilities, it is useful to examine how information is exchanged between the parties to a typical transaction. Here is a simplified representation of such a transaction:


If the information does not reach a particular part of this system, who should be held responsible? This would clearly depend on the source of the failure, assuming that it is possible to establish the cause. Some possible causes relate to network down-time or a slowing down of network activity because a particular machine is inoperative. It could also depend on the number of users accessing a particular Internet Service Provider's facilities. Other possible causes for degraded performance are errors in network or interface software, or deliberate "denial of service" attacks on a particular Internet site.

A well-known example of this was a virus released over the Internet in the late 1980's by a University student in the US. The infamous "Internet Worm' virus caused the shutdown of a large number of computers in organisations all over the world. If the damage caused by this incident was substantial in 1989, a similar occurrence now would be catastrophic. Viruses are one contingency that financial institutions have to prepare for and which is not necessarily adequately addressed by encryption standards such as SET. These standards attempt to ensure that messages sent over the Internet are not interfered with, but they can do nothing about a failure of the message to arrive at all.

How can a bank or other financial institution protect itself in such an uncertain environment? There are some contractual steps that banks can take to avoid large-scale exposure. First, it is important to have a prudent approach in the promises that a financial institution makes about its Internet service offerings. This means that banks must avoid any promises regarding the speed and availability of the Internet banking service. This applies to contractual relationships with both customers and merchants.

Financial institutions must ensure that the exclusion clauses that are inserted into contractual agreements with both customers and merchants are drafted carefully so as to properly protect the financial institution without infringing relevant consumer protection and trade practices legislation. These clauses should also be specific and clear, because the courts tend to construe exclusion clauses strictly against the party who is seeking to exclude liability. For example, they should explicitly state that the financial institution does not warrant that a particular service will be available or will work efficiently. The clauses should also specifically refer to events such as viruses and network failures as events for which the financial institution accepts no responsibility or liability.

One point where a financial institution may also be subject to liability is in the provision of interface software. The current trend (at least in Australia) seems to be that a financial institution which wants to provide Internet services provides proprietary software for installation in the customer's machine which then interacts with the financial institution's systems (this is the case with both the Advance Bank and the Commonwealth Bank systems).

There are several quite valid reasons for providing custom-built software. It may enhance security, because the financial institution can specify exactly the way that the software interacts with information provided by the financial institution. The financial institution is also able to use proprietary encryption techniques which may be stronger than those available in generic software products (particularly if the products are sourced from the USA, which has strict encryption software export restrictions). The financial institution can seek to avoid the danger that the customer uses a piece of software which encourages fraud - for example, by sending PINs to unauthorised Internet addresses. Also, this approach allows the financial institution to have control of the way that the system presents information. This has clear marketing advantages - for example, the financial institution can ensure that its logo appears on any screen image and print-out produced by the program.

The provision of software to consumers can also result in additional liabilities being imposed on the financial institution. It would be hard for the financial institution to provide consumers with software and still exclude all liability for damage caused by that software. Damage to the customer could be caused by errors in the software or by dishonest programmers inserting code designed to intentionally defraud the customer and/or the financial institution. If the software is developed by an independent contractor, then the financial institution should seek to make the developer liable for malfunctions in the software. This is likely to be a heavily negotiated point in a software development agreement, because the financial institution will be attempting to cover its potential liability to its customers and other participants in the Internet banking transaction, while the software developer will be attempting to exclude or minimise its liability exposure.

There are several possible resolutions to this issue. The optimum one would be to ensure that errors of the type described above did not occur. Unfortunately, it is a fact of modern software development that all software will contain some degree of errors. To deal with the practical issues related to the occurrence of errors, the parties could negotiate a disaster recovery plan which would be put into action whenever a software fault is detected.

As for the ultimate issue of liability for the consequences of such error, a liability cap may be negotiated between the parties where the developer would only be a liable for damages suffered by the financial institution up to an agreed maximum sum. From the financial institution's perspective a liability cap should not apply in the case of code which is written with the intention to defraud the financial institution or a customer. It should also be the responsibility of the software supplier to supervise the code being written. To enable the financial institution to verify that the software does not contain a fraudulent malfunction, the financial institution should have the ability to access and verify source code. This is another point which could be contentious during the contract negotiation stage.

3. Consequences of and responsibility for unauthorised access to the system

The legal consequences of unauthorised access will ultimately depend on where that unauthorised access occurs within the Internet network. This is something which may be difficult to determine. Information can theoretically be intercepted at any stage during its passage from an Internet user to a financial institution.

A security breach within a financial institution's technology and communication systems could permit unauthorised access. This could happen by a person gaining access to those systems through the Internet or by modem and reading or manipulating account information. It could also occur by physical access to a financial institution's computer equipment. One critical aspect of a financial institution's defences is encryption. If the encryption software used by the financial institution fails to encrypt information properly, this failure could significantly compromise system security. It may also be very difficult to detect such a fault.

Unauthorised access to a communication can also occur while the message is being transmitted through the Internet. This is a particular danger for messages sent in plain text. Further there could be complex jurisdictional issues involved because the interception may occur outside Australia. There may also be complex technical problems in trying to trace the interception.

The legal implications for banks of this form of Internet interception will be discussed later in this paper. For the time being, it is important to note that the interception may in certain circumstances also constitute criminal activity under several different pieces of legislation. Some examples of such legislation are outlined below:

(a) Telecommunications Interception Act 1979 (Commonwealth)

The Telecommunications Interception Act 1979 prohibits the interception of a communication passing over a telecommunication system. There are exceptions for interceptions by mistake or under warrants.

"Interception" consists of listening to or recording, by any means, a communication in its passage over a telecommunication system, without the knowledge of the person making the communication. For these purposes, a telecommunication system is defined as the system or combination of physical facilities through or over which services can be provided. This legislation provides a remedy for improper access to line based telecommunication systems, PABX's and voicemail boxes. It would not apply to communications carried by means of radio-communications.

(b) Telecommunications Act 1991 (Commonwealth)

The Telecommunications Act imposes a number of prohibitions on carrier employees and service providers disclosing or using contents of communications. There are some specific exceptions.

(c) Crimes Act 1914 (Commonwealth)

The Crimes Act of the Commonwealth creates a number of offences relating to telecommunication services. It is an offence to knowingly or recklessly:

  • cause a communication in the course of telecommunications carriage to be received by a person or telecommunications service other than the person or service to whom it is directed; or

  • to tamper or interfere with a facility belonging to a carrier (here it is sufficient to prove that there has been a use of the carrier's facilities for an irregular purpose).

There are other provisions which relate to equipment used for unlawful purposes (in particular, unauthorised call switching and interception devices), and the connection of such equipment to a telecommunications network with the intention of committing an offence. The Act prohibits the manufacture, sale or possession of devices of this kind.

There is also a prohibition on any unauthorised access to a computer system, where the access is facilitated by means of a service provided by the Commonwealth or any carrier. If the unlawful access to data was obtained with the intent to defraud any person, or the access related to particularly sensitive data, the penalty increases. It is also an offence to use a telecommunications facility operated or provided by the Commonwealth or by a carrier, to intentionally interfere with data, the unlawful use of a computer, or to impede access to or impair the usefulness or the effectiveness of data stored in a computer.

In addition, there is some state-based legislation which attempts to deal with "computer crimes".

Another possibility is that unauthorised access is obtained through a security breach in the machine of an Internet Service Provider. As between an ISP and the ISP's client, whether such a breach would be the responsibility of the ISP could depend on the contractual arrangement in place between the ISP and its client but such a contractual relationship will not necessarily exist between a financial institution and those ISPs who may be involved in the transmission of an Internet communication. To minimise the risk to banks of direct liability to their customers and merchants, it is important for the financial institution to receive a written acknowledgment from each customer and merchant, stating that Internet transactions, particularly when sent without encryption, are inherently insecure.

In addition to possible contractual remedies there may be a number of other civil causes of action where the security of an Internet banking transaction is breached. These might include any one or more of the following:

  • negligence

  • trespass

  • breach of intellectual property entitlements (such as copyright and trade secrets); and

  • actions for misrepresentations

Each of these causes of action may provide a potential remedy against the person who either gains access to the system or communication or the person who allows such access or breach of security to occur.

It is possible that the software used by participants in an Internet communication for the purpose of effecting that communication may contain a weakness which also allows unauthorised access. Where this software is provided by a financial institution, then the financial institution may have to bear some responsibility for defects in the software or at least be exposed to potential liability. Where the software supplied by the financial institution was written by an independent contractor, the contract liability issues discussed above obviously become relevant.

Finally, the unauthorised access could occur because the user fails to protect secret information (such as their private key) or gives improper access to his or her software. Responsibility for these types of security breaches should clearly rest with the user, and this should be specified in any contractual agreement with the user. Additionally that user may be subject to liability in negligence.

All of these considerations rely on being able to identify at which point in the transaction chain the security breach occurred. However, actually establishing who is at fault will obviously be difficult, given the number of parties involved and the potential for such parties to be dispersed throughout the world.

4. Identifying and providing for the implications of force majeure events

One of the main functions of contract law is risk allocation. The basic principle of risk allocation is that the party who can best deal with a particular event should be the one who assumes the risk if that event occurs.

Force majeure clauses attempt to deal with matters which are beyond the reasonable control of either party, but which substantially affect a party's ability to deal with a particular matter. Some typical events which are incorporated in force majeure clauses are war, natural disasters and industrial disputes beyond the control of a party to the contract.

In the Internet banking context, "network malfunctions and failures" could be added to this list. As no specific organisation or entity is responsible for performance of the Internet as a whole, it is difficult to obtain or give any assurances about performance. On the other hand, poor performance can have disastrous effects on a business which relies on the Internet for fundamental commercial activities such as exchange and clearance of funds.

The consequences for a financial institution, if not disastrous, can be extremely unpleasant. For example, a financial institution may approve an unauthorised transaction because the information that a particular card has been stolen was not distributed quickly enough. Could a merchant take action against a financial institution because a bank, due to network downtime over which the bank has no effective control, fails to process payments, effectively preventing the merchant from processing orders?

These answers are best resolved between the parties during the formation of their contractual relationships. A properly drafted force majeure clause provides the parties to a contract with certainty by allocating the risk before a particular event occurs and specifying under which circumstances the parties agree that a network failure will constitute an event of force majeure.

Essential to any force majeure clause which deals with network failure is the definition of such failure. The distributed nature of the Internet means that almost all messages do arrive, but the time that this takes could be uncertain. Network performance could be defined by reference to specific performance criteria. For example, if a pre-determined message takes longer than a specified time to arrive from the sender to the receiver and the parties involved in the communication have no control over that time, then this could specifically trigger the force majeure provisions of the contract. Alternatively, the force majeure clause could simply refer to those categories of network failure which are beyond the control of the parties.

5. The unauthorised access of confidential communications

Correspondence passing between banks and their customers will often contain highly sensitive information pertaining to the financial affairs of those customers, information which is plainly intended by both parties to be kept in the strictest confidence. Any inadvertent disclosure of such information by the financial institution to a third party may, from the institution's perspective, be not only a breach of contractual and equitable obligations of confidence, but also, depending on the circumstances of the disclosure and the nature of the information disclosed could constitute:

  • negligence;

  • a breach of the financial institution's implied obligations to exercise reasonable care and skill in acting upon instructions and to observe confidentiality.

Any such disclosure may therefore give rise to substantial liability to the financial institution if damage flows from that disclosure.

The nature of the obligation

Obligations of confidentiality, whether arising under contract or in equity, will generally include an obligation not to disclose information to third parties as well as an obligation to keep information confidential

Such obligations, in their terms, attach liability in respect of conduct which involves no "disclosure" in the sense of an active or even inadvertent handing over of information. If a third party is allowed to acquire confidential information because the financial institution has maintained inadequate safeguards with respect to that information this may potentially be a breach of confidence. Depending on the circumstances, it may also amount to negligence.

Can the interception of an Internet communication give rise to liability for breach of confidence on the part of the sender? This would depend on whether sending the communication can be characterised as an "inadvertent" disclosure if the communication is, or in any event it can amount to a failure to keep information confidential sufficient to allow a remedy in equity or under the principles of negligence.

Conventional communication

Is there any justification in allowing different considerations to apply, for example, in the case of a facsimile transmission, a telephone conversation or a communication by conventional mail.

In the case of these other forms of communication, the sender has generally been well protected. It has never been the law that confidentiality will be lost simply because a letter ends up at the wrong destination through incompetence or intervention. It is arguable that the failure to send a facsimile to the correct address due to misdialing may be negligence, but this would be a different situation than, for example, a facsimile sent to the wrong address due to a telephone network error or a tapped telephone conversation. It can be argued that although none of the conventional forms of communication are totally secure, the mere fact that a communication may be intercepted does not render the disseminator liable for the direct or foreseeable consequences of that interception. This argument is based on the principle that a person should not be expected to effect protection against criminal behaviour. If confidential papers are stolen from a locked filing cabinet, the owner of those papers has not necessarily breached the obligation of confidentiality and can hardly be said to be negligent.

The difficulty is in how far these principles can apply to a medium as inherently insecure as Internet communications.

One complication has already arisen in the context of analogue mobile telephones. Because conversations on analogue mobile telephones utilise ordinary FM radio frequencies, it is well known that, from time to time, conversations will be overheard by third parties. Arguably, use of such technology may amount to negligence.

The reasoning applicable to mobile telephone communications is also readily applicable to Internet communications unless secure communication systems are used.

The contrary view could be put, that it is illegal to intercept Internet traffic, and it cannot be a breach of confidentiality or fiduciary duty to allow disclosure of information which is obtained illegally. This reasoning, assuming it to be correct, does not assist in, for example, a claim in negligence where the issue is whether there is a foreseeable risk which could be protected against by using a different and safer means of communications.


Another consideration in implementing electronic banking facilities via the Internet is the way in which a financial institution attempts to control the use and disclosure of personal information. Although the Federal Government has recently decided that it will not extend privacy laws to the private sector, the use of credit information is controlled by the Privacy Act 1988. Banks are already familiar with privacy issues in the context of lending. However, banks must ensure that their systems can adequately protect confidential information in all aspects of Internet banking. This is particularly important given a 1995 European Community Directive, which requires EU member countries to prevent transfer of personal data to countries with inadequate privacy protection safeguards.

6. Conclusion

As with everything else connected with the Internet, banking and electronic commerce on the Internet is changing rapidly. To properly advise their clients, lawyers must be able to understand the technology involved (particularly the structure of the networks) and must also be prepared to review and, if possible, adapt traditional legal principles in their application to this new technology.