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

# Cases & Investigations

> Open investigation cases, link transactions and alerts, assign analysts, and run SAR-ready workflows from the Business Console. $0.02 per transaction.

When transactions are flagged by rules, Didit creates **alerts** that can be organized into **cases** for structured investigation. Cases group related alerts and transactions, track investigation progress, and maintain an audit trail.

<Note>
  Case management is **console-only**. There is no public alert- or case-CRUD API. Analysts triage, assign, and resolve cases from *Case Management* in the Business Console. See [alerts](/transaction-monitoring/alerts) for the alert lifecycle in detail.
</Note>

## Case types

Each case is categorised by the type of investigation:

| Type                     | Description                                                    |
| ------------------------ | -------------------------------------------------------------- |
| `TRANSACTION_MONITORING` | Investigation triggered by transaction rule matches or alerts  |
| `AML`                    | AML-specific investigation (sanctions hits, watchlist matches) |
| `BUSINESS_REVIEW`        | Review of a business entity's verification or activity         |
| `VERIFICATION_REVIEW`    | Review of a user verification session                          |
| `DUPLICATES`             | Investigation of potential duplicate entities or sessions      |
| `GENERAL`                | General-purpose case for any compliance matter                 |

## Alerts

Every time a rule matches a transaction, an **alert** is created. Alerts can also be created manually by analysts or by external providers.

### Alert sources

| Source       | Description                                                 |
| ------------ | ----------------------------------------------------------- |
| **Rule**     | Automatically created when a transaction rule matches       |
| **Provider** | Created by an external AML or blockchain analytics provider |
| **Manual**   | Created manually by an analyst from the console             |

### Alert statuses

| Status          | Description                                          |
| --------------- | ---------------------------------------------------- |
| `OPEN`          | New alert, not yet reviewed                          |
| `INVESTIGATING` | An analyst is actively working on this alert         |
| `AWAITING_USER` | Additional information is needed from the user       |
| `PENDING_SAR`   | Under review for a Suspicious Activity Report filing |
| `SAR_FILED`     | A Suspicious Activity Report has been filed          |
| `RESOLVED`      | Investigation complete — no further action needed    |
| `DISMISSED`     | Alert reviewed and determined to be a false positive |

## Cases

A case is an investigation container that links together related alerts and transactions for a structured review workflow.

### Case workflow

<Steps>
  <Step title="Triage" icon="inbox">
    Review incoming alerts in the Transactions section of the console. Group related alerts into a new case or add them to an existing case.
  </Step>

  <Step title="Assign" icon="user-plus">
    Assign the case to an analyst for investigation. Track assignment and response times for SLA monitoring.
  </Step>

  <Step title="Investigate" icon="magnifying-glass">
    Analysts review the linked transactions, user verification history, AML screening results, and any attached evidence. Add internal notes and document findings.
  </Step>

  <Step title="Resolve" icon="check">
    Close the case with a resolution — escalate to SAR filing, dismiss as false positive, or take action (e.g., block the user, decline future transactions). The resolution is logged in the audit trail.
  </Step>
</Steps>

### Creating a case

Cases are created from the Business Console:

1. Navigate to **Transactions** and select one or more flagged transactions
2. Click **Create Case** and provide a title and description
3. Set the severity and priority
4. Link the relevant alerts and transactions
5. Assign to an analyst

### Case properties

| Property                | Description                                                    |
| ----------------------- | -------------------------------------------------------------- |
| **Title**               | Short description of the investigation                         |
| **Case type**           | Type of investigation (see case types above)                   |
| **Severity**            | `LOW`, `MEDIUM`, `HIGH`, `CRITICAL`                            |
| **Priority**            | `LOW`, `NORMAL`, `URGENT`                                      |
| **Status**              | `OPEN`, `UNDER_REVIEW`, `AWAITING_USER`, `ON_HOLD`, `RESOLVED` |
| **Assigned to**         | Analyst responsible for the investigation                      |
| **Linked alerts**       | Alerts included in the case                                    |
| **Linked transactions** | Transactions associated with the investigation                 |
| **Evidence**            | Documents, screenshots, or files attached to the case          |
| **Typologies**          | SAR typology codes relevant to the investigation               |
| **Due date**            | Deadline for completing the investigation                      |
| **Notes**               | Internal comments and findings from the investigation          |

## Resolution

When a case is resolved, the analyst selects a resolution type:

| Resolution       | Description                                          |
| ---------------- | ---------------------------------------------------- |
| `FALSE_POSITIVE` | Investigation determined the activity was legitimate |
| `VALID_THREAT`   | Confirmed suspicious or fraudulent activity          |
| `APPROVED`       | Activity reviewed and cleared for processing         |
| `DECLINED`       | Activity rejected after investigation                |
| `OTHER`          | Custom resolution with analyst notes                 |

The resolution, along with any closing notes, is immutable once set and forms part of the compliance audit trail.

## Transaction notes

Analysts can add notes to individual transactions at any time. Notes include:

* The note text
* The analyst who wrote it (name and email)
* Timestamp
* Optional metadata

Notes are visible to all team members with transaction access and form part of the audit trail.

## Analytics

The Transactions overview in the console tracks analyst performance including:

* Average alert resolution time
* Alerts resolved per analyst
* Alert-to-case conversion rate
* Open alert backlog by status

## Next steps

<CardGroup cols={3}>
  <Card title="Alerts" icon="bell" href="/transaction-monitoring/alerts">
    Alert lifecycle, sources, and SAR workflow.
  </Card>

  <Card title="Console" icon="desktop" href="/transaction-monitoring/console">
    Full console walkthrough.
  </Card>

  <Card title="Statuses" icon="list-check" href="/transaction-monitoring/statuses">
    All status machines.
  </Card>
</CardGroup>