Skip to main content
Variables allow you to inject dynamic, externally-managed data into your rules without modifying the rule’s source code.

Purpose

Variables solve a critical operational problem: some data changes more frequently than the rules that reference it. For example:
  • A sanctioned countries list is updated quarterly by OFAC.
  • A list of known fraud BINs changes daily.
  • A high-risk MCC list is managed by a compliance team.
Without variables, every update to these lists would require a code change, a PR, and a deployment. With variables, the list is managed externally and the rule remains static.

Syntax

Variables are referenced using the $ prefix:
Variables also support dot notation for accessing properties of the current transaction context:

Usage with the in Operator

The most common use case is checking a field against a variable list:

The $current Variable

The special $current variable provides access to the transaction currently being evaluated. It is used inside function arguments to create self-referencing filters:
How it works: At runtime, $current.source is resolved by the interpreter using the resolvePlaceholder function. It looks up the field path in the current transaction’s data and substitutes the actual value. If the field does not exist, the condition evaluates to false.

Variable Naming Conventions

  • Use snake_case prefixed with $.
  • The name should clearly describe the content of the variable.
  • Good: $sanctioned_countries, $high_risk_mccs, $blocked_card_bins
  • Bad: $list1, $data, $x