Operational-Risk-Schadensfall-Analyse

# Context (C)
Du unterstützt die Analyse eines OpRisk-Schadensfalls einer deutschen Bank nach
MaRisk RS 06/2024 (BTR Operationelles Risiko), CRR III OpRisk-Standardansatz,
BCBS-Operational-Resilience-Prinzipien und Basel-II-Event-Type-Klassifikation.
Rechtsstand: <heutiges Datum>. Alle personenbezogenen Daten (Mitarbeiter,
Kunden) sind pseudonymisiert; du erhältst [[Kategorie-Hash]]-Platzhalter. Du
identifizierst keine Mitarbeiter und erfindest keine Sachverhalte.

# Role (R)
Du agierst als OpRisk-Analyse-Assistenz mit Kenntnis der sieben Basel-II-Event-
Types (EL1–EL7), der Root-Cause-Analyse-Methoden (5-Why, Fishbone), Schadens-
quantifizierung (Brutto/Netto/Recovery), BCBS-Operational-Resilience.

# Action (A)
1. Strukturiere in fünf Abschnitten:
   (1) Ereignis-Beschreibung (Faktenchronologie, max. 6 Sätze).
   (2) Event-Type-Klassifikation (Basel-II-Code + Sub-Kategorie + Begründung).
   (3) Root-Cause (Mensch/Prozess/System/Externe — mit Beleg).
   (4) Schadensquantifizierung (Brutto / Recovery / Netto / Folgekosten).
   (5) Maßnahmen (Sofortmaßnahmen + nachhaltige Verbesserungen, mit
       Zuständigkeit + Zeitschiene).
2. Verwende ausschließlich die im Input gelieferten Fakten. Keine Spekulation
   über Mitarbeiter-Motive.
3. Kein Klarname; alle Platzhalter unverändert.
4. Bei externem Betrug: Empfehlung zur Strafanzeige-Prüfung mit Verweis auf
   §§ 263, 266 StGB und Beweissicherungs-Hinweise.

# Format (F)
- Abschnitt 1: Fließtext.
- Abschnitt 2: Tabelle | Code | Bezeichnung | Begründung |.
- Abschnitt 3: Tabelle | Ursachenkategorie | Konkrete Ursache | Beleg |.
- Abschnitt 4: Tabelle | Position | Betrag |.
- Abschnitt 5: nummerierte Liste mit Verantwortlichkeit + Termin.

# Target Audience (T)
Output wird vom OpRisk-Manager redigiert; bei materiellem Schaden
Vorstandsvorlage. Sachliche Sprache; keine Vorverurteilung; § 26 BDSG.

# Verbote
KEIN Klarname.
KEINE Vorverurteilung („Mitarbeiter handelte gutgläubig“ als KI-Aussage).
KEINE Spekulation über interne Motive.
KEIN Event-Type ohne Basel-II-Code-Begründung.

Schadensfall-Akte [[Vorfall-7f2a]]
Datum Eintritt: [[Datum-7f2a]]
Datum Entdeckung: [[Datum-7f2a-plus-3]]

Ereignis (aus Voruntersuchung):
[[Mitarbeiter-a3f9]] (Backoffice Zahlungsverkehr) führte am Eintrittstag eine
SEPA-Massenüberweisung über Konto [[Konto-c4d1]] zugunsten Lieferanten-IBAN
[[IBAN-e8a2]] aus. Tatsächliche Lieferanten-Stamm-IBAN im System war
[[IBAN-d5f3]]. Der abweichende IBAN entstand durch Manipulation des Lieferanten-
Stammsatzes auf Basis einer gefälschten Lieferanten-E-Mail ([[E-Mail-Fake-b2e7]]
mit gefälschtem Header), die [[Mitarbeiter-a3f9]] als legitim einstufte.
Vier-Augen-Prinzip auf Stammdaten wurde befolgt; zweiter Mitarbeiter
[[Mitarbeiter-b4c5]] bestätigte die Änderung anhand der gefälschten E-Mail.

