Journal of Information, Law and Technology

Download 168.32 Kb.
Date conversion15.05.2016
Size168.32 Kb.
1   2   3   4   5   6   7   8   9   10   11

14: Solving the merchant’s problem without unfair contract

To solve the merchant’s problem, the banks need to invent an electronic equivalent of the cheque guarantee card, but without the features of the SET scheme which have hindered its adoption. An example of a possible approach is that the bank should certify a signature key for use by the customer for each account which the customer is authorised to use. The certificate would be signed by the bank with a signature key which the merchant could verify. The merchant would know from the certificate the value up to which the bank was thereby guaranteeing the customer’s account signature. The merchant could also be required to check that the bank had not revoked or suspended its certificate by checking the equivalent of a ‘hot card’ list. (The bank could suspend its certificate if funds or facilities were exceeded, to deal with the risk of a stolen signature key being used in a huge number of transactions.) The procedures for verifying the bank’s signature on the certificate, and for checking the fact that the certificate had not been revoked or suspended, could be made entirely automatic.
The appropriate liability régime for such an approach is equally simple. The bank must be bound to pay the merchant if the merchant has correctly verified the customer’s signature and the bank’s certificate for it. In the case where the customer claims that the signature was forged, the bank must carry all the risk (or all the risk above £50) unless it can prove the contrary. For this purpose, ‘proving the contrary’ must require positive evidence of the customer’s responsibility, not mere assertion that in the absence of any acceptable explanation discovered by the bank, the customer must be in the wrong.
Such an approach is open to the objection that it is easy for us to give away the banks’ money in this way. The answer to that objection is that taking this risk is what the banks earn their commission for. It is the central core of the function of banks in trade finance to bridge the risk between merchant and customer, and through bills of exchange and letters of credit it is exactly what they have been doing with great success for several centuries, despite the risks of forgery to which such documents are prone. Electronic commerce is a fresh opportunity for them to deploy their traditional skills in a new environment.
There is also a practical justification for this allocation of risks. Neither the merchants nor the customers can provide the technical infrastructure for electronic payments: only the banks can do so. Those who provide the technical infrastructure should carry the risks of its deficiencies: just as the banks decide how small an amount justifies checking the signature on a cheque, because they carry the risk of the decision, so the banks should carry the risk of forgery of electronic signatures. And in due course, if it is worth their while, the banks can subsidise the emergence of genuinely secure signature devices whose design can command enough public confidence to justify a modification of the liability régime. Among the essential requirements for public confidence is the abandonment of ‘security through obscurity’ and its replacement by an open and transparent approach; a further requirement is that the legal régime must be defined at the same time as the engineering approach that is claimed to justify it.
There is finally a legal reason why banks should not seek to allocate to consumers the risk of fraudulent use of their accounts. Regulation 5 (1) of the Unfair Terms in Consumer Contracts Regulations 1999 (SI 1999 No. 2083) provides as follows:
A contractual term which has not been individually negotiated shall be regarded as unfair if, contrary to the requirement of good faith, it causes a significant imbalance in the parties’ rights and obligations arising under the contract, to the detriment of the consumer.
We began by drawing attention to the fact that the bank and not the customer carries the risk of forgery of a cheque. That allocation of risk provides a benchmark against which to assess any alternative. Both where customer authentication relies on shared secrets, and where signature keys can be stored or used only in insecure systems, allocating more than a very small risk of fraud to the customer seems inescapably (in the words of the Regulations) to cause ‘a significant imbalance in the parties’ rights and obligations arising under the contract, to the detriment of the consumer.’
Regulation 8(1) provides that ‘an unfair term in a contract concluded with a consumer by a seller or supplier shall not be binding on the consumer.’ The Director General of Fair Trading is responsible for the enforcement of the Regulations, and has power to apply for an injunction to restrain the use of an unfair term. A copy of this paper has been supplied to him.
We also draw attention to the impact on such contractual terms of the Unfair Contract Terms Act 1977. The terms we have described are such that they attempt to place on the customer the risk of having his or her account debited with fraudulent transactions carried out by others, who may include bank staff or other persons who have gained access through the bank’s carelessness in the design or implementation of banking systems. These terms seek to permit the bank to escape responsibility for its own carelessness or even fraud, and are therefore treated as exclusion clauses for the purpose of the 1977 Act. The Act renders such clauses unenforceable unless they satisfy the ‘requirement of reasonableness’ as defined in the Act. And in permitting the bank to debit a customer’s account with unauthorised payments, such terms are arguably also rendered unenforceable on the ground that they permit the bank to render a performance substantially different from what was reasonably expected. We have explained above why we think these terms are unreasonable.
Where a term to which the Act applies fails to satisfy the test of reasonableness, for example because it would exclude the bank’s liability for its own carelessness, the term is unenforceable in all circumstances (whether or not the customer can prove that the bank was careless in the particular case). We think that a customer faced with a bank relying on such a term will have very strong arguments under the 1977 Act; and we take comfort from the similar views on this subject expressed by the learned editor of the 11th edition of Paget on Banking.

