> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Fallmanagement - Fälle & Lebenszyklus

> Fälle in Didit öffnen, bearbeiten und abschließen, pro Benutzer oder Unternehmen, mit gespeicherten Ansichten, SLA-Fristen und Massenaktionen.

Das Fallmanagement ist die zentrale Untersuchungsstelle der Didit Console. Jeder AML-Treffer, jede markierte Verifizierung oder verdächtige Transaktion kann zu einem **Fall** werden, mit dem Ihr Compliance-Team von der Eröffnung bis zum Abschluss arbeitet, mit einem vollständigen Audit-Log.

***

## Lebenszyklus

Ein Fall durchläuft genau drei Status:

| Status | Bedeutung |
| - | - |
| `Open` | Wird aktiv geprüft |
| `Awaiting user` | Pausiert, während weitere Informationen vom verifizierten Benutzer erhoben werden |
| `Resolved` | Untersuchung abgeschlossen, mit dokumentiertem Abschlussgrund |

Um einen Fall abzuschließen, ist ein Abschlussgrund erforderlich:

| Abschlussgrund | Bedeutung |
| - | - |
| `False positive` | Die Aktivität war legitim |
| `Valid threat` | Verdächtige oder betrügerische Aktivität wurde bestätigt |

Jeder Fall hat außerdem eine **Priorität** (`Low`, `Medium`, `High`, Standard `Medium`) und ein optionales **Fälligkeitsdatum**, das die Sortierung nach SLA und die Markierungen für überfällige Fälle steuert.

> [!NOTE]
>
> Es gibt kein `Under review`, `On hold`, `Pending approval`, keinen `Critical`-Schweregrad und keine Falltyp-Achse. Der Lebenszyklus ist bewusst fest vorgegeben, damit Auswertungen, SLAs und Berechtigungen für jeden Fall eindeutig bleiben, unabhängig davon, wie er angelegt wurde.

## Ein Subjekt pro Fall

Jeder Fall ist genau einem **einzelnen** Benutzer oder einem Unternehmen zugeordnet. Sie können auf einem Fall keine Subjekte mischen. Sie können auch keine Sitzung, Unternehmenssitzung oder Transaktion anhängen, die einem anderen Subjekt gehört als dem Fall; in diesem Fall wird eine eindeutige Fehlermeldung zurückgegeben.

So bleibt jede Fallseite fokussiert: Die Subjektkarte, die Risikoübersicht, die Dokumente und die Finanzdaten beziehen sich alle auf dieselbe Person oder dasselbe Unternehmen, das untersucht wird. Um eine zweite Entität zu prüfen, öffnen Sie einen separaten Fall oder legen Sie einen neuen an.

## Kontext der Fraud-Check-Quelle

Wenn Sie einen Fall aus einer Fraud-Check-Sitzung anlegen, bleiben deren Check-ID, Anfrage-ID und der Bereich erhalten, den der Prüfer geöffnet hat.
Die Quellkarte hält außerdem den Analystenstatus der Sitzung zum Zeitpunkt der Fallanlage fest.
Die Entscheidung zum Fall und die Entscheidung zur Quelle bleiben getrennt.

API-Clients können beim Anlegen eines Falls `source_context` mit `check_id`, `request_id` und `source_section` übergeben.
Nehmen Sie diese Anfrage als Eintrag `session` in `links` auf.
Der Check und die verknüpfte Sitzung müssen zur ausgewählten Anwendung gehören und zueinander passen.
Die API liest den Analystenstatus selbst aus und lehnt in diesem Kontext vom Aufrufer übergebene Felder für Status, Empfehlung oder Quelltyp ab.

## Listen

Das Fallmanagement bietet in der oberen Navigation **Fälle**, **Übersicht** und **Zuweisung** an.
Der Bereich Fälle bietet die Statusansichten **Offen**, **Wartet auf Benutzer**, **Gelöst** und **Alle**.
Beim Öffnen eines Falls bleibt auf dem Desktop die Fallwarteschlange neben den Details sichtbar.
Auf dem Smartphone gelangen Sie über die Breadcrumb-Navigation zurück zur Warteschlange.

Die Suche findet Name oder ID des Subjekts, Tag, Fallnummer, Falltitel, verknüpfte Sitzungs-ID und verknüpfte Transaktions-ID. Sie können also eine Sitzungs- oder Transaktions-UUID einfügen und landen direkt beim zugehörigen Fall.

