Skip to content

Rule Engine

Configure, simulate, publish, and version Rule Engine policies through the API.

This guide covers the API setup for automated incoming and outgoing Travel Rule decisions. For policy ownership, review procedures, and when to apply the results, see the Rule Engine compliance workflow.

Start in the Client Dashboard

The easiest way to manage Rule Engine policies is through the Client Dashboard, where you can edit, simulate, and publish rules. If you need to manage policies programmatically, use the API steps below.

Find your policies

CryptoSwift maintains one INCOMING and one OUTGOING policy per tenant. Each policy has an editable draft, an active published rule set, and immutable published versions.

List both policies and save the returned id for the scope you want to manage:

curl --location 'https://api-dev.cryptoswift.eu/rule-engine' \
  --header "X-Api-Key: $API_KEY"

Retrieve one policy with GET /rule-engine/{id}. The response includes its scope, draftRules, publishedRules, publishedVersion, latest publish comment, and whether it has an unpublished draft.

Define a draft

Rules are evaluated from top to bottom and the first enabled matching rule wins. Every rule set must contain exactly one enabled fallback rule with empty all and any arrays, and that rule must be last.

curl --request PATCH 'https://api-dev.cryptoswift.eu/rule-engine/{ruleEngineId}/draft' \
  --header "X-Api-Key: $API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{
    "draftRules": [
      {
        "id": "high-amount-wait",
        "name": "Wait for large transfers",
        "enabled": true,
        "when": {
          "all": [
            { "field": "amount", "operator": "GTE", "value": 10000, "currency": "USD" }
          ],
          "any": []
        },
        "then": {
          "decision": "WAIT",
          "waitForSeconds": 120,
          "onTimeoutDecision": "REVIEW"
        }
      },
      {
        "id": "default",
        "name": "Default",
        "enabled": true,
        "when": { "all": [], "any": [] },
        "then": { "decision": "PROCEED" }
      }
    ]
  }'

Condition fields are status, riskSeverity, riskScore, amount, hasTxHash, counterpartyEntityId, and counterpartyEntityCountry. Operators are EQ, NEQ, GT, GTE, LT, LTE, IN, NOT_IN, CONTAINS, STARTS_WITH, ENDS_WITH, EXISTS, and NOT_EXISTS.

Within when, every condition in all must match, while at least one condition in a non-empty any array must match. Country values use uppercase ISO 3166-1 alpha-2 codes. An amount condition can specify USD or EUR as its currency.

Actions are PROCEED, WAIT, REVIEW, and BLOCK. A WAIT action also requires waitForSeconds from 1 to 86,400 and an onTimeoutDecision of PROCEED, REVIEW, or BLOCK.

Simulate before publishing

Simulation is read-only and returns the decision, matched rule, and a per-rule evaluation trace. Use DRAFT with the rules you are editing, or PUBLISHED to test the active version.

curl --request POST 'https://api-dev.cryptoswift.eu/rule-engine/{ruleEngineId}/simulate' \
  --header "X-Api-Key: $API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{
    "source": "PUBLISHED",
    "input": {
      "status": "DELIVERED",
      "riskScore": 25,
      "riskSeverity": "LOW",
      "amount": 12000,
      "amountCurrency": "USD",
      "hasTxHash": false
    }
  }'

When source is DRAFT, include the complete draftRules array in the simulation request.

Publish and retain version history

Publishing activates the current draft, increments publishedVersion, and creates an immutable snapshot:

curl --request POST 'https://api-dev.cryptoswift.eu/rule-engine/{ruleEngineId}/publish' \
  --header "X-Api-Key: $API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{ "comment": "Large transfer review policy" }'

Use these endpoints for change review and rollback:

EndpointPurpose
GET /rule-engine/{id}/versionsList published versions and their comments.
GET /rule-engine/{id}/versions/{version}Retrieve the complete immutable rules snapshot.
POST /rule-engine/{id}/restoreCopy a previous version into the draft with { "version": 3 }.

Restoring does not activate the old policy immediately. Simulate the restored draft, then publish it to make it active.

Read the outcome in a transaction

The transaction response includes a ruleEngine result with the decision, matching rule, policy version, and any wait or timeout values. Use that result when your backend decides whether to proceed, wait, send the case for review, or block. Continue handling webhooks because the counterparty may respond after the initial result.

See the Travel Rule data model for the response fields and the transaction search and audit guide for event history.

Next steps