April 4, 2026

User variables in transaction screening

You can now use user variables in transaction screening rules to support more dynamic and context-aware rule logic.

This is particularly useful when you need to reference user-level attributes, such as expected behaviour, account type, or risk profile directly within screening rule conditions, without having to create separate rules for each user segment.

To configure user variables in screening, navigate to your rules configuration and select the relevant user variable fields when building your transaction screening rule.

Screening for legal entity aliases

A new screening variable Business User / Alias of legal entity has been added to business user screening rules.

This allows you to screen against the aliases of a legal entity, improving match coverage for businesses that may be listed under different names in sanctions lists, PEP databases, or adverse media sources.

To use this, navigate to your business user screening rule configuration and select the alias screening variable when setting up your rule conditions.

Multi-column list support in screening

Custom lists used in screening rules can now contain multiple columns, allowing you to build more precise rule conditions based on the combination of values within a single list entry.

For example, say you have a custom sanctions list with three columns — name, nationality, and ID number — and two entries:

If you configure a list variable on the ID column and add a filter condition requiring nationality=Iranian, only Entry 1 will activate the rule. Entry 2 will not, even though it shares the same ID — because it fails the nationality condition.

This is more precise than maintaining separate lists for names and nationalities, where each condition is checked independently and has no awareness of the other values on the same row.

Note that each list variable currently supports one filter condition. If you need to screen against additional attributes, this can be combined with separate rule conditions in the rule builder.

To use multi-column lists, configure your list with the relevant columns in the list management settings, then reference it as a list variable in your rule configuration and add a filter condition for the column you want to check.

Separate screening for individuals and legal entities

Screening rules for consumer and business users can now be configured to target sanctioned individuals or sanctioned legal entities separately.

Previously, all screening rules matched against both sanctioned individuals and sanctioned businesses simultaneously. This meant that a consumer user could generate a hit based on their name matching a sanctioned company, even though they are a person, not a legal entity, resulting in false positives that required manual dismissal.

With this update, consumer user screening rules will only match against sanctioned individuals, and business user screening rules will only match against sanctioned legal entities, reducing irrelevant hits and making screening results easier to action.

Diners Club added as a supported card brand

Diners Club has been added to the list of supported card brands in Flagright.

You can now track, monitor, and apply rule logic to transactions made with Diners Club cards alongside other supported card types, ensuring consistent compliance coverage across your card payment channels.

Beneficiary name in payment details

Beneficiary name is now available as a field in payment details, giving you richer data for transaction monitoring and investigation.

This is particularly useful for identifying discrepancies between the intended and actual beneficiary of a payment, supporting more thorough AML investigations and sanctions screening on outbound transfers.

The beneficiary name field can be submitted via API. See our API documentation for implementation details.

cardFirst6Digits field added

The cardFirst6Digits field is now supported, enabling improved card-level data handling in transaction monitoring.

This field allows you to identify the issuing bank and card network from the first six digits of a card number (the Bank Identification Number), which can be used in rules to flag transactions from specific issuers or geographies.

The cardFirst6Digits field can be submitted via API. See our API documentation for implementation details.

Expected currency field for users

You can now add an expected currency field to user profiles to enhance currency-based risk monitoring.

This can be referenced in rules to trigger alerts when transactions are made in unexpected currencies, helping you identify unusual activity patterns and potential fraud or money laundering behaviour.

To add expected currency to a user profile, update the profile via API. See our API documentation for implementation details.

GBPA added as a supported transaction currency

GBPA is now available as a supported transaction currency in Flagright.

You can now monitor and apply rule logic to transactions denominated in GBPA, ensuring consistent compliance coverage for your GBPA payment flows alongside other supported currencies.

BASE network support added

The BASE network has been added to the list of supported

crypto networks in Flagright.

You can now track and monitor transactions on BASE for comprehensive cryptocurrency compliance coverage alongside other supported networks.

Live and shadow rule versioning

Live and shadow rule versioning is now available, giving you better visibility and control over changes made to active rules.

This allows you to track how rules have changed over time without interrupting live operations, supporting more confident rule management and clearer audit trails for compliance purposes.

Rule versions are updated automatically when changes are saved. Navigate to the rule detail view to review version history.

Filter audit logs by parameter name

A new Parameter name filter has been added to the audit log, allowing you to filter audit log entries by the specific field that was changed.

This is particularly useful for compliance reporting — for example, filtering for all changes made to PEP status, sanctions status, or KYC status across your user base over a given period, without having to manually review every audit log entry.

The Parameter name filter is available after selecting an Entity, as the list of available fields is populated dynamically based on that entity's attributes. Fields that can be filtered on include:

To use this filter, navigate to the audit log, select entity:USER, and then select the relevant parameter name from the filter dropdown.

Uploaded documents on user profiles

Uploaded documents are now displayed directly on user profiles in the Console, giving you quicker access to KYC and compliance documentation during reviews.

This removes the need to navigate away from a user profile to find supporting documents, streamlining the review process for compliance analysts and case managers.

More data included in user profile exports

User profile exports now include a richer set of data, giving you a more complete picture of each user in a single download.

Exports for business users now include additional fields across the following sections:

Previously, exports contained only top-level user information and risk score summaries. No additional configuration is required, the expanded data is included automatically when you download a user profile report.

Delete agents from the AIF Agents table

You can now delete agents directly from the AIF Agents table, making it easier to manage your agent configuration over time.

This is useful when decommissioning agents that are no longer in use, helping you keep your AI Forensics setup clean and up to date.

To delete an agent, navigate to the AIF Agents table and select the delete option for the relevant agent.

Checklist enhancements for QA

Checklists now support a third response option and inline comments, giving investigation and QA teams more flexibility when reviewing cases.

A "Not applicable" option has been added alongside the existing responses for both investigation and QA checklist items:

QA reviewers can now also add a comment directly against each checklist item after marking it as Pass, Fail, or Not applicable. This makes it easier to document reasoning, flag exceptions, or provide context without leaving the checklist view.