Copy page

How Tos

Test Compliance Risk Checks

Exercising risk screening is hard to arrange on demand. For inbound payments you would normally need access to a wallet that already carries a risk score. In both directions it is not obvious which addresses correspond to which risk categories. To let you build and test your compliance handling against every outcome, Tesser provides two testing mechanisms in sandbox:

• Outbound: send a payout to one of the public test destination addresses below. Each address corresponds to a different risk severity.
• Inbound: call POST /v1/payments/simulate-inbound and choose the mocked_risk_status you want the screening verdict forced to.

With both mechanisms you get the same payment.risk_updated webhook, risk_status transitions, and manual-review flow as in production. See Compliance and Risk Management for how screening works and the Funds Movement Lifecycle and Data Model for the full risk_status taxonomy.

Test outbound risk checks

Outbound screening targets the beneficiary wallet, the on-chain address behind desired.to.account_id. To trigger a given outcome, create a payout whose destination account's crypto_wallet_address is one of the test addresses. A payout does not execute until risk is approved (see Payout risk review).

Outbound test destination addresses

These are EVM addresses and can be used on Ethereum Sepolia, Base Sepolia, and Polygon Amoy. In sandbox, use one as the beneficiary of a stablecoin payout.

Severity → risk_status	Destination address
Medium → automatically_approved	0xd3f72b3e91c8124dfc1b4273e93594bb00c9be6f
High → awaiting_decision	0x0a5b2bf3ccfb44c1d22f07eed9553ecba752d4ad
Severe → automatically_rejected	0xac4cc4b68ea24bbfaac8fd127b67ed445accce22

Steps

1. Create a beneficiary account at a test address. Create a counterparty and a stablecoin account whose crypto_wallet_address is the test address for the severity you want to exercise. Payouts to this account screen to the corresponding outcome.

2. Create a payout to that account. Follow Create a Payout and set desired.to.account_id to the beneficiary account. A minimal request:

   Code
   {
     "funding_account_id": "2113b166-5873-42fd-85fe-5b1a02940d43",
     "desired": {
       "from": {
         "account_id": "6de8a7e9-be79-4885-9b65-b25b11d38078",
         "amount": "1",
         "currency": "USDC",
         "network": "ETHEREUM"
       },
       "to": {
         "account_id": "53b7aabd-97bc-4a4f-9f9c-1c1c69474889",
         "currency": "USDC",
         "network": "ETHEREUM"
       }
     }
   }

3. Observe the verdict. Once desired.to.account_id is set, Tesser screens the beneficiary and emits a payment.risk_updated webhook carrying the mapped risk_status:

   Code
   {
     "risk_status": "automatically_rejected",
     "risk_status_reasons": [
       {
         "risk_status_reason_type": "OWNERSHIP",
         "risk_status_reason_category": "Sanctions",
         "risk_status_reason_message": "Address has OWNERSHIP activity for Sanctions",
         "risk_status_reason_severity": "Severe",
         "risk_status_reason_participant_id": null,
         "risk_status_reason_significance": "DECISIVE",
         "volume_usd_percent": "100.00",
         "volume_usd_percent_threshold": "1",
         "volume_usd_amount": "56051.10",
         "volume_usd_amount_threshold": null,
         "confidence_score": null,
         "confidence_score_threshold": null
       }
     ]
   }

Test inbound risk checks

POST /v1/payments/simulate-inbound sends a real, tiny test-USDC transfer from a Tesser-controlled faucet wallet into one of your managed wallets. It then forces the screening verdict to the mocked_risk_status you choose. The inbound itself is genuine. It is detected on-chain through the normal path, and balances, lifecycle, and webhooks all behave exactly as they would for a real inbound. Only the screening verdict is fabricated. It carries risk indicators that match your mocked_risk_status, so risk_status_reasons is populated the same way as in production. See Receive an Inbound Payment to a Wallet for the flow this exercises.

Prerequisites

• A managed stablecoin_ethereum wallet with an on-chain address to receive the inbound (to_account). Provision one via Create an Account. An account that exists but is not an eligible managed wallet returns payments-3055.

Request

Field	Required	Description
to_account	Yes	Managed account ID that should receive the simulated inbound.
mocked_risk_status	Yes	The risk_status the screening verdict is forced to: automatically_approved, awaiting_decision, or automatically_rejected.
network	No	EVM testnet to send on: BASE_SEPOLIA (default), ETHEREUM_SEPOLIA, or POLYGON_AMOY. Any other network returns payments-3054.

The transfer is a fixed 1 USDC per call. The API returns the actual value.

Code
curl -X POST https://sandbox.tesserx.co/v1/payments/simulate-inbound \
  -H "Authorization: Bearer your-access-token" \
  -H "Content-Type: application/json" \
  -d '{
    "to_account": "7a3d8f2e-6b4c-4a91-b8e5-2f9c1d7e3a0b",
    "mocked_risk_status": "awaiting_decision",
    "network": "BASE_SEPOLIA"
  }'

The mocked_risk_status you send is exactly the risk_status the resulting inbound screens to. If you choose awaiting_decision, record a decision afterward (see Review a payment awaiting a decision).

Response

Once the inbound payment is detected and screened, the endpoint returns the full payment with risk_status set to your mocked_risk_status:

Code
{
  "data": {
    "id": "9f3b7e1c-4a2d-4f69-b5a8-0c6e2d9f1a3b",
    "direction": "inbound",
    "risk_status": "awaiting_decision",
    "risk_status_reasons": [
      {
        "risk_status_reason_type": "OWNERSHIP",
        "risk_status_reason_category": "High-Risk Exchange",
        "risk_status_reason_message": "Address has OWNERSHIP activity for High-Risk Exchange",
        "risk_status_reason_severity": "High",
        "risk_status_reason_participant_id": null,
        "risk_status_reason_significance": "DECISIVE",
        "volume_usd_percent": "100.00",
        "volume_usd_percent_threshold": "1",
        "volume_usd_amount": "56051.10",
        "volume_usd_amount_threshold": null,
        "confidence_score": null,
        "confidence_score_threshold": null
      }
    ],
    "balance_status": null
  }
}

If the on-chain transfer is broadcast but not yet detected and screened within the request's wait budget, the endpoint returns 202 Accepted instead, with the transaction hash and (once known) the payment_id. Poll GET /v1/payments/{paymentId} for the screened payment:

Code
{
  "data": {
    "tx_hash": "0xabcdef0123",
    "network": "BASE_SEPOLIA",
    "status": "pending",
    "payment_id": null
  }
}

Inbound risk is advisory and does not gate the credit (see Spending the Inbound Funds).

Review a payment awaiting a decision

Whenever a payment lands in awaiting_decision, record a decision through the risk review decision API or in the Tesser dashboard:

Code
curl -X POST https://sandbox.tesserx.co/v1/payments/{paymentId}/review \
  -H "Authorization: Bearer your-access-token" \
  -H "Content-Type: application/json" \
  -d '{
    "is_approved": true
  }'

After the decision is recorded, risk_reviewed_by and risk_reviewed_at are populated. A payment.risk_updated webhook fires with risk_status transitioned to manually_approved (when is_approved is true) or manually_rejected (when false).