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

# Settings

> Configure KYT defaults: score thresholds, currency, and blockchain analytics providers (BYOK). Pay-per-call $0.02 per transaction.

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

## General settings

| Setting                | Default | Description                                                                                                                                     |
| ---------------------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| **Monitoring enabled** | `true`  | Enable or disable transaction monitoring for the application. When disabled, submitted transactions are stored but not evaluated against rules. |
| **Default currency**   | `USD`   | Currency used for rule threshold comparisons and currency conversion. All amounts are converted to this currency for consistent evaluation.     |

## Score thresholds

Score thresholds determine how the cumulative risk score from [matched rules](/transaction-monitoring/rules) maps to a transaction status:

| Setting               | Default | Description                                                                                                                                        |
| --------------------- | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Review threshold**  | 60      | Transactions scoring at or above this value receive `IN_REVIEW` status                                                                             |
| **Decline threshold** | 85      | Transactions scoring at or above this value receive `DECLINED` status. Set the slider to the maximum value (`500`) to never auto-decline by score. |

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.

<Note>
  Lowering the review threshold increases the volume of flagged transactions for analyst review. Adjust based on your team's capacity and risk appetite.
</Note>

## Crypto monitoring

Enable or disable automatic [crypto screening](/transaction-monitoring/aml-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:

| Provider           | Configuration                                                                |
| ------------------ | ---------------------------------------------------------------------------- |
| **Merkle Science** | Enable with managed pricing (the default) or connect your own API key (BYOK) |
| **Crystal**        | Connect your own API key from the console **Marketplace** (BYOK)             |
| **Chainalysis**    | Connect your own API key from the console **Marketplace** (BYOK)             |
| **Elliptic**       | Connect your own API key and secret from the console **Marketplace** (BYOK)  |
| **TRM Labs**       | Connect your own API key from the console **Marketplace** (BYOK)             |

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](/transaction-monitoring/rules#requiring-user-verification-awaiting-user) 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](https://business.didit.me) to configure these options. Settings take effect immediately for all new transactions.

## Next steps

<CardGroup cols={3}>
  <Card title="Risk scoring" icon="gauge" href="/transaction-monitoring/risk-scoring">
    How score thresholds map to statuses.
  </Card>

  <Card title="Crypto screening" icon="link" href="/transaction-monitoring/aml-screening">
    Wallet screening and provider details.
  </Card>

  <Card title="IP enrichment" icon="globe-pointer" href="/transaction-monitoring/ip-enrichment">
    What IP data is available to rules.
  </Card>
</CardGroup>