> ## 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. # Transaction Monitoring Statuses > Reference for every transaction, alert, case, and travel-rule status, with transitions and meanings. Pay-per-call $0.02 per transaction, no contracts. Transaction Monitoring has four separate status machines: the **transaction**, each **alert**, each **case**, and (where applicable) the **travel-rule check**. This page is the reference. ## Transaction status Set on creation and updated through the lifecycle. | Status | Meaning | | --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `APPROVED` | Transaction passed all rules below the review threshold. | | `IN_REVIEW` | Score crossed the review threshold, or a rule explicitly required review. Analyst attention needed. | | `DECLINED` | Score crossed the decline threshold, or a rule explicitly declined. Transaction rejected. | | `AWAITING_USER` | The user must act before the transaction can settle: a rule action required additional verification (a remediation session was created), or a Travel Rule transfer needs proof of wallet control. Read the transaction's `action_required` block for the concrete action and URL. | ### Transitions ```mermaid theme={null} stateDiagram-v2 [*] --> APPROVED: Score < review threshold, no blocking rules [*] --> IN_REVIEW: Score >= review threshold [*] --> DECLINED: Score >= decline threshold, or rule decline action [*] --> AWAITING_USER: Rule action change_status → AWAITING_USER IN_REVIEW --> APPROVED: Analyst cleared IN_REVIEW --> DECLINED: Analyst declined AWAITING_USER --> APPROVED: Remediation session approved AWAITING_USER --> DECLINED: Remediation session declined AWAITING_USER --> IN_REVIEW: Remediation session ended in review ``` Note: there is no direct transition from `APPROVED` or `DECLINED` back to other states. Use status patches via the console for corrections; those are logged to the audit trail. ## Alert status See [Alerts](/transaction-monitoring/alerts) for full detail. | Status | Meaning | | --------------- | -------------------------------------- | | `OPEN` | Just generated; unassigned. | | `INVESTIGATING` | Analyst is actively working it. | | `AWAITING_USER` | Pending user action (remediation). | | `PENDING_SAR` | SAR filing in progress. | | `SAR_FILED` | SAR filed with regulator; case closed. | | `RESOLVED` | Closed with an action taken. | | `DISMISSED` | Closed as false positive. | ## Case status See [Case Management](/console/case-management/cases) for full detail. | Status | Meaning | | --------------- | ------------------------------------------------------------- | | `OPEN` | Under active investigation. | | `AWAITING_USER` | Waiting on user-side input. | | `RESOLVED` | Closed with a resolution: `FALSE_POSITIVE` or `VALID_THREAT`. | Cases carry a separate **priority** (`LOW`, `MEDIUM`, `HIGH`). ## Travel-rule check status Virtual-asset transfers under the FATF Travel Rule run a dedicated **13-state exchange**, separate from the transaction status above. It starts at `AWAITING_COUNTERPARTY` (or `UNCONFIRMED_OWNERSHIP` on the beneficiary side) and finishes in `FINISHED`, `CANCELLED`, or `EXPIRED`. | Status | Meaning | | ----------------------------------- | ------------------------------------------------------------------------- | | `AWAITING_COUNTERPARTY` | Sent to the counterparty; awaiting their response. | | `UNCONFIRMED_OWNERSHIP` | Beneficiary wallet ownership not yet proven. | | `ON_HOLD` | Held for manual action (transaction shows `AWAITING_USER`). | | `COMPLETED` | Originator and beneficiary data matched - safe to broadcast on-chain. | | `FINISHED` | On-chain hash reported; exchange closed. | | `CANCELLED` | Cancelled from a non-terminal state. | | `EXPIRED` | Confirmation timeout elapsed. | | `COUNTERPARTY_MISMATCHED_DATA` | Beneficiary name did not match. | | `COUNTERPARTY_VASP_NOT_FOUND` | No rail could resolve the counterparty. | | `COUNTERPARTY_VASP_NOT_REACHABLE` | Counterparty identified but its `TRP` endpoint was unreachable. | | `COUNTERPARTY_VASP_GENERAL_DECLINE` | Counterparty declined the exchange. | | `NOT_ENOUGH_COUNTERPARTY_DATA` | Counterparty response was incomplete (repairable). | | `NOT_APPLICABLE` | Disabled, below `threshold_amount`, or a passively recorded legacy value. | Older integrations may still send the legacy values `UNKNOWN`, `COMPLIANT`, `PENDING_ACTION`, `PENDING_COUNTERPARTY`, `FAILED`, and `EXEMPT`; Didit maps them onto the states above automatically. See [Travel Rule](/transaction-monitoring/travel-rule#lifecycle) for the authoritative reference. ## Provider result status Every external provider result (wallet screening, fiat monitoring, sanctions screening) is stored with its own status. Surfaced under `provider_results[]` in the transaction response. | Status | Meaning | | ----------- | ----------------------------------------------------------------- | | `PENDING` | Provider query in flight. | | `COMPLETED` | Result returned successfully. | | `FAILED` | Provider errored or timed out. | | `SKIPPED` | Provider deliberately skipped (e.g. transaction below threshold). | ## Rule-run outcomes Every `TransactionRuleRun` has: * `matched` (boolean) — did the rule fire? * `is_test` (boolean) — was the rule in TEST mode? * `mode` — `ACTIVE`, `DISABLED`, `TEST` at evaluation time. * `score_delta` — contribution to the score (if matched and active). * `status_target` — the status the rule asked for (if `change_status` action). See [Rules](/transaction-monitoring/rules) for the rule anatomy. ## Decision reason codes Common `reason` values on status transitions: | Reason | Meaning | | ------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | | `rule_score_threshold` | Score crossed review/decline threshold. | | `rule_change_status` | A rule's `change_status` action forced a status. | | `analyst_approved` / `analyst_declined` / `analyst_cleared` | Manual analyst action. | | `user_action_approved` / `user_action_declined` / `user_action_in_review` | Outcome of the linked remediation session (the user action requested while `AWAITING_USER`). | | `provider_update` | External provider updated the result. | | `aml_confirmed_sanction` | AML screen confirmed a sanctions match. | | `blocklist_applicant` / `blocklist_counterparty` | Blocklist enforcement on a party. | ## Next steps How scores map to statuses. Alert lifecycle. Case lifecycle.