Screen transactions before settlement

Settlement rule

Branch only on should_block

should_block = true  → do not settle
should_block = false → continue settlement

Do not use alert_ids, triggered-rule count, highest severity, Mule results, or asynchronous case status as the synchronous settlement gate.

Integration at a glance

One decision endpoint

Call POST /v1/engine/evaluate before settlement and branch on should_block.

Signed requests

Authenticate with an API key and sign the exact UTF-8 request body with HMAC-SHA256.

Explainable results

Receive the final action, severity, triggered rules, evaluation coverage, and behavioural-data status.

Core decision under 350 ms

The synchronous core-evaluation target is under 350 ms, excluding network latency and post-response processing.

How a transaction flows

Payment service
      │
      ▼
POST /v1/engine/evaluate
      │
      ▼
Vantrace core evaluation
      ├── should_block ──► synchronous settlement decision
      └── async ─────────► alerts / Mule analysis / cases

Mule analysis is asynchronous network-risk analysis. It is supporting information and never replaces the synchronous should_block decision. See Concepts.

Integration sequence

1. Build the transaction, customer, and account payload.
2. Serialize the JSON once.
3. Sign those exact bytes and send the request.
4. Read evaluation_status and should_block.
5. Store trx_id, your reference_id, and the X-Request-ID generated for the attempt.

Public contract

This site documents the public API contract. Environment base URLs and credentials are supplied separately to authorised integrations and are intentionally represented as placeholders here.