# On-Demand Wallet Screening

Check one wallet address before a transfer or during an investigation. Myaza returns its risk score, fund-flow exposure and rule decision. The check does not create a transaction.

| What you need | Where to start |
|---|---|
| Check an address by hand | **Spot Checks → Wallet** |
| Check an address from your backend | [Wallet Screening API](https://trust.myaza.co/documentation/api-wallet-screenings/markdown) |
| Assess a customer payment | [Transaction Monitoring](https://trust.myaza.co/documentation/monitoring-events/markdown) |

For a crypto transaction, **Myaza** screens the counterparty wallet through the same engine. Myaza does not send the transaction or its hash to the wallet provider. Keep the hash in your transaction record for audit. The [legacy transaction-reference route](https://trust.myaza.co/documentation/api-transaction-screenings/markdown) remains available for existing integrations; it uses the same Wallet Screening rate and screens the supplied wallet, not the hash.

## Try it in Sandbox

1. Create a Sandbox secret key under **Developers → API Keys**.
2. Open **Spot Checks → Wallet**, enter a valid address and choose a test scenario. Or use the [curl example](https://trust.myaza.co/documentation/api-wallet-screenings/markdown) with `sandboxScenario: "wallet.sanctions.direct"`.
3. Read the **risk**, **exposures**, **decision** and **rulesTriggered** fields. Direct sanctions exposure is blocked by the default rule; its `hops` value may be zero.
4. Save `screening.id` to retrieve the result or link a case.

Sandbox scenarios run your published rules without calling the live provider or creating billable wallet usage. Your key selects the environment; the request has no `sandbox` switch.

## Understand the result

The result shows what was screened, how risky it is, why, which rule fired and what Myaza decided. `allow`, `review` and `block` are the API decisions. A provider's display band `UNKNOWN` for scores 0–9 is different from an operationally unknown result, which requires review. Malformed network identifiers and locally invalid address formats return `422` before a provider call.

Enter a network name or code. Myaza translates known aliases and forwards other well-formed identifiers to the configured provider. There is no fixed network allowlist; the provider decides whether it can screen the network and address. A successful Sandbox scenario does not confirm live coverage.

The **Exposure map** groups reported source and destination exposures. It is not a verified path of on-chain transfers. Myaza stores the exact encrypted provider response for audit and can render a signed provider PDF for an eligible completed address screen. Neither raw provider data nor internal cost appears in the public response.

## Automatic checks and rules

Under **Risk Intelligence → Rules & Policies → Fraud rules → Settings**, turn **Wallet verification & screening** on for new crypto transactions. Then review the wallet templates in **Rule library**. The switch controls automatic counterparty screening; it does not disable Spot Checks or the direct API.

Seven safety templates are enabled by default. The 27 optional templates cover score thresholds, direct and nearby exposure, source and destination concentration, and transfer context. Duplicate a template to change its action or threshold. Each saved decision keeps the matched rule version and values. Test a rule in Sandbox, then copy it to a Production draft and publish it separately.

See [Wallet Screening API](https://trust.myaza.co/documentation/api-wallet-screenings/markdown), [Transaction Monitoring](https://trust.myaza.co/documentation/monitoring-events/markdown), [past transaction import](https://trust.myaza.co/documentation/import-past-transactions/markdown) and [wallet webhooks](https://trust.myaza.co/documentation/webhook-wallet-intelligence/markdown).