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:
- Central Bank of Kuwait (CBK) legislation, instructions and supervisory reporting requirements; and
- 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 field | Purpose |
|---|---|
| Event ID | Unique identification |
| Date of event | Establishes occurrence |
| Discovery date | Measures detection delay |
| Business unit | Identifies responsible area |
| Process | Identifies affected activity |
| Risk category | Classifies the event |
| Cause | Identifies root cause |
| Gross loss | Measures financial impact |
| Recovery | Records insurance/third-party recovery |
| Net loss | Measures actual economic impact |
| Customer impact | Measures conduct consequences |
| Regulatory impact | Identifies reporting obligations |
| Control failure | Identifies weakness |
| Corrective action | Tracks remediation |
| Responsible officer | Establishes accountability |
| Closure date | Tracks remediation |
| Supporting evidence | Preserves 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:
- What information is required?
- Who owns the data?
- Who validates it?
- Who approves submission?
- When must it be submitted?
- What evidence supports the figures?
- 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.

comments