CFO Gameboard: Can your controls withstand modern fraud?

AI is often highlighted as a technology that creates growth, efficiency gains and new opportunities in the finance function. But AI is also changing the threat landscape and creating new demands on the controls designed to protect the company against fraud. Based on a composite, anonymised real-world case, this article examines how attacks can be tailored to a company’s own projects and workflows, and what this requires of the CFO’s control environment.

Most companies have procedures for larger payments, such as additional approvals, telephone callbacks, verification of the supplier’s bank details or a requirement for approval from the CFO. These are well-known and tried-and-tested controls that have been incorporated into the daily workflows of many companies.

But what happens when the voice on the phone can be forged, the email comes from a compromised inbox, and the invoice contains accurate information about a project known only to a few people in the company?

Fraud and phishing existed long before generative AI, but generative AI can improve the quality, speed and scalability of a range of established attack methods. Attackers can clone voices, write convincing emails in flawless Danish or English, imitate the wording of specific individuals, produce credible invoices and analyse internal information to identify the point at which a payment appears most plausible.

An Accounts Payable employee is therefore no longer merely faced with a poorly written email from an unknown sender. They may instead encounter a coherent story that fits the company’s reality.

The key question is therefore not only whether the company has more controls or more approvers. The key question is whether the controls are based on independent sources of information. Controls may be separated between different individuals, while still not being independent from an information perspective. It is not sufficient for several people to review a payment if they are all assessing the same compromised documentation.

*The following is a composite case based on patterns and experience from working with finance functions. The case is not a reproduction of one specific incident, but a synthesis of several anonymised real-life incidents.

An international project and engineering company was in the process of making a major acquisition abroad. The finance function was handling confidential payments and costs related to the project, which was known to only a few people in the organisation.

One Tuesday morning, the company’s Head of Accounts Payable, whom we will call Maria, received a telephone request from the CFO. The voice and tone sounded like the CFOs, and the request fitted the current situation. A payment to an existing supplier had to be made that same day to avoid delaying an important part of the transaction.

Shortly afterwards, Maria received an email from the CFO in an existing project thread. The email contained the supplier’s name, project references, amount and an invoice as an attachment. Everything looked correct. The only deviation from previous payments was that the supplier’s bank details had been changed.

Maria followed the company’s procedure and called the supplier to confirm the change. She used the telephone number provided in the email and on the invoice she had received. The person who answered the phone confirmed the change and was familiar with the project, the supplier’s role and the payment in question.

The payment required an additional approval. The second approver could see that the invoice was linked to a purchase order in the ERP system. The purchase order had been created or amended by a user with the necessary access rights, so that it matched the current payment and the actual project. He had also been told that the payment was time-critical because of the acquisition. Since both the invoice and the purchase order appeared relevant, he approved the payment, and the money was transferred.

It was not until several weeks later that the real supplier contacted the company about the missing payment. A subsequent review showed that the email communication had been compromised and that the bank details had been changed in the fraudulent correspondence. The purchase order and the additional approval had made the payment appear legitimate, but none of the controls had actually validated the information independently of the compromised communication.

At first glance, this could look like a classic Accounts Payable error. An employee accepted new bank details, a large payment was processed quickly, and a second approver failed to ask enough questions.

But the case is more complex.

The attack exploited several layers of the company’s control environment at the same time. The telephone call created the impression that the request came directly from the CFO. The compromised email thread made the enquiry relevant and credible. The fraudulent invoice contained accurate information about a real project, and the change to the bank details was confirmed using a telephone number from the same compromised communication.

At the same time, the created or amended purchase order gave the payment an additional layer of legitimacy. When a transaction has an invoice, a purchase order and an approval, it can appear correct in the system, even if the individual elements are based on the same manipulated narrative.

The case therefore does not necessarily show that the company lacked controls. The employee followed the procedure, the payment was approved by two people, and the documentation was present in the ERP system. The problem was that several controls were based on the same information. Since the email thread, the telephone number and the underlying payment details had all been compromised, the controls provided a false sense of security rather than genuine, independent assurance.

Modern fraud attacks do not necessarily require entirely new controls. Traditional controls remain important, but they must be designed for the threats the company actually faces. An additional approval, a callback, segregation of duties, restricted user access and controls over supplier master data are still fundamental elements of a strong control environment. However, they only work if they are independent and genuinely validate the action to be carried out.

Here are three principles to rely on:

• Independent verification
  A callback to a telephone number from the received email is not an independent control. When bank details are changed or large payments are made, verification should be conducted using contact details already recorded in the supplier register, a contract or another independent source.

• Resilience to time pressure
  “Time-critical” should not mean that controls can be bypassed. It should mean that the payment is escalated according to a defined procedure and that any exceptions are documented.

• The authority to stop
  Employees must have the authority to stop a payment if something appears unusual, even when the request comes from a manager or refers to a telephone conversation with the CFO.
  

AI can also help strengthen the control environment by identifying changes in suppliers’ bank details, unusual amounts and payment patterns, or atypical links between users, suppliers and approvals. However, AI cannot determine on its own whether a payment is legitimate. The technology must therefore be combined with clear roles, competent employees and a defined escalation process.

The best solution is not necessarily the one that automates the most decisions, but the one that helps employees ask the right questions at the right time.

When fraud is analysed after the event, responsibility is often placed on the employee who failed to detect the attack. This is rarely a sufficient analysis. An employee may have followed the existing procedure, contacted the supplier, obtained an approval and ensured that the documentation was present in the ERP system.

The key question is therefore not only why the employee failed to detect the fraud. It is also whether the control environment was designed to detect precisely this type of fraud.

Management should therefore regularly test whether controls work in practice and whether they are resilient to both technical attacks and human manipulation. This could include examining the following:

Data and verification

• Are callback telephone numbers obtained from an independent source?

• Can supplier master data be changed and used for a payment on the same day?

• Who can create or amend a purchase order, and how is it verified that the purchase order is legitimate and related to the specific payment?

• Can the company identify atypical patterns before the money leaves the company?

Roles and access rights

• Can a large payment be processed solely based on a telephone conversation with the CFO? If not, how should the request be verified?

• Are roles and access rights in the accounts payable process designed so that the same person cannot change supplier master data and process or support a payment?

Behaviour and escalation

• Are exceptions documented and subsequently evaluated?

• Are employees trained to handle enquiries involving pressure, urgency or authority?

• Is there a defined escalation procedure for when a payment deviates from the norm?

• Do employees in Accounts Payable have the authority to stop a payment, even if it is time-critical?

If the answers are unclear, this does not necessarily mean that the company is poorly protected. It is a sign that the control environment should be examined more closely. Fraud is rarely prevented by introducing one new control. It requires alignment between processes, systems, data, access rights, employees and management.

AI makes the task more urgent, but it does not change the fundamental need for clear roles, independent verification and attentive finance employees. In a world where a voice can be copied within seconds, the most valuable control may still be the classic one:

How do I know that this is the right person, the right supplier and the right payment?