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

# Business Transactions

> Retrieve a Didit Business entity's transaction history and see how ongoing activity feeds Transaction Monitoring velocity, behavioral, and screening rules.

Every transaction you submit with a `vendor_data` identifier that matches a Business entity — as applicant, remitter, beneficiary, or counterparty — is linked to that Business profile. The Business becomes a running ledger of its activity, and Transaction Monitoring uses this history to feed velocity, behavioral, and screening rules at the business level.

## Retrieving a business's transactions

Filter the Transactions list by the business's `vendor_data`:

```bash theme={null}
curl -G https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  --data-urlencode "vendor_data=biz-acme" \
  --data-urlencode "page_size=50"
```

Returns every transaction where the business appears as the applicant. For counterparty-side history, filter in the Business Console (the public list endpoint filters by applicant only).

## How transactions link to businesses

```mermaid theme={null}
flowchart LR
    T["Transaction<br/>txn_id=tx-0042"]
    A["applicant:<br/>vendor_data=biz-acme"]
    C["counterparty:<br/>vendor_data=biz-widgets"]
    B1[Business: biz-acme]
    B2[Business: biz-widgets]
    T --> A
    T --> C
    A -.-> B1
    C -.-> B2
```

Each transaction includes up to four parties (`applicant`, `remitter`, `beneficiary`, `counterparty`). When a party includes `vendor_data` that matches a Business entity in your application, Didit binds the party to that Business. Parties without `vendor_data` are stored as external snapshots (no entity link).

See [submitting transactions](/transaction-monitoring/transactions) for the full party model.

## Mixed party kinds

A single transaction can mix Users and Businesses across parties — for example, an individual user paying a business:

```json theme={null}
{
  "txn_id": "tx-0099",
  "direction": "OUTBOUND",
  "amount": "500.00",
  "currency": "EUR",
  "applicant": { "vendor_data": "user-42" },
  "counterparty": { "vendor_data": "biz-acme" }
}
```

Or a B2B transfer between two businesses:

```json theme={null}
{
  "txn_id": "tx-0100",
  "direction": "OUTBOUND",
  "amount": "120000.00",
  "currency": "USD",
  "applicant": { "vendor_data": "biz-acme" },
  "counterparty": { "vendor_data": "biz-widgets" }
}
```

Didit resolves each party independently based on `vendor_data` — the same transaction flows into the profiles of every matched entity.

## Aggregated risk signals

Transactions feed these business-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 Business can be moved to `FLAGGED` or `BLOCKED` automatically depending on the rule's action.

## How rules act on businesses

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 business's `vendor_data` to a blocklist or custom list.

When a rule adds the business to a blocklist, the Business entity is transitioned to `BLOCKED` and a `business.status.updated` webhook fires.

## Monitoring a business's behavior

Use the Transactions tab on the Business 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 business to track an investigation.

## Payment methods owned by a business

Each transaction can attach one or more payment methods (bank cards, bank accounts, e-wallets, crypto wallets). When a payment method is owned by a business, it links back via `vendor_data` — so you see every payment method a business has used historically, right on the Business detail page.

## Historical ingestion

To backfill historical transactions against an existing Business, 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": "25000.00",
    "currency": "EUR",
    "applicant": { "vendor_data": "biz-acme" },
    "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 businesses.
  </Card>

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