Response and decisions
The endpoint returns a JSON decision. Use should_block as the immediate settlement gate.
Response fields
Section titled “Response fields”| Field | Type | Description |
|---|---|---|
evaluation_status |
string | complete or incomplete. |
rule_evaluations |
object[] | Status for every rule included in the core decision. |
trx_id |
integer | Vantrace transaction identifier. Store it for reconciliation. |
should_block |
boolean | Authoritative synchronous settlement gate. |
final_action |
string | Aggregated action: none, flag, alert, or block. |
highest_severity |
string | Highest severity among successfully triggered rules. |
triggered_rules |
object[] | Successfully evaluated rules that triggered. |
triggered_count |
integer | Number of entries in triggered_rules. |
alert_ids |
integer[] | Empty in the immediate response because alert creation runs afterward. |
mule_risk_summary |
object or null | Immediate Mule state, normally queued or disabled. |
mule_risk |
object or null | Not part of the immediate core decision. Normally null. |
behavioural_data_status |
string or null | Summary of baseline availability and quality. |
behavioural_sufficiency |
object or null | Detailed reasons and baseline facts. |
Settlement logic
Section titled “Settlement logic”if evaluation_status == "incomplete": should_block is true
if should_block == true: use the approved blocking path before funds moveelse: use the approved settlement pathIncomplete evaluation
Section titled “Incomplete evaluation”Every core rule selected for the decision is mandatory. If a rule fails technically:
evaluation_statusisincomplete.- The failed rule appears in
rule_evaluations. error_codeidentifies the technical rule failure when available.should_blockistruedefensively.- A failed rule does not appear as a triggered compliance finding.
{ "evaluation_status": "incomplete", "rule_evaluations": [ { "rule_id": "B5", "rule_name": "Velocity spike", "evaluation_status": "failed", "triggered": null, "action": null, "error_code": "RULE_EVALUATION_ERROR" } ], "trx_id": 120046, "should_block": true, "final_action": "block", "highest_severity": "low", "triggered_rules": [], "triggered_count": 0, "alert_ids": []}When no rule triggers, highest_severity: "low" is the current baseline/default value; it does not mean a low-severity rule triggered. Use triggered_rules to identify actual findings and should_block for settlement.
Triggered rule shape
Section titled “Triggered rule shape”| Field | Type | Description |
|---|---|---|
rule_id |
string | Stable rule code. |
rule_name |
string | Human-readable rule name. |
severity |
string | low, medium, high, or critical. |
action |
string | flag, alert, or block. |
report_type |
string or null | Regulatory report type when applicable. |
details |
object | Rule-specific thresholds, evidence, and data-quality information. |
Enabled rules and configured actions can vary by tenant. Integrations should consume the response instead of hard-coding a rule catalog.
Alerts are asynchronous
Section titled “Alerts are asynchronous”The core decision is committed before post-response processing starts. Alert creation, notifications, case linkage, Mule persistence, auditing, and customer/account synchronisation occur after the synchronous response.
Therefore:
alert_idsis empty in the synchronous response.- Settlement must not wait for an alert.
trx_idand the caller-generatedX-Request-IDare immediate reconciliation references.
Mule status
Section titled “Mule status”Mule analysis is asynchronous network-risk analysis. When it is enabled, the immediate summary has status queued. When it is not enabled, the status is disabled. Later analysis does not change the synchronous should_block value already returned for the core decision.
Possible Mule status values in the broader response model include queued, evaluated, partially_evaluated, not_evaluated, disabled, and failed.