Skip to main content
Every transaction you submit with a vendor_data identifier (either as applicant or counterparty) is linked to the corresponding User entity. The User profile becomes a running ledger of the person’s activity, and Transaction Monitoring uses this history to feed velocity and behavioral rules.

​
Retrieving a user’s transactions

Filter the Transactions list by vendor_data:
Returns every transaction where the user is the applicant. For counterparty-side history, filter in the Business Console (the public list endpoint filters by applicant only). Every transaction includes up to four parties (applicant, remitter, beneficiary, counterparty). When a party includes vendor_data, Didit binds it to that User. Parties without vendor_data are stored as external snapshots (no entity link). See submitting transactions for the full party model.

​
Aggregated risk signals

Transactions feed the following user-level signals: These signals are computed in real time and evaluated against your active transaction rules. When a rule matches, the user can be moved to FLAGGED or BLOCKED automatically depending on the rule’s action.

​
How rules act on users

A transaction rule’s actions can include:
  • add_score — increases the transaction’s risk score.
  • change_status — sets the transaction’s status (IN_REVIEW, DECLINED, AWAITING_USER).
  • add_tags — tag the transaction.
  • add_to_list — add the user’s vendor_data to a blocklist or custom list.
When a rule adds the user to a blocklist, their User entity is transitioned to BLOCKED and a user.status.updated webhook fires.

​
Monitoring a user’s behavior

Use the Transactions tab on the User detail page in the Business Console to:
  • See every transaction in chronological order.
  • Filter by status, amount, direction, counterparty.
  • Open any transaction to inspect rule runs, IP enrichment, and crypto screening results.
  • Open a case against the user to track an investigation.

​
Remediation sessions

When a transaction enters AWAITING_USER, Didit creates a linked remediation session that requires the user to complete additional verification (for example, source of funds documentation, refreshed ID). The remediation session is tied to the same vendor_data — on completion, the transaction’s status updates automatically. See transaction statuses for the full state machine.

​
Historical ingestion

To backfill historical transactions against an existing User entity, pass txn_date in the past:
Historical transactions still run through the rule engine. If you want to ingest history without triggering rules, use the console import flow which supports a “dry ingest” mode.

​
Next steps

Submit transactions

Full payload reference.

Rules

How rules evaluate transactions and act on users.

Statuses

Transaction and remediation status reference.