In the Sandbox, you can test your Transaction Monitoring integration, rule logic, and webhook management before moving the setup to production.

Testing Transaction Monitoring on Sandbox helps you check how your rules evaluate transactions, how Sumsub calculates scores, and which statuses and webhooks your integration receives for different outcomes.

How Transaction Monitoring testing works

When you submit a transaction in Sandbox, Sumsub evaluates it against the Transaction Monitoring rules that you configured in your Sandbox environment.

Transaction Monitoring does not rely on predefined test values that always produce the same result. The outcome depends on the rules, scores, actions, priorities, and transaction history that you configure.

Sandbox rules stay fully isolated from production rules. You can create, update, and test different rule versions in Sandbox without affecting your production setup.

⚠️

Important

Use Sandbox for integration and rule-behavior testing, not for performance testing or historical transaction import. We recommend submitting no more than 1,000 transactions per day. Avoid high request rates: the API may still accept transactions, but scoring may become unstable under heavy load.

Test scenarios

The following scenarios show how to configure sample rules and submit test transactions that produce different Transaction Monitoring outcomes.

Create reusable scoring rules

To start with testing, you need to create scoring rules:

1. In the Dashboard, go to the Installed rules.
2. Click Create rule.
3. Create the rules described below. You will need to reuse them in Approved and Requires action scenarios.

📘

Note

Rules 2 and 3 evaluate currentScore only after other scoring rules have run. Set these rules to the lowest priority so they run last and calculate currentScore correctly.

Rule 1 — Amount threshold

Create the Amount threshold rule with the following conditions:

Rule 2 — Medium risk: hold for review

Create the Medium risk: hold for review rule with the following conditions:

Rule 3 — High risk: reject

Create the High risk: reject rule with the following conditions:

Approved

Use this scenario to test that a transaction passes all checks and receives automatic approval.

This scenario uses the reusable scoring rules created earlier.

Submit the transaction:

{
  "txnId": "txn-approved-001",
  "type": "finance",
  "applicant": {
    "externalUserId": "user-sandbox-01",
    "fullName": "John Smith"
  },
  "info": {
    "direction": "out",
    "amount": 500,
    "currencyCode": "EUR"
  },
  "counterparty": {
    "externalUserId": "counterparty-sandbox-01",
    "fullName": "Jack Posek"
  }
}

How Sumsub evaluates this transaction:

• Rule 1 checks amountInDefaultCurrency: 500 >= 10000 → no match, score stays 0.
• Rule 2 checks currentScore: 0 >= 25 → no match.
• Rule 3 checks currentScore: 0 >= 65 → no match.
• No rules match, so Sumsub approves the transaction.

The transaction receives the following result:

• Status – Approved.
• Score – 0.
• Webhook – applicantKytTxnApproved.

Requires action

Use this scenario to test the transaction that Sumsub puts on hold for manual review when the transaction amount exceeds the scoring threshold.

This scenario uses the reusable scoring rules created earlier.

Submit the transaction:

{
  "txnId": "txn-requires-action-001",
  "type": "finance",
  "applicant": {
    "externalUserId": "user-sandbox-01",
    "fullName": "John Smith"
  },
  "info": {
    "direction": "out",
    "amount": 10001,
    "currencyCode": "EUR"
  },
  "counterparty": {
    "externalUserId": "counterparty-sandbox-01",
    "fullName": "Jack Posek"
  }
}

How Sumsub evaluates this transaction:

• Rule 1 checks amountInDefaultCurrency: 10001 >= 10000 → match, score increases by 30.
• Rule 2 checks currentScore: 30 >= 25 AND 30 < 65 → match, action is on hold.
• Rule 3 checks currentScore: 30 >= 65 → no match.

The transaction receives the following result:

• Status – Requires action.
• Score – 0.
• Webhook – applicantKytOnHold.

Sumsub adds the transaction to the manual review queue in the Dashboard. After manual review, Sumsub sends the applicantKytTxnReviewed webhook before sending one of the following webhooks, depending on the review result:

• applicantKytTxnApproved
• applicantKytTxnRejected

