Skip to content

Concepts

The synchronous processing of one transaction against the tenant’s enabled core rules. An evaluation is complete when every required core rule finishes and incomplete when one or more required rules fail technically.

A configured test applied during evaluation. A rule can trigger an action such as flag, alert, or block; rule availability and configuration vary by tenant.

The immediate decision your payment flow consumes before funds move. should_block is the only synchronous settlement gate: true means do not settle, and false means continue settlement.

An asynchronous compliance work item created after the core decision. alert_ids is normally empty in the immediate response and must not delay settlement.

Asynchronous network-risk analysis that can enrich later investigation. Mule results are not part of the synchronous settlement decision and never replace should_block.

A score from 0 to 100 calculated from screening, country risk, KYC, recent alerts, cases, regulatory reports, and transaction risk. Vantrace converts the score into a low, medium, or high rating. See Customer risk scoring for the thresholds and point values.

The bank-owned account Vantrace reviews for transaction history, velocity, KYC limits, and behavioural baselines. Send it as evaluated_account_id.

The account from which funds originate. source_account_id always describes fund direction; it must not be repurposed to mean “the account being screened.”

The receiving account, sent as beneficiary_account_id when known.

Your stable transaction reference, sent as reference_id. Store it for reconciliation. It is not a server-side idempotency key.

The Vantrace identifier returned as trx_id after the transaction is committed. Store it with your transaction record.

A fresh UUID generated by the caller and sent in the required X-Request-ID header. Use it to trace one specific request attempt. It does not make the request idempotent.

See Which ID should I use? for retention and retry guidance.