Hostname: page-component-6898cfcb55-zkb6p Total loading time: 0 Render date: 2026-11-11T16:48:37.085Z Has data issue: false hasContentIssue false
  • English
  • Français

From Ransomware Payment Bans to Payment Governance: A Risk-Based Regulatory Framework for the EU

Published online by Cambridge University Press:  05 August 2026

Jersain Zadamig Llamas CovarrubiasOpen the ORCID record for Jersain Zadamig Llamas Covarrubias[Opens in a new window]
Jersain Zadamig Llamas Covarrubias*
Affiliation:
División de Estudios Jurídicos, Centro Universitario de Ciencias Sociales y Humanidades (CUCSH), Universidad de Guadalajara, Guadalajara, Jalisco, Mexico
*
Email: jersain.llamas@academicos.udg.mx
Rights & Permissions [Opens in a new window]

Abstract

The European Union’s cybersecurity framework treats ransomware as a vulnerability problem and an incident reporting problem, but not yet as a payment problem. NIS2, DORA, GDPR and PSD2 govern incidents; the Cyber Resilience Act governs products; the Union cyber sanctions framework governs listed persons. None of these regimes provides a comprehensive, payment-specific governance framework for ransomware payments as regulated events. Drawing on the risk regulation, responsive regulation and cyber governance literatures, this article argues that the Union should fill the gap with a three-pillar, risk-based architecture: pre-payment notice, post-payment report and targeted bans for defined covered entities, supported by ancillary safeguards, including safe harbours, a structured harm-assessment and cost-benefit matrix, and victim-support mechanisms. The Commission’s 2026/0012(COD) NIS2 reform proposal makes a first move on the reporting side but leaves the deeper governance question unaddressed. The architecture proposed here would complete it without committing the Union to a universal ban whose operational fragility has been documented in comparative practice and discussed in the emerging empirical literature.

Keywords

payment governanceransomware paymentsrisk-based regulation

Information

