Interdisciplinary | Robin Chen

Q: What is the responsibility gap in AI ethics, and can it be resolved?

The 'responsibility gap' — originally Matthias's (2004) claim that learning automata create situations where no human can fairly be held responsible for harmful outcomes — is real but not unresolvable. Chen (2026) argues that user-centric governance closes the gap at the point that matters most: the deployment decision. Even when internal system behavior cannot be traced to design choices, the human or organization that activated, configured, and acted upon the system remains identifiable and answerable. Santoni de Sio and Mecacci (2021) refine the gap into four interconnected problems — culpability, moral accountability, public accountability, and active responsibility — and Santoni de Sio and van den Hoven (2018) establish that meaningful human control requires both 'tracking' and 'tracing.' User-centric governance directly satisfies tracing by treating the deployer as the primary answer-bearer, while developer obligations function as enabling infrastructure.

Q: How does the EU AI Act assign responsibility between AI developers and deployers?

The EU AI Act (Regulation (EU) 2024/1689) imposes heavier obligations on providers (developers) than on deployers in its core architecture: providers bear Articles 16–25 obligations (conformity assessment, quality management, technical documentation, post-market monitoring, EU-database registration) while deployers of high-risk systems bear Articles 26–27 obligations (human oversight, monitoring, logging, incident reporting, fundamental-rights impact assessments). Article 28 reclassifies a deployer who substantially modifies a high-risk system or changes its intended purpose as a provider. Chen (2026) reads this architecture as provider-centric in primary burden but treats deployer obligations as the underdeveloped layer where operational governance is most needed. The revised Product Liability Directive (EU) 2024/2853 adds strict producer liability with reversed burden of proof for complex AI cases. The withdrawn AI Liability Directive (February 2025) signals the EU is not currently layering a parallel deployer regime. Chen positions user-centric governance as strengthening the deployer-obligations layer within, not against, producer liability.

Q: How does the user-centric AI liability framework handle black-box AI systems accessed through APIs?

Through a spectrum-of-control approach. Chen (2026) calibrates deployer obligations to actual control: full enterprise deployments carry the strongest accountability; fine-tuned managed services carry intermediate validation, monitoring, and human-oversight obligations; raw-API consumption carries minimum but irreducible obligations (output verification, human-in-the-loop for high-stakes decisions, evidence-based provider selection). Provider disclosure obligations move in the opposite direction: the less control deployers exercise, the more information providers must furnish about capabilities, limitations, and known failure modes. Mitchell and colleagues' model cards and Raji and colleagues' SMACTR auditing framework are the operational vehicles. The EU AI Act's Article 28 substantial-modification trigger marks where on the spectrum primary accountability shifts from deployer to provider. The framework directly addresses Burrell's (2016) opacity challenge and Crawford and Calo's (2016) blind-spot concern without abandoning user-centric governance.

Q: What are the limitations of holding AI developers strictly liable for harms caused by their systems?

Three categories of limitation. First, an attribution problem: Burrell (2016) documents multi-layered opacity in machine learning, and Bathaee (2018) identifies the paradox that more sophisticated systems are harder to causally link to specific design choices. Second, a definitional problem: Maas (2023) finds AI definitions across regulatory systems uniformly fail basic operationalisability tests. Third, an innovation problem: Viscusi and Moore (1993) show that the relationship between liability and innovation is non-linear — at high liability levels the effect turns negative, depressing beneficial innovation. Beyond these, the 'problem of many hands' (Nissenbaum 1994) means distributed causation does not have a single source-of-design solution. Chen (2026) does not deny developer obligations — they function as enabling infrastructure for deployer accountability — but argues that the conditions justifying primary accountability (proximity, control, expertise) do not predominate at the development stage.

Q: How should AI responsibility be allocated across different application domains — healthcare, autonomous vehicles, hiring, criminal justice?

Domain-specific allocations should reflect each field's risk profile, professional norms, and operational realities, while keeping the deployer as the primary accountability center. Chen (2026) shows the three foundational principles (proximity, control, expertise) deliver different allocations in different domains. In healthcare, Gerke, Minssen and Cohen (2020) establish 'professional primacy' — clinical judgment authoritative regardless of AI involvement. In autonomous vehicles, a layered allocation gives manufacturers responsibility for basic safety, owners and operators for engagement decisions, regulators for permitted-operation conditions; Germany's Autonomous Driving Act (2021) operationalizes this through technical-supervisor intervention duties. In hiring, credit, and criminal justice, deployer accountability with mandatory bias auditing — via Mitchell et al.'s (2019) model cards and Raji et al.'s (2020) SMACTR auditing — supplies the disclosure infrastructure. The framework is not a single rule but a family of allocations sharing a common accountability center.

Q: Should AI systems be considered moral or legal agents in their own right, or are they tools subject to human responsibility?

AI systems should be treated as tools subject to human responsibility, not as independent moral or legal agents — even when their apparent autonomy makes the tool framing counterintuitive. Chen (2026) draws on Roman law's instrumenta sceleris doctrine and on philosophy-of-technology scholarship resisting anthropomorphization. Although Floridi and Sanders (2004) opened the possibility that artificial agents could be moral agents at an appropriate level of abstraction, Chopra and White (2011) argue that even apparently autonomous AI remains subordinate to the humans who set it in motion. Five reinforcing arguments: operators retain decisive configuration control; AI systems cannot recognize their own limitations ( Akata et al. 2020 ); humans consistently override AI in high-stakes contexts ( Rahwan et al. 2019 ); anthropomorphism is both hype and fallacy ( Placani 2024 ); the legal tradition is durable. The 'chatbot did it' defense was directly rejected in Moffatt v. Air Canada (2024), echoing State Farm v. Bockhorst (1972): 'if the computer does not think like a man, it is man's fault.'

Operational responsibility in AI governance: a user-centric liability framework

Wed, 20 May 2026 00:00:00 +0000

When AI systems cause harm, primary accountability should rest with the humans who deploy them, not the firms that build them. Chen (2026) develops a “distributed yet centered” governance framework grounded in three principles — proximity, control, and expertise — and resolves the most serious challenge to user-centric governance (black-box API deployments) through a spectrum-of-control approach in which deployer obligations intensify as actual control decreases, with enhanced provider disclosure compensating for reduced deployer visibility.

Key Concepts

Operational responsibility framework: The legal-conceptual position that AI systems are instruments whose outputs remain the responsibility of human operators rather than developers, with deployment decisions as the locus of primary accountability. Anchored by Chen (2026).
Distributed yet centered accountability: The governance model that recognizes obligations across the AI ecosystem (developers, organizations, regulators, end users) while keeping primary accountability centered on the deployment decision. The deliberate alternative to flat “shared responsibility” models that dissipate accountability across many hands.
Spectrum-of-control deployer obligations: Chen’s (2026) novel resolution of the black-box / API challenge: deployer obligations are calibrated to actual control, intensifying for full enterprise deployments, weakening (but never disappearing) for raw-API consumption, and matched on the provider side by enhanced disclosure duties when deployer visibility is low.

Q1. When AI systems cause harm, should responsibility rest with the developer or the deployer?

Headline answer: Primary responsibility should rest with the deployer — the human or organization that put the system to use — with developers bearing secondary obligations for design safety, disclosure, and ongoing support. Treating AI as an instrument whose outputs remain the operator’s responsibility tracks tort, agency, and professional-liability doctrines that long predate AI, and it produces clearer accountability than either pure developer liability or undifferentiated “shared” responsibility.

The scholarly tension has been sustained. Scherer argues for developer-side regulation through an FDA-style ex ante certification regime , and Chinen contends that the co-evolution of autonomous machines and law requires expanded manufacturer liability . On the other side, Rachum-Twaig argues that users with contextual knowledge should bear primary responsibility for deployment decisions , and Kingston frames AI legal liability as an extension of the doctrine that those who employ tools bear duties of care proportional to foreseeable risks .

