Inspiration for this week’s post comes from the Far East, where the local operation of a Swiss bank was recently revealed to have been the victim of a $13mm dollar payment fraud.
Now fraud will happen, yet what makes this worth a second look is that it happened in such an obvious risk area, that it happened over a number of years and that it seems to me the kind of thing that with today’s tech tools, would be easily controlled for. This is all in the area of Operational Risk, OpRisk.
This particular case centres on something called a “Third Party Payment”. That means money being sent from Mr. Chan’s account that is not for the account and benefit of that same Mr. Chan. Typically, this includes anything not going to from a bank to another bank account for the same person and might include paying a bill, even for school fees.
Many moons ago, I was part of the Client Services team at Goldman Sachs, which served the normally wealthy clientele that maintained a brokerage account there. Every day, the analysts would review movements on their accounts from the prior day. Simple “eyeballing”. I don’t recall that we ever had a payment fraud. Of course, volumes were quite low, yet on the other hand the systems were not sophisticated. If memory serves me well, the analysts were simply reviewing a list of all account activity from the prior day and there was no exception processing as we know it today.
Now in today’s world, many payments are both electronic and initiated by the clients themselves or via cheque, or its equivalent in some countries, such as Switzerland, where the client sends the payments to processing centre as a batch. If we allow that there are proper controls in place for those processes, then what is left would be the exceptions which one might be interested in. These exceptions will all be manual payments, ones done other than by “Internet” or “Clearing Centre”, and there will for certain be an internal Userid associated with them. This means that the client sent in the payment in some means other than over the internet and asked for it to be made; a call or a fax, or even an old fashioned letter.
This happens and clients at all levels of wealth might do this. The issue at hand is what happens next; what are the lines of defence? I would suggest there are three.
The first line of defence is simply to avoid them; either by not accepting the payments at all and politely suggest the DIY approach and, or to price them at some exorbitant rate, such as $100 per ticket. That will deter some of the flow, but never all of it.
The next line of defence is the good old “four eyes” control aka maker-checker aka input release. This is a system configuration or rules issue. Any single payment entered should require separate people to input and approve. Now admittedly, this would still allow for fraud if there is collusion between employees. A way to avoid this, or at least try to, is to require a call back to the client to a known phone number. Known as in not the one on the fax or letter, but one that is on file. The person doing the call back and approval should be from a different team; again, take a configuration in your systems, but only a little.
The third line of defence is review. In the case cited above, the fraudulent activity went on over a period of years. This suggests a couple of things; either this bank had inadequate controls or the adequate controls were not properly followed. It also suggests that the client was not checking his, or her, statement either. Given that these manually entered payments ought to be rare generally and quite exceptional for any one account, then it would not seem too onerous to both generate an extract of these types of payment for review or to have somebody not involved in the process check them periodically. That check might look at who the input and approvers were; always the same? It might involve checking the paperwork, both for the client’s instruction and the call back.
Lessons Learned: 100% elimination of fraud is an unlikely nirvana. Good controls with the right kind of tools will allow the checks to be carried out efficiently and effectively. You need both; if the tools are inadequate, then the checks will be perfunctory and might miss something.
The right kind of controls will generate enough capacity and enable you to do it a reasonable cost. The 3C’s.
A personal request: The book of the Blog is in the works. Your support would be appreciated on two fronts:
- Please subscribe, if you don’t already.
- Please share this with a friend or two and ask them to subscribe too.
If the comments are wide of the mark and not offering anything of use, please comment or make contact directly via E-Mail.
Share on:
