Recently the UK has seen a massive increase in a fraud described as ‘spoofed email payment requests’. Its estimated to be over 500% up year on year and according to BBC sources expected to cost UK businesses over £200m in just 2016.
How does it work and how do you prevent yourself or your company becoming its next victim? Having personally been the subject of an attempted scam on Monday this week, I’ve done some research and think good ERP controls are the answer.
The scam works by the fraudsters sending an email that looks as if it’s from a senior member of your management team, to your finance team, requesting that they either change the bank details of a major supplier or make a payment into a specified bank account. It seems the fraudsters take real email from that management person and alter it before sending it back into your company. The one sent to my team for instance was aliased with my real email address but actually sent used a specially registered email domain as teccman.co.uk hoping the extra ‘C’ would be missed by the person receiving it. The domain and account was created on google mail that morning apparently by someone in the USA but in reality they could be anywhere.
Now fortunately my team spotted it having been aware of this type of scam through several of our clients in the past, so we have a informal rule about things like this. The fact they received it while I was in the room helped – had been missed though we could have been £50k+ out of pocket.
So simple but clever, your finance team think they are being helpful by making the change and by the time the payment is questioned or the supplier chases to see why their bank account has not had the money, its long gone for the account it was sent to. At that point you don’t have any way of recovery and your bank will say the responsibility is yours, as you authorised the payment.
How can you use Dynamics NAV to prevent this happening? Well first I’d suggest the following process rules:
1. Only pay into bank accounts setup against a vendor in Dynamics NAV. No exceptions, it has to be a vendor – you’re going to need to setup that vendor soon anyway.
2. Only use the suggested payments worksheet to compile your list of payments and the bank accounts they are going to pay into. That means that the vendor must have its bank account details setup on NAV. You should not be able to amend the bank account details on the worksheet, just select a different bank account for that vendor. Remember you can manually add lines to the worksheet if its not ‘due for payment’.
3. You export the bank payment details for the payment worksheet, import into your online banking system and send for payment without editing. You do not store bank account details for vendors in your banking system.
This means that what we now really need to control is the ability to setup and edit bank account details against vendors. In Dynamics NAV 2016 its simple to have one of the new authorisation workflows that approves any creation or changes but in previous versions you need to set the security roles so that only one role has the ability to edit the ‘Vendor Bank Accounts’ (T288) table and restrict that to a list of people who understand the risks.
In fact what we have done is amend our 2016 system so that the workflow means any bank changes not only have to be approved but that it makes a payment of just £1 into that account first. We then have a further approval process step in the workflow, that enforces confirmation that that £1 has ended up in our vendors account (we expect a phone call to ask why have you only paid us £1?) before we can make any further payments to that bank account.
If we want to give money away, we will find a worthwhile charity. I really resent these criminals getting significant reward for just sending a few emails. If this heads up prevents just one company (or individual) getting taken it was worth it.
