Case management: Case groups
You can now group related alerts into shared cases by defining case groups and assigning a rule to one. When a rule assigned to a case group produces alerts, those alerts are grouped into a shared case (and reused for subsequent hits) instead of opening a separate case for every alert. This keeps related activity, for example alerts from a set of rules that together indicate one typology, in a single case for investigation.
How it works for you:
Create, rename, and delete case groups under Settings.
Assign a rule to a case group in the rule's Alert Creation step. Alerts from that rule are then grouped into a case tied to that group.
The Cases table shows a Case group column so you can see at a glance which group a case belongs to.
Note Case group assignment is currently available for custom rules using scenario builders. If you use a template rule configuration, the case group option isn't exposed there yet.
Case management: Custom tags on cases and alerts
You can now define and apply your own tags to cases and alerts, the same way you already can for users. Tags can be free-text or a fixed set of dropdown options, and they're configurable per tag key, so you can standardize how your team labels and later filters cases and alerts.
How it works for you:
Define your case and alert tag keys (and dropdown options, where applicable) under Settings, with the same tag configuration experience used for user tags.
Setting to add custom tags to cases
Add or edit tags directly on a case or alert detail page, and include tags when creating a manual case.
Tags set via the console and tags set via the API work together: both are shown, and updating a tag key over the API with a new value updates that same tag rather than creating a duplicate.
Tag changes are permission-controlled and recorded, so tag edits are subject to your role permissions and captured for audit.
Tagged case through a case detail page
For detailed guide on how to tag cases and alerts, refer to this knowledge base article
Case management: Filter users by pending approval field and approver
If you use approval (maker-checker) workflows on user changes, you can now filter the Users table by what's awaiting approval, both by which field is pending approval (for example EODD, CRA, PEP) and by which approver role the change is waiting on. This makes it much faster for reviewers to find exactly the changes they're responsible for approving, instead of scanning the full user list.
How it works for you:
New pending-approval filters on the Users table: filter by pending field and by approver role.
The filters read from a maintained snapshot of pending approvals, so the list loads quickly even with many users, without having to open each user's pending changes.
Good to know: because the filter is driven by a synchronized snapshot that updates as approvals are created and resolved, there can be a brief lag between an approval action and the filtered list reflecting it, it self-corrects on the next update.
Fig 1. This is how you would attach a approval workflow user state field
Fig 2. An example of what changing a user state might look like
Fig 3: After making changes, your changes will then require approval from someone with approval roles
FRAML API: ALERT_OPEN and CASE_OPENED webhooks now fire on reopen
Previously these webhooks fired only when an alert or case was first created. They now also fire whenever an alert or case moves back to Open from another state (for example In Progress, On hold, or Escalated). If you drive downstream systems or SLAs off these webhooks, you'll now be notified on reopen, not just initial creation.
How it works for you:
No configuration change needed, existing
ALERT_OPEN/CASE_OPENEDwebhook subscriptions will simply start receiving events on reopen transitions as well as on creation.If your integration assumed these events meant "created," you may want to check how it handles a repeat event for an entity it has already seen.
See our API docs for reference
Transaction monitoring: New alert grouping option, one alert per counterparty user pair
When configuring how a rule creates alerts, you now have an additional grouping option: group alerts into:
Single alert for all counterparties: a single alert per sender/receiver user pair, based on user ID and ignoring the payment identifier. This is useful for monitoring flows between your own users, where you want one alert per relationship rather than one per payment instrument.
Separate alert for each counterparty: With this option there will one alert per counterparty. So for a transaction between, sender and receiver, there are 2 alerts generated.
Separate alert for each payment identifier: With this option, alerts are created per payment identifier in the the transaction
Separate alert for each counterparty user ID: With this we create a new alert per User ID
For a detailed guide, go through this knowledge base article
Screening: Auto-close user screening alerts when new events clear the match
User screening alerts can now auto-close when a later user event removes the match, the same auto-close behavior already available for transaction screening. For example, if a screening alert was raised on a name that was later corrected via a user event, and the corrected name no longer produces a hit, the open alert closes automatically instead of waiting for manual review.
Enable the auto-close setting on supported user and user-screening rules (available in both the V2 and V8 rule editors).
Auto-close only triggers when a screening re-evaluation actually runs and returns no match, a skipped re-screen won't close an alert.
Case management: SAR approval workflows
SARs can now go through jurisdiction-specific approval workflows with visibility restrictions, instead of a single flat review process applied regardless of jurisdiction. This lets teams operating across multiple regulatory regimes route each report to the right approvers and control who can see it.
Case management: Validate option before submitting SARs
You can validate a SAR before submitting it. Flagright console now highlights any missing sections that needs to be filled out and data issues that need to be resolved before sending out these SARs
Case management: Alerts for periodic rules no longer duplicate
Daily, weekly, or monthly periodic rules used to open a brand-new alert every cycle even when one was still open. New transactions now get added to the existing open alert as they occur, rather than waiting for the next cadence or piling up duplicate alerts.
No configuration change needed; periodic rules automatically reuse an open alert if one exists.
Transactions are added as they get hit, so the open alert stays current instead of only updating on the daily/weekly/monthly schedule.
Compliance: FINTRAC filing transaction limit increased
The transaction selection limit for FINTRAC STR filing is raised from 30 to 500 transactions per report, with a 25 MB file size cap enforced to keep generated reports within FINTRAC's submission limits.
The higher 500-transaction limit applies to FINTRAC STR reports specifically; other report types (e.g. FinCEN) keep their existing limits.
If a report with many transactions would exceed 25 MB, you'll be prompted to select fewer transactions.
Screening: catch exact-match abbreviations of sanctioned entities
Transaction reference field screening now creates hits when the reference contains an exact abbreviation of a sanctioned entity, not just the full name, for example "IRGC" for the Islamic Revolutionary Guard Corps. This closes a gap where sanctioned entities referred to only by their acronym could otherwise pass unscreened.
Custom rules & risk factors: Timestamp variables
You can now build rule and risk factor conditions based on when a specific event last happened, comparing it against the current transaction or another timestamp, instead of relying only on fixed variables.
Key updates include:
New Timestamp variable type, available in the rule builder and transaction risk factor (TRS) configuration.
Match on a user event or transaction event field, either an exact value or just its presence.
Compare two timestamps using the new
compare_timestampsfunction, e.g. "within 30 minutes of X."
Fig 1. Example of what a timestamp variable looks like
Find more details on how to configure these in this knowledge base article