Type
Articles
Information
European Journal of Risk Regulation , First View , pp. 1 - 14
Creative Commons
Creative Common License - CCCreative Common License - BY
This is an Open Access article, distributed under the terms of the Creative Commons Attribution licence (https://creativecommons.org/licenses/by/4.0/), which permits unrestricted re-use, distribution and reproduction, provided the original article is properly cited.
Copyright
© The Author(s), 2026. Published by Cambridge University Press

I. Introduction

The ransomware payment is, in Union law, almost an unregulated event. A victim entity may be obliged to notify a personal-data breach to the supervisory authority,Footnote 1 a significant incident to the computer security incident response team (CSIRT) or competent authority,Footnote 2 a major ICT-related incident to the financial sector authorityFootnote 3 or a major operational or security incident to the payments authority.Footnote 4 None of those duties governs the decision that, from the perspective of the ransomware business model, matters most: whether and how the entity sends funds to the attacker, and to whom. The Union has not adopted a payment-specific instrument; the Commission’s 2026/0012(COD) proposal amending NIS2 only begins to fill the gap on the reporting side, and even there only on request of the competent authority.Footnote 5

The doctrinal puzzle is whether the gap can be filled by an inherited combination of incident reporting and sanctions law, or whether the payment itself must be treated as a regulated event with its own pre-payment and post-payment obligations. The political puzzle is whether the Union should follow the United Kingdom’s 2025 turn towards targeted bans plus a payment-prevention regime, or restrict itself to information-gathering. The position advanced here is intermediate: targeted bans for covered entities are defensible only if they sit inside a wider architecture of notice, reporting and support. Universal payment bans, by contrast, are politically attractive but operationally fragile, for reasons that the comparative experience and the academic literature converge on.Footnote 6

The article offers a doctrinal and normative contribution, informed by comparative and empirical literature but not itself designed as an empirical study. It draws on a body of regulation-theory scholarship that has been underused in the ransomware debate: risk-based regulation, responsive regulation and cyber risk governance.Footnote 7 Section II locates the contribution in that literature. Section III clarifies the regulatory object, distinguishing the payment from the vulnerability and from the incident. Section IV maps the EU acquis and locates the payment gap. Section V benchmarks the Union framework against the United States and the United Kingdom. Section VI sets out a three-pillar architecture. Section VII evaluates the Commission’s 2026/0012(COD) proposal against three criteria. Section VIII responds to counter-arguments.

II. Locating the argument: risk regulation, responsive regulation and cyber governance

1. Risk-based regulation and the design of supervisory attention

Risk-based regulation describes a family of regulatory strategies that allocate enforcement attention according to a structured assessment of risk to regulatory objectives, rather than uniformly across regulated entities. A central reference in the European tradition is Hood, Rothstein and Baldwin’s work on regimes that combine risk identification, risk assessment and risk management within a single institutional architecture.Footnote 8 Black and Baldwin, refining that tradition into what they called “really responsive risk-based regulation,” argued that the design challenge is to make risk-based supervision responsive to the behaviour of regulated entities, the regulator’s own institutional capacity and changing patterns of risk.Footnote 9 Black’s separate work on the rise of risk-based regulation in the United Kingdom emphasised that risk-based design becomes a way of managing uncertainty in conditions of incomplete information.Footnote 10

For present purposes the risk-based regulation literature does three things. First, it supplies a vocabulary (proportionality, regulatory sequencing, information asymmetry, institutional capacity, enforcement discretion) that situates the ransomware payment problem within a recognisable scholarly debate rather than a policy improvisation. Secondly, it offers a methodological discipline: rules should be calibrated to risk, with the most demanding obligations applied to the entities whose failure would generate the greatest social cost. Thirdly, it cautions against rule designs that produce compliance fatigue or chilling effects, both of which feature prominently in the ransomware payment debate.

2. Responsive regulation and the enforcement pyramid

Responsive regulation, as set out by Ayres and Braithwaite, theorises an enforcement pyramid in which regulators move from persuasion, through warning, civil penalty and licence suspension, to the most coercive sanction available at the apex.Footnote 11 The model is responsive in that the regulator escalates only as compliance fails. Two features of the model bear directly on ransomware payment regulation. First, the pyramid disciplines the temptation to begin at the top: criminal liability or universal prohibition. Secondly, the apex sanction supplies credibility to the lower rungs, because regulated entities know the regulator can escalate.

The architecture proposed in Section VI translates this logic into the ransomware payment context. The pre-payment notice sits at the bottom (a procedural step short of substantive review); the post-payment report adds a verification rung; the targeted ban for public-sector bodies and essential entities in Annex I high-criticality sectors sits towards the apex. The design therefore observes Ayres and Braithwaite’s warning that effective regulation requires a continuum of responses, not a single instrument applied flat across the regulated population.Footnote 12 Nieuwesteeg and Faure’s analysis of the ransom-tax option, which proceeds from an explicit pyramid-of-regulation argument, is consistent with this reading: their preference for taxation over prohibition was grounded in the same theoretical commitment to milder market-based instruments where they can achieve the regulatory objective.Footnote 13

3. Cyber risk governance and the role of private intermediaries

A separate strand of the literature, on cyber risk governance, foregrounds the role of private intermediaries (insurers, incident response firms, crypto-asset service providers, managed security service providers) in shaping the behaviour of regulated entities. Mott and others, in their study of cyber insurance in the ransomware era, argue that the insurance market has become a de facto private regulator of cybersecurity hygiene, with underwriting requirements increasingly prescribing controls that resemble baseline regulatory standards.Footnote 14 The literature is contested on whether insurance fuels moral hazard or, on the contrary, hardens defences; the available evidence does not clearly establish a general moral-hazard effect; by contrast, recent underwriting practices suggest a hardening of baseline cybersecurity expectations.Footnote 15

Public–private governance literature also matters because the payment often touches, or seeks to avoid, regulated financial and crypto-asset infrastructures. The AML architecture, in which regulated intermediaries are enrolled as primary screeners of suspicious flows, is the obvious template; Mitsilegas’s critique of the AML paradigm in the European Union supplies both the model and a useful warning about the rights-protective limits of the design.Footnote 16 The architecture proposed in Section VI borrows the suspicious-transaction logic without importing its more controversial features, notably the tipping-off prohibition that would make no sense in a victim-reporting context.

4. The ransomware governance debate

Three groups of contributions in the ransomware governance literature deserve separate notice. The economic-incentives literature, exemplified by Nieuwesteeg and Faure, treats ransomware payments as a negative externality and asks which policy instruments (subsidies, taxes, prohibitions) best internalise it.Footnote 17 The empirical literature, including Paquet-Clouston, Haslhofer and Dupont’s mapping of cryptocurrency flows and Ramjee and Leverett’s long-run analysis of extortion payments, supplies the data on which the policy debate must rest.Footnote 18 The behavioural-victim literature, including Matthijsse and others on SME decision making, identifies the conditions under which victims pay; that work matters because any regulatory design must accommodate the realities of the negotiation room rather than the assumptions of the model.Footnote 19 What remains underdeveloped is a specifically EU-oriented architecture that treats the payment itself as the regulatory object.

Lubin’s essay on the law and politics of ransomware diagnoses the fragmentation problem: across jurisdictions and instruments, ransomware regulation has produced “an environment within which ransomware gangs continue to thrive,” because no single layer is comprehensive enough to govern the financial flow.Footnote 20 Worsley and others, surveying US state-level legislation, make the parallel point that a patchwork of definitions, reporting timelines and partial bans hampers rather than supports a unified response.Footnote 21 The contribution sought here is to translate that diagnosis into a defensible regulatory architecture for the European Union, using the analytical resources of risk regulation, responsive regulation and cyber governance.

A further, regionally grounded contribution comes from the criminal-law literature: Čentéš and Rampášek, analysing ransom payments through the lens of Czech and Slovak criminal law, map the offences a paying victim may risk, chiefly the laundering of criminal proceeds and the financing of terrorism, together with the restrictive-measures exposure that attaches where the recipient is a listed person, and conclude that victims need a structured compliance and risk-management procedure rather than an unaided judgment call.Footnote 22

III. The payment as a regulated event

1. Defining the regulatory object

A ransomware incident has three distinct moments. The first is the antecedent vulnerability in software or configuration, exploited by the attacker. The second is the incident proper: the unauthorised access, encryption, exfiltration and extortion. The third is the payment, when the victim transfers value, usually in a crypto-asset, to a recipient that may be unidentified, sanctioned or both. Each moment is the proper object of a different kind of regulation. Vulnerability disclosure governs products and is best handled ex ante.Footnote 23 Incident notification governs entities and is best handled ex post, but quickly.Footnote 24 The payment is the third regulatory object, and is conceptually closest to suspicious-transactions regulation in anti-money-laundering law: a financial flow with externalities, whose legal permissibility depends on factors such as sanctions status, attribution and financial crime risk, that the payer often cannot verify in real time.

Treating the payment as a regulated event has informational, behavioural and institutional implications. Informationally, the authority is no longer dependent on an incident description for what is, economically, the most consequential moment of the attack. Behaviourally, the timing of reporting shapes the cost-benefit calculus of the victim. Institutionally, it requires that competent authorities have a procedural device through which they can intervene in real time, including, where appropriate and under applicable national procedures, by requesting or triggering provisional preservation or freezing measures over crypto-assets.Footnote 25 The choice between treating the payment as an incident detail and treating it as a regulated event is therefore not cosmetic; it determines what the regulator can do at all.

2. The limits of the existing EU acquis

The Union’s main cybersecurity instruments are framed around incidents, not payments. Article 23 NIS2 requires significant-incident notification with an early warning within 24 hours of awareness, an incident notification within 72 hours, and a final report at one month.Footnote 26 Article 19 DORA sets analogous deadlines for major ICT-related incidents in the financial sector.Footnote 27 Article 33 GDPR obliges controllers to notify the supervisory authority of a personal-data breach within 72 hours, where feasible.Footnote 28 Article 96 PSD2 obliges payment service providers to notify the competent authority of major operational or security incidents without undue delay.Footnote 29 In each instrument, the payment is, at best, an item buried inside the incident description; at worst, it is invisible.

The Union’s cyber sanctions framework, by contrast, operates on the payment, but only obliquely. Council Regulation (EU) 2019/796 and Council Decision (CFSP) 2019/797 prohibit making funds or economic resources available to listed persons or entities.Footnote 30 The difficulty is well rehearsed in the literature: the victim rarely knows the recipient’s identity, or the recipient’s links to a listed entity, in the compressed timeline of an extortion negotiation.Footnote 31 The framework therefore governs the payment, but in a way that imposes significant sanctions-related legal risk without giving the victim any procedural device to manage it.

IV. Mapping the acquis: where the payment gap sits

NIS2 frames its reporting duties around the concept of a “significant incident,” defined in Article 23(3); Recital 54 expressly identifies ransomware as a driver of the directive.Footnote 32 The directive does not, however, require notification of any payment. Without payment-specific reporting, the authority cannot easily aggregate data on payment frequency, amounts or destination wallets. Trend analysis is correspondingly weak as to the financial side of the criminal economy.Footnote 33

DORA distinguishes initial, intermediate and final reports for major ICT-related incidents in the financial sector but, again, does not govern payments. A bank that pays a ransom to restore operations would notify the incident under Article 19, would notify a personal-data breach under Article 33 GDPR if data were exfiltrated, and would, if relevant, notify under Article 96 PSD2. None of these channels asks whether a ransom was paid, in what amount, in what means of payment, or to what crypto-asset address.

Article 33 GDPR is the most likely incident channel for a private-sector victim, because most large attacks involve a personal-data breach. The European Data Protection Board has clarified that paying a ransom does not extinguish breach-notification duties; if anything, paying may aggravate a finding of failure to implement appropriate technical and organisational measures under Article 32 GDPR.Footnote 34 This indirectly discourages payment but provides no procedural framework for it. Article 96 PSD2 captures only payment service providers, not their clients. The Cyber Resilience Act addresses the antecedent vulnerability rather than the incident or the payment. It is therefore relevant to ransomware prevention, but not to payment governance.

The Commission’s 2026/0012(COD) proposal amending NIS2 is the first Union instrument to address ransomware payments in a structured way. It adds two new paragraphs to Article 23. Paragraph 12 obliges entities to indicate whether they detected a ransomware attack, the attack vector and whether mitigation measures were implemented. Paragraph 13 requires Member States to ensure that entities inform the CSIRT or competent authority, on request, whether a ransom was paid and, if so, in what amount, by what means of payment and to which recipient. The provision is meaningful but limited. It treats payment information as something the authority may request, not as a free-standing reporting duty triggered by the payment itself. The weakness of the proposal is therefore not that it ignores ransomware payments, but that it treats them as incident-related metadata rather than as a regulatory event capable of triggering ex ante intervention, legal-risk management and downstream financial disruption. It is silent on pre-payment notice and on any payment-review or blocking power. It does not address sanctions due diligence in the compressed timeline of an extortion negotiation. Crucially, the Union has politically aligned with the non-binding Counter Ransomware Initiative 2023 joint statement, under which member governments “should not pay ransomware extortion demands,” but that political commitment has not been operationalised in Union law beyond the proposed information duties.Footnote 35

V. Comparative benchmark

1. The United States: CIRCIA, OFAC, FinCEN

The US framework has, since 2020, deliberately separated three layers: a sanctions risk warning (OFAC), a money-laundering compliance overlay for facilitators (FinCEN) and a critical-infrastructure incident reporting regime (CIRCIA). OFAC’s 2020 advisory, updated in September 2021, frames the legal risk of facilitating a ransomware payment in strict-liability terms, with a presumption of denial for licence applications.Footnote 36 The strict-liability framing has been criticised in the literature on the ground that it imposes legal risk without an administrative route to fast clearance, thereby over-deterring honest victims while doing little to deter sophisticated attackers.Footnote 37

FinCEN’s 2021 advisory addresses the AML-CFT dimension, characterising certain facilitators as potentially subject to Bank Secrecy Act obligations, including suspicious activity reports.Footnote 38 CIRCIA is the most substantive of the US instruments for present purposes. Section 681(a)(2) requires a covered entity that makes a ransomware payment to report it to CISA within 24 hours of payment; CISA’s April 2024 notice of proposed rulemaking sets out the proposed contents of the Ransomware Payment Report and of the joint Covered Cyber Incident and Ransomware Payment Report. The clock runs from payment, not from intent to pay; CIRCIA is therefore post-payment only, by design.Footnote 39 The regime is also limited to covered entities in defined critical-infrastructure sectors, and is co-extensive with the incident reporting regime, which avoids the duplication problem that would otherwise arise.

At state level, North Carolina (2021) and Florida (2022) introduced targeted bans for state agencies and local government entities.Footnote 40 The empirical evidence on those bans is mixed: studies report that the number of attacks on North Carolina public entities did not notably decrease after the ban, suggesting that an isolated sub-jurisdictional ban tends to shift attacker focus rather than disrupt the underlying business model.Footnote 41

2. The United Kingdom: a closer doctrinal cousin

The Home Office consultation of January 2025 proposed three measures: a targeted ban on ransomware payments by public-sector bodies and operators of Critical National Infrastructure; a payment-prevention regime requiring all other potential victims to report intent to pay before doing so; and a ransomware incident reporting regime.Footnote 42 The Government Response confirmed support for all three proposals.Footnote 43 The consultation analysis records 72% support for the targeted ban and 63% net agreement for an economy-wide mandatory reporting regime; importantly, the State retains a power to block but not to approve payment, preserving the principle that paying is a private decision with public consequences rather than a State-licensed act.Footnote 44

The UK design is the closest doctrinal cousin to what is proposed below. It has, however, been criticised on chilling effects and revictimisation grounds. Consultation responses warned that criminal or civil penalties for non-compliance could “push incidents underground, reducing visibility into ransomware threats and hindering collective efforts to combat them.”Footnote 45 That concern is not dispositive; it argues for careful enforcement design, not for abandoning the architecture.

3. A regional doctrinal perspective: Czech and Slovak criminal law

A recent criminal-law analysis from the Central European region reinforces the case for the architecture proposed below. Čentéš and Rampášek, examining ransom payments under Czech and Slovak criminal law, situate the payment within the offences of money laundering and the financing of terrorism and within the Union’s restrictive-measures framework, stressing that the financing-of-terrorism offence may be made out where funds merely could be used for terrorist purposes, and that proving the victim’s knowledge or intent becomes acutely difficult once payment is routed through anonymising crypto-asset systems.Footnote 46 Two features of their analysis are notable for present purposes. First, it confirms, from a doctrinal criminal-law standpoint, that the payment is already a legally consequential event for the victim even in the absence of a payment-specific instrument, the premise advanced in Section III. Secondly, reasoning independently from that national perspective, the authors arrive at a Union-level prescription that closely tracks the model defended here: a duty on entities not subject to a ban to notify law-enforcement authorities of an intended payment before making it, coupled with an official legality check and victim support; a targeted prohibition on payment for public-sector and critical-infrastructure entities and their significant suppliers, modelled on the United Kingdom proposal; and an economy-wide obligation to report ransomware incidents within 72 hours.Footnote 47 That a criminal-law analysis grounded in two Member States converges on a notice-plus-report-plus-targeted-ban structure is itself evidence that the architecture responds to the legal-risk realities victims actually face.

VI. A three-pillar architecture for the Union

The model proposed here treats the payment as a regulated event with three sequenced pillars. The starting premise is that universal bans are not, at present, the most defensible option at Union level. Universal bans risk pushing payments underground, may bankrupt small and medium-sized enterprises that lack the resilience to absorb a worst-case incident, and create severe pressure in critical-services sectors where the only realistic alternative to payment may be sustained operational failure with downstream safety implications.Footnote 48 The architecture therefore stops short of a universal ban while moving substantially beyond a notification-only regime. It is structured, in the manner of Ayres and Braithwaite’s pyramid, as a graduated set of obligations, with the targeted ban reserved for the apex.Footnote 49 The proposed three-pillar payment-governance architecture is summarised in Table 1.

1. Pillar one: pre-payment notice and due-diligence

For this purpose, covered entities would include NIS2 essential and important entities, DORA financial entities and other legal persons above a defined size or payment threshold. Any covered entity that contemplates a ransomware payment should be required to file a pre-payment notice with the designated authority and to wait a defined period (in the order of 72 hours, with provision for emergency abbreviation) before paying. The notice records the ransom demand, the recipient details so far as known, the proposed amount and means of payment, and a documented due-diligence assessment of sanctions, terrorism-finance and money-laundering risk. The authority does not approve the payment; it should be empowered, under national procedural law, to warn the entity of any known sanctions match, to request or trigger provisional preservation or freezing measures involving a crypto-asset service provider where appropriate, and to offer operational support.Footnote 50 The design is doctrinally analogous to a suspicious-transaction report under AML law, with two differences. First, the notifying entity is the victim, not a regulated financial institution. Secondly, the notice is timed to allow administrative intervention rather than only post-hoc analysis.Footnote 51

2. Pillar two: mandatory post-payment report

Where a payment is made, the entity files a post-payment report within 24 hours of the transfer, inspired by the CIRCIA model, while adapted to the Union’s institutional architecture.Footnote 52 The report records the final amount, the actual recipient address, any differences from the pre-payment notice, and any communications with the attacker. The dual structure (notice plus report) is essential. The pre-payment notice supports authority intervention before the funds leave the system; the post-payment report supports trend analysis, downstream disruption (including civil recovery and crypto-asset forfeiture) and aggregate evaluation of the regime. Without the post-payment leg, the architecture loses its retrospective accountability function; without the pre-payment leg, it loses its operational disruption function.

3. Pillar three: targeted bans for defined covered entities

A subset of entities is excluded from the pre-payment notice route altogether and subject to a hard prohibition on paying. The proposed perimeter is sequenced: first, central, regional and local public authorities, and other public bodies designated by Member State law; secondly, after a transition period during which the resilience of those operators is verified, entities operating in the high-criticality sectors listed in Annex I to NIS2, where they qualify as essential entities under the Directive.Footnote 53 The ban should not extend to Annex II “important entities” except by Member-State election, because the smaller scale and lower systemic significance of those entities mean that the operational fragility argument bites harder.

Two design features deserve emphasis. The first is the sequencing: a simultaneous ban on the entire NIS2 scope would, if introduced cold, replicate the small-hospital problem at Union scale. The phased design beginning with the public sector (which already operates under the principle that public funds should not flow to criminals, consistent with the Counter Ransomware Initiative’s 2023 commitment) attempts to address that concern without abandoning the underlying policy direction.Footnote 54 The second is the enforcement design: administrative fines and licence consequences are the primary instruments, with criminal liability reserved for officers who direct payment in defiance of the prohibition. Criminalising the entity itself would, on the available evidence, deter reporting more than payment.Footnote 55

The healthcare sector illustrates why the perimeter of any ban must be drawn with sector-specific care. Health has been the most attacked sector in the Union in recent years, and ransomware dominates its threat picture: ENISA attributes a majority of analysed health-sector incidents in 2021–2023 to ransomware, and the Commission has reported that most attacks with a direct effect on patient care, delayed treatment and diagnosis, impaired access to emergency services, were of the ransomware type.Footnote 56 The Commission’s 2025 action plan on the cybersecurity of hospitals and healthcare providers responds to that picture not with a payment prohibition but with a prevention-first, capacity-building and risk-based package; tellingly, it invites Member States to ask NIS2 entities, including healthcare organisations, to report both ransom payments made and ransom payments they intend to make, and to promote guidance and decryption tools that help providers avoid paying.Footnote 57 That sector-sensitive posture, calibrated obligations and support rather than a blanket ban for the very sector in which the operational-fragility argument bites hardest, is precisely the orientation the three-pillar architecture generalises: it supplies concrete institutional backing for treating intent-to-pay notice and post-payment reporting as the default, with targeted bans reserved for entities whose resilience can first be assured.

4. Supporting elements

The three pillars are supported by three structural elements that do not, by themselves, constitute regulatory pillars but without which the architecture would be punitive or unworkable. The first is a limited safe harbour. The safe harbour would not immunise antecedent failures of cybersecurity, data protection or operational resilience compliance. It would only prevent a lawful, reported and duly assessed payment from being treated as an independent ground of liability or as an aggravating factor, provided that the entity has conducted the prescribed sanctions due diligence and no match with an EU-listed person or entity was identified at the time of payment. Without a safe harbour, the layered duties (Article 23 NIS2, Article 19 DORA, Article 33 GDPR, Article 96 PSD2 and Article 3 of Regulation (EU) 2019/796) compound to a level that, in practice, chills reporting.Footnote 58

The second is a standardised structured harm-assessment and cost-benefit matrix developed by ENISA in consultation with national CSIRTs and, given the financial-flows component, the Anti-Money Laundering Authority. The matrix would oblige the entity to consider alternatives to payment, to identify costs incurred regardless of payment, and to record the residual judgment that payment is the lowest-harm resolution.Footnote 59 The third is a victim-support mechanism integrated into the Cyber Solidarity Act framework or established as a parallel instrument, accessible to SMEs and to public-sector bodies subject to the ban, underwriting incident response, recovery and (where appropriate) temporary continuity-of-service expenditure.Footnote 60

VII. Evaluating the commission proposal against the model

Three criteria structure the evaluation: effectiveness in disrupting the ransomware economy, proportionality and legal certainty for victims, and institutional feasibility.

On effectiveness, the 2026/0012(COD) proposal narrows the payment information gap but does not close it. By treating payment information as available “on request” of the CSIRT or competent authority,Footnote 61 the proposal trades simplicity for predictability. An authority that does not specifically ask will not learn whether a payment was made or to whom; trend analysis becomes dependent on case-by-case initiative rather than a structural feature of the reporting regime. The provision also does not require a pre-payment notice, which means it cannot trigger downstream disruption. As a tool for disrupting the ransomware economy, the proposal is therefore inferior to the three-pillar architecture. The proposal does, however, deliver one useful structural feature: by attaching payment information to the existing significant-incident notification under Article 23(1), it does not create a new reporting silo for an already burdened regulated population.

On proportionality and legal certainty, the proposal imposes only an information duty on entities already obliged to report incidents; the marginal compliance burden is modest. The deeper proportionality concern is structural: the duty sits alongside the cyber sanctions framework and the AML obligations, but offers no safe harbour and no defined procedural route to clear them. The aggregate effect for a victim is a constellation of overlapping duties without a defined procedural route for managing the resulting legal risk. The architecture proposed in Section VI would improve legal certainty: a victim who filed a pre-payment notice, performed sanctions due diligence and waited the prescribed period would have a defined legal position under each of those instruments. There is a residual concern that the on-request power could be used to compel disclosure of sensitive negotiation information well after the fact, exposing the victim to enforcement risk under other instruments.

On institutional feasibility, the Commission proposal preserves the institutional architecture of NIS2: notification to the CSIRT or competent authority, with ENISA in a supporting role on cross-border matters.Footnote 62 That is the right starting point. The three-pillar architecture would build on the same architecture, adding a dedicated payment-review function within each Member State, combining cybersecurity, sanctions and AML expertise, and a real-time information-sharing protocol with Europol’s European Cybercrime Centre and the relevant Financial Intelligence Unit. Comparable cross-functional units already exist in some Member States in the AML context.

VIII. Counter-arguments

The objections to the architecture fall into four families: chilling, displacement, victim re-traumatisation and strict-liability over-deterrence. Each requires a focused reply.

The chilling argument is that any payment-side regulation will chill the reporting it seeks to encourage.Footnote 63 In the UK consultation analysis, respondents observed that civil or criminal penalties for non-compliance with reporting duties may “push incidents underground.”Footnote 64 The reply is twofold. First, the chilling argument is strongest against criminal penalties and against universal bans, and weakest against pre-payment notice, which is a procedural step rather than a substantive prohibition. Secondly, the answer to genuine chilling risk is calibrated enforcement: the safe harbour for compliant victims; criminal liability reserved for executive-level evasion; resourcing of the support mechanisms that make notice an attractive route. The chilling argument disciplines the design rather than refutes it.

The displacement argument is that any Union regime can be evaded by routing the payment through a third-country subsidiary or an unregulated crypto-asset service provider. Displacement is real and cannot be abolished. Three mitigating considerations apply. The first is the EU Travel Rule for crypto-asset transfers, which limits the unregulated space available to regulated entities.Footnote 65 The second is the Counter Ransomware Initiative’s progressive alignment of reporting and disruption practice across more than fifty jurisdictions.Footnote 66 The third is that displacement to non-cooperative jurisdictions imposes its own costs on the victim (slower payment, less reliable decryption, more legal exposure), which themselves reduce the attractiveness of payment.

The victim re-traumatisation argument is that imposing additional duties on the victim, in the middle of an extortion negotiation, compounds the harm. The point is serious and is best addressed at the design stage. Pre-payment notice should be a short, structured filing, supported by clear guidance, a 24-hour helpline and a real victim-support mechanism. The point of the architecture is not to interrogate the victim but to slow the transaction enough for the authority to act, where it can. The literature on the human-rights dimension of ransomware regulation, in particular on the positive obligations of States in relation to critical-services attacks, supports the inclusion of a narrowly tailored waiver mechanism for situations involving imminent risks to life, health or essential services, analogous to the humanitarian exemptions found in sanctions regimes.Footnote 67

The strict-liability argument is that the Union should resist replicating OFAC’s framing, which has been criticised as imposing legal risk without giving victims a reliable procedural route to clearance.Footnote 68 The reply is built into the architecture: the safe harbour is designed precisely to give a compliant victim a defined legal position, conditional on substantive cybersecurity compliance. The Union should not move towards strict liability for ransomware payment per se; the sanctions framework, where it applies, is sufficient.

IX. Towards payment governance

Universal bans on ransomware payments are intuitive responses to a criminal economy whose business model depends on the willingness of victims to pay. They are also, on the available comparative and empirical evidence, operationally fragile. The argument advanced here is that the Union should reject the universal-ban frame and adopt a payment-governance framework instead, structured by three risk-based pillars: pre-payment notice, post-payment report and targeted bans for defined covered entities, supported by ancillary safeguards, including safe harbours, a structured harm-assessment and cost-benefit matrix, and victim-support mechanisms.

The Union’s comparative regulatory advantage in this domain is its capacity to combine cybersecurity, financial regulation, sanctions and data protection instruments in a single coherent architecture. CIRCIA covers reporting but not pre-payment notice; OFAC and FinCEN cover sanctions and AML respectively but not entity reporting; the UK design covers payment prevention but exists in a single jurisdiction with limited cross-border reach. A Union architecture that combined the strongest elements of each, while avoiding the most criticised features of each (strict liability, criminal exposure for victims, universal bans), would set a template for how a sophisticated regulatory order governs criminal financial flows in a digitalised economy.Footnote 69

The Commission’s 2026/0012(COD) proposal makes a useful first move by adding payment-related information duties to Article 23 NIS2. It does not, however, complete the architecture. The doctrinal point, on the analysis offered here, is that the payment is now a regulated event in fact, even if it is not yet treated as one in form, and the Union framework is overdue a coherent instrument that engages it as such. Whether the Union ultimately moves in this direction is a political question, and one on which reasonable scholars and practitioners will continue to disagree.

Table 1.

The payment-governance framework: three risk-based pillars and supporting safeguards for victims and authorities.

A table outlining a payment-governance framework with three pillars and supporting safeguards.
Table 1. Long description

A table detailing a payment-governance framework with four main sections. The table has four rows and four columns. Column headers are (i), (ii), (iii), and (iv). Row labels are Scope, Notice due-diligence check, Short waiting period before payment, Authority may warn, Scope, Filed within 24 hours of the transfer, Records amount, recipient address, payment channel and attacker contacts, Enables tracing, recovery, intelligence-sharing and trend analysis, Scope, Public authorities first, Possible extension to NIS2 Annex I essential entities once resilience and support mechanisms are verified, Administrative fines and regulatory consequences, Scope, Victims: limited safe harbour and victim-support mechanism, Both: ENISA harm-assessment and cost-benefit matrix, Authorities: payment-review function; real-time sharing with Europol/EC3 and relevant FIUs. Row 1: (i) Before payment Pillar 1: pre-payment notice, (ii) After payment Pillar 2: post-payment report, (iii) Targeted prohibitions Pillar 3: targeted ban on paying, (iv) Supporting safeguards for victims and authorities. Row 2: Scope: all covered entities (NIS2 essential and important entities, DORA financial entities, and other entities above a defined size or payment threshold)., Scope: all covered entities, where a payment is made., Scope: a defined subset only apex of the graduated architecture., Scope: cross-cutting operate across all three pillars.. Row 3: Notice due-diligence check: sanctions, money-laundering and terrorist-financing risks, Filed within 24 hours of the transfer, Public authorities first., Victims: limited safe harbour and victim-support mechanism,. Row 4: Short waiting period before payment, subject to emergency derogation, Records amount, recipient address, payment channel and attacker contacts, Possible extension to NIS2 Annex I essential entities once resilience and support mechanisms are verified., Both: ENISA harm-assessment and cost-benefit matrix,. Row 5: Authority may warn, trigger freezing/preservation measures, or offer support; no approval, Enables tracing, recovery, intelligence-sharing and trend analysis, Administrative fines and regulatory consequences; possible liability for officers who knowingly authorise prohibited payments., Authorities: payment-review function; real-time sharing with Europol/EC3 and relevant FIUs.

Note. The model forms a graduated, sequenced architecture in the manner of a responsive-regulation (enforcement) pyramid. The pre-payment notice (Pillar 1, before payment) and the post-payment report (Pillar 2, after payment) apply to all covered entities; the targeted ban (Pillar 3) is reserved, as an apex measure, for a defined subset, beginning with public authorities and extending to NIS2 Annex I essential entities once their resilience is verified. The supporting safeguards in panel (iv) operate transversally across all three pillars.

Competing interests

The author confirms there are no conflicts of interest to declare.

Footnotes

1 Art. 33 of Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data [2016] OJ L119/1 (GDPR).

2 Art. 23 of Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union [2022] OJ L333/80 (NIS2 Directive).

3 Art. 19 of Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector [2022] OJ L333/1 (DORA).

4 Art. 96 of Directive (EU) 2015/2366 of the European Parliament and of the Council of 25 November 2015 on payment services in the internal market [2015] OJ L337/35 (PSD2).

5 Commission, “Proposal for a Directive of the European Parliament and of the Council amending Directive (EU) 2022/2555 as regards simplification measures and alignment with the [Proposal for the Cybersecurity Act 2]” COM(2026) 13 final, 2026/0012(COD), 20 January 2026, inserting new paras. 12 and 13 in Art. 23 NIS2. As of writing, the proposal is before the European Parliament and Council under the ordinary legislative procedure and has not been adopted.

6 Institute for Security and Technology, Combating Ransomware: A Comprehensive Framework for Action (Ransomware Task Force Report, April 2021); see also Institute for Security and Technology, The Ransomware Task Force: Doubling Down (April 2024) p 16, reporting that Australia ultimately dropped a proposed payment ban from its national cybersecurity strategy after consultation.

7 B Nieuwesteeg and M Faure, “The Uneasy Case for a Ransom Tax” (2023) 14 European Journal of Risk Regulation 382; A Lubin, “The Law and Politics of Ransomware” (2022) 55 Vanderbilt Journal of Transnational Law 1177.

8 C Hood, H Rothstein and R Baldwin, The Government of Risk: Understanding Risk Regulation Regimes (Oxford University Press 2001) pp 8–10.

9 J Black and R Baldwin, “Really Responsive Risk-Based Regulation” (2010) 32 Law & Policy 181; see also B Hutter, The Attractions of Risk-Based Regulation: Accounting for the Emergence of Risk Ideas in Regulation (LSE Centre for Analysis of Risk and Regulation, Discussion Paper No 33, 2005).

10 J Black, “The Emergence of Risk-Based Regulation and the New Public Risk Management in the United Kingdom” (2005) Public Law 512; for the EU dimension, M Lodge and K Wegrich, “High-Quality Regulation: Its Popularity, Its Tools and Its Future” (2009) 29 Public Money & Management 145.

11 I Ayres and J Braithwaite, Responsive Regulation: Transcending the Deregulation Debate (Oxford University Press 1992); for a contemporary restatement, J Braithwaite, Regulatory Capitalism: How It Works, Ideas for Making It Work Better (Edward Elgar 2008).

12 Ayres and Braithwaite, supra, note 11, ch 2.

13 Nieuwesteeg and Faure, supra, note 7, pp 388–389.

14 G Mott and others, “Between a Rock and a Hard(ening) Place: Cyber Insurance in the Ransomware Era” (2023) 128 Computers & Security 103162; DW Woods and T Moore, “Does Insurance Have a Future in Governing Cybersecurity?” (2020) 18(1) IEEE Security & Privacy 21.

15 Mott and others, supra, note 14; Ransomware Task Force Report, supra, note 6, p 61.

16 V Mitsilegas, Money Laundering Counter-Measures in the European Union: A New Paradigm of Security Governance versus Fundamental Legal Principles (Kluwer 2003); for the contemporary EU architecture, Regulation (EU) 2024/1620 of the European Parliament and of the Council of 31 May 2024 establishing the Anti-Money Laundering Authority (AMLA) [2024] OJ L 2024/1620.

17 Nieuwesteeg and Faure, supra, note 7, pp 384–385; D Dey and A Lahiri, “Should We Outlaw Ransomware Payments?” (2021) 54 Hawaii International Conference on System Sciences 6609; A Laszka, S Farhang and J Grossklags, “On the Economics of Ransomware” in C Kiekintveld and others (eds), Decision and Game Theory for Security (Springer 2017) p 397.

18 M Paquet-Clouston, B Haslhofer and B Dupont, “Ransomware Payments in the Bitcoin Ecosystem” (2019) 5(1) Journal of Cybersecurity tyz003; D Ramjee and E Leverett, “From Ransoms to Ruin: Are Extortion Payments by Ransomware Victims Insurable?” (2025) 7 Data & Policy e80.

19 SR Matthijsse and others, “Examining Ransomware Payment Decision-Making among Small- and Medium-Sized Enterprises” (2025) 22(4) European Journal of Criminology 625–45, 626–30.

20 Lubin, supra, note 7, pp 1185–6.

21 MK Worsley, J Kendall-Morwick and KA Houston, “Change Waits for No One: An Examination of the Legal Response to Ransomware Attacks” (2025) 36(6) Criminal Justice Policy Review 259, 273–4.

22 Jozef Čentéš and Michal Rampášek, “Ransomvér a úhrada výkupného v kontexte trestného práva” [Ransomware and Ransom Payments in the Context of Criminal Law] (2025) 33 Časopis pro právní vědu a praxi 555, doi:10.5817/CPVP2025-3-7.

23 Arts 13–14 and Annex I to Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements [2024] OJ L 2024/2847 (Cyber Resilience Act).

24 Art. 23(4)(a)-(c) NIS2 Directive (24-hour early warning, 72-hour incident notification, one-month final report).

25 Ransomware Task Force Report, supra, note 6, Action 4.2.4 (pre-payment information-sharing to allow downstream disruption, including crypto-asset freeze letters).

26 Art. 23(4)(a)-(c) NIS2 Directive; for analysis of the threshold concept, S Schmitz-Berndt, “Defining the Reporting Threshold for a Cybersecurity Incident under the NIS Directive and the NIS 2 Directive” (2023) 9 Journal of Cybersecurity tyad009.

27 Art. 19(1)-(4) DORA; Commission Delegated Regulation (EU) 2024/1772 of 13 March 2024 supplementing DORA with regard to classification of major ICT-related incidents [2024] OJ L 2024/1772.

28 Art. 33(1) GDPR; European Data Protection Board, Guidelines 9/2022 on personal data breach notification under the GDPR (adopted 28 March 2023).

29 Art. 96(1) PSD2.

30 Art. 3 of Council Regulation (EU) 2019/796 of 17 May 2019 concerning restrictive measures against cyber-attacks threatening the Union or its Member States [2019] OJ L129I/1; Council Decision (CFSP) 2019/797 [2019] OJ L129I/13. For the first listings explicitly targeting individuals involved in ransomware campaigns (Trickbot/Conti, June 2024), see F Teichmann, “International Legal Responses to Ransomware: Toward a Ban on Payments?” (2026) 7 International Cybersecurity Law Review 41, 53–54.

31 Ransomware Task Force Report, supra, note 6, p 44 (“identifying payment recipients can prove quite challenging, especially under the short timelines of a ransomware attack”); for the broader attribution problem, T Rid and B Buchanan, “Attributing Cyber Attacks” (2015) 38 Journal of Strategic Studies 4.

32 Art. 23(3) and Recital 54 NIS2 Directive.

33 Institute for Security and Technology, Doubling Down, supra, note 6, pp 12–13.

34 Teichmann, supra, note 30, pp 50–51.

35 Counter Ransomware Initiative, “International Counter Ransomware Initiative 2023 Joint Statement” (1 November 2023). The Union participates in the CRI alongside Member States and has aligned with the statement. See also R Radu, “Countering Ransomware: Government Responses in a Comparative Perspective” in Proceedings of the 17th International Conference on Cyber Conflict: The Next Step (IEEE 2025) 91; Teichmann, supra, note 30, p 46.

36 US Department of the Treasury, Office of Foreign Assets Control, Advisory on Potential Sanctions Risks for Facilitating Ransomware Payments (1 October 2020); Updated Advisory on Potential Sanctions Risks for Facilitating Ransomware Payments (21 September 2021) pp 4–6.

37 Ransomware Task Force Report, supra, note 6, p 44; M Iwasaki, “Banning Ransomware Payments: Unintended Effects on Cybersecurity Investment and Incident Reporting” (2025) 6 International Cybersecurity Law Review 17, 19–20.

38 FinCEN, Advisory on Ransomware and the Use of the Financial System to Facilitate Ransom Payments FIN-2021-A004 (8 November 2021); for analysis, C Patsakis, E Politou, E Alepis and JC Hernandez-Castro, “Cashing Out Crypto: State of Practice in Ransom Payments” (2024) 23(2) International Journal of Information Security 699, 703–705.

39 Cyber Incident Reporting for Critical Infrastructure Act of 2022, Pub L No 117-103, div Y, codified at 6 USC § 681b(a)(2); Cybersecurity and Infrastructure Security Agency, “Cyber Incident Reporting for Critical Infrastructure Act of 2022 Reporting Requirements”, Notice of Proposed Rulemaking, 89 Fed Reg 23644 (4 April 2024) pp 23653–23656. The rulemaking is not final; the discussion is therefore tentative.

40 Worsley and others, supra, note 21, pp 264–267, mapping NC Gen Stat Ann § 143–800 (2021) and Fla Stat Ann § 282.3186 (2022).

41 Teichmann, supra, note 30, p 45 (“the number of reported attacks on NC public entities did not notably decrease after the ban”; “an isolated ban in one state or sector can be circumvented or may shift attackers’ focus rather than stop them outright”); Worsley and others, supra, note 21, p 273.

42 Home Office, Ransomware Legislative Proposals: Reducing Payments to Cyber Criminals and Increasing Incident Reporting (consultation, 14 January 2025).

43 Home Office, Government Response to Ransomware Legislative Proposals: Reducing Payments to Cyber Criminals and Increasing Incident Reporting (updated 2 September 2025).

44 Government Response, supra, note 43, analysis of Q6 and Q29; on State non-approval of payment, Home Office consultation, supra, note 42, paras. 51–53.

45 Government Response, supra, note 43, Q15 analysis (quoting respondent).

46 Čentéš and Rampášek, supra, note 22 (analysing the money-laundering, terrorism-financing and sanctions exposure of ransom payments under Czech and Slovak criminal law).

47 Čentéš and Rampášek, supra, note 22, p 577.

48 Teichmann, supra, note 30, pp 47–48 (summarising the April 2024 testimony of K Walden, former Acting US National Cyber Director: “we’d essentially be pressing victims to make their payments go underground”; a ban could “bankrupt the very small- and medium-sized businesses that the American economy relies upon”); for the empirical underpinning, Matthijsse and others, supra, note 19, pp 625–645.

49 Ayres and Braithwaite, supra, note 11, ch 2.

50 Ransomware Task Force Report, supra, note 6, Actions 4.2.4 and 4.3.1–4.3.3. The architecture proposed here departs from the RTF’s structure in that it integrates the pre-payment notice with a post-payment report and with a targeted ban, rather than treating these as discrete actions.

51 On the AML analogy and its limits in a victim-reporting context, see Mitsilegas, supra, note 16; Patsakis and others, supra, note 38, pp 706–707.

52 CIRCIA 6 USC § 681b(a)(2); CISA NPRM, supra, note 39, pp 23653–23656.

53 NIS2 Directive, Art. 3(1) and Annex I.

54 CRI 2023 Joint Statement, supra, note 35.

55 On the empirical case against criminalising victim entities, see Teichmann, supra, note 30, p 49; Worsley and others, supra, note 21, p 273; Government Response, supra, note 43, Q15 (preference for civil penalties).

56 European Commission, “Communication from the Commission to the European Parliament, the Council, the European Economic and Social Committee and the Committee of the Regions: European action plan on the cybersecurity of hospitals and healthcare providers” COM(2025) 10 final, 15 January 2025, section 2.

57 Footnote Ibid., section 3.

58 For the broader concern that overlapping reporting regimes generate compliance fatigue without commensurate enforcement gains, see Institute for Security and Technology, Doubling Down, supra, note 6, pp 12–13; Schmitz-Berndt, supra, note 26.

59 Ransomware Task Force Report, supra, note 6, Actions 4.3.2–4.3.3.

60 Regulation (EU) 2025/38 of the European Parliament and of the Council of 19 December 2024 laying down measures to strengthen solidarity and capacities in the Union to detect, prepare for and respond to cyber threats and incidents and amending Regulation (EU) 2021/694 (Cyber Solidarity Act) [2025] OJ L 2025/38; for the design idea of a victim-support fund, Ransomware Task Force Report, supra, note 6, Action 4.1.2.

61 Proposal COM(2026) 13 final, supra, note 5, Art. 1(8), inserting new Art. 23(13) NIS2.

62 Arts. 8, 10 and 11 NIS2 Directive (designation of competent authorities, CSIRTs, single points of contact); Proposal COM(2026) 13 final, supra, note 5, Art. 1(12), inserting new Art. 37a NIS2 (“ENISA’s role in mutual assistance”).

63 Teichmann, supra, note 30, p 47, quoting Walden’s statement that “we’d essentially be pressing victims to make their payments go underground.”

64 Government Response, supra, note 43, Q15 (“Penalising organisations for non-compliance is counterproductive and risks discouraging transparency and reporting. Criminal or civil penalties could push incidents underground, reducing visibility into ransomware threats and hindering collective efforts to combat them”).

65 Regulation (EU) 2023/1113 of the European Parliament and of the Council of 31 May 2023 on information accompanying transfers of funds and certain crypto-assets [2023] OJ L150/1; read alongside Regulation (EU) 2023/1114 (MiCA) [2023] OJ L150/40.

66 CRI 2023 Joint Statement, supra, note 35; Radu, supra, note 35.

67 T J van Benthem and R Radu, “Domestic and International Approaches to Combating Ransomware: Between Contradiction and Coherence” (2026) 34 International Journal of Law and Information Technology eaag004; Teichmann, supra, note 30, p 58.

68 Iwasaki, supra, note 37, pp 19–20.

69 On the case for an integrated technical-legal framework, see M Robles-Carrillo and P García-Teodoro, “Ransomware: An Interdisciplinary Technical and Legal Approach” (2022) 2022 Security and Communication Networks 2806605, 8–10.

Ibid
Figure 0

Table 1.The payment-governance framework: three risk-based pillars and supporting safeguards for victims and authorities.Table 1 long description.