Skip to main content
The rule engine evaluates the rules in your active ruleset against the decision context and produces the outcome. Rules run in the order they appear in the ruleset; a BLOCK short-circuits evaluation, while REVIEW outcomes accumulate. If no rule matches, the decision is ALLOW.

​
Rule types

TypePurpose
conditionMatch the decision context with a boolean expression and apply an action.
backendDelegate the decision to a backend exposed by a Link integration. Specter Connect
backend_groupEvaluate several backends together as one rule. Specter Connect
blacklistBlock when a context value matches a blacklist entry.
Each rule carries an action (ALLOW, REVIEW, or BLOCK) and an enabled flag. Rules are evaluated in the order they appear in the ruleset’s rules array.
The exact ruleset JSON schema is documented in the API reference. This page describes the concepts; the schema is the source of truth for field names.

​
Conditions

A condition rule evaluates a boolean expression tree over the decision context, addressed with JSONPath ($.transaction.amount, $.metadata.channel, …). Expressions compose:
  • Comparison — eq, neq, lt, lte, gt, gte
  • Set membership — value in a list
  • Boolean composition — and, or, not
  • Velocity — a rolling-window count (see below)
and(
  gte($.transaction.amount, 50000),
  eq($.payment_method.card.bin_data.is_commercial, true)
) → action: BLOCK

​
Velocity

Velocity conditions count how many decisions matched a given identity within a rolling time window — for example, “more than 5 attempts on this card in the last hour”. Counters are maintained atomically and fail open: if the counter store is unavailable, the velocity check never blocks a transaction. The following fields can be counted:
FieldCounter
$.credential_fingerprintPer card instrument
$.device.ipPer device IP
$.device.fingerprintPer device fingerprint
$.customer.idPer customer

​
Backend rules

Specter Connect backend and backend group rules require the Specter Connect edition; on Specter Core they cannot be added to a ruleset. A backend rule delegates the decision to a backend exposed by a Link integration. The rule names the integration slug and the backend_id to invoke; Specter calls Link to assess the transaction and maps the outcome to a Specter decision. Before any call, Specter checks that the context contains the backend’s required fields. If any are missing, it skips the backend with an insufficient_context result and makes no call. Each backend rule has an on_error setting that governs what happens when the backend errors or times out:
on_errorBehavior
allowSkip the backend and continue evaluation (fail open). The default.
blockTreat the failure as a BLOCK.
reviewTreat the failure as a REVIEW.

​
Evaluation order

Rulesets

Version and activate collections of rules.

Backends & connections

Connect external risk engines.