Can a fraudulent SEPA Instant or real-time payment be reversed once it's confirmed sent?

Not by simply asking for it back. Once an SCT Inst payment settles — the scheme's own maximum execution time is 10 seconds — the sending bank's only lever is a formal Request for Recall by the Originator, which the receiving bank can accept or refuse, and which it has up to 15 banking business days to respond to. The scheme rulebook itself requires the sending bank to tell the customer this request is not a guarantee of getting the funds back.

Does this replace our DORA incident-notification obligations?

No, it sits alongside them. DORA's 4-hour initial / 72-hour intermediate / 1-month final notification timeline for a major ICT incident applies the same way here as for any other confirmed incident at a DORA-scoped entity — that full breakdown is covered in NIS2 and DORA without the consultant theatre and isn't repeated here. This post is about the containment and recall sequence that runs in parallel with, not instead of, that regulatory clock.

What happened to the old PSD2 incident-reporting guidelines — do those still apply to us?

For most banks, payment institutions, and e-money institutions, no — the EBA formally repealed its PSD2 major-incident-reporting guidelines on 17 January 2025, the date DORA became applicable, specifically to avoid two overlapping reporting regimes. A narrow set of PSPs outside DORA's scope, such as post-office giro institutions and credit unions, can still be subject to the old PSD2-style requirement under their national competent authority.

Is this the same response sequence as a ransomware incident?

No, and treating it like one wastes the minutes that matter. Ransomware sits still once it lands — the file stays encrypted whether you spend twenty minutes scoping or two — so a careful, evidence-preserving isolation is usually the right call, covered in ransomware response for an online casino: the first hours. A confirmed fraudulent real-time payment doesn't sit still: the exposure is largely fixed the moment the transfer settles, which is usually before your team is even looking at an alert.

Should we freeze the customer's account before we've confirmed the fraud is real?

Freeze the compromised channel or session first — the app login, the card, the API credential that authorized the transfer — rather than the whole account by default, unless account-wide access is itself the suspected compromise. A false-positive freeze on a legitimate customer's full account has its own cost and its own complaint-handling obligation; the point of the containment step is to stop the specific authorization path that was abused, then widen scope only if the evidence says the compromise is broader than one channel.

Incident Response for a Digital Bank: The Payment-Finality Clock

The short answer

A confirmed fraudulent real-time payment at a digital bank or payment platform is usually already settled — SEPA Instant's own scheme rulebook sets a 10-second maximum execution time — before an incident-response process can start containing it, so the response isn't a race to stop the transfer. It's a race to freeze the compromised channel before a second transfer goes out, file a Request for Recall with the receiving bank within the first hour while the beneficiary account is least likely to be emptied, and start the regulatory-notification clock at classification rather than at containment. The recall itself is not guaranteed: the receiving bank can refuse it, and has up to 15 banking business days to respond.

Who this is for

This is for the Head of Security, Head of Fraud, or on-call incident lead at a digital bank, e-money institution, or fintech payment platform who has just confirmed — or strongly suspects — that a customer's real-time payment channel was used to push out one or more fraudulent instant transfers, and needs to know what to do in the next hour. It is not the prevention layer: hardening the identity, API gateway, and network controls that should make this harder to trigger in the first place is covered in hardening a fintech payment platform: what comes first. It's also not the equivalent response for a different incident type or vertical — a licensed casino's ransomware event runs on a different clock and a different regulator, covered in ransomware response for an online casino: the first hours, and a crypto exchange's hot-wallet compromise runs on-chain tracing and OFAC screening instead of a bank recall request, covered in crypto exchange breach response: the first hours.

Why the clock here is different

Every incident-response sequence has an implicit assumption about what stays still while you work. Ransomware sits still once encryption finishes — the file is exactly as encrypted twenty minutes from now as it is right now, so a deliberate, evidence-preserving isolation is the right trade. A hot-wallet compromise moves on an open, traceable ledger, so on-chain tracing and exchange freeze requests still have leverage for as long as the funds haven't crossed a mixer or a bridge.

A confirmed real-time payment fraud doesn't behave like either. The transaction itself is usually over before anyone is looking at an alert: the EPC's SCT Inst Scheme Rulebook sets a maximum execution time of 10 seconds between participating banks, with the payment settled and the receiving customer's account credited well inside that window. There is no in-flight transaction to stop. What's still open, for a short and shrinking window, is whether the money is still sitting in the receiving account or has already been moved on again.

What sits still, and for how long	Ransomware	Hot-wallet / custody compromise	Real-time payment fraud
What's actually moving right now	Nothing — encryption already ran	Funds, on-chain, until they clear a mixer/bridge	Nothing — the transfer already settled
What the first-hour work targets	Scope and isolate without destroying evidence	Cut the signing path, sweep remaining balance, trace on-chain	Freeze the compromised channel, file a recall request fast
What "acting fast" actually buys you	Limits spread to additional systems	Limits how much more leaves before the path is cut	Improves odds the receiving account still holds the funds
Recovery mechanism	Restore from clean backup	On-chain freeze/recovery, no guarantee	Bank-to-bank recall request, no guarantee

