Banking Law And Operational Risk Data Collection Governance Kuwait .

Banking Law and Operational Risk Data Collection Governance in Kuwait

1. Introduction

Operational risk data collection governance in Kuwaiti banking law concerns the legal and supervisory framework governing how banks identify, record, validate, protect, analyse and report information about operational-risk events and losses.

Operational risk generally arises from failures involving:

  • internal processes;
  • employees and other people;
  • information systems;
  • technology;
  • fraud;
  • external events;
  • legal and compliance failures;
  • payment and settlement processes;
  • outsourcing and third-party providers.

For Kuwait, this subject has two interconnected foundations:

  1. Central Bank of Kuwait (CBK) legislation, instructions and supervisory reporting requirements; and
  2. Basel operational-risk and risk-data principles, which CBK has incorporated progressively into its supervisory framework.

CBK's own supervisory material identifies governance, risk management, internal controls, internal/external audit and statistical supervisory systems as components of its banking-supervision framework.

2. Statutory Foundation: Central Bank of Kuwait Law

The principal statute is Law No. 32 of 1968 concerning Currency, the Central Bank of Kuwait and the Organisation of Banking Business, as amended.

The statute is particularly important because it gives CBK extensive powers concerning banking information, inspection, statistics and supervisory data.

Article 82 — Banking Information and Statistical Data

Article 82 provides that CBK may require banks to submit:

  • statements;
  • information;
  • statistical data;
  • periodic banking-credit statistics.

The CBK Board determines the nature of information and submission periods, and banks are required to provide information requested under the applicable CBK system.

This is the statutory foundation for an important principle:

Operational-risk data governance is not merely an internal management preference; banks have legally enforceable information and reporting obligations toward CBK.

3. Article 83 — Centralized Risks System

Article 83 allows CBK to establish a Centralized Risks System.

Its objectives include:

  • assisting banks in evaluating the financial position of credit applicants;
  • allowing CBK to monitor banking-credit trends;
  • supporting the application of the discount and rediscount system.

The provision also regulates disclosure of information obtained through the system.

Although Article 83 principally concerns credit risk rather than operational risk, it demonstrates an important Kuwaiti regulatory principle:

Centralized and reliable banking data is a component of prudential supervision.

The same logic extends to operational-risk data.

4. Article 78 — CBK Inspection

CBK has powers to inspect banks and review their:

  • books;
  • records;
  • instruments;
  • operations.

After inspection, CBK may prepare a comprehensive report identifying weaknesses and recommending corrective measures. CBK can also prescribe a period within which the institution must correct violations or unsound conditions.

This has major implications for operational-risk data governance.

A bank therefore needs records that enable CBK or its inspectors to reconstruct:

Event → Cause → Control failure → Financial impact → Corrective action → Management response.

5. Article 79 — False or Withheld Information

Article 79 is particularly significant.

A director, manager or official who:

  • refuses to provide information or records required for inspection; or
  • knowingly provides false information or data

may be subject to statutory penalties.

Consequently, operational-risk data governance involves more than simply maintaining a database.

The information must be:

  • available;
  • accurate;
  • complete;
  • authentic;
  • capable of being produced to the regulator.

6. Article 80 — Confidentiality

CBK inspectors and officials are subject to confidentiality obligations concerning information obtained during inspections.

The statute restricts disclosure of information concerning:

  • banks;
  • customers;
  • accounts;
  • books;
  • instruments.

There are statutory exceptions for legally permitted disclosures.

This creates a fundamental balance:

CBK must have sufficient information for effective supervision, while banking information must remain confidential except where disclosure is legally authorized.

Operational-risk data governance must therefore incorporate access control and confidentiality.

7. Article 84 — Internal Control and Audit

Article 84 requires the external auditor's annual report to address the adequacy of the bank's internal control systems and the sufficiency of provisions against losses and liabilities.

This connects operational-risk data with the audit function.

A bank's operational-loss database should therefore be capable of supporting:

  • internal audit;
  • external audit;
  • risk-management review;
  • regulatory inspection;
  • management reporting.

8. CBK Instructions for Conventional Banks

CBK publishes extensive instructions applicable to conventional banks.

The CBK's official list expressly includes instructions concerning:

  • internal control systems;
  • confidentiality of customer information and data;
  • notification of embezzlement;
  • external auditors;
  • electronic payment of funds;
  • financial statements;
  • risk systems;
  • regulatory reporting. 

The official CBK website also notes that its English translation is provided for information and that the Arabic text is the legally authoritative version.

9. Basel Operational-Risk Framework

Kuwait has adopted Basel standards as an important part of its prudential framework.

