Civil Law And Algorithmic High-Frequency Trading Loss Liability In Europe

1. Introduction

Algorithmic high-frequency trading (HFT) is a technologically intensive form of algorithmic trading in which computer systems analyse market information and rapidly generate, modify, route, cancel and execute very large numbers of orders, often with minimal human intervention.

Under MiFID II, algorithmic trading includes systems that automatically determine parameters such as whether to initiate an order, timing, price or quantity. HFT is a particular form characterised by features such as low-latency infrastructure, automated order determination and high intraday message rates. (esma.europa.eu)

HFT can generate several kinds of loss:

losses suffered by the HFT firm itself;

losses suffered by its clients;

losses caused by erroneous orders;

losses caused by software malfunction;

losses resulting from inadequate risk controls;

losses caused by unauthorised or excessive trading;

losses associated with market manipulation;

losses suffered by counterparties;

losses resulting from a trading venue's technological failure.

European law does not currently provide one single civil-liability regime specifically called “HFT loss liability.” The analysis combines MiFID II/MiFIR, Market Abuse Regulation, DORA, national contract law, tort/delict law, financial-services duties and, increasingly, software/product-liability principles.

A major point is that regulatory breach and private compensation are not always identical. A violation of a financial-market rule may support a civil claim, but the claimant must still establish the applicable private-law basis, causation and recoverable damage under the relevant national law.

2. What Is Algorithmic HFT?

MiFID II defines algorithmic trading broadly as trading in financial instruments where a computer algorithm automatically determines individual order parameters, including whether to initiate the order, timing, price or quantity, with limited or no human intervention.

HFT is a subset involving characteristics such as:

sophisticated infrastructure designed to minimise latency;

automated determination of orders without human intervention for individual trades;

high intraday message rates involving orders, quotes or cancellations. (esma.europa.eu)

Examples include:

market making;

statistical arbitrage;

latency arbitrage;

automated execution;

cross-venue arbitrage;

smart order routing;

automated liquidity provision.

3. Why HFT Creates Civil-Liability Problems

Traditional trading involves a human trader making a decision.

HFT may involve:

Market data

↓

Algorithm

↓

Order generation

↓

Order routing

↓

Execution

↓

Cancellation/modification

all within extremely short periods.

If something goes wrong, several questions arise:

Was the algorithm defective?

Was it badly designed?

Was it incorrectly configured?

Was the market data inaccurate?

Did the trader exceed a risk limit?

Was there sufficient human supervision?

Did the trading venue malfunction?

Did a third-party software provider cause the problem?

Was the transaction itself unlawful?

Did the loss result from the algorithm or from market movement?

Can the claimant prove causation?

4. Main Sources of European Law

A. MiFID II

MiFID II is central to algorithmic trading.

Article 17 requires investment firms engaging in algorithmic trading to maintain effective systems and controls ensuring that:

trading systems are resilient;

sufficient capacity exists;

appropriate trading thresholds and limits exist;

erroneous orders are prevented;

systems do not contribute to disorderly markets;

systems are tested and monitored;

business continuity arrangements exist. (esma.europa.eu)

HFT firms must also maintain accurate, time-sequenced records of orders, cancellations, executed orders and quotations. (esma.europa.eu)

This evidence can become extremely important in civil litigation.

5. DORA and Operational Resilience

The Digital Operational Resilience Act (DORA) is also relevant to financial entities' ICT risk management.

HFT firms increasingly depend upon:

trading software;

cloud systems;

network infrastructure;

market-data feeds;

exchange connectivity;

cybersecurity;

third-party ICT providers.

A technological failure may therefore generate both:

regulatory consequences

and potentially

contractual/civil claims.

6. Market Abuse Regulation

The Market Abuse Regulation is relevant where an algorithm:

manipulates prices;

creates false or misleading signals;

engages in spoofing;

layering;

wash trading;

abusive quote activity;

unlawful use of inside information.

Importantly, an algorithm does not receive a legal exemption simply because it operates automatically.

The legal question remains whether the relevant conduct falls within the applicable market-abuse rules.

7. Civil Liability Categories

HFT loss claims can broadly be divided into six categories.

1. Contractual liability

Example:

Broker promises controlled execution but its algorithm sends erroneous orders.

2. Tort/delict liability

Example:

Negligent algorithm design causes foreseeable financial harm.

3. Investment-services liability

