Settings

Configure application-level transaction monitoring settings from the Business Console to control scoring thresholds and provider preferences.

​

General settings

​

Score thresholds

Score thresholds determine how the cumulative risk score from matched rules maps to a transaction status: Transactions below the review threshold are automatically APPROVED. If a rule has an explicit change_status action, that status takes priority over score-based thresholds — DECLINED always wins.

​

Crypto monitoring

Enable or disable automatic crypto screening for cryptocurrency transactions. When enabled, Didit screens wallet addresses and transaction hashes against blockchain analytics providers for all transactions with currency_kind: "crypto". Transaction-hash screening requires both the hash and the related wallet address.

​

Provider preferences

Select and configure your preferred blockchain analytics provider: With BYOK (Bring Your Own Key), you use your existing provider agreement and pay a reduced per-screening fee through Didit.

​

Remediation workflow

The remediation workflow (remediation_workflow_id on the settings API) is your application-wide default for AWAITING_USER rule actions that don’t name their own workflow - in practice, the built-in library rules (custom rules always carry their own selection, which wins). The field accepts a workflow id (or a specific version uuid) on write and always returns the stable workflow id on read; sessions are created with the latest published version. When such a rule sets a transaction to AWAITING_USER, Didit creates the linked verification session with the first workflow found in this order:

1. The remediation workflow configured here.
2. Your application’s Biometric Authentication workflow, when the subject already has a stored reference face.
3. Your application’s default workflow.

The session’s URL and token are returned in the transaction’s action_required and remediation fields and in both transaction webhooks, so you can redirect the user to complete the required verification. Once that session reaches a decision, the transaction status follows it automatically (approved, declined, or in review) and a transaction.status.updated webhook fires. A Biometric Authentication workflow is the recommended choice here: the user re-proves their identity with one live selfie matched against the face from their original onboarding. It requires the subject to have a stored reference face from an approved verification; users without one are asked to complete your application’s default workflow instead, with a note on the transaction recording the substitution.

​

Where to find

Navigate to Transactions > Settings in the Business Console to configure these options. Settings take effect immediately for all new transactions.

​

Next steps