Contributing Transactions is an optional feature that allows scenarios to attach the transactions that triggered an alert directly to the alert view. When enabled and correctly configured, investigators see a list of relevant transactions at the bottom of each alert without needing to manually search for them.
The feature is designed to reduce investigation time by giving analysts immediate access to the evidence behind an alert.
How It Works
When Contributing Transactions is enabled for a scenario, the scenario's SQL query must be modified to return a comma-separated list of transaction IDs as an additional column. When an alert is generated, the platform reads that column and links those transactions to the alert.
On the alert page, contributing transactions are displayed in an expandable card at the bottom of the page. If multiple scenarios contributed to an alert, each scenario gets its own card, stacked vertically.
Currently, up to 100 contributing transactions per scenario are shown. If the limit is hit, you will see a warming that there might be more transactions contributing to the alert being generated.
Enabling the Feature
To enable Contributing transactions for a scenario:
Open the scenario you want to configure and create a new version (or edit an existing draft).
On the right side of the scenario editor, find the Show contributing transactions on alert toggle.
Turn the toggle on.
Update the scenario SQL query to return transaction IDs in the correct position (see below).
Save the version and make it current when ready.
Note: Enabling the toggle is safe. If the query is not yet updated to return transaction IDs, alerts will still be created normally — they just won't show contributing transactions.
Query Configuration
To attach contributing transactions to alerts, the scenario query must return a comma-separated list of transaction IDs using string_agg(id::text, ','). The position of this column in the SELECT statement depends on the scenario type.
Scenario Type | Column Position | Note |
Real-time / Post-event | 2nd | 1st: boolean condition, 2nd: transaction IDs, 3rd+: detail values |
Periodic | 3rd | 1st: person_id, 2nd: boolean condition, 3rd: transaction IDs, 4th+: detail values |
This feature is not supported for scenarios that use data aggregations.
Example: Real-time / Post-event Scenario
The first SELECT column must be a boolean condition. The transaction IDs column goes in 2nd position, immediately after the condition. Any detail values used as $param in the alert details follow from the 3rd position onwards.
Before (without contributing transactions):
select count(past.id) >= $count_threshold , count(past.id) from transaction new join transaction past on past.person_id = $person.id where new.id = $transaction.id and new.direction = any($direction) and past.direction = any($direction) and past.timestamp >= $transaction.timestamp - $period and past.timestamp <= $transaction.timestamp |
After (with contributing transactions):
select count(past.id) >= $count_threshold , string_agg(past.id::text, ',') -- 2nd position: contributing transaction IDs , count(past.id) from transaction new join transaction past on past.person_id = $person.id where new.id = $transaction.id and new.direction = any($direction) and past.direction = any($direction) and past.timestamp >= $transaction.timestamp - $period and past.timestamp <= $transaction.timestamp |
Note: If your query includes a GROUP BY clause, make sure you do not add the transaction ID column to it. The string_agg() function is an aggregate — it does not need to be in GROUP BY.
Example: Periodic Scenario
Periodic scenarios require person_id as the first SELECT column and a boolean condition as the second. The transaction IDs column goes in 3rd position, right after the condition.
Before (without contributing transactions):
select past.person_id , sum(past.amount) >= $total_amount_threshold , sum(past.amount) from transaction past join person p on p.id = past.person_id where past.direction = any($direction) and past.timestamp >= current_date - $period and past.timestamp <= current_date and p.customer_id = $organisation.id and p.type = any($person_type) group by past.person_id |
After (with contributing transactions):
select past.person_id , sum(past.amount) >= $total_amount_threshold , string_agg(past.id::text, ',') -- 3rd position: contributing transaction IDs , sum(past.amount) from transaction past join person p on p.id = past.person_id where past.direction = any($direction) and past.timestamp >= current_date - $period and past.timestamp <= current_date and p.customer_id = $organisation.id and p.type = any($person_type) group by past.person_id |
Alert View
On the alert page, contributing transactions appear at the bottom of the alert in an expandable section labelled with the scenario name. Each row shows transaction details including counterparty, sender and receiver accounts, status, amount, and currency.
If an alert was generated by multiple scenarios, each scenario's contributing transactions are displayed in a separate card, stacked vertically. Up to 100 transactions are shown per scenario.