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: 
curl -G https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  --data-urlencode "vendor_data=user-42" \
  --data-urlencode "page_size=50"
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:
SignalUsed by
Total volume inbound / outboundVelocity rules, thresholding
Transaction count in a time windowVelocity rules
Unique counterpartiesBehavioral rules
High-risk jurisdictions touchedGeography rules
Sanctioned / PEP counterparty exposureAML screening rules
Payment method varietyFraud rules
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, AML provider 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: 
curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "txn_id": "legacy-0001",
    "txn_date": "2024-03-15T10:00:00Z",
    "direction": "INBOUND",
    "amount": "2500.00",
    "currency": "EUR",
    "applicant": { "vendor_data": "user-42" },
    "counterparty": { "name": "Historic payer" }
  }'
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.