Rejected

Use this scenario to test that Sumsub rejects a transaction directly when the amount exceeds a hard limit, without relying on score-based evaluation.

In the Dashboard, go to the Installed rules and click Create rule. Create the Hard limit rule with the following conditions:

✅

Tip

To generate the condition automatically, click Generate with AI next to the Condition field and describe the rule in plain language. For example: Amount in the default currency is 50000 or more.

Review the generated condition before saving.

Submit the transaction:

{
  "txnId": "txn-rejected-001",
  "type": "finance",
  "applicant": {
    "externalUserId": "user-sandbox-01",
    "fullName": "John Smith"
  },
  "info": {
    "direction": "out",
    "amount": 50001,
    "currencyCode": "EUR"
  },
  "counterparty": {
    "externalUserId": "counterparty-sandbox-01",
    "fullName": "Jack Posek"
  }
}

Sumsub compares the transaction amount with the hard limit set in the rule. Since 50001 is greater than or equal to 50000, the rule matches, and Sumsub rejects the transaction. Evaluation stops immediately.

The transaction receives the following result:

• Status – Rejected.
• Score – 0.
• Webhook – applicantKytTxnRejected.

Requires action based on velocity

Use this scenario to test that Sumsub puts a transaction on hold after the same applicant sends repeated transactions to the same counterparty within a short time window.

In the Dashboard, go to the Installed rules and click Create rule. Create the Counterparty velocity rule with the following conditions:

✅

Tip

To generate the condition automatically, click Generate with AI next to the Condition field and describe the rule in plain language. For example: Applicant sends 3 or more non-rejected transactions to the same counterparty within the last 24 hours.

Review the generated condition before saving.

Submit the following transactions from the same applicant to the same counterparty. Sumsub should approve both and store them in transaction history.

{
  "txnId": "txn-vel-001",
  "type": "finance",
  "applicant": {
    "externalUserId": "user-sandbox-02",
    "fullName": "John Smith"
  },
  "info": {
    "direction": "out",
    "amount": 100,
    "currencyCode": "EUR"
  },
  "counterparty": {
    "externalUserId": "counterparty-sandbox-01",
    "fullName": "Jack Posek"
  }
}

{
  "txnId": "txn-vel-002",
  "type": "finance",
  "applicant": {
    "externalUserId": "user-sandbox-02",
    "fullName": "John Smith"
  },
  "info": {
    "direction": "out",
    "amount": 100,
    "currencyCode": "EUR"
  },
  "counterparty": {
    "externalUserId": "counterparty-sandbox-01",
    "fullName": "Jack Posek"
  }
}

Submit the third transaction that acts as a trigger, with the same applicant and counterparty.

{
  "txnId": "txn-vel-003",
  "type": "finance",
  "applicant": {
    "externalUserId": "user-sandbox-02",
    "fullName": "John Smith"
  },
  "info": {
    "direction": "out",
    "amount": 100,
    "currencyCode": "EUR"
  },
  "counterparty": {
    "externalUserId": "counterparty-sandbox-01",
    "fullName": "Jack Posek"
  }
}

How Sumsub evaluates this transaction:

• You submit test transactions 1 and 2. Sumsub approves them and stores them in transaction history.
• You submit test transaction 3 with the same applicant and counterparty.
• The rule counts non-rejected outgoing transactions from user-sandbox-02 to counterparty-sandbox-01 in the last 24 hours: count is 3.
• The condition checks the count: 3 >= 3 → match, action is on hold.

The triggering transaction receives the following result:

• Status – Requires action.
• Webhook – applicantKytOnHold.

Review results

After submitting each transaction, check the result:

• In the Dashboard, navigate to the Transactions and travel rule section and open the list of all transactions. Use the Dashboard to confirm the transaction status, score, matched rules, and review queue behavior.
• Use webhook logs to confirm that your integration receives and processes the expected events.

⚠️

Important

Sandbox and production rules stay isolated from each other. Changes made in Sandbox do not affect production, and production rules do not automatically inherit Sandbox changes.