One of the topics I cover in my Banking Technology class at GSBC is the issue of privacy and security of customer data. It is one of the most important aspects of our jobs as bankers – to keep our customer’s data secure. Beyond any fines or penalties and reissuing cards and other hard costs related to fraud or a breach, the diminishment or loss of reputational risk is perhaps the greatest cost of all. If our customers lose faith that we can keep their data safe and secure, then the damage could be terminal. So, bankers go to great lengths to ensure that systems are secure from hackers or other bad actors. Perhaps for the very reason that banking systems are so secure, criminal elements shift their target from hacking banking systems to infecting customer computers with malware. More specifically, business customers. Why? Because business accounts are regularly executing wire transfers and ACH files, so it’s easier for a criminal to mix in their fraudulent activity amongst regular transactions. How does this all work? Step 1 is getting malware loaded on a computer at a business. Generally, this occurs when a user at that business clicks on a link and is unaware that malicious code has been installed on that computer. Generally, the malware is a form of key logger; essentially capturing a stream of characters representing everything typed on that keyboard. This data is sent to the criminals, who interpret the string and identify patterns of characters, much in the way that detectives used to “read” a typewriter cartridge. From this activity, they ascertain user IDs and passwords, even answers to challenge questions. Using this access data, Step 2 is logging in as a valid user. No hacking required; they walk in the front door. Once in, the criminals generally try to ascertain the amount and velocity of transactions that this user executes and what type of permissions they have. This allows them to create a fraudulent wire or ACH file that is not too far out of bounds for the activity that is typically executed by this user. Once a fraudulent wire or ACH file is created it is executed and the funds go to accounts that they control. The funds can then be sent to accounts out of the country. Does all this sound familiar? Of course, it is what we call “Corporate Account Takeover”. And there has been a consistent drumbeat of admonishment from regulators and compliance professionals to enact procedures and systems to remediate the threat of a corporate account takeover. Hundreds of thousands of dollars have been spent on systems to address this threat. In addition to the systems that may be in place, one procedure that should be followed is Dual Control. Yes, that’s been around forever, but it works. Dual control in this context simply means that two individuals with the appropriate authorities and permissions, who by the way do not have to work in the same physical location, must collaborate in order to submit a wire or ACH file for processing. One user has the create / edit permission but no verification permission. The second user has no create / edit rights, but has verification rights. This should include back-office transactions, branch transactions and online banking system transactions. In your service agreement with your customer you should stipulate how wire and ACH transactions will be verified. This can be handled with call back processes, security codes and authorized individuals. Why does this work? Institutions that enforce dual control should be able to see a fraudulent wire or ACH file submitted for processing, but not verified. The verification step is of extreme importance. No one should ever take this step until they have confirmed the validity of the transaction. All too often someone will verify a transaction without reviewing the details and confirming the transaction is legitimate which poses a risk to the FI and its customer. Properly trained employees should be able to catch these transactions and prevent them from leaving the bank. All institutions have the capability of enforcing dual control and should require it for their business customers as well. Encourage and highly recommend that your customers institute their own procedures that include dual control. Does your institution require dual control? If not, what is your rationale for not doing so? Most bankers I talk to that don’t require dual control usually have an excuse of something like, “It’s inconvenient for our customers”. Hmmm, I would think a $100,000 fraudulent wire would be much more inconvenient. I will never forget a bank CEO who shared with me how he handled a business owner that would not agree to a dual control requirement. He had a form letter that he would send to the recalcitrant business owner, which said effectively, “Your company has refused to implement dual control. Based on that decision, this letter is informing you that your decision is wrong-headed and dangerous. Dual control will absolutely protect your company against fraud but your refusal to use it leaves you open to financial loss and reputational risk. By signing this letter below, you acknowledge that our institution has no responsibility for any fraud or losses you incur.” What do you think a business owner’s reaction is to receiving that letter? Pretty bold, I’d say, but the CEO swears he had a 100% success rate of getting companies to agree to enforce dual control using that letter. Another aspect of loss prevention on wires and ACH files is your insurance policy. The question is not whether you have the dual control option but can you enforce its use across all business customers as a commercial reasonable security procedure. For those of you that would rely on insurance to cover losses under the Computer Systems section of your insurance bond, you might want to go back and read that section. It is possible that by not requiring use of dual control, you could be negating the insurance protection you think you have. In fact, another option you should strongly consider for businesses that regularly initiate wires and ACH files is the requirement that the business have their own insurance bond that covers computer crime. It should be noted that UCC4A states that a bank is not liable for a fraudulent transfer if 1) the bank has commercially reasonable security procedures in place and 2) the bank accepted the transfer in good faith and in compliance with their security procedures. If these two items are true, the commercial customer is on the hook and the bank is not required to make the customer whole. If the bank is not required to make the customer whole, there is no Bond loss – even if the bank wants to reimburse their customer for business reasons. It’s really simple, a) verify your system has dual control, b) enforce its use with business customers, and c) verify the insurance coverage related to computer crime for both you and your business customers. FNBB customers can speak with Delvan Irwin at FNBB Insurance Agency, LLC or their Relationship Manager if they would like to discuss or review their insurance coverage. You can contact Delvan at firstname.lastname@example.org or 601.953.8562.