Transaction Monitoring Statuses

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.

​

Transitions

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 for full detail.

​

Case status

See Case Management for full detail. 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. 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 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.

​

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 for the rule anatomy.

​

Decision reason codes

Common reason values on status transitions:

​

Next steps