Corsa can automatically freeze a transaction when a monitoring rule matches, preventing it from settling until a compliance analyst reviews the associated alert. This page explains how the halting mechanism works, the difference between synchronous and asynchronous evaluation, and how frozen transactions move through status changes.Documentation Index
Fetch the complete documentation index at: https://docs.corsa.finance/llms.txt
Use this file to discover all available pages before exploring further.
How halting works
When you create a rule, you choose one of two response modes:- Alert only — Create an alert for analyst review. The transaction proceeds normally.
- Alert + Halt transaction — Create an alert and freeze the transaction until it is explicitly released.
HALT_TRANSACTION action matches a transaction, the evaluation returns a FREEZE decision. If multiple rules match, the final decision is FREEZE if any matching rule includes a halt action.
Evaluation modes
Corsa supports two ways to evaluate transactions against your rules. The key difference is who acts on the decision.Asynchronous evaluation (automatic)
This is the default mode for production transaction monitoring. When you ingest a transaction through the API, Corsa automatically evaluates it against all active rules in the background. If a rule withHALT_TRANSACTION matches:
- The transaction status is set to FROZEN.
- A compliance alert is created with the highest priority from all matching rules.
- The alert includes metadata indicating the transaction was halted.
Synchronous evaluation (on-demand)
You can evaluate a transaction on demand by calling the evaluation endpoint directly: Endpoint:POST /v1/evaluation/evaluate
decision field:
| Decision | Meaning |
|---|---|
ALLOW | No matching rule requires halting. The transaction can proceed. |
FREEZE | At least one matching rule includes a halt action. You should hold the transaction. |
In synchronous mode, Corsa returns the decision but does not automatically freeze the transaction. Your system is responsible for acting on the
FREEZE decision — for example, by holding settlement until the alert is resolved.Synchronous evaluation (inline on ingest)
You can evaluate a transaction during ingestion by settingevaluateSynchronously: true on the transaction object within a deposit, withdrawal, or trade request. The response includes an evaluationResult field with the rule-engine decision, matched rules, and action outcomes.
Unlike the on-demand endpoint above, inline sync evaluation automatically freezes the transaction when the decision is FREEZE — you do not need to handle the status change yourself.
Evaluation result
WhenevaluateSynchronously is set, the transaction in the response includes an evaluationResult object:
| Field | Description |
|---|---|
decision | ALLOW — no halt rules matched. FREEZE — at least one halt rule matched and the transaction was frozen. UNKNOWN — evaluation failed (see failureReason). |
matchedRules | Array of matched rules, each with ruleId, ruleVersion, and ruleName. |
actionsExecuted.haltApplied | true if the transaction was frozen by the evaluation. |
actionFailures | Array of action failures, each with actionType and error. Empty when all actions succeed. |
failureReason | Present only when decision is UNKNOWN. Either TIMEOUT (evaluation took too long) or ERROR (evaluation failed). |
Fail-open behavior: If the evaluation times out or encounters an error, the transaction is not blocked. The decision is
UNKNOWN with a failureReason, and the transaction proceeds normally. Async evaluation still runs in the background.The
evaluateSynchronously flag only applies to new creates. When upsert=true and a record with the same referenceId already exists, the flag is ignored.Choosing the right mode
| Mode | When to use |
|---|---|
| Async (automatic) | Standard production flow. Transactions are ingested and evaluated automatically. Freezing and alert creation happen without additional code. |
| Sync (on-demand) | Pre-settlement checks where your system needs to make a go/no-go decision before processing a transaction. Your system acts on the decision. |
| Sync (inline on ingest) | Get a rule-engine decision at ingestion time within the same API call. Corsa automatically freezes the transaction on FREEZE. Useful when you need a decision before returning a response to your user. |
Transaction statuses
Every transaction in Corsa has a status that reflects its current state:| Status | Description |
|---|---|
PENDING | The transaction is in progress or awaiting processing. |
SUCCESS | The transaction completed successfully. |
FROZEN | The transaction is halted pending compliance review. |
CANCELLED | The transaction was cancelled. |
FAILED | The transaction failed. |
Status flow for halted transactions
A typical halted transaction follows this path:- Transaction is ingested with status PENDING.
- Async evaluation triggers a rule with
HALT_TRANSACTION. - Status changes to FROZEN. A compliance alert is created.
- An analyst reviews the alert and the transaction details.
- Based on the review, the analyst updates the transaction status:
- PENDING or SUCCESS if the transaction is cleared.
- CANCELLED if the transaction should not proceed.
Releasing a frozen transaction
After reviewing the associated alert, update the transaction status to release it: Endpoint:PUT /v1/transactions/{id}/updateStatus
Configuring halt rules
To add halting to a rule, select Alert + Halt transaction in the Rule Builder configure step, or includeHALT_TRANSACTION in the actions array when creating a rule via API:
What’s next?
Building rules
Configure halt actions in the Rule Builder wizard.
Conditions reference
See all operators, entities, and aggregations available for conditions.
Rules and Evaluation API
Full API reference for rule management and evaluation.