CBK announced the application of Basel II's standardized approach for operational risk and conducted implementation trials with local banks before its application.

This matters because Basel's operational-risk framework requires banks to develop reliable systems for:

  • identifying operational-risk events;
  • measuring losses;
  • monitoring exposures;
  • reporting risk;
  • maintaining appropriate controls.

10. What Should Operational-Risk Data Contain?

A proper operational-risk database should ordinarily record at least:

Data fieldPurpose
Event IDUnique identification
Date of eventEstablishes occurrence
Discovery dateMeasures detection delay
Business unitIdentifies responsible area
ProcessIdentifies affected activity
Risk categoryClassifies the event
CauseIdentifies root cause
Gross lossMeasures financial impact
RecoveryRecords insurance/third-party recovery
Net lossMeasures actual economic impact
Customer impactMeasures conduct consequences
Regulatory impactIdentifies reporting obligations
Control failureIdentifies weakness
Corrective actionTracks remediation
Responsible officerEstablishes accountability
Closure dateTracks remediation
Supporting evidencePreserves audit trail

Basel guidance specifically emphasizes that operational-risk reports should be comprehensive, accurate, consistent and actionable. It also identifies significant internal operational events, losses and root-cause analysis as important reporting components.

11. Data Collection Governance

Operational-risk data governance can be divided into six stages:

Stage 1 — Identification

Employees and business units identify an operational-risk event.

Stage 2 — Recording

The event is entered into the central operational-risk system.

Stage 3 — Validation

Risk-management personnel verify:

  • classification;
  • loss amount;
  • cause;
  • business impact;
  • regulatory significance.

Stage 4 — Reconciliation

The operational-risk database is reconciled with:

  • accounting records;
  • legal claims;
  • insurance recoveries;
  • fraud records;
  • customer complaints.

Stage 5 — Reporting

Information is reported to:

  • senior management;
  • risk committees;
  • board;
  • CBK where required.

Stage 6 — Remediation

The bank identifies the control weakness and monitors corrective action.

12. Three Lines of Defence

A strong governance framework normally uses the three-lines model.

First Line — Business Units

Business units are responsible for:

  • identifying incidents;
  • recording losses;
  • maintaining process controls;
  • escalating incidents.

Second Line — Risk Management

Risk management:

  • establishes methodology;
  • validates classifications;
  • analyses trends;
  • monitors risk appetite;
  • prepares risk reports.

Third Line — Internal Audit

Internal audit independently evaluates:

  • data quality;
  • controls;
  • methodology;
  • governance;
  • reporting;
  • regulatory compliance.

This approach is consistent with Basel's expectation for strong operational-risk monitoring and reporting.

13. Board-Level Governance

Operational-risk data should eventually reach the board of directors.

Basel guidance states that appropriate operational-risk reporting should exist at:

  • board level;
  • senior-management level;
  • business-unit level. 

The board should receive information concerning:

  • major operational losses;
  • fraud;
  • cyber incidents;
  • control failures;
  • emerging risks;
  • risk appetite breaches;
  • unresolved audit findings;
  • major third-party incidents.

The purpose is not to give directors every individual incident.

Rather:

The board should receive sufficient aggregated information to understand the bank's operational-risk profile and material weaknesses.

14. Data Quality

One of the most important elements is data quality.

Operational-risk information should satisfy:

Accuracy

The recorded loss should correspond with the underlying accounting evidence.

Completeness

Material incidents should not be omitted.

Consistency

Different departments should classify similar events in the same manner.

Timeliness

Material incidents should be reported promptly.

Traceability

Every material figure should be capable of being traced back to evidence.

Integrity

Records should not be improperly altered or deleted.

Basel's risk-data principles emphasize governance, accuracy, integrity, completeness, timeliness, adaptability, comprehensiveness and usefulness of risk information.

15. Operational Loss Data

CBK's Financial Stability Report provides useful evidence of why this system matters.

CBK reported that Kuwaiti banks' operational losses reached approximately KD 7.4 million in 2021. It identified external fraud and execution, delivery and process-management errors among the principal operational-risk categories by volume and value.

This illustrates that operational-risk data is not theoretical.

It can reveal:

  • fraud patterns;
  • process weaknesses;
  • transaction errors;
  • technology failures;
  • control deficiencies.

16. Root-Cause Analysis

Recording only the monetary loss is insufficient.

For example:

Bank loses KD 100,000 through payment-processing error.

A weak database records:

Loss = KD 100,000.

A stronger governance system records:

Employee error → inadequate segregation of duties → defective approval workflow → system weakness → payment incorrectly executed → KD 100,000 loss.