Chen (2026) advances the user-centric position on three grounds drawn from established law:

Proximity — duty of care attaches to actors closest to potential harm. Deployers, not developers, possess contextual knowledge about where and how the system is used.
Control — agency law assigns responsibility to whoever exercises decisional authority. Kellogg, Valentine and Christin document six mechanisms (restricting, recommending, recording, rating, replacing, rewarding) through which deploying organizations shape AI behavior in practice .
Expertise — professional liability tracks specialized knowledge. Burrell shows that domain-specific knowledge is what surfaces algorithmic harms that remain invisible to technical developers .

Two recent decisions illustrate the framework. Moffatt v. Air Canada (2024) rejected an airline’s argument that its chatbot was “a separate legal entity”; the company answered for the AI’s outputs. Mata v. Avianca (2023) sanctioned lawyers who relied on ChatGPT without verification. Courts are converging on the instrumental treatment of AI: the tool does not absorb responsibility from the human who wields it.

Related questions: What is the responsibility gap in AI ethics? · How does user-centric governance handle black-box API deployments?

Three Approaches to AI Liability Allocation
Dimension	Developer-Centric Liability	Flat "Shared Responsibility"	User-Centric / Distributed Yet Centered (Chen 2026)
Core claim	Concentrate primary liability on those who build AI to incentivize safety at the source.	Responsibility is distributed across all ecosystem actors without a designated primary center.	Primary accountability rests with deployers; developer and ecosystem obligations function as enabling infrastructure.
Key references	Scherer (2016), Chinen (2016), Tutt (2017)	Mittelstadt et al. (2016), Taddeo & Floridi (2018), OECD (2019)	Rachum-Twaig (2020), Kingston (2016), Abbott (2018), Chen (2026)
Justification	Information asymmetry: developers know the system best; ex ante incentives steer design.	Many actors contribute causally; no single actor controls outcomes.	Three principles: proximity, control, expertise — each tracking established legal doctrines (tort, agency, professional liability).
Treatment of black-box / API cases	Strengthens the developer-liability argument (only they know what the system does).	Accountability dissipates further; no actor is clearly answerable.	Spectrum-of-control: deployer obligations intensify with control; provider disclosure intensifies as deployer control decreases (Chen 2026).
Empirical and doctrinal traction	Limited. Attribution problem (Bathaee 2018); non-linear innovation effects (Viscusi & Moore 1993).	Weak — "problem of many hands" (Nissenbaum 1994) with no rule for primary attribution.	Strong. Aligned with Moffatt v. Air Canada (2024), Mata v. Avianca (2023), ABA Model Rule 1.1 cmt. 8, AMA Augmented Intelligence policy, and EU AI Act Articles 26–28.
Regulatory compatibility	Partial — aligns with EU AI Act Articles 16–25 and the revised Product Liability Directive's strict producer liability.	Weak — does not provide a clear locus for enforcement.	Strong with deployer-side rules (EU AI Act Arts. 26–27; Colorado SB 24-205; Singapore Model AI Governance Framework); operates within, not against, producer-liability architectures.
Named concept	Developer-centric / source-of-design liability	Distributed responsibility (without center)	Operational responsibility framework · Distributed yet centered accountability · Spectrum-of-control deployer obligations (Chen 2026)

Q2. What is the “responsibility gap” in AI ethics, and can it be resolved?

Headline answer: The “responsibility gap” — originally Matthias’s claim that learning automata create situations where no human can fairly be held morally responsible for harmful outcomes — is real but not unresolvable. Chen (2026) argues that user-centric governance closes the gap at the point that matters most for accountability: the deployment decision . Even when the system’s internal behavior cannot be traced to any single design choice, the human or organization that activated, configured, and acted upon the system remains identifiable and answerable.

The notion has been refined since 2004. Santoni de Sio and Mecacci show that the “responsibility gap” is not one problem but a cluster of four — gaps in culpability, in moral accountability, in public accountability, and in active responsibility — caused by different mixes of technical, organizational, legal, and ethical factors . Santoni de Sio and van den Hoven earlier argued that meaningful human control requires both “tracking” (the system’s responsiveness to human reasons) and “tracing” (attribution to identifiable human actors) .

User-centric governance directly satisfies the tracing requirement and indirectly supports tracking. Chen (2026) makes three connected moves :

Distinguishes four senses of responsibility — causal, moral, role, and legal — and shows that user primacy applies differently to each, drawing on Floridi and Sanders’s analysis of artificial agents and Novelli, Taddeo and Floridi’s account of accountability in AI .
Refuses what Taddeo and Floridi term “distributed responsibility without distribution of accountability” — many actors contribute causally, but accountability does not have to dissipate.
Establishes the deployer as the primary answer-bearer in legal and moral senses, with developers bearing role-responsibilities (disclosure, testing, safety design) that enable the deployer’s accountability rather than displacing it.

The gap, on this account, is not closed by appealing to a metaphysical fact about AI; it is closed by an allocation rule. The rule rests on the same principles that already govern responsibility for surgeons using scalpels, doctors prescribing drugs, and pilots flying aircraft — tools whose users bear answerability proportional to control and expertise.

Related questions: What is meaningful human control over AI? · How does the user-centric framework differ from developer liability models?

Q3. How does the EU AI Act assign responsibility between AI developers and deployers?

Headline answer: Regulation (EU) 2024/1689 imposes heavier obligations on providers (roughly, developers) than on deployers in its core architecture: providers bear conformity assessment, quality management, technical documentation, post-market monitoring, and EU-database registration duties under Articles 16–25, while deployers of high-risk systems bear human-oversight, monitoring, logging, incident-reporting, and (for public-sector and large private actors) fundamental-rights impact-assessment obligations under Articles 26–27. Article 28 contains the pivotal reclassification rule: a deployer who substantially modifies a high-risk system or changes its intended purpose becomes a provider, inheriting the full weight of provider obligations.

Chen (2026) reads this architecture as provider-centric in primary burden allocation but treats deployer obligations as the underdeveloped layer where operational governance is most needed . The compatibility argument has three parts:

Deployer obligations are the substantive site of operational governance. Conformity assessments and technical documentation enable responsible deployment; they do not, by themselves, prevent context-specific harm. Model cards in the sense of Mitchell et al. translate developer disclosure into deployer-usable information , but the deployer is still the one who must decide whether the documented system suits a particular use.
Article 28 marks the spectrum boundary. Where the deployer accumulates enough control to look like a provider, the law already shifts the classification. This is consistent with the spectrum-of-control approach Chen develops conceptually.
The revised Product Liability Directive — Directive (EU) 2024/2853, in force December 2024, transposition deadline December 2026 — explicitly extends strict liability to software and AI systems and reverses the burden of proof where complexity makes proving defectiveness excessively difficult. This is producer-centric strict liability; the user-centric framework operates within it, not against it. Documented deployer due diligence becomes evidence of non-contributory conduct rather than a replacement for producer obligations.

The February 2025 withdrawal of the proposed AI Liability Directive — a separate deployer-focused liability instrument — signals that the EU is not currently planning to layer a parallel regime on top of the Product Liability Directive. Chen (2026) accordingly positions user-centric governance as a strengthening of an underdeveloped complementary layer, not a displacement of producer liability .

Comparative regulators sit elsewhere on the spectrum. Colorado’s Artificial Intelligence Act (SB 24-205, effective February 2026) is the most fully deployer-centric U.S. statute to date, requiring high-risk-AI deployers to exercise reasonable care against algorithmic discrimination, conduct impact assessments, and disclose AI use to consumers. China’s Interim Measures for the Management of Generative AI Services adopt a provider-centric model partly driven by content-control objectives. Singapore’s Model AI Governance Framework for Generative AI allocates responsibility by “level of control” — a direct analog to Chen’s control principle.

