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


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