Australia: Payment perils: Electronic payment fraud and bank liability to commercial customers

Key Points:

Banks should keep security measures up to date, inform customers about optional fraud mitigation measures and have clear forensic and legal procedures where a potential fraud is detected.

The recent decision by the United States Court of Appeals in Patco Construction Company Inc v People's United Bank is an interesting study of the difficulties that can arise when fraud risk allocation is not properly addressed by a bank and appropriate measures are not implemented when a potential fraud is detected.

The decision turned on the interpretation of Article 4A of the United States Uniform Commercial Code and in particular the Code's requirements about the "commercial reasonableness" of security procedures for payment orders issued to a bank by commercial customers.

In Australia, there is no equivalent to this Article 4A requirement. The risk allocation between banks and commercial customers for fraudulent payment instructions would be dealt with in the contract with the customer, subject to the Code of Banking Practice and the Australian Consumer Law, where applicable. But the decision is nevertheless of interest because it highlights how the "best practice" benchmark in payment fraud prevention is constantly changing, and the types of issues that could arise where a bank has not adequately addressed its exposure in its contract with its commercial customer.

The fraudulent withdrawals

The dispute arose because unknown third parties initiated a series of fraudulent withdrawals in May 2009 totalling US$588,851.26 by supplying the proper user ID, password and other credentials of one of the customer's employees. The bank was able to recover or block US$ 243,406.83, leaving the customer with a residual loss of US$345,444.43.

The fraudulent withdrawals were very different in size, type and frequency when compared with the customer's usual withdrawals. The customer used eBanking primarily to make weekly payroll payments to employees. Its instructions originated from a single static IP address, and had not exceeded approximately US$36,000 prior to May 2009.

In contrast, the five fraudulent withdrawals were considerably larger, ranging from approximately US$56,000 to US$115,000, and were effected almost daily over a period of seven days from an IP address other than the single static IP address from which the weekly payroll instructions originated. Each of these transactions generated high risk scores, but the bank proceeded with them.

The Court's decision

The Court determined that the bank's security procedures were "commercially unreasonable" for the purposes of Article 4A of the Uniform Commercial Code.

The Court has left open for later determination by the lower court the question of what, if any, obligations Article 4A imposes on the customer. There are several issues that the customer still has to address in order to obtain any damages from the bank, including:

• Whether the fraud resulted from the customer's computers being infected with keylogging malware which enabled the fraudsters to ascertain and use the passwords, user IDs and other information that customer employees needed to supply when issuing payment instructions to the bank.
• Whether the bank offered the customer the option of receiving e-mail alerts regarding incoming/outgoing transactions, changes to the customer's balance, etc.
• Whether appropriate action was taken by the bank and the customer when the loss was discovered. The bank claims that the customer did not isolate its computers, stop using them, or forensically preserve their hard drives as it had requested. The customer disputes this, alleging that the bank recommended only that it check its system for a security breach using a third party forensic professional, which it did.

The bank's security measures

The bank implemented security measures in January 2007, including:

• user IDs and passwords;
• device authentication to identify customer devices used to access online banking, and identify when a new device was being used;
• risk profiling which gave the bank a risk score for every log-in attempt and transaction based on several items of data including IP address, device cookie ID, Geo location and transaction activity, when compared with typical transactions for the customer;
• challenge questions - on initial log-in users were asked to select three questions and responses, and on subsequent log-ins might be asked to answer those questions if a particular risk score or transaction amount threshold was exceeded on that log-in;
• transaction amount thresholds – the ability to set a dollar threshold above with a transaction would automatically trigger the challenge questions even if the user ID, password and device cookie ID were all valid; and
• subscription to the eFraud network, which allowed the bank to check features of its transactions (eg. IP addresses) against features associated with known instances of fraud.

Measures that the bank could have implemented, but didn't

The Court considered various measures available to the bank, including:

• offline authentication (eg. by telephone verification, email approval or separate confirmation by mobile phone);
• okens for multi-factor authentication; and
• monitoring of the risk scoring reports that the bank received as a result of the risk score given to the bank for each log-in attempt.

The failure of the bank to implement the above measures (when they became available) contributed to the Court's conclusion that the bank's security procedures were commercially unreasonable.

The triggers for challenge questions

As at June 2008 the transaction threshold above which challenge questions would be asked to advance the transaction was decreased from $100,000 to $1. While this move might be thought to increase security, it paradoxically increased the risk that the answers to those questions would be captured by keylogging.

The Court referred to evidence that best industry practice at the time was for challenge questions to be triggered only selectively, when unusual or suspicious activity is detected, thereby lessening the risk that the answers to those questions would have already been keylogged.

Lessons for banks

Several warnings and lessons emerge from the case for banks:

• Check the fraud risk allocation provisions in contracts with commercial customers: Does the contract make it clear that the bank can rely on instructions it receives in sessions initiated with a correct userID, password and other credentials, even if the instructions are not actually initiated by the customer?
• Ensure that security measures are kept up to date with evolving practice: Is the bank lagging behind industry best practice?
• Ensure that customers are made aware of any optional fraud mitigation measures available to them, such as email alerts.
• Ensure that there are clear forensic and legal procedures for dealing with customers and their computer equipment where payment security appears to have been compromised.

Relevance to consumer payments

The bank/customer fraud risk allocation in consumer payments is regulated, including by the EFT Code/ePayments Code (and relevant aspects of Card Scheme Rules in the case of credit card payments). As a result, the legal context differs from that of commercial payments. But the need to keep security measures up to date, inform customers about optional fraud mitigation measures and ensure there are clear forensic and legal procedures where a potential fraud is detected apply equally to payment facilities offered by banks to consumers.

You might also be interested in...

• Managing legal risks of online fraud

Clayton Utz communications are intended to provide commentary and general information. They should not be relied upon as legal advice. Formal legal advice should be sought in particular transactions or on matters of interest arising from this bulletin. Persons listed may not be admitted in all states and territories.