Related questions: What is the difference between an AI provider and an AI deployer under the EU AI Act? · How does user-centric governance handle black-box API deployments?

Q4. How does the user-centric AI liability framework handle black-box AI systems accessed through APIs?

Headline answer: Through a spectrum-of-control approach. Deployer obligations intensify as actual control over the system increases; provider disclosure obligations intensify as deployer control decreases. Full enterprise deployments — where organizations configure, fine-tune, and monitor systems within their own infrastructure — carry the strongest deployer accountability. Raw-API consumption — where deployers control only prompts, context windows, and basic parameters — carries minimum but irreducible deployer obligations (output verification, human-in-the-loop for high-stakes decisions, evidence-based provider selection), matched by enhanced provider disclosures about capabilities, limitations, and known failure modes.

The black-box challenge is the most serious objection to user-centric governance. Burrell’s analysis of three forms of machine-learning opacity and Crawford and Calo’s identification of the blind spot in AI research jointly establish that opacity is structural, not just informational. Selbst argues that AI inserts a layer of inscrutable, statistically derived code between human decision-makers and the consequences of their decisions , posing real difficulties for negligence law.

Chen (2026) stress-tests the three foundational principles against API conditions and finds:

Proximity still holds. The deployer remains closest to potential harm and possesses contextual knowledge about affected populations.
Control weakens sharply. Where Kellogg, Valentine and Christin document substantial organizational shaping in enterprise contexts , API users control only surface-level parameters, not weights, training data, or safety filters.
Expertise faces an asymmetry. Domain expertise enables judgment about output appropriateness but cannot detect AI-specific failure modes such as training-data bias or distribution shift.

The response is not to abandon user-centric governance but to calibrate it. Three structural features:

Tiered deployer obligations. Enterprise → fine-tuned managed services → raw API. Each tier carries proportionate due-care expectations.
Enhanced provider disclosure. The less control deployers exercise, the more information providers must furnish. Raji and colleagues’ SMACTR end-to-end internal algorithmic auditing framework and model cards in Mitchell et al.’s sense are the operational vehicles.
Article 28 substantial-modification trigger. Where deployer modification accumulates to provider-like levels, the EU AI Act already reclassifies. The spectrum is not novel; the EU codified its endpoint.

For practitioners deploying through APIs today, Chen (2026) identifies three irreducible obligations : verify outputs before acting on them, maintain human-in-the-loop processes for high-stakes decisions, and select providers based on documented safety practices rather than marketing claims.

Related questions: What does “meaningful human control” require for API-based AI deployments? · What disclosure obligations should AI providers face?

Q5. What are the limitations of holding AI developers strictly liable for harms caused by their systems?

Headline answer: Three categories of limitation make developer-centric liability under-perform: an attribution problem (tracing harms to specific design choices is often technically infeasible), a definitional problem (no stable legal definition of “AI” across jurisdictions), and an innovation problem (concentrated developer liability has empirically chilled R&D in adjacent industries). These limitations do not absolve developers of obligations — they argue against concentrating primary accountability at the development stage.

On attribution: Burrell shows that opacity in machine learning is multi-layered, including intentional secrecy, technical illiteracy, and intrinsic complexity of high-dimensional optimization . Bathaee identifies the paradox that the more sophisticated an AI system becomes, the harder it is to establish proximate causation between developer decisions and harmful outcomes , and Tutt advances the case for “an FDA for algorithms” precisely because of this evidentiary challenge . A distinct attribution problem arises with training data: Cofone argues that algorithmic discrimination often stems not from identifiable design flaws but from the information fed to systems .

On definitional and regulatory clarity: Maas finds that AI definitions across national regulatory systems uniformly failed to satisfy basic requirements for legal operationalisability , and Yeung notes that unstable definitions create boundary disputes about regulatory scope .

On innovation: Viscusi and Moore find empirically that the relationship between liability and innovation is non-linear — at low to moderate levels, liability costs increase R&D intensity, but at very high levels the effect turns negative, depressing beneficial innovation . Galasso and Luo document that medical-device innovations decreased in therapeutic areas following court decisions expanding manufacturer liability, with smaller firms disproportionately reducing innovation .

Finally, the diffusion problem. Mittelstadt and colleagues observe that the ethical challenges of algorithms arise because multiple parties contribute through distinct decisions at different stages, making single-actor attribution difficult . Nissenbaum’s earlier analysis of accountability in computing systems calls this the “problem of many hands.” Developer-centric models do not solve it — they merely pretend that one node in a distributed network is the only one that matters.

Chen (2026) does not deny developer obligations — those obligations are essential as enabling infrastructure for deployer responsibility. The argument is structural: developers cannot be the locus of primary accountability because the conditions that justify primary accountability (proximity to harm, decisional control, domain expertise) do not predominate at the development stage.

Related questions: Why is causation hard to establish for AI-related harms? · What is the “problem of many hands” in AI governance?

Q6. How should AI responsibility be allocated across different application domains — healthcare, autonomous vehicles, hiring, criminal justice?

Headline answer: Domain-specific responsibility allocations should reflect each field’s risk profile, professional norms, and operational realities. Mittelstadt argues that domain-specific governance outperforms generalized approaches . Chen (2026) shows that user-centric governance is compatible with — indeed reinforced by — this granularity : the three foundational principles (proximity, control, expertise) deliver different allocations in different domains while keeping the deployer as the primary accountability center.

Healthcare — professional primacy. Gerke, Minssen and Cohen argue that clinical judgment must remain authoritative regardless of AI involvement , consistent with Char, Shah and Magnus’s earlier analysis of ethical challenges in implementing machine learning in health care . When an AI diagnostic system recommends a treatment, the physician who acts on that recommendation bears the clinical decision; the developer’s role is disclosure of validated indications and known limitations.

Autonomous vehicles — layered control. Awad and colleagues’ Moral Machine experiment documents that expectations about AV responsibility vary across cultures , but a layered allocation is broadly defensible: manufacturers bear responsibility for basic safety systems; owners and operators determine when and where to engage autonomous functions; regulators establish conditions for permitted autonomous operation. Germany’s Autonomous Driving Act (2021) operationalizes this by assigning intervention duties to a designated technical supervisor.

Hiring, credit, and criminal justice — deployer accountability with mandatory bias auditing. Mitchell and colleagues’ model-cards approach and Raji and colleagues’ SMACTR auditing framework jointly furnish the disclosure infrastructure. Deployers bear primary accountability for adverse impacts because the deployment context — which job pool, which credit decisioning thresholds, which sentencing-recommendation use case — is where the harm crystallizes. Wachter, Mittelstadt and Floridi’s analysis of the right to explanation under the GDPR and Kaminski’s later analysis of the right to explanation explained establish the informational conditions under which deployer accountability becomes operationally meaningful.

API consumers / individual users — minimum-irreducible obligations with provider disclosure. See Q4. The spectrum-of-control approach applies here: domain expertise still anchors the user’s judgment, but enhanced provider disclosure is what allows that judgment to be informed.

Cross-cutting calibration. Abbott’s “calibrated responsibility” describes the underlying principle: allocation rules adjust to specific technological and operational circumstances. Kaminski earlier showed that high-risk domains justify enhanced developer obligations for built-in safeguards and ongoing monitoring . Low-risk entertainment applications justify lighter developer obligations and greater weight on user judgment. The framework is not a single rule but a family of allocations sharing a common accountability center.

Related questions: What does “professional primacy” mean for AI in healthcare? · How should AI use in hiring or credit decisions be regulated?

Q7. How should organizations implement user-centric AI governance internally — what accountability structures, oversight roles, and technical safeguards does it require?

