Rules

Rules are the building blocks of the Decision Engine. They define how transactions are evaluated and what should happen as a result.

Each rule combines a set of conditions with one or more actions, allowing you to control transaction behaviour in real time - without requiring code changes. Rules can be created, modified, and reused across different parts of the system, making it easy to adapt decisioning logic as your needs evolve.

Rather than being fixed or hard-coded, rules in the Decision Engine are fully configurable and can incorporate transaction data, historical activity, and dynamic parameters. This enables everything from simple controls to highly tailored, context-aware decisioning.

Key Concepts

Trigger Conditions

The logic that determines when a rule is met. Conditions can be based on transaction attributes (such as amount, merchant, or location), as well as historical patterns and behavioural signals.

Scope

Defines where the rule applies within the system hierarchy (for example Client, Product, Account Group, or Card). Rules can be applied broadly or targeted to specific segments. Scopes

Actions

The outcome triggered when a rule is satisfied - such as declining a transaction, raising an alert, or invoking additional platform behaviour. Actions

User-Adjustable Parameters

Optional values that can be configured per client or per card at runtime via APIs. This allows rule behaviour to be customised without creating new rules. User Adjustable Parameters

Rule Cascading

Rules applied at higher levels of the hierarchy automatically apply to lower levels, unless explicitly overridden. This reduces duplication and simplifies rule management.

Example

Scenario:
If a transaction amount exceeds €1,000 and the card is not present, decline the transaction.

Explanation:
This rule could be applied at the Product level, automatically affecting all cards under that product, while still allowing parameter overrides for specific cards if needed.