Red Team Testing Part 2- Receiving Bank Activities

Fraud-Red-Team_Logo-Color

In the past twelve months, there is a brand-new focus on receiving banks becoming involved in reimbursements for financial scams.  First, we saw Zelle announce receiving banks would be responsible in 2023 for reimbursing selective impersonation scams.  Next, in the U.K., the Payment Systems Regulator (PSR) announced that financial scam reimbursement would be split between both the sending and the receiving bank.  And then in early 2023, we saw a successful lawsuit (subject to appeal) based on a large BEC scam loss. This is significant because Business Email Compromise (BEC) continues to grow at a clip of $2.7 billion per year in the U.S.  And for the most part, there is no reimbursement.  So, the companies that suffer these losses are trying to find ways to get their money back.

Let’s look at this BEC lawsuit and talk about what a good fraud red team could have done to save over $700,000 in a BEC lawsuit.  In 2023, the United States District Court for the Eastern District of Virginia found that the receiving bank involved in a large BEC scam was liable for the BEC loss ($558,868.71) plus $200,000 for punitive damages (1). Why the receiving bank?  Well, the sending bank probably showed they had commercially reasonable security, contacted the customer who said it was a legitimate transaction (this is the author’s assumption as it is not discussed in the court documents).  So, no cause of action on the sending bank.  So, the victim’s lawyer probably said, ‘let’s do discovery on the receiving bank and see if we can get the money back’.  And this is part of what they found (from the actual court documents):

  • Receiving bank opened a new personal account for the account in question and did not verify the address.
  • The inbound deposits from the BEC fraud victim to the receiving bank were ACH transactions with a NACHA code of CCD (business-to-business transactions) and sent to a personal account at the receiving bank.
  • The inbound ACH transaction amounts were anomalous for a personal account.
  • The inbound ACH transactions, because of the size of each transaction, should have triggered a new account alert.
  • Receiving bank had anti-money laundering software that detected anomalies and these anomalies were ignored.
  • The ACH inbound deposit name, Olympic Steel Inc., did not match the personal account name at receiving bank account.
  • Receiving bank alerts on hundreds or thousands of mismatched names daily.  Each of the four inbound ACH transactions alerted for name mismatch.  No one at the receiving bank is notified when these alerts are generated.
  • The owner of the receiving bank account tried to send two international wires, but the receiving bank was alerted by an OFAC control based on the destination of the wires.  Receiving bank declined sending the wires.
  • Receiving bank’s Compliance department started an investigation because of the declined wires.
  • Subsequently, the owner of the receiving bank account was still able to remove the remaining balances. 

Let’s look at some of what red team testing could have caught:

    • By testing the account opening (online and via the branch), weaknesses would have been identified.
    • By observing inbound traffic at this financial institution (FI) (the dollar amounts of the transactions may have been too high to have a red team create them), the red team would have discovered weak alerting for inbound transaction anomaly detection and that name matching and NACHA CCD code assessment was lacking (and by the way, the name matching and CCD checking was something the sending bank should have also done).  Why was a business-to-business NACHA CCD code going to a personal account?
    • The process for investigation was weak.  Once the wires were declined, the account should have been frozen until the compliance investigation was completed.

    This was a $758,000 weakness.  If the receiving bank has deployed a red team, maybe……  And be prepared for more receiving bank BEC lawsuits.

    We have to remember that most fraud controls have been focused on the sending bank activities.  Until recently, the receiving bank activities did not put the bank at risk (other than for standard AML concerns).  So, the online security team has little or no controls on sending bank activities.  But with the rise of money mule accounts and the shifting liabilities, this needs to change.  Red team testing is a great way to start assessing receiving bank activities for weaknesses.

    In the next blog, we will talk about more use cases for red team testing. And if you are looking to refer to the first blog in this series, we linked it here.

    Click here to learn more about Greenway Solutions and their Fraud Red Team services. If you are interested in how our team can help your organization, contact us today!

    (1) United States District Court for the Eastern District of Virginia, Studco Building Systems, LLC vs 1st Advantage Credit Union, Case No 2:20-cv-417, January 12, 2023. (Source)

    About the Author

    Since 2005, Ken has been in Online Security.  He was a Director at MUFG Union Bank, retiring in early 2019.  He helped shape the initial responses to the U.S. 2005 and 2011 FFIEC Regulatory Guidance to improve online security for US Banks.  He is an early adopter and has selected and implemented a number of online security products.   Ken was an advisor to the RSA eFraud Global Forum and a Program Committee member for the annual San Francisco RSA Conference.  He is currently on The Knoble Scam Committee.  He has recently published three white papers—one on the need to focus on online customer safety, one on online authentication and one on how to select a multi-factor authentication solution.  He has been blogging on consumer financial scams and focusing on when financial institutions offer reimbursement.  He also was the editor for the complete list of definitions of financial scams, published by The Knoble in 2022.  In 2019, he received the Legends of Fraud Award at the 3rd annual FraudCON conference in Israel.  He is currently consulting to banks and to online security vendors.

    Follow Ken Palla on LinkedIn.