Example:

Investment firm fails to comply with applicable conduct obligations.

4. Market-abuse-related liability

Example:

Manipulative algorithm causes another participant's loss.

5. Product/software liability

Example:

Defective trading software causes qualifying damage.

6. Trading-venue liability

Example:

Exchange technology malfunctions and causes losses.

8. Case Law

Direct European reported case law specifically awarding civil damages for AI/HFT algorithm malfunction remains limited. Therefore, the following cases should be understood as relevant European authorities and analogical precedents, rather than as cases that all directly concern modern HFT.

Case 1: Genil 48 SL v Bankinter — C-604/11

CJEU, 30 May 2013, ECLI:EU:C:2013:344

Facts

The case concerned financial instruments and the investment-services obligations applicable to financial institutions.

The dispute involved interest-rate swaps and the MiFID conduct-of-business regime.

Principle

The CJEU examined the scope of investment advice and the obligations imposed on investment firms when providing investment services.

It also addressed the consequences of failure to comply with the applicable investment-services obligations. (Infocuria)

Relevance to HFT

The case is useful because an HFT dispute may not be purely technological.

The claimant may argue that:

the investment firm breached its regulatory and contractual duties concerning the investment service.

Thus, a firm cannot necessarily respond:

“The computer made the decision.”

The legal obligations remain obligations of the investment firm.

Principle

Algorithmic execution does not automatically eliminate the investment firm's legal responsibilities.

Case 2: Kolassa v Barclays Bank — C-375/13

CJEU, 28 January 2015, ECLI:EU:C:2015:37

Facts

Kolassa was an investor who suffered losses connected with a financial investment and brought proceedings involving a financial institution.

Importance

The CJEU addressed jurisdictional questions surrounding investor claims against financial institutions.

HFT relevance

The case illustrates an important practical issue:

Which court can hear a cross-border financial-loss claim?

HFT frequently involves:

trader in France;

broker in Germany;

exchange in the Netherlands;

software provider in the UK;

server in another jurisdiction;

client in Spain.

Therefore, jurisdiction can become almost as important as substantive liability.

Kolassa demonstrates the difficulties of locating financial loss in cross-border investment litigation. (Infocuria)

Case 3: Spector Photo Group and Van Raemdonck — C-45/08

CJEU, 23 December 2009, ECLI:EU:C:2009:806

Facts

Spector purchased its own shares before information concerning its commercial situation was publicly disclosed.

The Belgian financial regulator treated certain transactions as insider dealing.

Principle

The case concerned the interpretation of EU insider-dealing rules and sanctions.

The CJEU emphasised the objective of protecting financial-market integrity and investor confidence. (Infocuria)

HFT relevance

An automated trading system may process enormous amounts of information.

If the system uses:

inside information;

unlawfully obtained information;

information subject to restrictions;

automation does not itself eliminate market-abuse responsibility.

Example

Algorithm receives non-public information → immediately purchases securities → profits before public disclosure.

The legal analysis concerns the conduct and knowledge attributable under the applicable rules, not whether a human manually clicked “buy.”

Case 4: Geltl v Daimler — C-19/11

CJEU, 28 June 2012, ECLI:EU:C:2012:397

Principle

The CJEU considered what constitutes precise inside information under the market-abuse framework.

Information can qualify where it concerns circumstances or an event that may reasonably be expected to occur and is sufficiently specific to permit conclusions about its possible price effect. (Infocuria)

HFT relevance

HFT systems operate precisely because they process market information rapidly.

Suppose an algorithm receives information about:

an impending takeover;

an executive change;

an earnings announcement;

a major corporate transaction.

Whether the information is sufficiently precise and legally classified as inside information can determine whether subsequent automated trading is unlawful.

Importance

Algorithmic speed does not alter the underlying legal definition of inside information.

Case 5: Lafonta v Autorité des marchés financiers — C-628/13

CJEU, 11 March 2015, ECLI:EU:C:2015:162

Facts

The dispute concerned the meaning of “precise” information for purposes of the EU market-abuse regime.

Principle

The CJEU examined whether information must enable a sufficiently concrete conclusion concerning its potential price effect.

HFT relevance

HFT systems may act upon information that appears uncertain to human observers but is statistically significant to an algorithm.

The fact that an algorithm assigns a high probability to a market movement does not itself determine whether information legally qualifies as inside information.