This distinction is legally and prudentially important because the purpose of operational-risk management is risk reduction, not merely historical accounting.

Basel specifically recommends reporting significant events together with root-cause analysis.

17. Fraud Data Governance

Fraud is a particularly important operational-risk category.

A Kuwaiti bank should be capable of identifying:

  • internal fraud;
  • external fraud;
  • attempted fraud;
  • successful fraud;
  • employee involvement;
  • customer impact;
  • recovery;
  • law-enforcement referral;
  • control failure.

CBK's regulatory instructions specifically include notification requirements concerning embezzlement of bank funds.

Therefore, fraud data should not remain solely within:

Internal audit or security department.

Material fraud information should feed into the bank's broader operational-risk framework.

18. Cyber and Technology Risk

Modern operational-risk governance must also capture:

  • cyberattacks;
  • ransomware;
  • system downtime;
  • unauthorized access;
  • data breaches;
  • payment-system interruptions;
  • software failures;
  • cloud outages;
  • telecommunications failures.

The data architecture should link:

Cyber incident → operational event → customer impact → financial loss → regulatory notification → remediation.

This allows senior management to determine whether an apparently technical event has become a material banking-risk event.

19. Third-Party and Outsourcing Data

Banks increasingly depend upon:

  • cloud providers;
  • payment processors;
  • technology vendors;
  • cybersecurity companies;
  • telecommunications providers.

Therefore, operational-risk databases should identify:

Which critical service failed?

Which third party caused or contributed to the failure?

How long was the service unavailable?

What customers were affected?

What financial loss resulted?

Was the third-party contract adequate?

Basel guidance also emphasizes maintaining information about products and services, including outsourced services, to monitor changes and operational risk.

20. Data Confidentiality

Operational-risk information can itself be highly sensitive.

It may reveal:

  • security vulnerabilities;
  • fraud patterns;
  • employee misconduct;
  • customer information;
  • system weaknesses;
  • cyber vulnerabilities.

Therefore, access should be based on need-to-know principles.

This follows naturally from Article 80's confidentiality requirements concerning information obtained in banking supervision.

21. Regulatory Reporting

CBK has authority to prescribe the nature and timing of data and information that banks must submit.

Therefore, banks need a regulatory-reporting process capable of answering:

  1. What information is required?
  2. Who owns the data?
  3. Who validates it?
  4. Who approves submission?
  5. When must it be submitted?
  6. What evidence supports the figures?
  7. How is the submitted information retained?

A bank should never depend upon manually reconstructed data immediately before a regulatory deadline.

22. Data Retention and Audit Trail

A strong operational-risk governance system should preserve an audit trail showing:

Original event → data entry → amendment → validation → approval → reporting → remediation → closure.

This becomes especially important when a dispute arises.

For example, if a bank reports that:

"No material operational loss occurred"

the bank should be able to demonstrate:

  • how it searched for incidents;
  • what thresholds were applied;
  • who validated the result;
  • what accounting records were reconciled;
  • which exceptions were excluded.

23. Case Law

A qualification is important here: publicly accessible Kuwaiti case law specifically addressing the modern technical concept of “operational-risk data collection governance” is limited. It would therefore be inaccurate to present ordinary banking cases as if they directly decided Basel operational-risk data-governance questions.

The following Kuwaiti authorities are better understood as analogous banking and regulatory authorities relevant to the legal principles underlying operational-risk data governance.

Case 1 — Kuwait Court of Cassation, Appeal No. 685/2010 (Administrative), Judgment of 22 May 2013

This litigation involved The Investment Dar Company and the Central Bank of Kuwait, including issues concerning CBK regulatory action and the company's financial position.

The case is relevant to operational-risk governance because it illustrates that supervisory decisions must have an appropriate factual and legal basis.

Principle

A regulator's decision affecting a financial institution is capable of judicial scrutiny, including scrutiny of the factual and legal basis for the decision.

Operational-risk relevance

CBK supervisory decisions based upon operational-risk information should therefore be supported by:

  • reliable data;
  • identifiable methodology;
  • documented evidence;
  • legally relevant criteria.

This makes data provenance important.

24. Case 2 — Kuwait Court of Cassation, Appeal No. 1484/2023, Commercial Circuit, 29 October 2023

This banking dispute concerned a loan, promissory-note documentation and disputes concerning amounts, interest and charges in the context of CBK requirements.

Principle

A court examining a banking dispute may need to consider the substantive financial evidence and applicable regulatory requirements rather than relying mechanically on an isolated document.

Operational-risk relevance

The same principle supports the need for reconciled operational-risk data.

A bank should not rely exclusively on one database field.

LEAVE A COMMENT