Rule and scenario engine
The rule engine is the component where compliance and risk teams define their own scenarios and apply them to every incoming event. TruvaLI's engine is not limited by templates: you can build logic trees to any depth and use any data field as a variable.
Logic trees, not templates
Most systems on the market offer pre-built scenario templates where you only fill in the parameters. Real risks, however, often fall outside these templates.
In TruvaLI, you can nest AND, OR, and NOT blocks to any depth. A scenario can be as detailed as your actual operational complexity, such as "if this condition is met, and one of these two conditions is present, but this exception does not apply".
Any field can be a variable
Every field in the incoming data packet can be mapped to a variable: customer name, device ID, location, browser information, channel, counterparty, or the company's activity code. No infrastructure changes are required to use a new field in a scenario.
Flexible aggregation windows
Daily and monthly totals exist in most systems, but the real need lies beyond them. In TruvaLI, you define the window:
- Total amount "in the last 73 hours".
- Number of unique recipients "in the last 15 transactions".
- Number of unique accounts logging in from the same device "in the last 7 days".
Windows do not have to be time-based: you can also set up windows based on transaction volume.
Cross-entity checks
Within a single scenario, you can evaluate the history of both the sender and the recipient together, check shared IPs, and include blacklist matches in the same condition. Most risk is visible not in a single transaction, but in the relationship between the parties.
Expression editor
For cases where drag-and-drop logic is not enough, custom calculation blocks can be written. This is for advanced users: the vast majority of scenarios are built without writing code. If you prefer, you can also describe the scenario in your daily operational language, see the writing rules with prompts page.
Rule-triggered callbacks
A rule does not just generate alerts: it can trigger actions by sending a call, such as an HTTP POST, to your core system. Instantly suspending a suspicious transaction, requesting additional identity verification, or restricting an account is done this way.
Separate rule sets
For institutions with multiple platforms or subsidiaries, data sources can be managed independently. Each department only sees its own source, rules, and alerts.
What it delivers to the institution
- No template limits on scenario complexity.
- Same-day response to new threats.
- Rules can trigger actions beyond just generating alerts.
- A record of who modified each rule version and when.
Common questions
- Do I need to know SQL or coding to write rules?
- No. Scenarios are created by building logic blocks in the interface or by describing them in daily operational language. The expression editor is only there for advanced cases requiring custom calculations.
- How flexible is the aggregation window?
- It is not limited to pre-set periods like days and months. Free-form time windows like 'the last 73 hours' or volume-based windows like 'the last 15 transactions' can be defined.
- Can a rule stop a transaction directly?
- Yes. By triggering a callback to your core system from within the rule, a transaction can be suspended, additional verification can be requested, or the account can be restricted. Depending on the institution's maker/checker settings, putting the decision into production may be subject to approval.
- Do we have to deploy a new rule directly to production?
- No. A rule can be run against your historical data to preview the alert volume and false positive rate it will generate. For details, see the rule sandbox and simulation page.