The legal test remains the applicable EU market-abuse standard.

(Infocuria)

Case 6: Autorité des marchés financiers — C-302/20

CJEU Grand Chamber, 15 March 2022, ECLI:EU:C:2022:190

Facts

The case concerned information about the forthcoming publication of a press article reporting a market rumour and whether the information could constitute inside information.

Principle

The CJEU examined:

precision;

potential price effects;

market rumours;

disclosure;

market integrity.

The Court explained that information may qualify as sufficiently precise when, assessed in context, it allows conclusions about its potential effect on financial-instrument prices. (Infocuria)

HFT significance

This is relevant to high-speed trading because algorithms may react to information before most market participants can process it.

However:

speed of reaction alone does not transform lawful trading into unlawful trading.

The question remains whether the information and trading conduct satisfy the applicable market-abuse rules.

Case 7: Österreichische Post — C-300/21

UI v Österreichische Post AG

CJEU, 4 May 2023, ECLI:EU:C:2023:370

Principle

The CJEU addressed GDPR damages, non-material harm and causation following unlawful processing.

HFT relevance

Modern trading algorithms increasingly process:

customer data;

behavioural data;

trading histories;

profiling information;

risk information.

Where personal data are unlawfully processed in an automated trading environment, GDPR claims may exist alongside financial-law and civil-law claims.

Important distinction

A financial loss caused by a trading algorithm is not automatically a GDPR claim.

The claimant must identify an actual violation of data-protection law and satisfy the relevant damage and causation requirements.

Case 8: Boston Scientific — Joined Cases C-503/13 and C-504/13

CJEU, 5 March 2015

Principle

The CJEU recognised the significance of a systemic defect in product-liability law.

HFT relevance

This becomes increasingly important under the new EU Product Liability Directive.

Suppose:

Trading software contains a systemic coding defect.

The same defect repeatedly causes:

incorrect order quantities;

incorrect prices;

erroneous cancellations;

uncontrolled order generation.

The analogy with systemic product defects becomes relevant.

However, Boston Scientific does not itself concern trading software or HFT.

9. The New EU Product Liability Directive

Directive (EU) 2024/2853 significantly changes the legal environment for software.

The Directive expressly states that software, including AI systems, is a product for purposes of EU product liability, irrespective of whether it is supplied through a device, network, cloud or SaaS model. (EUR-Lex)

The corrected application date is 8 December 2026 for products placed on the market or put into service after that date. (EUR-Lex)

This may become relevant to trading software.

10. Can HFT Software Be a Defective Product?

Potentially, but the analysis must be careful.

Imagine:

HFT software contains a programming defect.

The software unexpectedly interprets:

€101.20

as:

€1.0120

and sends thousands of erroneous orders.

Possible losses:

trading losses;

cancellation expenses;

counterparty losses;

regulatory costs;

market disruption.

Whether a product-liability claim exists depends on the Directive's requirements, including:

whether the software qualifies as a product;

defectiveness;

damage within the Directive's scope;

causation;

applicable temporal scope.

The Directive also expressly preserves national contractual and non-contractual liability regimes. (EUR-Lex)

11. Important Limitation: Financial Trading Losses

This is particularly important.

Not every trading loss automatically becomes a product-liability claim.

The Product Liability Directive has a defined scope of compensable damage.

Therefore, an HFT firm's:

€50 million trading loss

cannot simply be characterised as:

“defective software = automatic PLD compensation.”

The claimant must first establish that the particular loss falls within the Directive's damage framework.

For purely financial losses, national contractual or tort/delict law may be more important.

12. MiFID II Article 17 and HFT Risk Controls

Article 17 is central.

An investment firm engaging in algorithmic trading must have effective systems and controls to:

prevent erroneous orders;

avoid disorderly markets;

maintain resilience;

manage capacity;

test systems;

monitor systems;

maintain continuity arrangements. (esma.europa.eu)

This produces an important civil-law question:

If an HFT firm's failure to maintain these controls causes a client loss, can the regulatory breach support a private claim?

The answer depends on national law.

A regulatory violation does not universally create an automatic damages action.

But it can be highly relevant evidence of:

breach of duty;

negligence;

contractual non-compliance;

foreseeability;

standard of care.

13. Third-Party Algorithm Providers

A major modern problem occurs when an investment firm purchases its algorithm from another company.

Example:

