EUR 89 Million in Losses: What ICT Risk Controls Miss

The Oesterreichische Nationalbank recorded total payment fraud of EUR 115.4 million for 2025, an increase of 17.6 percent over the previous year. Wire transfers accounted for only nine percent of fraud cases, yet caused around EUR 89 million, or 78 percent of total losses. Social engineering attacks, in which victims authorise the payment themselves, were responsible for 83 percent of these cases. For ICT risk controls under DORA, this holds a lesson that control documentation alone does not reveal.

Why do so few wire transfer cases cause the largest share of losses?

Because the average loss per fraudulent wire transfer, at around EUR 3,000, far exceeds that of a card payment, and in individual cases exceeds one million euros.

According to the Oesterreichische Nationalbank, nine out of ten fraud cases involved card payments, with an average loss of around EUR 75 per case. For wire transfers, the average was around EUR 3,000, and in individual cases exceeded one million euros. Measured by transaction volume, Austria’s fraud rate for wire transfers, at 0.004 percent, is twice the EU average.

This distribution follows a pattern that is underrepresented in many risk registers: high frequency with low individual loss versus low frequency with high individual loss. Control catalogues calibrated primarily on case numbers tend to underestimate the second pattern, even though it accounts for the larger share of total losses.

What does social engineering have to do with DORA's ICT risk framework?

DORA requires an independent ICT risk control function, but this function primarily oversees technical and procedural controls, not the moment at which an authorised person releases a payment themselves.

Under Article 6(4) of the DORA regulation, financial entities must ensure an appropriate level of independence for their ICT risk control function, implemented through a separation of risk management, control and audit functions following the three-lines-of-defence model, as explained by the Austrian Financial Market Authority (FMA).

Social engineering undermines this structure without formally breaching it: the person who releases the payment acts within their authority, deceived by a fabricated sense of urgency. As described in ‘ISMS: People, Processes and Technology are Decisive’, a technical control is only as effective as the behaviour of the person operating it in a real incident.

Why does documentation fail to reveal a control gap?

Because a documented four-eyes principle looks complete in every audit file, but says nothing about whether it is actually observed under time pressure and a perceived sense of urgency.

A control register confirms the existence of a process step, not its effect in a concrete attack scenario. As the article ‘Risk Management Serves the Achievement of Objectives, Not Itself’ points out, a system fails its purpose when it looks complete on paper but has never been tested operationally under real conditions.

Only a targeted review shows whether a callback requirement for changed account details is actually observed, or whether exception approvals under time pressure quietly become the rule. This exact difference between documented and lived control often goes undetected in a standard audit.

Which specific control elements should be reviewed now?

Three elements are most likely to show, in a real incident, whether the release chain holds: the callback channel, the threshold logic and the escalation path.

These three elements can be reviewed individually and therefore provide more reliable statements than a pure process description.

• Callback requirement: Is there an obligation to verify changed payment details through a second, independent channel, and is this obligation checked on a sample basis?
• Thresholds: Are wire transfers above a defined amount manually cross-checked, regardless of time of day or a fabricated sense of urgency?
• Escalation: Can employees stop a payment without this being treated as a breach of trust towards an apparent superior?

What is the next step for one's own control landscape?

Internal audit should carry out a simulated social engineering test case for payment release in the next audit cycle, rather than limiting itself to confirming process documentation.

The idea behind ‘FINMA Supervisory Communication 05/2025 as a Wake-up Call for Resilience by Design’, building resilience into processes from the outset rather than reviewing it afterwards, applies directly to payment releases.

A concrete first step is a simulated CEO fraud test case in the next ICS review round, jointly owned by internal audit and the payments team, evaluating actual response times and escalation paths rather than just the process documentation.