Filter-Chips: **Blueprint**, **Erstellt**, **Quelle**, **Zuständiger**, **Tag**, sowie **Filter hinzufügen** für **Priorität** und **Fällig**.

Spalten: Erstellt (Datum und Ersteller), Falldetails (Titel), Status, Blueprint, Subjekt (Name und ID), Subjekt-Tags, Zuständiger, Priorität und Fälligkeitsdatum. Weitere Spalten sind über horizontales Scrollen und die Spaltenkonfiguration verfügbar.

### Sortierung und SLA

Sortieren Sie nach **Erstellt am** (Standard) oder **Fälligkeitsdatum**. Bei Sortierung nach Fälligkeitsdatum erscheinen überfällige Fälle zuerst. Ein Fall ist überfällig, sobald sein Fälligkeitsdatum verstrichen ist, während er noch offen ist oder auf den Benutzer wartet. Er wird mit einem roten Chip **Fällig** angezeigt.

### Gespeicherte Ansichten

Speichern Sie die aktuelle Kombination aus Filtern und Spalten als benannte Ansicht mit **Ansicht speichern**. Wechseln Sie zwischen Ansichten über **Ansicht auswählen** und setzen Sie mit **Filter zurücksetzen** alles zurück. Ansichten sind persönlich und bleiben auf dieselbe Weise erhalten wie andere Tabelleneinstellungen der Console.

### Massenaktionen

Wählen Sie mehrere Fälle aus, um:

* **Zuweisen an** einen Compliance-Beauftragten. Alle ausgewählten Fälle müssen denselben Blueprint haben. Die Console warnt vor dem Absenden, wenn dies nicht der Fall ist.
* **Status festlegen** auf Wartet auf Benutzer, Erneut öffnen oder Als gelöst markieren (mit Abschlussgrund und optionaler Notiz). Jeder Fall wird einzeln geprüft. Ein Fall, der durch eine unvollständige Checkliste oder eine fehlende Pflichtnotiz blockiert ist, wird einzeln gemeldet, ohne den Rest des Stapels abzubrechen.

### Exporte