AI developer

↓

provides trading algorithm to

broker

↓

broker connects it to

exchange

↓

algorithm generates erroneous orders.

Who is liable?

Potential defendants include:

investment firm;

software developer;

system integrator;

cloud provider;

market-data provider;

exchange/trading venue.

ESMA specifically states that when firms use third-party systems offering algorithmic-trading functionality, the investment firm remains ultimately responsible for compliance with Article 17 and RTS 6, although contractual arrangements with the provider may be used for technical compliance. (esma.europa.eu)

14. Algorithmic Error and Contractual Liability

Suppose an investment bank provides algorithmic execution to a client.

The contract promises:

reasonable execution;

specified risk controls;

maximum order size;

execution within defined parameters.

The algorithm violates those parameters.

Potential claims may include:

breach of contract;

breach of an implied duty;

negligence;

breach of regulatory duties where relevant;

damages.

The claimant still needs to establish the contractual scope and causal loss.

15. Erroneous Orders

One of the classic HFT risks is the fat-finger-type algorithmic error.

Example:

Correct order:

Buy 100 shares.

Algorithm sends:

Buy 100,000 shares.

The system then automatically:

executes;

modifies;

cancels;

re-enters.

Potential issues include:

validity of trades;

cancellation rules;

exchange rules;

contractual obligations;

negligence;

risk-control failures;

losses suffered by counterparties.

ESMA's rules specifically require risk controls designed to prevent erroneous orders and address trading-venue procedures for cancellation or correction in certain malfunctioning or disorderly-trading circumstances. (esma.europa.eu)

16. Market-Impact Losses

HFT can also create a causation problem.

Suppose an algorithm sells:

10 million shares.

The market price falls.

The trader claims:

“The algorithm caused the market decline.”

But several factors may have contributed:

macroeconomic news;

other institutional sales;

market volatility;

liquidity changes;

other algorithms.

The claimant therefore needs to establish the causal contribution of the defendant's algorithm.

This is one of the most difficult issues in HFT litigation.

17. Counterparty Losses

Suppose:

Algorithm A sends erroneous buy orders.

A counterparty sells at unusually high prices.

The algorithm subsequently cancels the orders.

The counterparty claims:

“The algorithm caused me to rely on the transaction and I suffered loss.”

The court may need to examine:

whether a binding transaction existed;

exchange rules;

market rules;

cancellation mechanisms;

reliance;

foreseeability;

causation.

Thus, trade cancellation and civil damages are separate questions.

18. Spoofing and Layering

Algorithmic systems can potentially engage in:

Spoofing

Placing orders without genuine intention to execute them to influence market perception.

Layering

Placing multiple orders at different price levels to create a misleading impression of market demand or supply.

If an algorithm deliberately or systematically performs such conduct, Market Abuse Regulation issues may arise.

The Spector, Geltl, Lafonta and AMF authorities demonstrate the importance of EU market-abuse concepts, although those cases do not themselves concern modern HFT spoofing systems. (Infocuria)

19. HFT and Inside Information

An HFT algorithm may receive enormous quantities of market information.

The legal issue is not:

“Was the information processed by a computer?”

Instead:

“Was the information legally inside information, and did the conduct fall within the market-abuse prohibition?”

Geltl, Lafonta and AMF are useful authorities for understanding the precision and price-effect requirements.

20. HFT Loss and Causation

A typical civil claim can be represented as:

Software defect

↓

Erroneous algorithmic instruction

↓

Erroneous order

↓

Execution

↓

Market movement

↓

Financial loss

The claimant must connect each relevant stage.

The defendant may argue:

“Even without our algorithmic error, the claimant would have suffered the same loss.”

This is a classic causation dispute.

21. Contributory Fault

Suppose the trading firm receives repeated alerts:

“Algorithm behaving abnormally.”

The firm ignores the alerts for 30 minutes.

Loss:

€20 million.

The firm may then face an argument that its own conduct contributed to the loss.

Potential factors include:

failure to stop trading;

failure to activate kill switches;

failure to investigate alerts;

inadequate supervision;

failure to maintain limits.

National civil law determines the consequences of contributory fault.

22. Duty to Maintain Kill Switches

HFT systems should generally incorporate mechanisms allowing abnormal trading to be stopped.

Potential controls include:

maximum order size;

maximum daily loss;

position limits;

message limits;

