Transaction Monitoring

Transaction monitoring screens a transfer in real time against your account's rules and policy, and returns a decision you can act on. For crypto transactions the counterparty wallet is screened for sanctions, mixer, darknet, and other source-of-funds risk; pass transaction_hash and the settled on-chain transaction is screened instead of just the address.

This is the per-transfer counterpart to Wallet Screening: screening looks at an address in isolation, monitoring evaluates a transaction in the context of your rules and history.

Submitting a transaction

For a crypto transaction with screening enabled, counterparty.wallet_address is required - the external wallet whose risk you want - and for an inbound transfer subject.wallet_address (your deposit address) as well. Omitting them returns 422.

Three fields matter more than they look:

• blockchain_network (ethereum, tron, ...) disambiguates multi-chain assets such as USDT and drives chain-based rules.
• contract_address identifies on-chain tokens.
• transaction_at lets you back-date a submission so time-window rules aggregate correctly.

GET /monitoring/transactions lists what you have submitted, newest first, with pagination and filters on client_reference, decision, and direction.

Your policy

The policy is the escalation layer applied on top of the base screening: risk-score thresholds for review and decline, automatic decline on sanctions exposure, risk categories that force a decline, and optional EUR amount caps.

Anything you have not set inherits a platform default, and is_customized stays false while every value is inherited. PUT /monitoring/policy is a partial update: omit a field to leave it alone, or send a nullable field as null to reset it to the platform default. Sanctions auto-decline is a plain true/false switch with no separate default, so send it explicitly to change it. The decline threshold and the decline amount cap must each be at or above their review counterpart.

In this section