CIVIL LAW AND UAE SHIFT FROM BLAME TO SYSTEM-DESIGN LIABILITY MODELS

1. Introduction

Traditional civil liability is often described through the question:

Who was at fault?

A modern system-design approach asks a broader question:

What system, process, control, design, supervision or institutional arrangement allowed the harm to occur, and who was legally responsible for that system?

This distinction is increasingly important in the UAE because modern economic activity involves:

complex corporate structures;

construction projects;

financial institutions;

automated systems;

artificial intelligence;

cybersecurity;

digital assets;

smart contracts;

professional advisers;

hospitals;

logistics systems;

large infrastructure;

platform businesses; and

interconnected supply chains.

In such environments, an accident may not be attributable to one obvious individual's careless act.

A defective outcome may instead result from:

poor system design;

inadequate safeguards;

defective supervision;

insufficient testing;

weak internal controls;

inadequate risk assessment;

failure to implement warnings;

defective professional standards;

poor information architecture; or

failure to anticipate reasonably foreseeable risks.

The legal significance is that responsibility can increasingly be analysed at the level of the system rather than merely at the level of the individual actor.

However, this should not be overstated. UAE mainland civil law has not abolished fault-based liability and replaced it with a general doctrine of "system liability." Rather, existing doctrines of civil liability, causation, professional responsibility, contractual obligations, product liability, corporate responsibility and statutory duties can be applied to system-level failures.

2. Meaning of System-Design Liability

System-design liability means liability arising from the failure to properly design, organise, supervise, monitor or control a system where the resulting harm was legally attributable to that failure.

The "system" may be:

Physical

building;

machine;

factory;

transportation network.

Financial

payment system;

banking controls;

fraud-monitoring system;

investment platform.

Digital

software;

blockchain;

cybersecurity architecture;

automated trading platform.

Organisational

corporate governance;

employee supervision;

compliance procedures;

internal controls.

Professional

engineering design;

architectural supervision;

medical systems;

auditing systems.

The central question becomes:

Was the system reasonably designed and operated to manage foreseeable risks?

3. Traditional Blame Model

Under a conventional fault model, litigation tends to focus on:

who acted;

what the person did;

whether the conduct was negligent;

whether the person breached a duty;

whether that breach caused damage.

For example:

An employee enters an incorrect banking instruction.

Traditional analysis asks:

Did the employee act negligently?

System-design analysis asks additional questions:

Why could one employee execute the transaction?

Was dual authorisation required?

Were unusual transactions automatically flagged?

Were transaction limits appropriate?

Did the bank have adequate authentication?

Were there escalation procedures?

Were employees properly trained?

Were internal controls tested?

The second approach does not eliminate individual responsibility.

It adds institutional responsibility to the analysis.

4. UAE Mainland Civil-Law Foundation

The UAE Civil Transactions Law provides the underlying framework for civil liability.

The traditional civil-law structure remains important:

harmful act → damage → causation → compensation.

The current Civil Transactions Law continues to regulate performance of obligations and compensation, while the established UAE civil-law framework recognises compensation for actual harm and loss of profit where naturally resulting from the harmful act. The previous Civil Transactions Law's Article 292 expressly provided that compensation is assessed by reference to the harm suffered together with loss of profit where naturally resulting from the harmful act.

Thus, the move toward system-design liability should be understood as a development in how courts identify the legally relevant conduct, not as abandonment of the fundamental civil-liability structure.

5. From Individual Fault to Risk Architecture

A system can create risk even where every individual employee appears to have acted according to instructions.

Consider a bank:

Employee A follows the procedure.

Employee B follows the procedure.

Employee C follows the procedure.

Yet the procedure itself is defective.

A purely individual-fault model may struggle to identify the problem.

A system-design model asks whether:

The institution designed a reasonable process for the foreseeable risks of its activity.

This can shift the analysis from:

"Who made the mistake?"

to:

"Why was the system capable of producing this mistake without adequate safeguards?"

6. Important Legal Components

System-design liability generally involves six interconnected elements.

1. Foreseeability

Could the organisation reasonably anticipate the risk?

2. System responsibility

Did the defendant design, control, operate or supervise the relevant system?

