10.12.2020

Phishing for payment: How Team New Zealand was scammed

Hackers often try to scam entities making international payments by impersonating one, or both, parties to the payment.

This is a simple yet subtle scam.  Although there are often signs that the impersonated entity is not legitimate, otherwise-sophisticated parties can be tricked into making payments to hackers.  America’s Cup defender Team New Zealand, for example, was recently scammed out of $2.8 million by a hacker who pretended to be a European television contractor, Circle-O, which was providing services to Team New Zealand’s events company.  Operating on the belief that the hacker was in fact Circle-O, Grant Dalton instructed Team New Zealand’s accountant to change the bank details listed for Circle-O to those of a Hungarian bank account provided by the hacker.  When Circle-O submitted its legitimate invoice, payment was made to the hacker’s account.

A recent case from England demonstrates the legal consequences of this type of scam.

K v A: the English approach

This case involved a scam perpetrated over payment for a shipment of Romanian sunflower meal.  The claimant, K, bought the meal from A, the respondent, via an intermediary, Vicorus.  A sent an invoice for US$1,167,900 to Vicorus, who was to forward it on to K for payment.  The invoice directed payment towards A’s (correct) Citibank New York account.

But Vicorus’ email account had been hacked. Although Vicorus’ records purported to show that it had forwarded A’s email to K, K denied ever receiving it. Instead, K received an email directing payments to a different account, at Citibank’s London branch. The destination account details referred to a further bank account, probably held by the hacker.  Later emails sent by A to Vicorus appear to have been intercepted by the hacker, and slightly different versions sent on from Vicorus’ email account to K.  K denied ever receiving the correct bank details.  When K instructed its bank in Riga to make payment to A, the payment was to the fraudulent account at Citibank London.

By late November, when A had not received payment, both parties suspected fraud.

Although Citibank repaid the funds so they could be remitted to the correct bank account, fluctuations in foreign exchange rates meant that A was unable to recover US$161,646.93 of the original sum. A then claimed those losses.

The Court’s opinion: when is payment made?

On appeal from the first-instance decision, K argued that on the true construction of the contract, its obligation was only to pay the price to the seller’s bank. That obligation was fulfilled by payment to Citibank, regardless of any account details. Because it paid the amount into the hacker’s Citibank account, it fulfilled its obligations to A under the contract because it paid the amount into a Citibank account, even though it was not the correct Citibank account.

The judge disagreed: he held that the contract clearly contemplated that to enable K to make payment, A would notify K of the identity and branch of its bank, and the destination account details.  Without those details, the payment could not be made.

The buyer is not the guarantor of the correct processing of the payment between the seller’s bank and its customer.  But the judge held that it was “obviously right” that payment has not been made if it was accompanied by incorrect destination account details, even where those inaccuracies were not the fault of either party to the transaction. To hold otherwise would lead to commercial absurdities.  Ultimately, A’s loss was caused by K’s use of incorrect account details when making the payment.

Our comments:

Both of these examples demonstrate the dangers associated with being the target of a phishing attack.  These attacks can seem subtle and difficult to detect, but they are in fact relatively simple.  Hackers do not in fact access the parties’ email addresses, but instead use newly-created, visually similar, email addresses.  It is therefore often possible to detect the scam, by carefully scrutinising the email address and other details. 

Under English law as demonstrated by K v A, payment is not considered to be made until the money has successfully landed in the recipient’s account.  A person who sends money to another account by accident will therefore not be considered to have paid the correct, intended, recipient.  The payer will remain liable for the original amount owed and will have to make a further payment to the correct recipient to avoid being in breach of contract.

Although this question has not yet arisen in the New Zealand courts, it is likely that the New Zealand courts would follow the English approach and would hold the payer, who had been scammed, liable for the original amount owed.  K’s argument, that its obligation was only to pay the price to the seller’s bank, not to the seller’s correct account, makes no commercial sense and has the potential to introduce significant uncertainty into any contractual relationship which involves payments being made.  Even though the alternative interpretation – that the payer’s obligation is to make payment to the correct account – has the potential to further penalise the victim of the scam, it is more commercially and legally sensible, and ensures that the payee is not left out of pocket.  However, as always, it remains important to check the precise wording of the relevant contract.

