This piece is by Andrii Shevchuk, CTO & Partner, CONCRYT
It’s 20 months since the Digital Operational Resilience Act (DORA) became applicable across the EU, and regulators are now seeing where the reporting process is falling short. In mid-September, the European Supervisory Authorities (ESAs) published new operational instructions for national regulators handling major ICT-related incident reports under DORA. The aim is to improve the quality and consistency of reporting between jurisdictions.
Some details that firms must report are basic: what stopped working, for how long, what was the cause, and whether a supplier was involved. But those questions can take some unpicking when a transaction has passed through several providers.
The ESAs say incidents that began at a third-party provider have been difficult to report and analyse. Anyone who has worked in payments will recognise that, because each provider in the chain only sees its own part of a transaction.
A fall in approval rates could sit with the gateway, an acquirer, another provider further down the chain or an external outage. Fraud activity can muddy the picture as well – if all you can see is that approvals have dropped, there’s still a fair amount of digging to do, and I’d argue the gateway should be doing more of that digging for you. The first annual DORA incident report, which came out in June, covered 3,383 major ICT-related incidents reported across the EU financial sector in 2025. Payments made up 16% of the total and almost one in three incidents started with a third-party failure.
Where the delay happens
When a third party is involved, the reporting firm can be dealing with the effects of a problem while information is still coming back through the payment chain. Payments teams are used to that. They might have approval data in one place, fraud information somewhere else and provider updates arriving separately.
With card payments, every approval and decline comes back through the gateway, so when several providers are in the mix you can start to see when one is behaving differently from the rest.
This is one reason LLM technology is making its way into payment gateways: it can surface payment-performance insights and fraud signals in seconds. We’ve been exploring this capability in our own gateway. It helps teams investigate what happened and understand what it means, starting from the underlying payment data rather than a headline approval rate.
If approvals dipped on Tuesday, the payments team will want to know when it started, how many transactions were involved and what was happening across different providers, and compliance may need much of that same information later for a DORA report. Where an incident started with a supplier, DORA also asks for that provider to be identified by its legal name and identification code.
An initial notification can be due within four hours of an incident being classified as major, with an intermediate report due within 72 hours of the initial notification.
What should you be asking your gateway
Rising declines can come from fraud rules or from a fault somewhere further along the chain, and from the outside both can look similar. You need enough detail to work out which one you’re dealing with before you start changing anything.
Around 40% of companies put no direct or indirect costs against their incidents in 2025, according to the June report, and another 15% left the field blank. The ESAs point out that staff time spent dealing with an incident should be included, and in payments you can’t really start putting a figure on an outage without knowing how many transactions were hit and for how long.
If I were choosing a gateway or coming up for renewal, I’d want to know how quickly it could show me when approvals started to fall and which providers were involved, how many transactions were affected and over what period, and what it could show me about fraud-related declines versus technical ones.
If an incident began with a supplier, can the gateway provide that supplier’s legal name and identification code? And when somebody later has to work out what the outage cost, how much of the information is already there, and how much has to be pulled together by hand from several systems?
The next round of reports
I’d expect firms to get more demanding about this as they build up experience of DORA reporting. If a problem starts somewhere else in the payment chain, the regulated firm still has to understand what happened and complete its own report, and it can only work with what its providers give it.
The September instructions also mention cases where an incident reference number changed partway through, and final reports that never turned up at all.
Most of the information is already sitting somewhere in transaction records, provider data and fraud tools. Getting it in front of the right people while an incident is still running is where gateways, ours included, have more work to do, especially when operations and compliance are each looking at a different part of the same event.
The ESAs have said the instructions will keep changing as supervisors see more reports, and next year’s annual incident report should give a better idea of whether tracing third-party incidents is getting any easier.
Be the first to comment