> Toden documentation. For the full index fetch /llms.txt. Every page is available as Markdown by appending .md to its URL. Identity verification uses /api/kyc, Risk Intelligence uses /api/v1; they are separate contracts with different error shapes. Never invent an endpoint, field or enum value: read the API reference page for the operation first.

# Test and troubleshoot

> Exercise information gaps, review and stopped transfers.

## Test in Sandbox

Use a Sandbox secret key and set `sandboxScenario` on a transaction request. Start with these scenarios:

* **Travel Rule not required** for an explicit below-threshold result.
* **Missing beneficiary information** to test the information collection loop.
* **Travel Rule potential sanctions** to test a review outcome and specialist investigation.
* **Travel Rule confirmed sanctions** to test a stopped transfer.

After the request completes, open the transaction, inspect the summary, submit missing information when requested and verify the matching webhook deliveries. Scenario traffic is labelled and non-billable, but it still uses the governed Travel Rule assessment path.

Travel Rule scenarios require a compatible published policy. Create a Sandbox policy draft from the simulator preset under **Risk Intelligence → Rules & Policies → Travel Rule → Transfer rules**, then publish it before testing. Publishing that draft also updates Sandbox transfer checks.

For an API-driven deterministic test, set the top-level `sandboxScenario` to
`TRAVEL_RULE_MISSING_BENEFICIARY`, only in this recovery test. The scenario is
included in the request hash, follows the real policy and evidence path, and is
non-billable. It is accepted only in Sandbox and development. Production returns
`422 sandbox_scenario_not_available_in_production`; remove the field for live
traffic. Ordinary Sandbox requests without a scenario use configured pricing
and are billable.

## Acceptance checklist

* Complete data: one transaction, no duplicate information submission.
* Missing data: collect only the named fields and retain the original transaction.
* Response loss: reuse the exact request and idempotency key; do not charge or execute twice.
* Information accepted: still check current clearance and wallet authorisation.
* Invalid or expired webhook signature: reject it without changing customer access.
* Review or block: enforce the outcome in your application and make the reason visible to authorised staff.
* Live activation: test an actual institution channel and your wallet enforcement separately from synthetic scenarios.