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

# User Transactions

> Retrieve a User entity's full transaction history and see how Didit aggregates ongoing activity into Transaction Monitoring rules. Pay-per-call from $0.02.

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`:

```bash theme={null}
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).

## How transactions link to users

```mermaid theme={null}
flowchart LR
    T["Transaction<br/>txn_id=tx-0001"]
    A["applicant:<br/>vendor_data=user-42"]
    C["counterparty:<br/>vendor_data=user-99"]
    U1[User: user-42]
    U2[User: user-99]
    T --> A
    T --> C
    A -.-> U1
    C -.-> U2
```

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](/transaction-monitoring/transactions) for the full party model.

## Aggregated risk signals

Transactions feed the following user-level signals:

| Signal                                 | Used by                      |
| -------------------------------------- | ---------------------------- |
| Total volume inbound / outbound        | Velocity rules, thresholding |
| Transaction count in a time window     | Velocity rules               |
| Unique counterparties                  | Behavioral rules             |
| High-risk jurisdictions touched        | Geography rules              |
| Sanctioned / PEP counterparty exposure | Screening rules              |
| Payment method variety                 | Fraud rules                  |

These signals are computed in real time and evaluated against your active [transaction rules](/transaction-monitoring/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](/transaction-monitoring/statuses) for the full state machine.

## Historical ingestion

To backfill historical transactions against an existing User entity, pass `txn_date` in the past:

```bash theme={null}
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" }
  }'
```

<Note>
  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.
</Note>

## Next steps

<CardGroup cols={3}>
  <Card title="Submit transactions" icon="arrow-right-to-bracket" href="/transaction-monitoring/transactions">
    Full payload reference.
  </Card>

  <Card title="Rules" icon="scale-balanced" href="/transaction-monitoring/rules">
    How rules evaluate transactions and act on users.
  </Card>

  <Card title="Statuses" icon="list-check" href="/transaction-monitoring/statuses">
    Transaction and remediation status reference.
  </Card>
</CardGroup>