The first-hour sequence

Confirm the channel, not just the transaction. Establish which authorization path produced the fraudulent instruction — a compromised mobile-app session, a stolen card-on-file, a manipulated API integration, or a social-engineered call to a human agent who approved an out-of-band transfer. The channel, not the single payment, is what has to be shut down next.
Freeze that channel immediately, scoped as narrowly as the evidence allows. Revoke the specific session, API credential, or card rather than locking the customer's entire relationship by default — unless the evidence already points to a broader account-level compromise. A same-customer second fraudulent transfer through the same still-open channel, minutes after the first, is the single most common way a contained-looking incident gets worse.
File the Request for Recall with the receiving bank inside the first hour, in parallel with step 2, not after it. The scheme rulebook gives the originating bank the right to submit this request for reasons including an erroneous or fraudulently originated instruction, but it is explicit that doing so "does not guarantee" the funds come back — the receiving bank can refuse, and has up to 15 banking business days to respond. Filing late doesn't just delay a maybe; if the receiving account is emptied by the time the request lands, there's nothing left to recall.
Preserve the evidence the recall request and any later investigation both need, without letting evidence preservation slow down steps 2 and 3. Session logs, device fingerprints, the API call sequence, and the recorded call if a human agent authorized the transfer are the artifacts that decide whether this was a channel compromise or a customer-authorized-payment scam — a distinction that changes both the liability conversation and the regulatory classification.
Classify the incident and start the notification clock at classification, not at containment. If the entity is in scope for DORA, the 4-hour initial / 72-hour intermediate / 1-month final notification sequence applies from the moment of classification — the control-by-control detail is in NIS2 and DORA without the consultant theatre and isn't repeated here. GDPR's 72-hour window runs in parallel if customer personal data was exposed as part of how the channel was compromised.
Activate the incident-response engagement to carry containment through to closure, not just the first hour. That means confirming the channel-compromise vector is fully closed (not just the one session or credential that triggered the alert), a forensic timeline of how the channel was obtained, and a regulator-ready report that supports whichever notification timeline actually applies.

What an incident-response engagement delivers

Once Incident Response is engaged — 30-minute response on an advance retainer, rapid response without one — the work extends past the first-hour sequence above to full eradication of any remaining attacker foothold in the channel that was compromised (a revoked session credential doesn't help if the attacker also planted a persistence mechanism in the account-recovery flow that issued it), a complete forensic timeline for the recall request and any subsequent investigation, and a regulator-ready incident report covering GDPR's 72-hour window and, where in scope, DORA's classification-triggered notification sequence.

Limitations

This is a response sequence for the first hour of a confirmed or strongly suspected fraudulent real-time payment, not a fraud-detection or transaction-monitoring design guide — the controls that should flag an out-of-pattern instant transfer before it authorizes are a different engagement. It isn't legal or scheme-compliance advice: whether a specific recall request, liability allocation, or customer-notification action is required depends on your scheme membership, your national competent authority, and the specific facts of the case. And it doesn't promise a fund-recovery outcome — a fast recall request improves the odds the receiving bank still holds the money and is willing to return it; it does not guarantee either.

What to do next

If a real-time payment channel is compromised right now, the sequence above is the order to work through in the first hour; get an IR retainer in place afterward so the next one starts at containment speed rather than spending its first hour on access-provisioning and orientation. If you're not mid-incident and want to reduce the odds of reaching this point, start with the identity and API-gateway controls in hardening a fintech payment platform: what comes first.

Sources and review

The SEPA Instant Credit Transfer maximum execution time (10 seconds) and the Request for Recall by the Originator procedure (available for reasons including a fraudulently originated instruction, explicitly not guaranteed to recover funds, with the beneficiary bank required to respond within 15 banking business days) are drawn directly from the EPC's SCT Inst Scheme Rulebook 2025, Version 1.0 (fetched and read from the official PDF, not a secondary summary). The repeal of the EBA's PSD2 major-incident-reporting guidelines, effective 17 January 2025 in favor of DORA for in-scope entities, with a narrow carve-out for PSPs such as post-office giro institutions and credit unions still under national PSD2-style requirements, is drawn from the EBA's own press release announcing the repeal. DORA's 4-hour/72-hour/1-month notification timeline is codified in EU Regulation (EU) 2022/2554, as previously cited in NIS2 and DORA without the consultant theatre. The 30-minute retainer SLA and GDPR's 72-hour window reflect AnySec's own published Incident Response service terms, not a third-party claim. No unverified customer results, loss figures, or case data are cited. Author: AnySec Engineering. Published 2026-09-05; last reviewed 2026-09-05.