If you are drafting a contract for a transaction involving international transfer of funds, you may consider seeking to expressly allocate the risk of this type of scam.  These types of “cyber risk clauses” should consider the following points:

  • Place express responsibility on parties to have, or implement, procedures and staff training to minimise the risk of making payments as a result of this kind of scam;
  • Specify parties’ obligations to mitigate the impact of a cyber security incident;
  • Include a provision limiting or excluding liability in the event of a cyber security incident; and
  • If the intended payer is in a strong commercial position, consider including a provision which provides some form of relief in the event of a failure to pay because of a cyber security incident.

If you are making payments under an already-existing contract, there are several important things to remember:

  • Ensure that you are acting in accordance with your company’s cyber security protocols;
  • Check bank details against those you have been given previously;
  • If the intended recipient of a payment has given you new bank details, especially by email, pick up the phone and call the recipient to verify accuracy; and
  • If anything seems odd or out of the ordinary, seek verification.

If a misdirected payment has been made, the situation may still be fixable:

  • The payer should immediately contact the relevant bank, which may be able to place a temporary hold on the account;
  • Then, the payer should consider taking action against a range of parties. It should consider obtaining a freezing injunction over the scammer’s bank account, and should also consider taking action against the bank for security failures. 
  • Finally, the payer may be able to recover the money paid under its relevant insurance policy.

If you have any questions about the subject matter of this article, please get in touch with us, or your usual contact at Hesketh Henry.

 

Authors: Simon Cartwright; Lydia Sharpe

 

Disclaimer:  The information contained in this article is current at the date of publishing and is of a general nature.  It should be used as a guide only and not as a substitute for obtaining legal advice.  Specific legal advice should be sought where required.

 

 

 

Do you need expert legal advice?
Contact the expert team at Hesketh Henry.
Kerry_100x100 1
Media contact - Kerry Browne
Please contact Kerry with any media enquiries and with any questions related to marketing or sponsorships on +64 9 375 8747 or via email.

Related Articles / Insights & Opinion

“Recklessness” under the Health and Safety at Work Act 2015
The High Court has clarified the elements of the offence of reckless conduct in the Health and Safety at Work Act 2015.
When is someone ‘at work’ under the Health and Safety at Work Act?
The High Court has confirmed that to be ‘at work’ for the purposes of the Health & Safety at Work Act 2015 (HSWA), a link between the particular activity undertaken and the work of the PCBU is required. If that link is established, any person engaged in the activity will be 'at work' for the purposes of the HSWA.
18.02.2021 Posted in Business Advice & Health & Safety Law
English Supreme Court clarifies approach to determining the governing law of an international arbitration agreement
The English Supreme Court has recently clarified how the governing law of an arbitration agreement should be determined, where the agreement lacks an express choice of law provision.  In an area of l...
The High Court clarifies the liability of ‘officers’ under the Health and Safety at Work Act 2015
The High Court has clarified the due diligence duty imposed on ‘officers’ of a PCBU. Due diligence is not limited to obligations of governance, but will depend on the nature of the PCBU and the role the officer occupies in it.
17.02.2021 Posted in Business Advice & Health & Safety Law
Employment Law Considerations for Buying or Selling a Business
The people in a business often make the business, so if you are planning to buy or sell a business, it is important that you understand your employment law obligations in relation to employees.
17.02.2021 Posted in Business Advice & Employment Law
Construction Contracts Act Enforcement Costs
Cubo Projects Ltd v S&S Import Solutions Ltd
17.02.2021 Posted in Construction Law
Employment Court Deems Uber Driver a Contractor
Although immensely popular due to its user friendly interface and low prices, the Uber Group is facing challenges to its business model worldwide.  Issues about the rights of Uber’s drivers have be...
12.02.2021 Posted in Business Advice & Employment Law
Send us an enquiry
For expert legal advice, please complete the form below or call us on (09) 375 8700.
  • This field is for validation purposes and should be left unchanged.
-->