3. Preventive capacity

Could reasonable safeguards have reduced the risk?

4. Breach

Was the system below the legally required standard?

5. Causation

Did the system failure materially cause the loss?

6. Damage

What legally recoverable harm resulted?

These concepts closely resemble the ordinary negligence framework but apply it to institutional processes.

7. Professional Standard as a System-Design Standard

A particularly important bridge between individual fault and system liability is professional standard of care.

In the DIFC, Article 21 of the Law of Obligations provides that reasonable care is measured against the care of a person of ordinary care and skill engaged in the relevant activity, while professionals are assessed against the standard of an ordinary skilled person exercising the relevant special skill. Where there are competing professional approaches, an approach supported by a responsible body of professional opinion can satisfy the standard.

This allows the court to ask not merely:

"Did the engineer make a mistake?"

but:

"Was the engineering methodology, design process and professional system consistent with the applicable professional standard?"

8. CASE LAW

Case 1 — Aegis Resources DMCC v Union Bank of India (DIFC Branch)

[2020] DIFC CFI 004

This is one of the strongest UAE examples of system-oriented liability.

Facts

Aegis suffered loss after fraudulent payment instructions were processed.

The bank argued that responsibility lay substantially with Aegis because its email system had been compromised.

Issue

Was the bank liable for failing to prevent fraudulent payment instructions despite circumstances giving it reason to suspect fraud?

Principle

The Court found that the bank owed Aegis a duty, in accordance with the Quincecare principle, not to make payments where it had reasonable grounds for believing that the instructions were an attempt to misappropriate funds.

The Court concluded that the bank had breached that duty and was liable for the resulting loss, subject to contributory negligence considerations.

System-design significance

The case demonstrates a movement beyond asking:

"Who sent the fraudulent email?"

The institution's payment-control architecture became legally relevant.

Relevant system questions include:

transaction monitoring;

suspicious-payment detection;

internal escalation;

authentication;

employee review;

fraud indicators.

Therefore, institutional controls can become part of the causation and duty analysis.

9. Case 2 — Gate Mena DMCC / Huobi Mena FZE v Tabarak Investment Capital Ltd & Christian Thurner

[2020] DIFC TCD 001

This is particularly important for digital-asset system liability.

Facts

The dispute concerned a Bitcoin transaction involving approximately 300 BTC.

Tabarak became involved in the transaction and was alleged to have assumed a role involving custody/escrow and the design of the transaction mechanism.

The claimant alleged that inadequate safeguards resulted in the Bitcoin being transferred before payment was properly secured.

Issue

Could a party involved in designing and implementing a transaction mechanism owe a duty of care?

Principle

The DIFC Law of Obligations provides that negligence liability depends upon duty, breach and causation. Duty may arise where:

harm is reasonably foreseeable;

sufficient proximity exists; and

it is fair, just and reasonable to impose a duty.

A positive duty to act may arise where a person has assumed responsibility for the claimant, property or a third party causing loss. The standard of care concerns reasonable care in light of probability and seriousness of loss.

System-design significance

The case is highly relevant because the alleged responsibility was not simply:

"Do not steal Bitcoin."

It concerned the design and implementation of a transaction mechanism intended to protect the parties' interests.

This is a classic example of how modern civil liability can focus on:

transaction architecture;

custody controls;

escrow mechanisms;

access controls;

operational safeguards;

allocation of responsibility.

10. Case 3 — Gate Mena DMCC v Tabarak Investment Capital Ltd

[2024] DIFC DEC 002

The later proceedings are particularly important for distinguishing strict liability from reasonable-care liability.

Facts

The claimants sought to advance a contractual case that Tabarak had assumed an exceptionally strict obligation regarding the transaction.

The earlier pleadings had described Tabarak's obligation as one of reasonable care.

Principle

The Court noted that the claimants had repeatedly accepted that Tabarak's obligation was one of reasonable care and attempted later to advance a materially different strict-liability theory.

The Court treated the distinction between reasonable-care responsibility and strict liability as legally significant.

System-design significance

This case demonstrates an important limit:

System-design liability is not automatically strict liability.

A party responsible for designing or operating a system is not necessarily an insurer against every failure.

