Skip to main content
Every transaction submitted to Didit is evaluated against all active rules for your application. Rules define conditions, velocity checks, and actions that determine the transaction’s final status and score.

​
Built-in rule bundles

Didit provides a pre-configured rule library for every application with transaction monitoring enabled. These rules are based on common regulatory typologies and can be customized or disabled:
BundleExamples
FinanceStructuring detection (inbound/outbound), large single transactions above reporting thresholds
AML/CTFCumulative volume limits, rapid in-and-out movement, sanctions counterparty matching, PEP counterparty exposure, suspicious payment reference keywords
Anomaly detectionHigh velocity inbound/outbound, dormant account reactivation after 12+ months of inactivity
FATFHigh-risk jurisdiction exposure for counterparties and subject IPs
Device intelligenceRepeated bonus-campaign use from the same device fingerprint, multiple device fingerprints for the same subject
Fraud preventionMulti-accounting via shared device fingerprints across distinct subjects
Crypto monitoringMixer/obfuscation service exposure, high-risk wallet addresses (darknet, sanctioned, stolen funds)
Responsible gamingRapid deposit bursts within short windows
E-commerceE-commerce specific transaction patterns

​
Rule anatomy

Each rule consists of:
ComponentDescription
Title & descriptionHuman-readable name and explanation of what the rule detects
CategoryLogical grouping (e.g., finance, aml_ctf, crypto_monitoring, device_intelligence)
ModeActive (live evaluation), Disabled (skipped), or Test (evaluated but results don’t affect the transaction)
Evaluation modeAll (every condition must match) or Any (at least one condition must match)
ScopeLimits which transactions the rule applies to — by transaction type, direction, or other filters
ConditionsField-level checks — compare transaction fields against values using operators like eq, lt, gte, in, contains_any, exists
AggregationVelocity windows — aggregate historical transactions over a time period (e.g., count, sum, or distinct count over 1 hour, 7 days, 30 days)
ActionsWhat happens when the rule matches (see below)

​
Actions

When a rule matches a transaction, one or more actions are executed. Each rule can have multiple actions that are all applied together:
ActionDescription
Add scoreAdd a specified number of points to the transaction’s risk score. The cumulative score across all matched rules determines whether the transaction crosses the review or decline threshold.
Change statusDirectly set the transaction status to IN_REVIEW, DECLINED, or AWAITING_USER. This takes effect immediately regardless of the score.
Add tagsAutomatically tag the transaction for categorization and filtering (e.g., high-risk, structuring-suspect).
Add noteAttach an automated note to the transaction for analyst context.
Add to listAdd the applicant, counterparty, or other entity to a blocklist, allowlist, or custom list.
Most preset rules combine add score with change status — for example, a sanctions counterparty rule adds 90 points to the score and immediately declines the transaction.

​
Scoring

When a transaction matches one or more rules, the scores are combined:
  1. Each rule match contributes to the transaction’s overall risk score via the add_score action
  2. The final score determines the transaction status based on your application’s score thresholds
  3. If any rule has a change_status action, that status is applied directly — DECLINED always takes priority
Default score thresholds (configurable in the console):
SettingDefaultDescription
Review threshold60Scores at or above this value trigger IN_REVIEW
Decline threshold85Scores at or above this value trigger DECLINED

​
Creating custom rules

Custom rules are created and managed from the Business Console:
  1. Go to Transactions > Rules in the console
  2. Click Create Rule
  3. Define the rule title, description, and category
  4. Set the mode — Active to run live, or Test to evaluate without affecting transactions
  5. Choose the evaluation mode — All (every condition must match) or Any (at least one)
  6. Set the scope — which transaction types or directions the rule applies to
  7. Add conditions — field comparisons like amount thresholds, country codes, custom property checks
  8. Optionally add aggregation — velocity checks over a time window (count, sum, or distinct count)
  9. Define one or more actions — add score, change status, add tags, add notes, or add to list
  10. Save and enable the rule
Rules take effect immediately for all new transactions.

​
Velocity windows (aggregation)

Velocity rules aggregate historical transaction data over a time period to detect patterns that single-transaction checks would miss:
MetricDescription
CountNumber of transactions matching the filters in the window
SumTotal of a numeric field (e.g., preferred_currency_amount) in the window
Distinct countNumber of unique values for a field (e.g., distinct device fingerprints) in the window
Each aggregation specifies:
  • A time window (e.g., 1h, 6h, 1d, 7d, 30d)
  • Filters to narrow which historical transactions are included (e.g., same subject, same direction, same device)
  • An operator and threshold (e.g., count >= 20)

​
Example patterns

PatternHow it works
StructuringCount of transactions below $10,000 for the same subject in 30 days >= 20
High velocityCount of inbound transactions for the same subject in 7 days >= 20
Rapid in-and-outCurrent transaction is outbound + count of inbound transactions for the same subject in 6 hours >= 1
Multi-accountingDistinct count of subjects sharing the same device fingerprint in 7 days >= 3
Dormant reactivationDays since subject’s previous transaction >= 365, combined with amount >= $1,000

​
Condition operators

Rules support the following comparison operators for conditions:
OperatorDescriptionExample
eqEqual todirection eq "OUTBOUND"
ltLess thanamount lt 10000
gteGreater than or equalpreferred_currency_amount gte 25000
gtGreater thantravel_rule_obligations_count gt 0
inValue is in a listcounterparty_country in ["IRN", "PRK", "SYR"]
contains_anyText contains any keywordpayment_details contains_any ["terror", "weapon"]
existsField is presentsubject_device_fingerprint exists true

​
AML transaction screening

Didit integrates with external AML and blockchain analytics providers to enrich transactions with risk intelligence. When a transaction is submitted, the system can:
  • Screen counterparties against global sanctions and watchlist databases
  • Evaluate wallet addresses (for crypto transactions) against blockchain intelligence data, including mixer exposure, sanctioned entity connections, and high-risk service interactions
  • Check applicant AML status by cross-referencing the transaction’s linked user against their latest AML screening results
AML screening results are attached to the transaction and factor into the rule engine’s scoring. If a counterparty or wallet matches a sanctions list, the corresponding rule automatically flags or declines the transaction.

​
API reference

List rules

Retrieve all rules including execution counters.

Get settings

Retrieve score thresholds and configuration.