Bank Frauds and Fallout: Practical Implications of UCC 4A-202

Social engineering has outpaced hacking in the cybercrime arena in terms of monetary losses for banks. In the latest FBI report[1], tech support or customer support has resulted in losses of over $3 billion in 2025 alone!

One of the most prevalent methods of this type of scam is a scenario where a fraudster calls a victim and pretends to be calling from a financial institution. The fraudster even spoofs the phone number of the financial institution and impersonates the bank’s customer support personnel pretending to investigate a fraudulent transfer. The fraudsters are so convincing they have been known to trick seasoned accountants, controllers, chief financial officers, and former bank employees.

Banks and customers rely on security procedures to protect their accounts. The goal of the fraudster is to gain access to the account by obtaining the username, password, and second factor token or multifactor authentication (MFA) token. The MFA token may be an SMS text to a caller’s phone, a physical RSA token with a rotating code, or an authentication app on the user’s phone. The callers are often convincing enough to obtain that code and then use the code to access a bank account and transfer money to another person or account.

When a fraudster can convince a customer to provide the MFA token, and a fraud loss occurs, who then bears the loss? Financial institutions, especially large ones, cannot be expected to review every single transaction for fraud. Indeed, the need to manually review transactions would slow commerce to a crawl. So, the practical implications seem apparent, but what does the law say about their liability?

Such transactions are covered by the Uniform Commercial Code (UCC), which has provisions specifically dealing with transactions initiated by fraudsters using social engineering techniques. Specifically, Article 4A-202(b) provides:

If a bank and its customer have agreed that the authenticity of payment orders issued to the bank in the name of the customer as sender will be verified pursuant to a security procedure, a payment order received by the receiving bank is effective as the order of the customer, whether or not authorized, if (i) the security procedure is a commercially reasonable method of providing security against unauthorized payment orders, and (ii) the bank proves that it accepted the payment order in good faith and in compliance with the security procedure and any written agreement or instruction of the customer restricting acceptance of payment orders issued in the name of the customer. (Emphasis added.)

The question is whether the security procedure, the MFA token in the above scenario, is commercially reasonable. The financial institution has the burden to prove the method was a commercially reasonable security procedure.

In cases in which the “reasonableness” of the security procedures was questioned, court have looked to the agreements between the parties. In All American Siding & Windows, Inc. v. Bank of America, N.A. ,[2] a Texas court reviewed the online banking agreement and noted that the customer “agreed that the authenticity of ACH transactions were to be verified using an ID, passcode, and digital certificate verification.”[3]  Based on the above and an affidavit from the bank which states the bank “follow[ed] the guidelines of the Federal Financial Institution Examination Counsel and requires multifactor authentication for its online banking customers,” the court concluded that the security procedures were commercially reasonable, entitling the bank to summary judgment.[4]

In a similar issue addressed by the count in Precision Comp. Servs. v. Newtown Savs. Bank[5], the court noted:

[A] payment order is treated as the order of the person in whose name it is issued if it is properly tested pursuant to a security procedure and the order passes the test.

…for most commercial banking customers, contemporary reasonable commercial standards of fair dealing require multifactor authentication.

… As noted by the FFIEC in 2005 in connection with internet banking, “[g]enerally, the way to authenticate customers is to have them present some sort of factor to prove their identity. Authentication factors include one or more of the following: Something a person knows—commonly a password or PIN … Something a person has—most commonly a physical device referred to as a token … Something a person is—most commonly a physical characteristic, such as a fingerprint, voice pattern, hand geometry, or the pattern of veins in the user’s eye.” (Emphasis omitted.) Federal Financial Institutions Examination Council, “Authentication in an Internet Banking Environment,” (2005), p. 7, available at http://www.ffiec.gov/pdf/authentication_guidance.pdf (last visited October 22, 2021).

In sum, banks are entitled to rely upon commercially reasonable measures to authenticate a user. The use of multifactor authentication is a commercially reasonable method of authentication. Indeed, the FFIEC requires banks to use MFA for authentication and allows banks to rely on such authentication as commercially reasonable security procedure.