The claimant must establish the applicable contractual or tortious obligation and prove breach and causation.

11. Case 4 — Haya Spa LLC v Harper Real Estate / Hasan Real Estate

[2016] DIFC SCT 150

Facts

The claimant relied upon technical information and drawings provided by the defendants.

The information proved incorrect, causing the claimant to undertake an expensive design process and suffer delay-related losses.

Principle

The Court analysed:

duty;

breach;

causation;

economic loss;

reliance; and

damages.

It held that the defendants' conduct was a "but-for" and substantial cause of losses during the relevant period because the claimant reasonably relied on the technical information provided.

System-design significance

The case illustrates liability arising from the information-production process.

The relevant question was not simply whether someone "lied."

It involved:

accuracy of technical information;

professional responsibility;

reliance;

information quality;

consequences of using defective information.

Modern system-design liability frequently operates through this kind of information architecture.

12. Case 5 — Brookfield Multiplex Constructions LLC v DIFC Investments LLC & DIFC Authority

[2016] DIFC CFI 020

Facts

The dispute concerned defects involving marble cladding at the DIFC Gate Building.

The pleadings alleged material defects in construction works and negligence by the designer/overseeing professional.

Principle

The Court considered the interaction between:

construction defects;

engineering/design responsibility;

negligence;

expert evidence;

contractual responsibility;

arbitration.

The Court observed that experts frequently address deficiencies in buildings and their causes, but the ultimate determination of negligence and breach remains a legal question for the tribunal or court.

System-design significance

Construction liability demonstrates why modern civil responsibility cannot always be reduced to the person who physically installed a defective component.

A construction failure may originate in:

architectural design;

engineering calculations;

materials selection;

supervision;

quality-control procedures;

installation;

inspection;

certification.

The system-design approach therefore examines the entire chain.

13. Case 6 — Bank Sarasin-Alpen (ME) Ltd v Al Khorafi & Others

[2009] DIFC CFI 026

Facts

The claimants alleged losses connected with structured financial products and the conduct of financial institutions.

The bank argued, among other things, that the allegedly wrongful acts were performed by persons employed by a separate legal entity and challenged the existence of sufficient foreseeability and proximity.

Principle

The Court considered the requirements for a duty of care, including:

foreseeability;

proximity; and

whether it was fair, just and reasonable to impose the duty.

The judgment discussed the development of duty-of-care principles in complex financial relationships.

System-design significance

Complex financial services are inherently system-dependent.

The legal question can therefore extend beyond one employee's conduct to:

product design;

customer communication;

risk disclosure;

institutional responsibility;

distribution arrangements;

supervision.

This provides an important conceptual foundation for system-oriented financial liability.

14. Case 7 — Vision Construction LLC v Banque Misr UAE

[2022] DIFC CFI 049

Facts

Vision Construction alleged that the bank delayed processing transactions and caused financial losses.

It pleaded both contractual breach and negligence.

Principle

The Court examined whether the bank owed a duty of care and whether the alleged acts or omissions caused the claimed loss.

The defendant argued that the claimant was essentially seeking to transfer investment or market risks to the bank and that the claimant had not established duty, breach and causation.

System-design significance

The case demonstrates a critical limitation of system-based liability:

A sophisticated institution does not become an insurer against every economic loss associated with its services.

The claimant must identify a legally recognised duty and a causal system failure.

15. Case 8 — Firstrand Property Holding (Middle East) Ltd v Damac Park Towers

[2014] DIFC CFI 030

Facts

The claimant alleged that the defendant had undertaken obligations concerning a property development and had assumed a duty of care in relation to performance.

Principle

The Court considered whether a duty of care had actually been assumed and whether contractual circumstances supported the alleged tortious duty.

The case illustrates the importance of examining the actual relationship and assumption of responsibility, rather than imposing a general duty simply because a defendant participated in a commercial project.

System-design significance

It provides an important boundary:

Participation in a complex system does not automatically make every participant responsible for every system failure.

Responsibility depends upon the particular role undertaken.

16. From Negligent Person to Responsible System

The cases demonstrate an emerging analytical sequence:

Traditional

