Fallmanagement - Fälle & Lebenszyklus

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: Um einen Fall abzuschließen, ist ein Abschlussgrund erforderlich: 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.

​

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 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

​

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.

​

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.