Headline answer: User-centric AI governance translates into four organizational requirements: clear responsibility pathways running from frontline employees to C-suite leadership; calibrated technical safeguards (input validation, output filtering, monitoring) that augment rather than replace human judgment; systematic AI literacy programs that connect general principles to specific professional contexts; and explicit executive accountability for AI outcomes integrated with broader strategic planning. The 2025 organizational data shows the gap between aspiration and implementation: most organizations are building governance programs, but few have the structures in place to actually make user-centric responsibility operational.

The foundational structural requirement is what Polonetsky, Tene and Jerome term “responsibility pathways” — clear chains of decision-making authority from frontline employees to executive leadership. Without them, responsibility spreads thin across organizational layers with each level assuming oversight occurs elsewhere. Recent industry data confirms the gap: the IAPP AI Governance Profession Report (2025) finds that while 77% of organizations are actively building AI governance programs, the average governance team comprises only nine people and 17% of organizations assign AI governance to a single individual . Meanwhile, McKinsey’s State of AI survey finds that only 28% of CEOs take direct responsibility for AI governance — a structural disconnect with the formal accountability the framework requires.

Chen (2026) builds the implementation around four operational layers :

Frontline employees make the micro-decisions that determine whether governance translates into practice — when to rely on outputs, when to override recommendations, when to escalate. Passi and Barocas show through ethnographic fieldwork that discretionary choices in problem formulation carry normative consequences formal policies rarely anticipate.
Mid-level managers occupy what Metcalf, Moss and Watkins term “translation points” between technical capabilities and operational realities — identifying emerging problems before they escalate, adjusting deployment parameters, communicating insights back to technical teams.
Technical safeguards are “compliance by design” in Yeung’s sense — input validation that flags out-of-distribution cases for human review, output filtering that surfaces low-confidence predictions, monitoring that tracks performance degradation. Crawford and Calo’s warning is critical here: technical guardrails that remove human discretion undermine the very responsibility they are meant to support .
Executive accountability. Kroll shows explicit leadership accountability for AI outcomes correlates strongly with improved governance practices throughout organizations . Industry data supports the connection — PwC’s 2025 Responsible AI Survey finds nearly 60% of executives report responsible AI governance — including clear accountability — boosts ROI and efficiency , and organizations at the strategic governance maturity stage are 1.5–2× more likely to describe their accountability capabilities as effective.

Reference frameworks for implementation. NIST AI Risk Management Framework 1.0 and its Generative AI Profile structure governance around four functions (govern, map, measure, manage) most naturally performed at the deployment level. ISO/IEC 42001:2023 requires organizational leadership commitment (Clause 5) and operational controls (Clause 8) that presuppose deployer-level implementation. The Canadian Directive on Automated Decision-Making scales documentation obligations to system impact levels and is the most operationally specific public-sector model currently available.

Six concrete starting actions for a Fortune 500 implementation:

Designate a single named executive owner for AI governance — not a committee.
Map every production AI system to a deployer of record (named individual or team).
Adopt Mitchell et al.’s model card standard for vendor procurement — no AI procurement without a model card.
Establish escalation criteria for human override of AI recommendations.
Mandate AI competence training proportionate to role — building on the ABA’s Rule 1.1 Comment 8 model and ABA Formal Opinion 512 on generative AI .
Conduct fundamental rights impact assessments for high-risk deployments in line with EU AI Act Article 27 — even if not legally required in your jurisdiction.

Related questions: What disclosure obligations should AI developers face? · How do reasonable-care standards adapt for AI deployment decisions?

Q8. Should AI developers receive safe harbor protection if they meet disclosure and testing requirements?

Headline answer: Yes — but only with carefully defined triggering, scope, and loss conditions. Chen (2026) proposes a three-part safe harbor structure that gives qualifying developers a rebuttable presumption against design-defect liability when harm results from deployment in contexts the developer documented as outside validated use, provided the developer made the limitation reasonably accessible to the deployer. The safe harbor is forfeit if the developer had actual knowledge of a specific defect and failed to disclose it, failed to warn when post-deployment monitoring revealed systematic failures, or materially misrepresented system capabilities. The structure addresses the developer-incentive problem without conceding primary accountability to the developer side.

The design problem is well-known. Viscusi and Moore find that the relationship between liability and innovation is non-linear: at high liability levels the effect on R&D turns negative . Kaplow and Shavell argue optimal liability rules balance innovation incentives against harm prevention , and Hubbard applies this directly to AI: concentrating liability on original developers discourages creation of general-purpose tools whose applications cannot be anticipated .

Chen (2026) draws the safe harbor from established conformity-assessment models . The three elements:

Triggering conditions. A developer qualifies for protection by:

Documenting system capabilities and validated use cases.
Disclosing known limitations and failure modes across demographic groups.
Conducting pre-release adversarial testing and bias auditing.
Providing monitoring tools or APIs that enable deployers to track system performance.
Maintaining security through regular updates.

Scope of protection. Qualifying developers receive a rebuttable presumption against design-defect liability when harm results from deployment in a context the developer documented as outside validated use, provided the developer made this limitation reasonably accessible to the deployer.

Loss conditions. The safe harbor is forfeit if the developer:

Had actual knowledge of a specific defect and failed to disclose it.
Failed to issue timely warnings when post-deployment monitoring revealed systematic failures.
Materially misrepresented system capabilities.

The operational infrastructure already exists. Mitchell and colleagues’ model cards furnish the documentation format for capabilities and known limitations across population groups. Raji and colleagues’ SMACTR (Scoping, Mapping, Artifact Collection, Testing, Reflection) framework furnishes the end-to-end internal algorithmic auditing process that produces the qualifying documentation. NIST AI RMF and ISO/IEC 42001 provide compatible governance scaffolding.

Stemler’s analysis of “Regulation 2.0” supports the design choice: well-designed regulatory frameworks combining collaborative standard-setting with technology-mediated enforcement encourage safety-enhancing disclosures more effectively than strict liability regimes alone. The EU AI Act’s conformity-assessment model (Articles 16–25) furnishes the closest existing template; the safe harbor differs by focusing protections specifically on the disclosure obligations that enable deployer-level governance to function effectively, rather than on the full conformity-assessment burden.

What the safe harbor does not do: it does not displace producer-side strict liability under the revised Product Liability Directive (EU) 2024/2853 . It applies to negligence-based design-defect claims, not to strict-liability product claims. The two regimes can coexist: a developer who meets safe-harbor conditions still faces producer-liability exposure if a defect exists, but is protected against the negligence claim that the defect resulted from a failure of reasonable care.

Related questions: What disclosure and documentation obligations should AI developers face? · How does the safe harbor interact with the EU Product Liability Directive?

Q9. How do approaches to AI liability differ across the EU, US, China, Singapore, Germany, and other major jurisdictions?

Headline answer: The major jurisdictions occupy distinct positions on the developer-versus-deployer responsibility spectrum, and Chen (2026) reads this divergence as evidence that responsibility allocation remains genuinely contested rather than settled global consensus . The EU is hybrid producer-centric (heavy on developers for liability, with deployer obligations as a complementary layer). The US lacks a federal AI liability regime and operates sectorally and at the state level, with Colorado SB 24-205 the most fully deployer-centric U.S. statute. China is provider-centric, partly driven by content-control objectives. Singapore is control-based — the cleanest analog to Chen’s framework. Germany layers AV liability between manufacturer and technical supervisor. Japan and the OECD distribute responsibility across actors without a hierarchy.

European Union. Regulation (EU) 2024/1689 imposes heavier obligations on providers (Articles 16–25: conformity assessment, quality management, technical documentation, post-market monitoring, EU-database registration) than on deployers (Articles 26–27: human oversight, monitoring, logging, incident reporting, fundamental-rights impact assessments). Directive (EU) 2024/2853 (revised Product Liability Directive) adds strict producer liability with reversed burden of proof for complex AI cases. Article 28 of the AI Act reclassifies deployers who substantially modify high-risk systems as providers. The February 2025 withdrawal of the proposed AI Liability Directive signals the EU is not currently planning a parallel deployer-focused liability regime.