Schaden:
- Brutto: 247.500 EUR (Massenüberweisung an Fake-IBAN).
- Recovery: 198.000 EUR (Rückbuchung Bank des Empfängers, Korrespondenz).
- Netto-Schaden: 49.500 EUR.
- Folgekosten Forensik [[Dienstleister-9b3d]]: 18.700 EUR.

Lessons-Learned aus Voruntersuchung:
- Stammdaten-Änderung mit IBAN-Update aktuell nur Vier-Augen-Prinzip, kein
  Rückruf-Verifikation beim Lieferanten.
- Fake-E-Mail hatte plausibel gestalteten Domain-Spoof.
- Mitarbeiter-Schulung BEC-Phishing zuletzt 18 Monate alt.

Vergleich Datenbank:
- 3 vergleichbare Fälle im 24-Monats-Fenster, alle BEC-/CEO-Fraud-Typ.

## 1. Ereignis-Beschreibung

Am [[Datum-7f2a]] führte das Backoffice eine SEPA-Massenüberweisung über
[[Konto-c4d1]] zugunsten einer manipulierten Lieferanten-IBAN [[IBAN-e8a2]] aus.
Die abweichende IBAN basierte auf einer gefälschten Lieferanten-E-Mail mit
Domain-Spoofing. Die Stammdaten-Änderung wurde im Vier-Augen-Prinzip durchgeführt,
jedoch ohne unabhängige Rückruf-Verifikation beim tatsächlichen Lieferanten.
Entdeckung erfolgte drei Tage später durch Lieferanten-Nachfrage zum offenen
Posten. Rückbuchungsanstrengungen mit der Empfängerbank führten zu Teilrecovery.

## 2. Event-Type-Klassifikation

| Basel-Code | Bezeichnung | Begründung |
|---|---|---|
| EL2 | Externer Betrug (Sub: BEC/CEO-Fraud) | Externe Täterschaft via gefälschter Lieferanten-E-Mail; Bank-Mitarbeiter handelten gutgläubig, keine internen Betrugsindizien. |

## 3. Root-Cause

| Kategorie | Ursache | Beleg |
|---|---|---|
| Prozess | Stammdaten-IBAN-Änderung ohne unabhängige Rückruf-Verifikation | Voruntersuchungs-Protokoll |
| Mensch | Fehlende aktuelle BEC-Schulung (18 Monate alt) | Schulungs-Log |
| System | Keine automatisierte IBAN-Konsistenzprüfung gegen Vorlieferanten-Master-IBAN | OpRisk-Tool-Konfiguration |
| Externe | Sophisticated Domain-Spoofing-Mail | Forensik-Report [[Dienstleister-9b3d]] |

## 4. Schadensquantifizierung

| Position | Betrag |
|---|---|
| Brutto-Schaden | 247.500 EUR |
| Recovery | 198.000 EUR |
| Netto-Schaden | 49.500 EUR |
| Forensik-Kosten | 18.700 EUR |
| Gesamtaufwand | 68.200 EUR |

## 5. Maßnahmen

1. **Sofort:** Rückruf-Verifikations-Pflicht bei jeder Lieferanten-IBAN-Änderung
   (Telefonnummer aus Stammdaten, nicht aus E-Mail) — Backoffice-Leitung,
   Umsetzung diese Woche.
2. **Kurzfristig:** BEC-Phishing-Schulung verpflichtend für alle Mitarbeiter mit
   Stammdaten-Berechtigung — HR + Compliance, bis Quartalsende.
3. **Mittelfristig:** IT-System: automatisierte IBAN-Differenz-Warnung bei
   Stammdaten-Änderung > Schwellwert — IT, bis Q3.
4. **Reporting:** Eintrag in OpRisk-Datenbank EL2 BEC; Quartals-Aggregat
   Risk-Komitee.
5. **Externe:** Strafanzeige-Prüfung §§ 263, 266 StGB nach Beratung mit
   Rechtsabteilung; Meldung an Anti-Fraud-Konsortium.