Actor → conduct → fault → damage

System-oriented

System → role → risk → safeguard → failure → causation → damage

This does not abolish fault.

Instead, the concept of fault itself can become more sophisticated.

A defendant may be negligent because the defendant:

failed to design an adequate system;

failed to maintain controls;

failed to test a system;

failed to supervise personnel;

failed to respond to known risks;

failed to implement warnings;

failed to establish appropriate escalation procedures.

17. Preventive Liability

A major feature of system-design thinking is the emphasis on prevention.

Traditional litigation often occurs after damage.

System-oriented regulation asks:

What reasonable controls should have existed before the damage occurred?

Examples include:

Banking

transaction limits;

two-factor authentication;

suspicious-payment alerts;

dual approval.

Cybersecurity

access controls;

encryption;

intrusion detection;

incident response.

Construction

inspections;

testing;

certification;

structural monitoring.

AI

testing;

human oversight;

bias monitoring;

explainability;

audit logs.

Healthcare

patient identification;

medication controls;

infection controls;

clinical escalation.

18. Causation Becomes More Complex

System failures frequently involve multiple causes.

Suppose:

a bank has inadequate controls;

an employee's credentials are stolen;

the attacker initiates a fraudulent transfer;

the bank fails to flag the transaction;

the money is transferred.

Who caused the loss?

A system-oriented analysis may identify several contributing causes.

The legal inquiry becomes:

Was the risk foreseeable?

Was the defendant's system failure substantial?

Was the intervening event foreseeable?

Did another person's conduct break the chain of causation?

Did the claimant contribute to the loss?

The DIFC framework expressly addresses causation and intervening events. In Haya Spa, the Court applied the "but-for" and substantial-cause analysis to the claimant's loss.

19. Contributory Negligence

System liability does not eliminate claimant responsibility.

Under Article 17(2) of the DIFC Law of Obligations, liability in negligence is reduced to the extent that the claimant's negligent conduct contributed to the loss.

For example:

A bank has inadequate fraud controls.

But the customer also:

ignores repeated warnings;

voluntarily discloses authentication information;

confirms suspicious transactions.

The court may have to allocate responsibility.

This creates a shared-risk model rather than a simple winner/loser model.

20. Strict Liability vs System-Design Liability

These concepts must not be confused.

Strict liability

Liability can arise without proving ordinary fault in circumstances recognised by law.

System-design liability

Liability is generally established by showing that the defendant failed to meet an applicable legal, contractual or professional standard concerning the system.

Therefore:

System-design liability is not automatically strict liability.

The 2024 Gate Mena/Huobi litigation illustrates the importance of distinguishing reasonable-care obligations from alleged strict obligations.

21. Product Design and Product Liability

System-design thinking is particularly relevant to defective products.

A product may fail because of:

manufacturing error;

design defect;

inadequate instructions;

inadequate warnings;

poor quality control.

The designer may therefore become legally relevant even where the final accident was caused by a user.

The legal analysis should distinguish:

design defect → manufacturing defect → misuse → failure to warn.

This is increasingly important as products become connected to software and cloud services.

22. AI and Algorithmic Systems

AI creates perhaps the clearest example of system-design liability.

Suppose an automated system:

rejects a financial transaction;

wrongly identifies fraud;

causes an incorrect payment;

makes an unsafe recommendation;

produces discriminatory results.

It may be difficult to identify a single "wrongdoer."

Potentially relevant actors include:

developer;

system owner;

deployer;

data provider;

operator;

supervisor;

professional user.

The legal question becomes:

Who had the ability and legal responsibility to design, test, monitor or correct the system?

This is fundamentally a system-design question.

The DIFC has expressly created specialist jurisdiction covering technology claims, including software, network systems, artificial intelligence-related digital technologies, robotics, autonomous systems and other cyber-physical systems.

That institutional development demonstrates the increasing importance of system-based legal disputes.

23. Cybersecurity Liability

Cybersecurity provides another strong example.

Suppose a company suffers a data breach.

A blame-oriented analysis asks:

Which employee clicked the malicious link?

A system-oriented analysis additionally asks:

Was multi-factor authentication implemented?

Were privileged accounts restricted?