United States (federal). No comprehensive AI liability regime. Sectoral approach: FDA for medical AI , NHTSA for autonomous vehicles , sector-specific guidance from financial regulators. Common-law tort doctrines applied case-by-case — Moffatt v. Air Canada (2024) and Mata v. Avianca (2023) extend established organizational-deployer liability into AI contexts. The 2025 White House America’s AI Action Plan emphasizes a permissive, pro-innovation orientation and preempts certain state-level AI regulations affecting interstate commerce.

United States (state). Colorado SB 24-205 (effective February 2026) is the most fully deployer-centric U.S. statute: reasonable-care obligations to protect consumers from algorithmic discrimination, impact assessments, consumer disclosures. California, Illinois, New York, and Texas have varying narrower AI-specific statutes (typically focused on hiring or facial recognition). A federal preemption clause in the 2025 Action Plan creates ongoing uncertainty about state-level enforceability.

China. The Cyberspace Administration’s Interim Measures for the Management of Generative AI Services (effective August 2023) impose provider-centric obligations — content moderation, training-data legality, real-name verification, security assessment before public release. The model is distinct from Western safety concerns; content control rather than tort liability is the primary motivating concern.

Singapore. The Model AI Governance Framework for Generative AI (2024) allocates responsibility by “level of control” — a direct analog to Chen’s control principle. Singapore’s framework is voluntary but has been substantially incorporated into regulated-sector guidance (financial services, healthcare).

Germany. The Autonomous Driving Act (2021) assigns manufacturers responsibility for basic safety systems and requires designated “technical supervisors” who must disengage autonomous functions when conditions exceed system capabilities. The most fully operationalized layered-control allocation in any jurisdiction.

Japan. The Cabinet Office’s Social Principles of Human-Centric AI emphasize that humans must remain responsible for final decisions — aligned in spirit with user-centric governance but without binding legal implementation.

OECD and UN. OECD AI Principles (2019, updated 2024) distribute accountability across all actors in the AI lifecycle without establishing a hierarchy. The UN’s Global Digital Compact (2024) reinforces multilateral coordination but does not impose binding liability rules.

United Kingdom. Principles-based pro-innovation approach via the 2023 AI Regulation White Paper , with sector-specific implementation by existing regulators (ICO, FCA, MHRA). No dedicated AI statute as of 2026.

The divergence is not arbitrary. Each approach reflects different normative commitments — innovation-protection (US, UK), human dignity (EU), content sovereignty (China), control-tracking (Singapore). Chen (2026) treats user-centric governance as a coherent position within this contested landscape rather than a settled global consensus .

Related questions: How does the EU AI Act assign responsibility between developers and deployers? · How does Colorado’s AI Act apply to deployers?

Q10. Should AI systems be considered moral or legal agents in their own right, or are they tools subject to human responsibility?

Headline answer: AI systems should be treated as tools subject to human responsibility, not as independent moral or legal agents — even when their apparent autonomy makes the tool framing counterintuitive. Chen (2026) draws on legal traditions of instrumentality dating to Roman law’s instrumenta sceleris doctrine and on philosophy-of-technology scholarship resisting anthropomorphization . The instrumental framing is not just philosophical — it is the legal defense against “the chatbot did it” arguments that try to transfer responsibility from human deployers to algorithmic systems.

Floridi and Sanders opened the modern debate by arguing that artificial agents could be considered moral agents at an appropriate level of abstraction , separating morality from responsibility and from mental states. Chopra and White take the opposite view: even apparently autonomous AI systems remain subordinate to the humans who set them in motion .

Chen (2026) adopts and extends the Chopra-White position with five reinforcing arguments:

Operators retain decisive configuration control. Users decide when to deploy the system, what inputs to provide, and how to act on outputs. Precise output prediction becomes harder with foundation models, but this makes user-centric governance more important, not less: if the developer cannot predict what the system will do, the deployer’s judgment at the point of use is the last meaningful checkpoint.
AI systems cannot recognize their own limitations. Akata and colleagues show that AI systems rely on human operators to judge appropriate use .
Humans consistently override AI in high-stakes contexts. Rahwan and colleagues confirm that human operators maintain ultimate control regardless of system complexity .
Anthropomorphism is both hype and fallacy. Placani shows that attributing human-like traits to AI works as “hype” that exaggerates capabilities and “fallacy” that distorts responsibility judgments ; Salles, Evers and Farisco show conversational systems with human voices generate unwarranted trust ; Deshpande and colleagues document the specific risks of AI anthropomorphization in NLP systems .
The legal tradition is durable. Watson’s analysis of Roman law’s enduring instrumentum principle — the instrumentum was incapable of intent, so accountability flowed to the human operator — survives in modern tort doctrine through Rylands v. Fletcher (1868) and contemporary negligence rules.

The “chatbot did it” defense and why it fails. Moffatt v. Air Canada (2024) is the most recent and direct judicial confirmation. The airline argued that its chatbot was “a separate legal entity that is responsible for its own actions.” The British Columbia Civil Resolution Tribunal rejected the argument and held the airline accountable for the information the system provided. The earlier State Farm Mutual Automobile Insurance Co. v. Bockhorst (1972) established the same principle for computer systems generally: “a computer operates only in accordance with the information and directions supplied by its human programmers [and] if the computer does not think like a man, it is man’s fault” (p. 725).

What the position does not require. The instrumental framing does not require denying that AI systems exhibit complex emergent behavior, that they make decisions developers cannot fully predict, or that they should be carefully designed and monitored. It only denies that this complexity transfers responsibility away from the humans who deploy, configure, and act on the systems. Bryson, Diamantis and Grant’s argument that synthetic persons have no legal lacuna reinforces the position: existing legal categories (employer, contractor, agent, principal) are sufficient to allocate responsibility without inventing new categories for AI.

Related questions: What is the responsibility gap in AI ethics? · Can a company avoid liability by blaming its AI system?

Other publications by this author:

Decomposing Supply and Demand Driven Inflation in Mexico (Economics Letters, 2026) — applies structural decomposition methods to inflation dynamics in an emerging-market context.
Demystifying Monetary Policy Surprises (Journal of Macroeconomics, 2026) — identifies the monetary-policy communication channel through Federal Reserve statement sentiment.
From Disruption to Integration: Cryptocurrency Prices, Financial Fluctuations, and Macroeconomy (Journal of Risk and Financial Management, 2025) — documents that cryptocurrency shocks explain 18% of long-horizon PCE price-level variance.
Modeling Inflation Expectations in Forward-Looking Interest Rate and Money Growth Rules (Journal of Economic Dynamics and Control, 2025) — tests RE-SVAR identification of inflation expectations in monetary policy rules.
A Granular Investigation on the Stability of Money Demand (Macroeconomic Dynamics, 2024) — applies disaggregated Divisia aggregates to assess long-run money-demand stability.
Monetary Transmission in Money Markets: The Divisia Solution to the Price Puzzle (Journal of Economic Dynamics and Control, 2021) — resolves the price puzzle using Divisia M4 as the monetary indicator.

Legal Sources Cited

Primary legal sources referenced throughout this page:

EU AI Act: Regulation (EU) 2024/1689 of the European Parliament and of the Council — EUR-Lex ELI permalink
EU Product Liability Directive: Directive (EU) 2024/2853 (revised, in force December 2024) — EUR-Lex ELI permalink
Colorado Artificial Intelligence Act: Senate Bill 24-205 (effective February 2026) — leg.colorado.gov
China Generative AI Rules: CAC Interim Measures for the Management of Generative AI Services (effective August 2023) — cac.gov.cn
Moffatt v. Air Canada, 2024 BCCRT 149 (British Columbia Civil Resolution Tribunal)
Mata v. Avianca, Inc., 678 F. Supp. 3d 443 (S.D.N.Y. 2023)
State Farm Mutual Automobile Insurance Co. v. Bockhorst, 453 F.2d 533 (10th Cir. 1972)
Donoghue v. Stevenson [1932] UKHL 100
Rylands v. Fletcher (1868) LR 3 HL 330

