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 screening rules at the business level.

​
Retrieving a business’s transactions

Filter the Transactions list by the business’s vendor_data:
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:
Or a B2B transfer between two businesses:
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: 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, 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:
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.