Was the system patched?

Was encryption used?

Was unusual activity monitored?

Were employees trained?

Was incident response available?

Was the vulnerability previously known?

The employee's conduct may remain relevant, but institutional controls become central.

24. Financial-System Liability

Financial institutions are particularly suitable for system-design analysis because financial services depend upon interconnected controls.

Relevant systems include:

payment processing;

AML monitoring;

KYC;

fraud detection;

cybersecurity;

transaction authorisation;

risk management.

Aegis v Union Bank is especially significant because the Court examined whether the bank's duty required it to respond to suspicious payment instructions rather than simply execute them mechanically.

25. Construction-System Liability

Construction projects contain numerous layers:

Owner → architect → engineer → consultant → contractor → subcontractor → supplier → inspector

A building defect can therefore be a system failure.

The court may need to determine:

who designed the system;

who approved it;

who supervised construction;

who inspected the work;

who certified completion;

who had knowledge of the risk.

Brookfield Multiplex illustrates the importance of distinguishing technical expert evidence from the court's ultimate legal determination of negligence and contractual breach.

26. Organisational Liability

A corporation acts through people and systems.

An organisation may therefore face civil consequences because of:

inadequate supervision;

poor compliance systems;

failure to train;

defective delegation;

insufficient internal controls;

inadequate risk-management structures.

This is especially significant in:

banks;

hospitals;

construction companies;

airlines;

logistics businesses;

technology companies.

The larger and more complex the organisation, the more difficult it becomes to treat every failure as the isolated act of one individual.

27. Evidence in System-Design Cases

Evidence becomes especially important.

Typical evidence includes:

Internal documents

policies;

procedures;

risk assessments;

audit reports;

compliance manuals.

Technical evidence

system architecture;

source code;

logs;

security reports;

engineering calculations.

Corporate evidence

board minutes;

risk committee records;

incident reports.

Expert evidence

engineering experts;

cybersecurity experts;

financial experts;

IT experts;

medical experts.

The court can therefore reconstruct how the system operated before the harmful event.

28. Role of Experts

System-design disputes are often technically complex.

The DIFC has a dedicated Technology and Construction Division for technically complex claims involving construction, engineering, professional advisers, software, IT systems, fires, complicated accounts and related matters.

The existence of specialist procedures is significant because system liability often requires technical reconstruction.

However, expert evidence does not decide the ultimate legal question.

As Brookfield Multiplex illustrates, experts can identify technical deficiencies and their causes, but whether those deficiencies constitute negligence or breach remains a legal determination.

29. Risk Allocation

Modern contracts increasingly allocate system risks expressly.

Examples:

cybersecurity obligations;

service-level agreements;

business-continuity obligations;

disaster recovery;

audit rights;

insurance;

indemnities;

limitation of liability;

warranties;

testing obligations.

The court must therefore distinguish:

risk expressly allocated by contract

from

risk imposed by mandatory law.

30. Preventive Compliance as Evidence

A company may reduce its exposure by demonstrating that it maintained appropriate systems.

Evidence may include:

regular audits;

documented risk assessments;

testing;

employee training;

independent certification;

incident response;

monitoring;

periodic system updates.

This does not create automatic immunity.

But it may be relevant to determining whether the defendant exercised reasonable care.

31. System Failure and Foreseeability

Foreseeability is central.

A company is not normally expected to eliminate every imaginable risk.

The question is whether the risk was reasonably foreseeable in light of:

the nature of the activity;

available technology;

industry standards;

previous incidents;

warnings;

regulatory requirements;

the seriousness of potential harm.

The DIFC negligence framework expressly incorporates foreseeability into the duty-of-care analysis.

32. The "Reasonable System" Standard

A useful conceptual model is:

What system would a reasonable organisation engaged in this activity have designed and operated under the circumstances?

This may require considering:

probability of harm;

severity of harm;

cost of safeguards;

availability of technology;

professional standards;

regulatory expectations;

contractual commitments;

knowledge of previous incidents.

This transforms the negligence inquiry from an exclusively personal standard into an organisational-risk standard.

33. Limits of System-Design Liability

System-design liability has important limits.

1. No automatic liability for accidents

