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

# Alerts

> Lifecycle of transaction alerts: created from rules, providers, or analysts; triaged, linked to cases, and resolved. Pay-per-call $0.02 per transaction.

An **alert** is a record that a transaction or pattern requires attention — either from a rule match, a provider flag (sanctions, wallet risk), or a manual analyst escalation. Alerts are the unit of triage in the Business Console.

## Alert lifecycle

```mermaid theme={null}
stateDiagram-v2
    [*] --> OPEN: Created (rule, provider, manual)
    OPEN --> INVESTIGATING: Analyst picks up
    OPEN --> DISMISSED: Clear false positive
    INVESTIGATING --> AWAITING_USER: Need user input
    AWAITING_USER --> INVESTIGATING: User responded
    INVESTIGATING --> PENDING_SAR: Preparing SAR filing
    PENDING_SAR --> SAR_FILED: SAR submitted to regulator
    INVESTIGATING --> RESOLVED: Closed — action taken
    INVESTIGATING --> DISMISSED: Closed — no action
    SAR_FILED --> [*]
    RESOLVED --> [*]
    DISMISSED --> [*]
```

## Alert sources

| Source     | Description                                                                                                                  |
| ---------- | ---------------------------------------------------------------------------------------------------------------------------- |
| `RULE`     | Generated by a matched transaction rule. Most alerts.                                                                        |
| `PROVIDER` | Generated by an external provider — wallet screening hit, sanctions match on counterparty, transaction screening escalation. |
| `MANUAL`   | Opened by an analyst from the console.                                                                                       |

## Alert statuses

| Status          | Meaning                                                                       |
| --------------- | ----------------------------------------------------------------------------- |
| `OPEN`          | Not yet picked up by an analyst.                                              |
| `INVESTIGATING` | An analyst is actively reviewing.                                             |
| `AWAITING_USER` | Blocked on user action (remediation session pending).                         |
| `PENDING_SAR`   | Analyst has decided to file a Suspicious Activity Report; filing in progress. |
| `SAR_FILED`     | SAR has been filed with the regulator.                                        |
| `RESOLVED`      | Alert closed with an action (e.g. user blocked, funds held).                  |
| `DISMISSED`     | Alert closed as a false positive. No action taken.                            |

## Alert fields

| Field                   | Description                                                       |
| ----------------------- | ----------------------------------------------------------------- |
| `uuid`                  | Alert ID                                                          |
| `title`                 | Short description (auto-generated from the rule)                  |
| `description`           | Longer description or analyst notes                               |
| `severity`              | Nullable — legacy field; use the alert's associated score instead |
| `source`                | `RULE`, `PROVIDER`, or `MANUAL`                                   |
| `assigned_to`           | Analyst currently owning the alert                                |
| `due_at`                | SLA deadline for resolution                                       |
| `linked_case_id`        | If linked to an investigation case                                |
| `linked_transaction_id` | The transaction that generated the alert                          |
| `resolved_at`           | When the alert reached a terminal state                           |

## Linking alerts to cases

A single alert might be small enough to resolve on its own. Larger or pattern-based investigations warrant a **case** — a container for multiple alerts, transactions, users, and evidence.

See [Cases](/transaction-monitoring/cases) for the case model.

Link from the alert detail pane: *Alerts → \[alert] → Link to case*. You can link to an existing case or create a new one from the alert.

## SAR workflow

For jurisdictions requiring Suspicious Activity Reports (SARs) or CTRs (Currency Transaction Reports):

1. Move the alert to `PENDING_SAR` and attach supporting evidence.
2. Generate the SAR filing (PDF + structured metadata) via *Alerts → \[alert] → Generate SAR*.
3. Submit to your regulator's portal through your usual filing channel.
4. Mark the alert as `SAR_FILED` and record the filing reference number.

Didit does not directly submit SARs to regulators — SAR filing remains your compliance team's responsibility. The console generates the artifact (form + evidence) to streamline the process.

## Console workflow

### Alerts list

Located at *Transactions → Alerts*. Columns: `Alert ID`, `Title`, `Transaction`, `Applicant`, `Status`, `Assigned to`, `Due date`, `Source`, `Severity`.

Filters: by status, source, severity, assigned analyst, date range. Saved views supported.

### Alert triage

Double-click an alert to open the triage surface:

* **Summary** — rule that fired, transaction context, score, matched conditions.
* **Transaction** — the underlying transaction with all parties and payment methods.
* **User / Business** — linked [entity](/entities/overview) profile.
* **Related alerts** — other alerts tied to the same user or pattern.
* **Actions** — assign, add note, link to case, close (resolve / dismiss), generate SAR.

### Bulk actions

From the alerts list:

* **Bulk assign** to an analyst.
* **Bulk dismiss** (use with care — logged to audit).
* **Bulk link to case** to group related alerts into one investigation.

## Assignment and SLAs

* Alerts can be auto-assigned to a round-robin analyst pool configured at *Settings → Team → Analyst pool*.
* `due_at` is computed from the alert's severity and your SLA matrix at *Settings → Transaction Monitoring → SLAs*.
* Overdue alerts are surfaced on the Alerts dashboard and via weekly email digests.

## Alert webhooks

Alerts currently flow through the `transaction.status.updated` webhook and are surfaced in the transaction response. Dedicated alert lifecycle webhooks are on the roadmap — subscribe to application changelog for updates.

## Programmatic access

Alert CRUD is **console-only** in the public API today — there is no public alert endpoint in this openapi spec. Use the console to triage and resolve alerts. Transactions with alerts can be retrieved via `GET /v3/transactions/` and inspected in bulk.

## Next steps

<CardGroup cols={3}>
  <Card title="Cases" icon="folder-open" href="/transaction-monitoring/cases">
    Full investigation workflow.
  </Card>

  <Card title="Rules" icon="scale-balanced" href="/transaction-monitoring/rules">
    What generates alerts.
  </Card>

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