# EUR 89 Million in Losses: What ICT Risk Controls Miss > SwissGRC explains what Austrian payment fraud data for 2025 means for ICT risk controls under DORA. Wire transfers caused 78 percent of losses, so internal audit should test controls such as callbacks and escalation, not only document them. - URL: https://swissgrc.com/ar/89-million-euro-loss-ict-risk-controls-dora/ - الناشر: SwissGRC® - تاريخ النشر: 2026-08-21 - آخر تحديث: 2026-09-17 ## معلومات أساسية - 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 made up nine percent of fraud cases but caused around EUR 89 million, or 78 percent of total losses. - Social engineering, in which victims authorise the payment themselves, was responsible for 83 percent of the wire transfer cases. - Under Article 6(4) of DORA, financial entities must ensure an appropriate level of independence for their ICT risk control function, following the three-lines-of-defence model. - SwissGRC names three control elements to review: the callback channel, the threshold logic and the escalation path. - SwissGRC recommends a simulated CEO fraud test case in the next ICS review round, owned jointly by internal audit and the payments team. 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. In short A recent fraud report shows that social engineering attacks on wire transfers are rare but especially costly. The lesson for the control landscape: documented controls such as the four-eyes principle say nothing about whether they actually hold up under time pressure. Effectiveness can only be verified through realistic testing, not through process descriptions alone. 89EUR million Losses from fraudulent wire transfers in Austria in 2025 Oesterreichische Nationalbank, cited by Meinbezirk.at 83% Share of wire transfer losses attributable to social engineering Oesterreichische Nationalbank, cited by Meinbezirk.at 3,000EUR Average loss per fraudulent wire transfer in 2025 Oesterreichische Nationalbank, cited by Leadersnet.at ## 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. For practice ## Key points - A few cases with high individual losses cause the largest share of total wire transfer fraud losses, not the mass of small fraud cases. - A documented ICT risk control function under DORA only covers social engineering if processes such as callbacks and escalation are regularly tested under realistic conditions. - Internal audit should include effectiveness tests for payment releases, rather than pure documentation reviews, in the next audit cycle. - Thresholds and callback requirements are only as robust as their actual enforcement under time pressure. FAQ ## Frequently asked questions How high was total payment fraud in Austria in 2025? The Oesterreichische Nationalbank recorded total losses 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 cases, yet caused around EUR 89 million, or 78 percent of total losses. What is the difference between the average loss in card fraud and wire transfer fraud? Card payments accounted for nine out of ten fraud cases, 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, which is why a small number of cases cause the largest share of total losses. Why does a documented four-eyes principle not reliably prevent social engineering? The person releasing the payment formally acts within their authority but is deceived by a fabricated sense of urgency. A control register only confirms the existence of the process step, not whether it is actually observed under time pressure in a concrete attack scenario. What role should internal audit play in reviewing payment releases? Internal audit should carry out a simulated social engineering test case for payment release in the next audit cycle, together with the payments team, evaluating actual response times and escalation paths rather than merely confirming the process documentation. Which three control elements show, in a real incident, whether a release chain holds? The decisive elements are the callback requirement for changed payment details via a second channel, the threshold logic for manual cross-checking above a defined amount, and an escalation path that allows employees to stop a payment without a breach of trust. Sources 1. [DORA – ICT Risk Management](https://www.fma.gv.at/querschnittsthemen/dora/dora-ikt-risiko-management/)Austrian Financial Market Authority (FMA) 2. [OeNB Report: Payment Fraud Caused EUR 115 Million in Losses Last Year](https://www.meinbezirk.at/c-wirtschaft/zahlungsbetrug-verursachte-im-vorjahr-115-millionen-euro-schaden_a8857823)MeinBezirk.at ## الأسئلة الشائعة ### How high was total payment fraud in Austria in 2025? The Oesterreichische Nationalbank recorded total losses of EUR 115.4 million for 2025, an increase of 17.6 percent over the previous year. Wire transfers accounted for nine percent of cases but around EUR 89 million, or 78 percent of total losses. ### What is the difference between average losses in card fraud and wire transfer fraud? Card payments accounted for nine out of ten fraud cases, with an average loss of around EUR 75 per case. For wire transfers the average was around EUR 3,000, and individual cases exceeded one million euros. ### Why does a documented four-eyes principle not reliably prevent social engineering? The person releasing the payment formally acts within their authority but is deceived by a fabricated sense of urgency. A control register confirms that the process step exists, not that it is observed under time pressure in a concrete attack scenario. ### Which control elements show whether a payment release chain holds? The callback requirement for changed payment details via a second channel, the threshold logic for manual cross-checks above a defined amount, and an escalation path that lets employees stop a payment without a breach of trust. ### What should internal audit do about payment releases? Internal audit should run a simulated social engineering test case for payment release in the next audit cycle, together with the payments team. It should evaluate actual response times and escalation paths instead of only confirming process documentation.