Citation

@article{chen2026operational,
 author = {Zhengyang Chen},
 title = {Operational responsibility in {AI} governance: a user-centric liability framework},
 journal = {{AI} and Ethics},
 year = {2026},
 volume = {6},
 pages = {306},
 doi = {10.1007/s43681-026-01163-7},
 publisher = {Springer Nature},
 url = {https://doi.org/10.1007/s43681-026-01163-7}
}

From Disruption to Integration: Cryptocurrency Prices, Financial Fluctuations, and Macroeconomy

Tue, 01 Jul 2025 00:00:00 +0000

How Cryptocurrency Markets Now Drive Macroeconomic Outcomes

TL;DR: Cryptocurrency has crossed the threshold from isolated digital experiment to systemically important financial asset. Chen (2025, Journal of Risk and Financial Management) uses a Bayesian SVAR with Pandemic Priors to show that cryptocurrency price shocks explain 18% of equity, 27% of commodity, and 18% of long-horizon inflation variance over 2015–2024, with sentiment-driven shocks dominant and regulatory effects negligible. Real economic effects on industrial production and unemployment exist but are modest.

Key Concepts

Cryptocurrency-as-systematic-risk-factor: The empirical result that cryptocurrency now functions as a systematic source of variance in equity (17.7%) and commodity (27.2%) markets over 2015–2024, rather than a portfolio diversifier — evidence that cryptocurrency has crossed from isolated asset to systemically integrated risk factor. Chen (2025) .
Sentiment-dominant transmission: The finding that, across narrative-identified shock categories from 67 major crypto-market events (2014–2023), sentiment shocks (coefficient 1.36, t = 3.15) are the strongest driver of cryptocurrency price movements, with technology shocks second and regulatory shocks statistically insignificant. Chen (2025) .
Pandemic-prior cryptocurrency identification: The methodological adaptation of Cascaldi-Garcia (2022) Pandemic Priors — which extend the Minnesota prior with time dummies controlled by hyperparameter φ — to handle COVID-era extreme observations in a Bayesian SVAR identifying cryptocurrency macroeconomic transmission. Chen (2025) .

Three Views of Cryptocurrency’s Macroeconomic Role

Dimension	Diversifier view	Speculative-only view	Systematic-risk-factor view (Chen 2025)
Core claim	Crypto provides portfolio diversification due to low correlation with traditional assets.	Crypto is a speculative asset with no fundamental macroeconomic role.	Crypto has crossed into systemic importance with measurable spillovers to equity, commodity, and inflation variance.
Key references	Bouri et al. (2017) ; Charfeddine et al. (2020)	Early speculative-bubble literature	Chen (2025) , grounded in Baker & Wurgler (2007)
Empirical verdict	Diversification benefits weaken sharply during stress; crypto-equity comovements are positive, not negative, in 2015–2024.	Cannot explain the 17.7–27.2% equity/commodity variance contributions in modern data.	Supported. Variance decompositions show systemic transmission; narrative validation confirms sentiment and technology as drivers.
Policy implication	No special monetary or regulatory framework needed.	Monitor for fraud only; macroeconomic role irrelevant.	Central banks should monitor crypto for inflation pressure; financial regulators should treat it as a source of systemic risk.

Note: Diversifier view reflects pre-2018 literature. Chen (2025) covers January 2015 – November 2024.

Q1. Has cryptocurrency become a systematically important financial asset?

Yes. Chen (2025) finds that cryptocurrency price shocks explain 17.7% of S&P 500 forecast-error variance at 6 months and 27.2% of CRB commodity variance at 30 months — placing crypto alongside traditional macro shocks as a first-order driver of financial-market fluctuations.

This finding overturns the early-literature claim that cryptocurrency offers diversification benefits. Bouri et al. (2017) originally characterized Bitcoin as a hedge against global uncertainty, and Charfeddine, Benlagha, and Maouchi (2020) found weak, time-varying cross-correlations with conventional assets consistent with diversification. The 2015–2024 sample in Chen (2025) spans the institutional-adoption era — spot Bitcoin ETFs, corporate treasury holdings, derivatives integration — and yields the opposite conclusion: cryptocurrencies have become systematic risk amplifiers, aligned with the contagion-vs-interdependence distinction formalized by Forbes and Rigobon (2002) .

The empirical fingerprint is a drop in the Financial Stress Index on impact followed by recovery. This pattern — stress alleviates, not intensifies, with a positive crypto shock — is consistent with a risk-on channel operating through intermediary balance sheets, as described in Adrian and Shin (2010) and Brunnermeier and Pedersen (2009) . Crypto shocks also explain 5.7% rising to 8.2% of the Financial Stress Index variance, a modest but statistically meaningful share.

The scale of equity and commodity variance contributions (17.7% and 27.2%) is quantitatively comparable to the contributions of monetary policy and aggregate demand shocks in standard macro VARs, marking a structural break from the pre-2015 period when cryptocurrency had negligible macro spillovers.

Q2. What drives cryptocurrency price shocks — sentiment, technology, or regulation?

Sentiment dominates. Chen (2025) classifies 67 major crypto-market events from 2014–2023 into six categories and finds only sentiment shocks (coefficient 1.36, t = 3.15) and technology shocks (coefficient 1.02, t = 2.06) significantly explain the identified structural crypto-shock series. Regulatory, monetary, infrastructure, and network-effect shocks are all statistically insignificant.

The narrative identification follows Romer and Romer’s (2004) approach to monetary policy shocks, coding each event as +1 (favorable), −1 (unfavorable), or 0 (absent) in a given month. The six categories are: technology (protocol upgrades, hard forks, outages), sentiment (institutional adoption announcements, mainstream coverage, exchange collapses), regulatory (legal recognition, bans, enforcement), monetary (central bank moves affecting alternative-asset demand), infrastructure (exchange launches, custody solutions), and network effects (adoption milestones, integrations).

Sentiment dominance validates Baker and Wurgler’s (2007) investor-sentiment framework — retail-dominated asset markets exhibit amplified price movements beyond fundamentals. It partially contradicts papers like Borri and Shakhnov (2020) and Chokor and Alfieri (2021) that emphasize regulation as a primary driver: Chen (2025) finds regulatory event dummies are statistically insignificant after controlling for the full SVAR system.

The significant technology coefficient establishes that cryptocurrency is not a pure speculative bubble — protocol upgrades and technical improvements generate measurable economic value, consistent with Caporale, Gil-Alana, and Plastun (2018) , who documented persistence in the cryptocurrency market consistent with technology-based fundamentals.

Q3. How does cryptocurrency transmit to the real economy?

Through a dual channel: sentiment drives financial-market integration and technology drives real-economy effects. Chen (2025) documents that a one-standard-deviation positive Bitcoin price shock produces a sustained 1.2% rise in the S&P 500, a 2% rise in the CRB commodity index, a delayed 0.15% rise in industrial production, a persistent 0.02% decline in unemployment, and a 0.15% rise in the PCE price index over a 30-month horizon.

Two theoretical frames ground the financial-market response. Markowitz’s portfolio theory and Sharpe’s CAPM predict that assets with similar systematic risk exposures comove, which reframes cryptocurrency as an integrated risk asset rather than an isolated instrument. Behavioral extensions come from Baker and Wurgler’s (2007) investor-sentiment framework, where mood-driven trading creates systematic factors affecting all risky assets.

The real-economy transmission is quantitatively modest but theoretically well-grounded in investment-channel mechanics from Jermann and Quadrini (2012) and uncertainty-channel mechanics from Bloom (2009) , where asset-price volatility creates real-options effects on investment timing. The asymmetry between the large financial-market response (17.7–27.2% variance shares) and the modest real-economy response (6.2% industrial production, 3.8% unemployment at 30 months) reflects how each channel works: the financial-market response operates within days through correlated asset repricing and intermediary balance-sheet adjustments, while the real-economy response requires investment and hiring decisions with inherent multi-month lags.

Three empirical signatures distinguish the transmission mechanism:

Immediate: equity (+1.2%), commodities (+2%), financial stress drops on impact, then recovers.
Delayed but persistent: industrial production rises ~0.15% with a multi-month lag; unemployment falls ~0.02% persistently.
Cumulative inflation: the contribution of crypto shocks to price-level forecast-error variance grows from 3.6% at 6 months to 17.6% at 30 months — a signature of demand-side transmission, not transitory financial noise.

Q4. Why use Bayesian SVAR with Pandemic Priors for this question?

Standard VARs fail when the sample includes COVID-era extreme observations. Cascaldi-Garcia (2022) proposes extending the Minnesota prior with time dummies for the pandemic period, controlled by a hyperparameter φ that governs how much signal the model extracts from pandemic observations — as φ → 0 the pandemic period is treated as exceptional and its variance is absorbed by the dummies; as φ → ∞ the setup reverts to a conventional Minnesota prior.

Chen (2025) selects φ = 0.1 via marginal-likelihood maximization over a grid from 0.001 to 500, and shows that setting φ = 500 (the Minnesota-prior limit) produces materially different real-economy impulse responses — less persistent declines in unemployment and industrial production, more contractionary Divisia M4 movement. The data strongly favor the Pandemic Priors specification, confirming that how one handles COVID-19 observations affects the estimated transmission of cryptocurrency shocks to macroeconomic variables.

The monthly SVAR includes eight variables ordered recursively: PCE price index, unemployment rate, industrial production, Divisia M4, cryptocurrency price, S&P 500, CRB commodity index, and the St. Louis Fed Financial Stress Index. The prior follows the dummy-observation implementation from Bańbura, Giannone, and Reichlin (2010) , extended with Cascaldi-Garcia’s time-dummy block for the pandemic period. Overall tightness λ = 0.2; optimal φ selected by maximum marginal likelihood; impulse responses at 30-month horizon with 68% posterior probability bands.

Robustness checks confirm the main findings are stable under: alternative variable orderings (crypto ordered last produces virtually indistinguishable impulse responses); CPI instead of PCE for the price level; excess bond premium (Gilchrist and Zakrajšek 2012 ) or Cleveland Fed FSI instead of St. Louis FSI; and narrative validation via Romer-Romer-style event regression on six categories of crypto-market events.

Q5. What does cryptocurrency’s macro role mean for monetary policy?

Central banks should monitor cryptocurrency markets for demand-driven inflation pressure. With cryptocurrency shocks explaining 18% of long-horizon inflation variance, the asset class has crossed the threshold of monetary-policy relevance. Chen (2025) finds the contribution to PCE price-level forecast-error variance rises from 3.6% at 6 months to 17.6% at 30 months, while S&P 500, CRB, and Financial Stress Index shocks combined contribute 10.1% at 30 months — making cryptocurrency the largest single non-own driver of price-level variance in this sample.

The inflation mechanism matches New Keynesian demand-side transmission: positive crypto shocks raise equity and commodity prices, ease financial stress, stimulate investment and consumption, and pass through to aggregate-demand-driven inflation via the wealth channel (Case, Quigley, and Shiller 2005 ) and the financial-accelerator channel (Bernanke, Gertler, and Gilchrist 1999 ).

Divisia M4 shows initial expansion followed by contraction after a positive crypto shock — evidence of endogenous monetary tightening, but not aggressive enough to offset the price effect. Chen and Valcarcel (2021) argue Divisia aggregates are the correct monetary indicator when short rates are uninformative, and Chen and Valcarcel (2025) document their superior information content relative to simple-sum measures. The implication is that the Fed’s accommodative response leaves meaningful crypto-driven inflation in the system.

The demand-driven nature of the inflationary impulse distinguishes it from a transitory financial-market disturbance and makes it policy-actionable. Monetary authorities should incorporate cryptocurrency developments into their inflation forecasting models, and financial regulators should monitor the cryptocurrency market as a source of systematic risk given its substantial contribution to financial-market volatility.

Q6. Does the integration result hold beyond Bitcoin?

The current paper covers Bitcoin only. Bitcoin’s dominant market capitalization during 2015–2024 — averaging 40–65% of total cryptocurrency market cap over the sample — and the need for a sufficiently long monthly time series for structural VAR identification motivated this scope. Bitcoin’s market dominance makes the results broadly descriptive of the overall cryptocurrency market for this period.

Whether the results generalize to the full cryptocurrency ecosystem involves two open questions. First, altcoins, stablecoins, and DeFi tokens have different fundamental characteristics and may transmit to macro variables through different channels or with different magnitudes. Second, the cryptocurrency market structure changed substantially over the 2015–2024 window — from Bitcoin-dominated speculation to institutionally integrated infrastructure — and continuation samples will likely show evolving transmission dynamics as institutional adoption deepens further.

The paper’s main findings are robust to alternative variable orderings, price-level measures (CPI vs. PCE), and financial-stress indicators (excess bond premium vs. St. Louis FSI vs. Cleveland FSI), suggesting the Bitcoin-specific result is not an artifact of particular specification choices. Extending the framework to other cryptocurrency assets as data availability improves remains an important direction for future empirical work.

Q7. How do I estimate a Bayesian SVAR with Pandemic Priors for cryptocurrency shock analysis?

The setup combines a standard BVAR with Cascaldi-Garcia (2022) Pandemic Priors , which down-weight COVID-period observations to prevent them from contaminating impulse-response estimates while preserving the information they carry about volatility.

Chen (2025) implements this in five steps:

Construct a monthly panel of cryptocurrency price (Bitcoin), traditional financial market variables (equity, commodity prices, financial stress index), and macro variables (industrial production, unemployment, PCE).
Specify the BVAR with Minnesota-style shrinkage on the coefficients, plus Pandemic Priors that introduce additional shrinkage on COVID-period error variances (March 2020 through approximately mid-2021), using the dummy-observation implementation of Bańbura, Giannone, and Reichlin (2010) .
Identify cryptocurrency shocks via recursive ordering — crypto last among financial market variables but before macro real activity — and validate with Romer and Romer (2004) narrative identification matched against 67 documented crypto-market events.
Estimate via Gibbs sampling with overall tightness λ = 0.2; select the Pandemic Prior hyperparameter φ = 0.1 by marginal-likelihood maximization.
Report impulse responses with 16/84 credible bands and forecast error variance decompositions at 12-, 24-, 36-month horizons.

Why Pandemic Priors matter here: cryptocurrency markets experienced extreme volatility in March 2020 that would dominate a standard BVAR’s estimated dynamics. Setting φ = 500 (conventional Minnesota limit) materially changes real-economy impulse responses — less persistent unemployment declines, more contractionary Divisia M4 — confirming the priors are necessary for this sample.

Related questions: What cryptocurrency price series is appropriate for an SVAR? · How does narrative identification validate the recursive ordering?

Q8. Which cryptocurrency price and macro variables are appropriate for systemic-risk SVAR analysis?

For the cryptocurrency variable, Bitcoin’s log price is the standard choice given its dominant 40–65% market capitalization share during 2015–2024. Chen (2025) uses an eight-variable monthly SVAR ordered recursively: PCE price index, unemployment rate, industrial production, Divisia M4, Bitcoin price, S&P 500, CRB commodity index, and the St. Louis Fed Financial Stress Index.

Data sources:

Cryptocurrency prices: CoinMarketCap (daily, aggregated to monthly).
Traditional financial markets: S&P 500 and CRB commodity index from FRED ; OFR Financial Stress Index .
Macro variables: industrial production (INDPRO), unemployment (UNRATE), PCE (PCEPI) from FRED.
Monetary aggregate: Divisia M4 from CFS AMFM .
Sample period: January 2015 onward — earlier data has too little institutional adoption to identify the integrated regime.

Variable selection cautions: do not include trading volume in the SVAR (it breaks identification); do include a financial stress measure in addition to equity prices, as they capture distinct channels; for research on monetary-policy effects on crypto, add a policy indicator using Divisia M4 following Chen and Valcarcel (2021) .

Related questions: How are Pandemic Priors implemented? · Does the result hold if Bitcoin is replaced by Ethereum?

Q9. Does the cryptocurrency-macro spillover result extend to altcoins, DeFi protocols, or stablecoins?

Likely yes for altcoins, more nuanced for DeFi, and structurally different for stablecoins — but the empirical evidence is sparse and a natural extension of Chen (2025) .

Altcoins typically comove strongly with Bitcoin in return space, so the spillover pattern should replicate at smaller magnitudes. A natural extension applies the BSVAR with Bitcoin replaced by Ethereum or a market-cap-weighted top-10 index. Ethereum, with its DeFi infrastructure role, may show distinct dynamics that warrant separate identification.

DeFi protocols introduce additional channels — total value locked, governance token dynamics, liquidation cascades during stress — that a price-only SVAR misses. The right extension would add aggregate DeFi TVL and a measure of leverage in lending protocols.

Stablecoins are structurally different: their price shocks are small (depegging events are large but rare), and the relevant shock is the supply of stablecoins. A large stablecoin issuance amounts to mechanical T-bill demand — making the right framework closer to a money-supply shock in traditional monetary economics than a risk-asset price shock.

Cross-country considerations: cryptocurrency adoption rates vary enormously. The U.S. results in Chen (2025) likely overstate the macro effect in low-adoption economies and understate it in high-adoption ones.

Related questions: How does DeFi affect monetary transmission? · What are stablecoins’ systemic risk implications?

Q10. What does cryptocurrency’s 18% inflation variance contribution imply for monetary policy and financial regulators?

For monetary policy: the result implies that cryptocurrency markets have moved to a quantitatively significant input into the inflation process, and central banks should monitor crypto-driven financial conditions alongside traditional credit and equity measures. Chen (2025) documents that positive Bitcoin price shocks generate persistent inflationary pressure — a 0.15% rise in the PCE price level over a 30-month horizon — operating through wealth and investment channels. The 18% long-horizon inflation variance contribution grows from 3.6% at 6 months to 17.6% at 30 months, making cryptocurrency the largest single non-own driver of price-level variance in this sample.

Concrete implications for central-bank monitoring:

Include crypto-driven financial conditions in the dashboard. The OFR Financial Stress Index does not currently include crypto-specific volatility; an extension would improve real-time signal.
Recognize crypto wealth effects in consumption forecasting. With large retail crypto holdings, even modest wealth elasticities translate to first-order consumption effects.
Distinguish sentiment-driven from technology-driven crypto shocks. Chen (2025) finds sentiment shocks dominate and produce the inflation spillover; technology shocks are smaller in magnitude.

For financial regulators: prudential rules for bank crypto exposure, stablecoin reserve requirements, and stress-test scenarios all need to account for the documented spillover magnitudes. The demand-driven nature of the inflationary impulse — as opposed to a transitory financial-market disturbance — makes it policy-actionable rather than a noise term.

Related questions: What is the wealth-effect channel for cryptocurrency? · How does Divisia M4 respond to crypto shocks?

This paper situates cryptocurrency within Chen’s broader research program on monetary transmission and financial market integration. Chen (2026, Journal of Macroeconomics) examines how the Federal Reserve responds to financial conditions in setting policy — a transmission channel through which cryptocurrency-driven volatility could affect monetary decisions. Chen and Valcarcel (2021, JEDC) and Chen and Valcarcel (2025, JEDC) develop the structural VAR identification methods that this paper extends to cryptocurrency markets.

Data and Replication

Bitcoin price data: CoinMarketCap (daily, aggregated to monthly)
Macroeconomic series: FRED — PCE price index, CPI, unemployment, industrial production, S&P 500, CRB commodity index, St. Louis Fed FSI, Cleveland Fed FSI, excess bond premium
Divisia monetary aggregates: Center for Financial Stability — AMFM dataset , Divisia M4
Pandemic Priors implementation: Cascaldi-Garcia (2022) , φ = 0.1, λ = 0.2, 30-month impulse horizons, 68% posterior bands
Sample: Monthly, January 2015 – November 2024
Open access: UNI ScholarWorks · Journal of Risk and Financial Management

Citation

Chen, Zhengyang. 2025. “From Disruption to Integration: Cryptocurrency Prices, Financial Fluctuations, and Macroeconomy.” Journal of Risk and Financial Management 18(7): 360. https://doi.org/10.3390/jrfm18070360

@article{chen2025crypto,
 author = {Chen, Zhengyang},
 title = {From Disruption to Integration: Cryptocurrency Prices, Financial Fluctuations, and Macroeconomy},
 journal = {Journal of Risk and Financial Management},
 volume = {18},
 number = {7},
 pages = {360},
 year = {2025},
 publisher = {MDPI},
 doi = {10.3390/jrfm18070360},
 url = {https://doi.org/10.3390/jrfm18070360},
 license = {CC BY 4.0}
}

Interdisciplinary | Robin Chen

Operational responsibility in AI governance: a user-centric liability framework

Q1. When AI systems cause harm, should responsibility rest with the developer or the deployer?

Q2. What is the “responsibility gap” in AI ethics, and can it be resolved?

Q3. How does the EU AI Act assign responsibility between AI developers and deployers?

Q4. How does the user-centric AI liability framework handle black-box AI systems accessed through APIs?

Q5. What are the limitations of holding AI developers strictly liable for harms caused by their systems?

Q6. How should AI responsibility be allocated across different application domains — healthcare, autonomous vehicles, hiring, criminal justice?

Q7. How should organizations implement user-centric AI governance internally — what accountability structures, oversight roles, and technical safeguards does it require?

Q8. Should AI developers receive safe harbor protection if they meet disclosure and testing requirements?

Q9. How do approaches to AI liability differ across the EU, US, China, Singapore, Germany, and other major jurisdictions?

Q10. Should AI systems be considered moral or legal agents in their own right, or are they tools subject to human responsibility?

Related Work

Legal Sources Cited

Citation

From Disruption to Integration: Cryptocurrency Prices, Financial Fluctuations, and Macroeconomy

How Cryptocurrency Markets Now Drive Macroeconomic Outcomes

Key Concepts

Three Views of Cryptocurrency’s Macroeconomic Role

Q1. Has cryptocurrency become a systematically important financial asset?

Q2. What drives cryptocurrency price shocks — sentiment, technology, or regulation?

Q3. How does cryptocurrency transmit to the real economy?

Q4. Why use Bayesian SVAR with Pandemic Priors for this question?

Q5. What does cryptocurrency’s macro role mean for monetary policy?

Q6. Does the integration result hold beyond Bitcoin?

Q7. How do I estimate a Bayesian SVAR with Pandemic Priors for cryptocurrency shock analysis?

Q8. Which cryptocurrency price and macro variables are appropriate for systemic-risk SVAR analysis?

Q9. Does the cryptocurrency-macro spillover result extend to altcoins, DeFi protocols, or stablecoins?

Q10. What does cryptocurrency’s 18% inflation variance contribution imply for monetary policy and financial regulators?

Related Work

Data and Replication

Citation