You can now save custom filter combinations as named views in case management, removing the need to reconfigure filters each time you investigate a specific type of alert or case.
Views appear as tabs in the top navigation bar alongside Cases and Alerts, giving you instant access to your most-used filter setups across sessions.
SAR generation for alerts without a user ID
Suspicious Activity Reports (SARs) can now be generated for alerts where no user ID is present, such as alerts triggered by payment details or counterparty data.
Previously, SAR generation required a user ID to be associated with the alert. This update ensures that alerts raised on transactions where the counterparty is unknown or unregistered can still be actioned through the standard SAR workflow.
Multi-column list support in screening
Custom lists used in screening can now contain multiple columns, giving you more control over how entries are matched and how results are displayed.
Previously, screening against a custom list treated each entry as a single value. With this update, you can structure your list with multiple attributes per entry, such as name, nationality, and ID number, and select which specific column the screening engine should match against when configuring your screening rule.
As shown in the screening variable configuration, when setting up a screening variable you can now select a Column name alongside the list name, specifying exactly which column in your custom list to screen against.
Matched entries are searchable via the screening engine, and when a hit is generated, the full column values from the matched list entry are displayed in the screening hit details. This gives investigators more context to assess whether a hit is a true match or a false positive without having to refer back to the original list.
To use multi-column lists, configure your list with the relevant columns in the list management settings, then select the column to screen against in the Screen variable against section of your screening variable configuration.
Transaction and user tags added to payment approval filters
Transaction tags and user tags have been added as filter options in the payment approval tab, bringing it in line with the filters available elsewhere in the Console.
External links on transaction and user details
You can now send URLs via API with each transaction or user, which will appear as clickable hyperlinks in the transaction and user details pages in the Console.
This allows your team to link directly to relevant pages in external tools, case management systems, or internal applications from within Flagright, reducing the need to switch between platforms during investigations.
As shown in the transaction details page, external links appear in a dedicated External links section at the bottom of the details view. Each link is displayed with its label and URL.
To add external links, include the externalLinks field in your transaction or user details payload via API. See our API documentation for implementation details.
Screening hit export from user profiles
You can now export a screening report directly from a user's profile, available in both CSV and PDF format.
The CSV report follows the existing batch export format with two additional columns making it easy to import into downstream compliance workflows.
Status (open or cleared)
Comments
The PDF report includes a full summary of the screening configuration and results for that user, covering:
User ID and name
Filter and settings used, including sanctions, PEP, adverse media, and REL coverage, screening profile name, screening values (nationality, year of birth, gender), business registration details, fuzziness percentage and algorithm, short name adjustment, phonetic matching, stop words configuration, and fuzzy address matching
Case details for each hit, including case ID, alert ID, created and updated timestamps, hit details, status, and comments
To export a screening report:
Navigate to the user's profile.
Select the three dots (⋯) menu in the top corner and select Export.
Select the Screening report tab and choose either CSV or PDF format.
Select Export
User aggregation variables in transaction rules
You can now configure user aggregation variables directly within transaction rules, giving you access to user-level aggregated data when building transaction monitoring logic.
Previously, user aggregation variables were only available in user rules. With this update, they can be configured in the transaction rule builder in the same way — as shown in the aggregation variable configuration, you can define variables such as unique counts of contact details, email IDs, or other user-level fields, and reference these in your transaction rule conditions.
An issue with transaction direction filtering in user aggregation variables has also been fixed as part of this update.
Auto-Close Alerts on Transaction Approval
Alerts can now automatically close when all transactions within the alert return an Allow action after Transaction Events are sent.
This reduces manual review workload by automatically resolving alerts once all associated transactions have been approved through your transaction monitoring workflow.
To enable this feature, configure it in the alert creation details step when setting up your rule.
Screening via User Events Configuration
You can now control screening behaviour through a toggle in Settings that enables screening either via all user events or only configured variables.
This gives you flexibility to balance comprehensive coverage with focused screening based on your risk appetite and operational needs.
To configure this setting, navigate to Settings and adjust the screening via user events toggle to your preferred option.
Custom alert statuses — extended coverage
Custom alert statuses are now supported across additional areas of the platform: rule configuration for default alert creation status, rule configuration for stopping transaction additions when a status is reached, SLA policy configuration, and analytics case management distribution views.
In the analytics distribution view, custom statuses are displayed with their full prefix structure to distinguish status type. Webhook events for custom statuses follow the same escalation-aware pattern as default statuses. An open alert with a custom status emits OPEN_customstatus, and an escalated alert emits ESCALATED_customstatus, consistent with how OPEN_ON_HOLD and ESCALATED_ON_HOLD behave for default statuses.
SLA policy configuration now includes custom statuses in the status selectors, with correct status options shown when switching between policy types.
Simulation history for AIF agents
The AIF agent interface now includes a simulation history panel, showing a log of when each simulation was run and its outcome. This allows you to review past simulation results without re-running them, and to track how agent behaviour has changed across iterations.
Configurable status triggers for transaction status update webhooks
When configuring transaction status update webhooks, you can now select which status transitions should trigger a webhook event. A checkbox list is shown, all enabled by default with the following options: Allow, Flag, Suspend, and Block. Only transitions to the selected statuses will generate webhook calls, giving you finer control over webhook volume and downstream processing.
Extended aggregation field support in v8 rules
User aggregation variables in v8 rules now support aggregation over additional fields: device ID, IP address, name, and email address, in addition to the existing user ID and payment ID fields. This allows you to build more granular monitoring logic, for example, counting unique device IDs or IP addresses associated with a user within a given time window.
AIF agent filters in the alerts table
The alerts table now includes filters for AIF agent investigations. You can filter alerts by agent disposition, correct auto-close or human review, making it straightforward to isolate alerts that were handled automatically by an agent versus those escalated for manual investigation.
Filter for enabled and disabled risk factors
A filter option has been added to the risk factors view, allowing you to restrict the list to enabled or disabled risk factors only. This makes it easier to audit your active configuration without scrolling through the full list.
Alternate payment identifier for NPP payments
For NPP payments where a PayID is not present, the platform will now fall back to using BSB and account number as the payment identifier. This ensures that NPP payments without a PayID are still correctly identified and processed through your monitoring rules, addressing cases where counterparty data does not include a PayID.