price collars;

automatic shutdown;

human intervention;

circuit breakers.

Failure of such controls may be important evidence in a negligence or contractual claim.

It may also demonstrate non-compliance with algorithmic-trading organisational requirements.

23. Evidence in HFT Litigation

HFT litigation is unusually evidence-intensive.

Important evidence includes:

Trading data

order IDs;

timestamps;

order prices;

quantities;

cancellations;

executions.

Algorithmic evidence

source-code versions;

model parameters;

configuration;

deployment records;

testing records.

Infrastructure

latency;

server logs;

network logs;

co-location records;

connectivity failures.

Risk-control evidence

kill-switch logs;

threshold alerts;

risk-limit records;

human interventions.

Market evidence

order-book data;

market depth;

volatility;

competing orders;

exchange events.

MiFID II specifically requires HFT firms to maintain accurate, time-sequenced records of orders, cancellations, executions and quotations. (esma.europa.eu)

24. Trade Secrets and Source Code

An HFT firm may resist disclosure of source code because it is commercially valuable.

The claimant may nevertheless need sufficient evidence to establish:

what the algorithm did;

whether it was defective;

whether risk controls existed;

why the erroneous order occurred.

The court may therefore need to balance:

trade-secret protection

against

effective proof of liability.

Not every claimant is entitled to unrestricted access to an entire proprietary algorithm.

25. Loss Calculation

Possible losses include:

Trading loss

Difference between:

price actually obtained;

price that would have been obtained absent the error.

Transaction costs

brokerage;

exchange fees;

cancellation costs.

Market-impact loss

Additional loss allegedly caused by the algorithm's effect on market price.

Opportunity loss

Profit that could allegedly have been achieved through proper execution.

Consequential loss

Additional losses flowing from the initial trading error.

Regulatory loss

Fines or penalties generally require separate analysis and may not simply be recoverable as damages from another party.

26. Foreseeability

Suppose an algorithm provider knows:

Its software is connected directly to a high-speed exchange.

A foreseeable failure could generate thousands of orders within seconds.

That fact may become relevant when determining:

contractual risk;

negligence;

reasonable precautions;

causation;

damages.

HFT is inherently capable of amplifying a technical error because speed and volume magnify the consequences.

27. Limitation of Liability

Commercial HFT contracts frequently contain:

liability caps;

exclusion of indirect loss;

exclusion of lost profits;

force-majeure provisions;

disclaimers concerning market volatility.

Their enforceability depends upon:

applicable national law;

type of claimant;

mandatory financial-services rules;

consumer/professional status;

gross negligence or intentional conduct;

public policy.

A contractual limitation cannot simply be assumed valid in every European jurisdiction.

28. Trading Venue Liability

The exchange or trading venue can also become involved.

Potential failures include:

erroneous market data;

matching-engine malfunction;

connectivity failure;

incorrect cancellation;

circuit-breaker failure.

MiFID II requires trading venues to maintain appropriate systems and procedures for fair and orderly trading, while EU rules provide mechanisms concerning cancellation/correction in specified circumstances. (esma.europa.eu)

The precise civil claim depends upon:

exchange rulebook;

contractual relationship;

national law;

regulatory obligations;

causation.

29. Cross-Border HFT Litigation

A single transaction may involve:

Trader: France

Broker: Germany

Exchange: Netherlands

Algorithm provider: Switzerland

Cloud infrastructure: Ireland

Client: Spain

This creates questions concerning:

jurisdiction;

applicable law;

contractual governing-law clause;

Rome I;

Rome II;

Brussels I bis;

financial-market rules;

regulatory jurisdiction.

Kolassa demonstrates how cross-border investor-loss disputes can generate difficult jurisdictional questions. (Infocuria)

30. Six Core Legal Case Authorities

31. Important Distinction: Regulatory Liability vs Civil Liability

This distinction is essential for examination.

Regulatory violation

Example:

HFT firm failed to maintain required risk controls.

Possible consequence:

regulatory investigation/sanction.

Civil liability

Example:

Failure to maintain risk controls caused a client's €10 million loss.

Possible consequence:

damages claim.

But the second does not automatically follow from the first.

The claimant must identify an appropriate private-law basis and prove the necessary elements.

32. Practical Example

Assume an investment bank operates an HFT system.

Stage 1

Market-data feed incorrectly reports:

€50.00.

Actual price:

