Skip to main content
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 AML rules at the business level.

​
Retrieving a business’s transactions

Filter the Transactions list by the business’s vendor_data: 
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). 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 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: 
{
  "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: 
{
  "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:
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 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, AML provider 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: 
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" }
  }'
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 businesses.

Statuses

Transaction and remediation status reference.