15: Nomenclature

We conclude with a few observations about the use of the term ‘non-repudiation’, which is often used in discussions of the issues addressed here, although we have not used it in this paper.

It is often (although not invariably) a desirable objective of a system to provide a non-repudiation service, either to prevent a signatory from falsely repudiating a genuine signature or to prevent the recipient of a message from falsely denying its receipt. Whether a particular system provides such a service, and the degree of its reliability, are matters for technical assessment.
If a system is believed to provide a reliable non-repudiation service, and is used in circumstances where legal consequences may follow the signing or receipt of a message, the contractual terms which establish the legal framework for the operation of the system may provide that what the system recognises as a valid signature shall bind the apparent maker, whether the apparent maker made the signature in fact or not; or that where the system records a message as having been received, the apparent recipient shall be treated as having received it, whether the apparent recipient received it in fact or not. Such terms may be described as providing for the non-repudiation of signatures or receipt of messages.
A technical assessment may prove that it is highly probable that a signature was made by its apparent maker. A legal assessment may hold that the apparent maker of a signature is bound by it whether the apparent maker made it or not. These two conclusions seem similar, but operate in different realms of thought. Debate about non-repudiation sometimes overlooks the distinction, to the evident frustration of the lawyers and engineers whose arguments pass through one another like angry ghosts. One object of this paper has been to bring about a fruitful conjunction of the legal and technical considerations involved.


Anderson R, 1993,‘Why Cryptosystems Fail’, Proceedings of 1st Conference on Computer and Communications Security '93, Fairfax, Virginia, USA, November 1993.

Anderson R, 1994, ‘Liability and Computer Security: Nine Principles’, Proceedings of European Symposium on Research in Computer Security, Brighton, UK, November 1994.
Beck J, 1995, ‘Sources of Error in Forensic Handwriting Examination’, Journal of Forensic Science 40 pp.78 87, 1995.
Dierks T and Allen C, 1999, ‘The TLS Protocol Version 1.0’. RFC 2246, January 1999.
Diffie Wand Hellman C, 1976. ‘New Directions in Cryptography’, IEEE Transactions on Information Theory, 22(6) pp.644 654, November 1976.
Harrison W, 1958, ‘Suspect Documents’ pp.373 426. New York: Praeger Publishers, 1958.
Hawkes N, 1998, ‘Machines Will Pay Up in the Blink of an Eye’, The Times , April 1998.
Kam M, Fielding G and Conn R,1997, ‘Writer Identification by Professional Document Examiners’, Journal of Forensic Sciences 42 pp.778 786, 1997.
Kam M et al, 1998, ‘Effects of Monetary Incentives on Performance of Non-professionals in Document Examination Proficiency Tests’, Journal of Forensic Sciences 43 pp.1000 1004, 1998.
Kömmerling O and Kuhn M, 1999, ‘Design Principles for Tamper Resistant Smartcard Processors’, Proceedings of USENIX Workshop on Smartcard Technology, Chicago, USA, May 1999.
Loscocco P et al, 1998, ‘The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environment’, Proceedings of the 21st National Information Systems Security Conference , October 1998.
SET 1999, ‘Secure Electronic Transaction’, LLC. The SET Specification. 1999.
1   2   3   4   5   6   7   8   9   10   11

The database is protected by copyright © 2016
send message

    Main page