Das Listenmenü bietet zwei CSV-Exporte, die über die [Berichtsseite](https://docs.didit.me/de/console/export-pdf-csv.md) bereitgestellt werden:

* **Bericht aller Fälle** mit einer Zeile pro Fall, mit Status, Abschlussgrund, Priorität, Tags, verknüpften Transaktionen und dem zuletzt eingereichten FIU-Bericht.
* **SLA-Bericht** mit zeitbezogenen Kennzahlen pro Fall: Stunden bis zur Zuweisung, Stunden bis zum Abschluss sowie Markierungen für überfällig und für eingehaltenes SLA.

## Aktionen zum Subjekt und Wiederholungsversuche

Über die Subjektkarte können berechtigte Prüfer den Status des Subjekts ändern, Tags hinzufügen, eine interne Notiz anlegen oder das Subjekt in die Sperrliste aufnehmen.
Diese Aktionen sind vom Abschluss des Falls getrennt.
Der Bereich Aktionen für das Subjekt erfasst jede angeforderte Aktion als **Angewendet** oder **Fehlgeschlagen** und zeigt Prüfer und Zeitpunkt an.
Verwenden Sie **Aktion wiederholen**, um eine fehlgeschlagene Aktion erneut auszuführen, nachdem Sie das aktuelle Subjekt geprüft haben.
Eine angewendete Aktion wird nicht erneut ausgeführt, wenn ihre Anfrage wiederholt wird.

API-Clients sollten mit jeder Anfrage an den Endpoint `entity-actions/` des Falls eine eindeutige `client_reference` senden.
Behalten Sie dieselbe Referenz und dieselbe Eingabe bei, wenn Sie eine Anfrage nach einem Verbindungsfehler wiederholen.
Eine geänderte Eingabe mit derselben Referenz liefert `409` zurück.
Wenn eine Referenz angegeben ist, prüfen Sie `receipt.status`. Eine Antwort mit `200` kann einen fehlgeschlagenen Beleg enthalten, was bedeutet, dass die Aktion nicht angewendet wurde.
Das erneute Senden einer fehlgeschlagenen Anfrage erfordert `retry: true` oder den Aufruf des Endpoints `action-receipts/{receipt_uuid}/retry/`.
Der Verlaufs-Endpoint liefert pro Seite höchstens 20 Belege und stellt `next_offset` für weitere Ergebnisse bereit.
Bestehende API-Clients, die `client_reference` weglassen, behalten ihr bisheriges Antwortverhalten.

## Tags

Fügen Sie einem Fall über dessen Kopfzeile Tags hinzu (**Tag hinzufügen**), um zusammengehörige Untersuchungen zu gruppieren. In der Liste können Sie außerdem nach Tags filtern und suchen. Änderungen an Tags werden in der Zeitleiste des Falls protokolliert.

## Verwandte Seiten

> [card] [Fälle anlegen](https://docs.didit.me/de/console/case-management/creating-cases.md)
>
> Alle Einstiegspunkte: Benutzer, Unternehmen, Sitzungen, Transaktionen und automatische Konnektoren.

> [card] [Blueprints](https://docs.didit.me/de/console/case-management/blueprints.md)
>
> Konfigurieren Sie Zuweisung, Eskalation, Übertragung und den Inhalt der Fallseite.

> [card] [Checkliste](https://docs.didit.me/de/console/case-management/checklist.md)
>
> Machen Sie den Abschluss von den erforderlichen Untersuchungsschritten abhängig.

> [card] [4-Augen-Prüfung](https://docs.didit.me/de/console/case-management/four-eyes.md)
>
> Maker/Checker-Freigabe für sensible Abschlüsse.

## Kundennachrichten

Verwenden Sie **Nachricht senden**, um eine Vorschau einer vordefinierten Anfrage oder eines Prüfungsupdates für einen verifizierten Kontakt anzuzeigen.
Zu Zustellungsstatus, sicheren Antworten und dem API-Workflow siehe [Kundennachrichten](https://docs.didit.me/de/console/case-management/customer-messages.md).

## Diskussion und angepinnte Notizen

Öffnen Sie die Diskussionsschaltfläche neben dem Fallstatus, um Notizen zu prüfen, ohne die Untersuchung zu verlassen.
Verwenden Sie das Menü einer Notiz, um darauf zu antworten oder sie anzupinnen.
Angepinnte Notizen erscheinen zuerst, und Antworten zeigen einen kurzen Auszug ihrer übergeordneten Notiz.
Änderungen an der Anheftung werden in der Fallaktivität protokolliert und ändern keine Entscheidungen aus der Quelle.

Durch Bestätigen der Löschung werden die Notiz und ihr zitierter Auszug in Antworten dauerhaft entfernt.
Die Antworten selbst bleiben erhalten.
Anhänge werden gelöscht, sofern sie nicht noch von einer anderen Notiz verwendet werden.

API-Clients können beim Hinzufügen einer Notiz eine `client_reference`-UUID angeben.
Ein unveränderter Wiederholungsversuch gibt die bestehende Notiz zurück, ohne Benachrichtigungen zu duplizieren.
Wird diese Referenz für geänderten Inhalt oder für eine gelöschte Notiz verwendet, liefert die Erstellung `409` zurück.
Geben Sie `reply_to` an, um auf eine aktive Notiz im selben Fall zu verweisen, und aktualisieren Sie `is_pinned` über den `PATCH`-Endpoint der Notiz.

## Nach einer bestehenden Untersuchung suchen

Der gemeinsame Dialog zum Anlegen eines Falls prüft auf bestehende Untersuchungen für den ausgewählten Benutzer, das Unternehmen oder die verknüpfte Quelle.
Öffnen Sie einen bestehenden Fall, um die Prüfung fortzusetzen.
Geschlossene Fälle bleiben sichtbar, damit Sie sie öffnen und entscheiden können, ob Sie sie wieder öffnen.
Um eine separate Untersuchung anzulegen, geben Sie einen Grund dafür an, dass es sich um einen anderen Vorfall handelt.
Der Grund wird mit dem neuen Fall gespeichert und in dessen Übersicht angezeigt.
Die Konsole prüft beim Absenden erneut auf Duplikate, auch auf Fälle, die ein anderer Prüfer angelegt hat, während der Dialog geöffnet war.

API-Integrationen können `POST .../cases/duplicates/` aufrufen, um Duplikate zu prüfen, und beim Anlegen eines Falls `review_duplicates=true` setzen.
Wird eine bestehende Untersuchung gefunden, liefert die Erstellung `409` zurück, sofern nicht `separate_incident_reason` angegeben ist.
Der Endpoint zur Duplikatsprüfung gibt bis zu 20 Fälle pro Seite zurück, mit `next_offset` für weitere Ergebnisse.
Bestehende API-Integrationen, die die Option weglassen, behalten ihr bisheriges Verhalten beim Anlegen bei.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.