A harmful outcome does not itself prove defective system design.

2. Causation remains necessary

The claimant must connect the alleged system defect to the loss.

3. Foreseeability remains important

A defendant cannot necessarily be liable for an entirely unforeseeable event.

4. Claimant conduct matters

Contributory negligence may reduce recovery.

5. Contract remains important

Parties may allocate certain risks contractually, subject to mandatory law.

6. Experts do not determine legal liability

Technical evidence informs the court but does not replace legal judgment.

34. Mainland UAE and DIFC

This distinction is essential.

Mainland UAE

The principal framework is UAE federal legislation, including the Civil Transactions Law and specialised legislation.

DIFC

The DIFC operates a separate common-law-oriented legal framework for civil and commercial matters.

The DIFC Courts themselves describe the DIFC as an independent legal and regulatory framework and explain that its courts administer a distinct English-language common-law jurisdiction within the UAE.

Consequently, DIFC cases such as Aegis, Huobi and Haya Spa should not automatically be treated as binding authorities for an ordinary mainland UAE civil claim.

They are nevertheless highly useful for analysing the direction of modern UAE commercial liability, especially in technology, finance and professional-risk disputes.

35. Comparison: Blame Model vs System-Design Model

36. Advanced Example — AI Banking System

Suppose a bank deploys an AI fraud-detection system.

The system wrongly approves a fraudulent transfer.

A traditional analysis might ask:

Did the employee negligently approve the transaction?

A system-design analysis asks:

Design

Was the algorithm properly designed?

Data

Was the training data reliable?

Testing

Was the system tested against fraud scenarios?

Human oversight

Could employees override the algorithm?

Alerts

Were unusual transactions escalated?

Monitoring

Was model performance continuously reviewed?

Governance

Who was responsible for the system?

Causation

Would appropriate controls have prevented the loss?

This produces a more sophisticated liability analysis without eliminating traditional negligence principles.

37. Advanced Example — Smart Construction

A developer constructs a high-rise building.

The building suffers structural failure.

The investigation reveals:

architect used outdated software;

engineer approved calculations;

contractor substituted material;

supervisor failed to inspect;

automated monitoring system was not calibrated.

A blame model may seek one negligent actor.

A system-design model maps the entire chain:

design → specification → procurement → construction → inspection → monitoring → approval.

The ultimate legal liability may still be allocated among individual actors, but the investigation begins with the system of responsibility.

38. Advanced Example — Cybersecurity

A customer loses AED 2 million through an unauthorised transfer.

The investigation finds:

stolen credentials;

no multi-factor authentication;

no transaction anomaly detection;

inadequate employee training;

no automatic high-value transfer hold.

The question is no longer simply:

"Who stole the money?"

Civil liability may also ask:

"Was the institution's security architecture reasonably designed to manage foreseeable risks?"

Aegis v Union Bank provides a useful illustration of this type of institutional-control analysis.

39. Shift Toward Resilience

An advanced form of system-design liability focuses on resilience.

A reasonable system is not necessarily one that never fails.

It may be one that:

detects failure quickly;

limits damage;

creates redundancy;

allows human intervention;

records events;

recovers rapidly.

Thus:

Safety = prevention + detection + containment + recovery.

This is especially important in:

financial systems;

cloud computing;

AI;

healthcare;

infrastructure;

cybersecurity.

40. Shift From Punishment to Incentives

Civil liability is not primarily criminal punishment.

Its functions include:

compensation;

risk allocation;

deterrence;

corrective justice;

encouraging reasonable precautions.

A system-design approach can therefore encourage organisations to invest in:

safer architecture;

stronger controls;

better training;

monitoring;

independent auditing;

incident response.

The legal system consequently influences future behaviour, not merely past blame.

41. Relationship With Insurance

System-design liability also interacts with insurance.

Businesses may insure:

professional liability;

cyber risks;

construction defects;

product liability;

directors' liability;

operational risks.

Insurance encourages formal risk assessment because insurers may require:

security controls;

audits;

compliance systems;

professional certifications;

incident-response procedures.

Thus, civil liability and private risk-management systems can operate together.

42. Relationship With Corporate Governance