€5.00.

Stage 2

Algorithm interprets the data as genuine.

Stage 3

It sends:

500,000 buy orders.

Stage 4

Risk-control system fails to stop them.

Stage 5

Orders execute.

Stage 6

Bank suffers:

€30 million loss.

Possible claims

Contract

Was the market-data provider contractually required to provide accurate data?

Software liability

Was the algorithm defective?

Negligence

Did the bank fail to maintain reasonable risk controls?

MiFID II

Were Article 17 controls satisfied?

Trading venue

Did the exchange malfunction?

Product liability

Does the software qualify as a defective product and does the claimed damage fall within the PLD?

Causation

Which failure actually caused the €30 million loss?

33. Defences

Potential defendants may argue:

1. Market volatility

The loss was caused by ordinary market movements.

2. No software defect

The algorithm operated according to its specification.

3. Bad input data

The error originated with a third-party data supplier.

4. Human intervention

A trader changed the parameters.

5. Failure to mitigate

The claimant failed to stop trading despite warnings.

6. Contractual limitation

The contract limits liability.

7. No causation

The loss would have occurred anyway.

8. Unforeseeable event

An extraordinary market event intervened.

9. Trading-rule allocation

The exchange's rulebook allocates the relevant risk differently.

34. Future Importance of AI

The next generation of HFT may use:

machine learning;

reinforcement learning;

adaptive strategies;

autonomous execution;

AI-generated trading strategies;

predictive market models;

large-scale alternative-data analysis.

This increases the difficulty of determining:

Who is responsible when the algorithm's behaviour changes after deployment?

Traditional software may execute predefined instructions.

A machine-learning system may alter its behaviour as data and market conditions change.

The Product Liability Directive is significant because it expressly recognises software, AI systems and certain software updates/upgrades within the modern product-liability framework. (EUR-Lex)

35. Key Legal Principles

Principle 1

Algorithmic trading does not eliminate the investment firm's legal responsibility.

Principle 2

HFT firms must maintain robust systems and risk controls.

Principle 3

Erroneous orders can create both regulatory and private-law consequences.

Principle 4

Market-abuse rules apply to algorithmic conduct just as they apply to human conduct.

Principle 5

A regulatory breach does not automatically equal a private damages award.

Principle 6

Causation is usually one of the most difficult elements of an HFT-loss claim.

Principle 7

Third-party technology does not necessarily transfer all responsibility away from the investment firm. ESMA expressly states that firms using third-party algorithmic systems remain ultimately responsible for compliance with relevant Article 17 requirements. (esma.europa.eu)

Principle 8

Software and AI are increasingly treated as products for EU product-liability purposes.

36. Conclusion

Algorithmic high-frequency trading loss liability in Europe is a multi-layered civil-law problem.

The principal legal framework consists of:

MiFID II for algorithmic-trading systems and controls;

MiFIR for transaction and record requirements;

Market Abuse Regulation for manipulation and insider dealing;

DORA for ICT and operational resilience;

national contract law;

national tort/delict law;

financial-services liability;

exchange rules;

and the new EU Product Liability Directive for qualifying defective software.

The central causation chain can be expressed as:

Algorithmic defect/error → erroneous order or unlawful trading → execution/market effect → identifiable loss → causal connection → legally responsible actor → recoverable damages.

The most important complication is that an HFT trading loss is not automatically a civil-liability loss. Market movements are inherently risky, algorithms are predictive rather than infallible, and regulatory obligations do not automatically create a private right to compensation. The claimant must establish the applicable contractual, tortious, statutory or product-liability basis and prove causation and recoverable damage.

The most useful authorities for revision are Genil 48, Kolassa, Spector Photo Group, Geltl, Lafonta, Autorité des marchés financiers, Österreichische Post and Boston Scientific. They do not collectively constitute a body of direct HFT-damages precedent; rather, they provide the European legal principles from which HFT civil-liability disputes are presently analysed. (Infocuria)

Exam keywords: algorithmic HFT, high-frequency trading, MiFID II Article 17, erroneous orders, kill switch, risk controls, market abuse, spoofing, layering, insider information, algorithmic malfunction, software defect, DORA, causation, market impact, contributory fault, contractual liability, tort/delict, trading venue liability, third-party algorithm provider, product liability, financial loss, damages, cross-border jurisdiction, trade secrets, audit trail.