What are the key requirements for operational risk loss data governance under the SMA, and how should banks handle boundary events?

Loss data governance is the foundation of the SMA's loss-sensitive component. Without rigorous data standards, the Loss Component (and therefore the ILM) becomes unreliable. Basel's framework imposes detailed requirements on data collection, classification, validation, and boundary event treatment.\n\nGovernance Framework Requirements:\n\n`mermaid\ngraph TD\n A[\"Loss Data Governance
Framework\"] --> B[\"Collection Standards\"]\n A --> C[\"Classification Rules\"]\n A --> D[\"Validation & Audit\"]\n A --> E[\"Boundary Event Policy\"]\n B --> F[\"EUR 20K minimum threshold
Date of accounting recognition
Gross and net amounts
Recovery tracking\"]\n C --> G[\"7 Basel event types
Business line mapping
Root cause coding
Consistent taxonomy\"]\n D --> H[\"Independent validation unit
External audit review
Board-level reporting
Annual data quality assessment\"]\n E --> I[\"Credit-operational boundaries
Market-operational boundaries
Legal entity attribution
Consistent treatment policy\"]\n`\n\nThe Seven Basel Event Types:\n\n| Event Type | Examples | Common Boundary Issues |\n|---|---|---|\n| Internal Fraud | Rogue trading, embezzlement | Trading loss vs. market loss? |\n| External Fraud | Cyber theft, card fraud | Credit card fraud vs. credit loss? |\n| Employment Practices | Discrimination lawsuits, safety | HR cost vs. operational loss? |\n| Clients, Products, Practices | Mis-selling, AML fines | Regulatory fine vs. legal cost? |\n| Damage to Physical Assets | Natural disaster, terrorism | Insurance recovery timing? |\n| Business Disruption | IT outages, system failures | Revenue loss vs. direct cost? |\n| Execution & Process Mgmt | Settlement errors, data entry | Failed trade vs. market loss? |\n\nBoundary Event Treatment -- Worked Example:\n\nClearfield Commercial Bank experiences a EUR 45M loss when a loan officer falsifies income documentation on 200 commercial loans, leading to defaults.\n\nIs this operational or credit risk?\n\n- Credit risk view: The loans defaulted due to borrower inability to pay. Loss = LGD x EAD.\n- Operational risk view: The root cause was internal fraud (falsified documentation). Without the fraud, these loans would not have been originated.\n\nBasel guidance: Losses that are related to credit risk but have an operational risk root cause are classified as credit risk for capital purposes but must still be captured in the operational risk loss database. They are flagged as 'boundary events' and may be included in the Loss Component calculation at supervisory discretion.\n\nClearfield's approach:\n- Record EUR 45M as credit losses in the credit risk capital framework\n- Flag as boundary event in operational risk database\n- Include a memo entry for LC calculation (supervisor decides inclusion)\n- Root-cause code: Internal Fraud -- Unauthorized Activity\n\nData Quality Metrics Banks Should Track:\n\n1. Completeness ratio: % of business units with active loss reporting\n2. Timeliness: average days between event occurrence and database entry\n3. Accuracy: % of entries requiring correction after initial submission\n4. Threshold compliance: % of losses above EUR 20K that are captured\n5. Recovery tracking: % of losses with updated recovery data\n\nCommon Pitfalls:\n- Inconsistent application of the EUR 20K threshold across business lines\n- Failure to update loss amounts as legal proceedings resolve over years\n- Under-reporting in business lines with strong P&L pressure\n- Treating insurance recoveries as loss reductions rather than separate recovery entries\n\nPractice loss data classification scenarios in our FRM question bank.