Corporate governance can become part of civil liability where:

boards ignore known risks;

internal controls are inadequate;

risk committees fail;

compliance warnings are ignored;

management fails to implement necessary safeguards.

The relevant question becomes:

Was the organisation governed in a manner reasonably capable of preventing foreseeable harm?

This is particularly relevant for large UAE companies and regulated financial institutions.

43. Relationship With Regulatory Law

Modern UAE liability increasingly exists at the intersection of:

regulation + contract + tort/civil liability.

For example:

A financial regulator may require certain controls.

Failure to comply with those controls may not automatically establish civil liability in every case.

But the regulatory requirement may be relevant evidence concerning:

foreseeable risk;

reasonable conduct;

industry standards;

duty;

breach.

This distinction prevents regulatory rules from being mechanically converted into private causes of action.

44. Six Core Legal Questions

For an advanced UAE system-design liability problem, ask:

Question 1

Who designed or controlled the system?

Question 2

What foreseeable risk did the system need to address?

Question 3

What safeguards were reasonably required?

Question 4

Were those safeguards implemented?

Question 5

Did the system failure materially cause the damage?

Question 6

What proportion of responsibility should legally fall on each participant?

This framework is particularly useful for complex litigation.

45. Case-Law Revision Table

46. Ten Key Principles

1.

UAE civil law remains fundamentally concerned with wrongful conduct, damage and causation.

2.

A system-design model does not automatically create strict liability.

3.

Institutional processes can form part of the duty-of-care analysis.

4.

Foreseeability is critical.

5.

Professional standards can establish the benchmark for system design.

6.

Internal controls can become legally relevant where they are connected to the defendant's duty.

7.

Causation remains essential.

8.

Contributory negligence can reduce liability.

9.

Technical experts can explain system failure, but the court determines legal liability.

10.

DIFC jurisprudence provides particularly useful UAE examples for technology, finance and complex-system liability, but DIFC decisions should not automatically be treated as binding mainland UAE precedent.

47. Short Exam Answer

The UAE civil-law system is increasingly capable of addressing liability through a system-design perspective, although it has not formally replaced fault-based liability with a separate general doctrine of system liability.

Traditional liability asks who committed the negligent act. Modern system-oriented liability additionally examines whether an organisation, professional or service provider designed and operated a reasonable system for managing foreseeable risks.

This approach is particularly relevant to banking, cybersecurity, construction, digital assets, AI, financial services and complex professional activities.

The DIFC Law of Obligations expressly structures negligence around duty, breach, causation and loss, with foreseeability, proximity, assumption of responsibility and reasonable care playing important roles.

Cases such as Aegis Resources v Union Bank of India demonstrate the relevance of institutional payment controls; Gate Mena/Huobi v Tabarak demonstrates responsibility arising from the design of a digital-asset transaction mechanism; Haya Spa demonstrates liability for defective technical information; and Brookfield Multiplex demonstrates the importance of design, construction defects and expert evidence.

The emerging model can therefore be expressed as:

Individual fault + organisational responsibility + system design + risk controls + causation.

48. Conclusion

The UAE has not simply abandoned the traditional question of blame. Instead, complex modern disputes increasingly require the court to examine the system through which the harmful event occurred.

The practical shift is from:

Who made the mistake?

toward:

Who had responsibility for designing, controlling, supervising or maintaining the system, what risks were reasonably foreseeable, what safeguards were required, and did the system failure cause the loss?

This approach is particularly visible in DIFC jurisprudence concerning financial controls, digital assets, technical information, construction and professional duties. Aegis shows how institutional payment controls can become central to liability; Huobi/Tabarak shows how responsibility can arise from designing and implementing a transaction mechanism; Haya Spa demonstrates the importance of reliable technical information; and Brookfield Multiplex shows how complex construction failures require analysis of the entire professional and technical chain.

The emerging UAE model can therefore be described as a movement from purely individualised blame toward risk-sensitive, process-sensitive and system-aware civil liability.

The most important legal caution is that this is a method of analysing existing duties and breaches, rather than a universal new cause of action. A claimant must still establish a recognised legal duty or obligation, breach, causation and legally recoverable damage.