Transaction Monitoring Investigations

The Transaction Monitoring application in Fenergo provides a structured, end-to-end process for assessing and resolving alerts generated from the detection of suspicious or unusual activity. Workflow-based investigation ensures a consistent, audited , and compliant process while enabling investigators to efficiently manage and escalate alerts as required. This guide introduces the features that support effective investigation, documentation, and decision-making within the TM investigation lifecycle.

Configuring the Investigation Workflow

TM alert investigation workflows are configured using the Fenergo Journey Builder. Configurators can take advantage the capabilities of the Fenergo Journey Engine to implement a workflow aligned to the Client’s operating model requirements using workflow stages, team assignment, maker-checker, SLA management and conditional escalation. The steps to configure a TM alert workflow are as follows, with each step explained further below:

• create a journey of type "Alert Assessment" to support the investigation process
• add the required number of Alert Assessment tasks for triage, review and escalation.
• Mark the final task a Compliance Task which, on completion, results in the alert being closed.
• Assign the relevant Team to each task. Only members of the assigned team will be permissioned to complete the task.
• Add maker- checker if required to enforce a 4-eye control.
• Add conditional steps with Task Scoping rules to enable conditional escalation so that for example only confirmed suspicious activity is escalated from first line to second line.
• Define a journey Event Trigger to connect the alert workflow to the detection engine.
• Define a journey Scoping Rule to link the alert workflow to the focal entity of the investigation.

Alert Assessment Journey

When the detection engine raises an alert, a journey-based alert workflow is triggered in the Alert Management UX using a journey of type Alert Assessment. Users follow the configured workflow to complete their investigation. With Fenergo, you can implement a multi-step workflow to manage a typical First Line / Second Line review and escalation process. False positive alerts can be acquitted early in the workflow, with true positives escalated for further review. To begin the configuration, create a new journey of type Alert Assessment. If that journey type is not available, you must edit the Journey Type reference data list to add it as an option.

Alert Assessment Tasks

The alert assessment workflow contains individual investigation tasks where each task represents a review and assessment of the alert by a user within a designated team. In the alert workflow, configure the required sequence of tasks ensuring that each task type is set to Alert Assessment (1). Note that all assessment tasks should be added to a single journey stage and implemented sequentially. The final step in the review must be identified as a Compliance task, which is indicated by the toggle (2). Completion of this task signifies the closure of the alert.

Team Assignment

A TM workflow involves multiple groups of users across first and second line functions collaborating in the investigation of suspicious activity. To support this process, each Alert Assessment task is assigned to a specific Team. Users allocated to that Team can then complete their allocated role in the investigation.

Maker-checker

The transaction monitoring workflow can be configured to include maker-checker rules, ensuring that assessments are completed by different users using a four-eye principle. These users may be part of the same Team. Maker-check is managed the Checker task option in the task configuration.

Alert Journey Configuration

Journey Scoping

Alert assessment journey must be triggered against the main entity on the alert. The fields available for scoping are Alert Source and Alert Type.

Event Triggers

The journey must be connected to a new alert being triggered when one or more detection rules fire. To do this, a journey Event Trigger must be defined using the following criteria:

• Event Type = Transaction Monitoring
• Event Subtype = Create Alert

Task Scoping

Within the Alert journey Task Scoping Rules can be used to add conditional steps. These rules are used to enable conditional escalation of the alert based on the previous step(s) in the investigation flow. Each alert assessment task can be triggered based on alert details or the outcome of previous alert assessments.

Alert Data Configuration

Information captured against an Alert can be re-labeled. Column (1) below indicates the database field name of each element, column (2) indicates the label the is applied by default to each element, and column (3) provides the ability to rename alert data elements as desired. The fields “Main Entity” and “Alert ID” are not configurable.

Any relabeled metadata elements will update the labels in the Information section of the Alert Assessment task and the column headers of the Alerts Dashboard.

Alert Configuration

Users and permissions: Alert Metadata

Alert Dashboard

Users manage investigations from the Alert Dashboard. To view the Alert Dashboard and access an alert in the alert dashboard the following permissions are required.

Entity Whitelisting Configuration

Entities can be white-listed from generating alerts for specific detection rules. The following permissions are required to manage entity white-listing.

Alert Assessment categorisation

Alerts are assessed during an investigation into outcomes like “Suspected Money Laundering” or “Suspected Terrorism Financing”. This categorisation is defined through configuration of two linked reference data lists. Alert Assessment Category: Two options should be added here - "True Positive" and "False Positive"

Alert Assessment Outcome The Alert Assessment Outcome list signifies how suspicious activity is characterised. These outcomes play a critical role in the investigation process. Outcomes can be configured to client requirements as required.

Link these reference data lists as a linked lookup, with Alert Assessment Category as the parent list.

Investigating Suspicious Activity

Fenergo Transaction Monitoring streamlines workload distribution and ensures timely resolution of alerts. With Fenergo Alert Management, clients can efficiently manage assignment of work to investigators, maintain clear oversight of operational activity, and support a consistent, risk-based approach to transaction monitoring investigations.

Alerts Dashboard

Investigations are launched from the Alerts Dashboard which is accessed from the main menu. The dashboard displays alert queues which provide investigators with an organised view of alerts that require assessment helping ensure efficient prioritisation. The “My Alerts” queue displays alerts specifically assigned to the current user, providing a focused workspace that supports timely review and resolution of their individual workload. The “All Alerts” queue presents the full population of alerts available to the wider investigation team, including unassigned items and those currently in progress.

My Alerts

The ‘My Alerts’ tab shows all alerts that have been assigned to the current user. The following attributes are displayed:

• Alert ID - Identification number which is unique to that particular alert - these always take the format XXX-YYYY where ‘XXX’ represents the alert type, and YYYY represents a number which increases by 1 for every alert generated.
• Status - Status of the alert.
  • Not Started - No journey initiated for this alert
  • In Progress - Alert available for assessment
  • Completed - Alert has been assessed and is closed
  • Paused - Alert Investigation has been paused
  • Whitelisted - Alert has been whitelisted and doesn’t need investigation
• Main entity - The focal entity of the Alert. This entity can be the sender or the receiver of a transaction
• Created Date - Date and time the alert was created
• Business rule - Detection rule that triggered the alert
• Score - Score defined in the detection rule
• Stage - Diplays the progression of the investigation
• Last assessment - Assessment label that was assigned in the previous assessment of an alert
• Group - Indicates if alert has been added to a group of linked alerts
• Transactions - Number of transactions in an alert
• Total Monitoring Amount - Sum of the transaction amounts in the alert

The Alert Queue can be sorted and filtered based on these attributes. Users can save their filters and reuse them. Saved filters persist across sessions, so when a user logs in to the application, their queue management preference is applied.

All alerts

The "All Alerts", tab contains all alerts, in the system including closed alerts. Alerts in this view have the same fields as the “‘My Alerts”’, view with the addition of Assignee, which indicates the current assigned owner. Journey configuration, including team assignment and maker checker settings influence which user can be assigned to assess an alerts from the Alerts Dashboard.

Alert Assignment: Assign to me/Assign to other/Unassign

An alert is always either assigned or unassigned. An alert must be assigned to a user for that user to assess the alert. Any user (with permission) can, however, comment on an open alert even if the alert is not assigned to that user. A user can only assign an alert to themselves or have that alert assigned to them if they are included in the team that is assigned to assess this alert task. If four-eyes checking has been toggled on, the user must not have assessed the alert in a previous stage. Alerts can be assigned to users from the dashboard or from within the alert task. Depending on the user’s permissions, they can assign and unassign alerts from themselves and others or directly reassign assigned alerts to themselves or other users. Alert assignment can be changed from the alert task and on the alert dashboard.

Alert Assessment

An alert assessment is accessed directly from the alert dashboard. If a previous assessment has been carried out then the result will be shown on the dashboard. Clicking into an alert will bring the user to the latest assessment, if they are assigned to the alert, they can complete the pending assessment. Otherwise, they will see the last completed assessment. The assessment shows the essential information for each individual alert, including:

• Overview: Alert Information, Transactions, Comments and Document
• Alert Activity

Alert Overview Page

The Alert Overview Page of the alert provides a detailed overview of an alert and is split up into the following sections:

• Alert Information
• Transactions
• Suspicious Transactions
• Assessments

Additionally, at the top left of the page is the Alert’s ID and the current stage of this alert. At the top right of the page, there is the option to perform actions on the alert.

Alert Overview Page Actions

• Assign to me
• Assign to others - this will list the relevant team members eligible for the this task
• Unassign - will remove the current assignee - Pause - where SLAs are configured, users can pause a task if they have permission, this will update to unpause as relevant

Transaction Evaluation

The transaction evaluation takes place in the Transactions section of the Alert Overview Page. The Transactions section consists of a table with the following columns:

• Transaction ID - Fenergp assigned GUID
• External ID - this is the id sent in the API, can be string or guid
• Relevant review tasks defined by journey- Assessment stages
• Compliance Assessment given at Compliance review stage (if applicable)
• Sender - The sender of funds in the transaction with a hyperlink to the entity if it is the main entity
• Receiver - The receiver of funds in the transaction with a hyperlink to the entity if it is the main entity
• Created Date - The date and time that the transaction took place
• Monitoring Currency - This monitoring currency as defined in the api
• Monitoring Amount - Monitoring amount provided
• Original Currency - Original currency of the transaction
• Original Amount - Original amount of the transaciton
• Payment Method - Method used e.g. paypal, visa
• Payment Type - Payin/payout

Assesing Alerts

Once all the transactions have been assessed within an alert, the Assessments section of the page will change to display an assessment box. The user must then input an assessment message for the alert and can optionally add files to attach to the assessment . The user must click ‘Submit Assessment’ to confirm. A modal will be presented which will ask users to confirm their assessment submission. At this point the alert will move to the next stage according to the workflow configuration.

Alert Activity Page

Activity Tab

This second tab on the alert detail page provides an overview of the alert’s lifecycle from its creation. It tracks the comments written about the alert, as well as any documents which were uploaded. All trail items have relevant timestamps and clearly specify which user has added a comment to ensure auditability.

Alert Activity - Commenting and adding documents

Within the alerts activity tab users can also add new comments and add documents to the alert to aid investigation. Comments are then always available to view in this activity tab along with uploaded documents which can then be downloaded.

The following restrictions apply to uploading documents (per comment and assessment):

• Maximum of 5 files per comment/assessment
• Maximum 100MB per file
• Files must be one of the following file types:
• bmp (Bitmap Image)
• csv (Comma-separated values)
• doc (Microsoft Office document)
• docm (Microsoft Word Macro-enabled Document)
• docx (Microsoft Office Open XML Format (OOXML) Document)
• dot (Microsoft Word Document Template)
• eml (E-Mail Message)
• gif (Graphics Interchange Format 87a and 89a)
• htm (Hypertext markup language)
• html (Hypertext markup language)
• jfif (JPEG File Interchange Format)
• jpeg (JPEG Image)
• jpg (JPEG Image)
• log (Log File)
• mht (MHTML Web Archive)
• msg (Microsoft Outlook file)
• nsf (Lotus Notes Database Format)
• odt (OpenDocument Text Document)
• oft (Microsoft Outlook file template)
• pdf (Portable Document Format)
• png (Portable Network Graphic)
• ppt (PowerPoint presentation)
• pptx (Microsoft Office Open XML Format (OOXML) Document)
• rtf (Rich Text Format File)
• tif (Tagged Image File)
• tiff (Tagged Image File Format)
• txt (Text)
• xls (Excel spreadsheet)
• xlsm (Microsoft Excel Macro-Enabled Spreadsheet)
• xlsx (Microsoft Office Open XML Format (OOXML) Document)
• xltm (Microsoft Excel Macro-Enabled Spreadsheet Template)
• xml (Extensible Markup Language)
• xps (XML Paper Specification File)

Transactions Page

Transactions can be accessed from either of the two transaction grids on an alert, Transactions or Supicious Transactions. Clicking on a transaction ID will navigate to the Transaction Details page. Here users can see more information about the transaction.

Alerts Tab

This page also has an “Alerts” tab, here alerts with this transaction will be show. Users can also switch the “Open Alerts” toggle if they would like to see completed alerts with this transaction.

Entity Profile Page Alerts Tab

Alerts for a main entity can be accessed from the Entity Profile page, an Alerts tab will show these alerts. There is aslo a toggle on this page to include closed alerts for this entity. The alerts journey is available from here.

Entity Profile Page Transactions Tab

All Transactions for an entity can be accessed from the Entity Profile page, Transactions tab will show these alerts. The alerts journey is available from here.

Entity Whitelisting

Where an entity has been granted an exemption for trading with a certain counterparty, specific rules may be “Whitelisted” for that entity for a duration of time, this mean that alerts that would be triggered don’t need to be investigated while the whitelisting is in place. Fenergo offers this as an option for clients. The process is as follows

The Whitelist can be accessed from the Alerts Dashboard. With the correct permission user will see the Whitelist icon and clicking on it will open the Whitelist drawer. From the drawer, if the user has the Whitelist Edit permission, they will see the ‘+’ option and from here can add a new request to the whitelist.

Whitelist Status:

• Requested - new request, not approved, not active
• Active - requested and approved and in date
• Terminated - if a whitelist is deleted before it expires it will show are terminated and no longer active
• Expired - Once a whitelist’s expiry date passes, the status will change to expired and it will no longer be valid/active

Scoring

Why Scoring is Needed

In high-volume transaction monitoring, a binary alerting approach (alert or no alert) generates large volumes of alerts without effective prioritization. This prevents differentiation between isolated low-risk activity and sustained suspicious behaviour. As a result:

• Investigative resources are inefficiently allocated
• High-risk entities are identified with delays
• Compliance with regulatory expectations for risk-based monitoring may be compromised

Scoring can be used to facilitate alert prioritisation.

Configuration

In the Detection Rules a numerical score within the range of 1-999 can be assigned to a business rule during configuration in the Settings tab.

Display Scores on the Alerts Dashboard

When an alert is triggered for which a score has been applied, the score is displayed on the Alerts Dashboard. The score is available on all of the alerts dashboards, including on the entity profile page under the alerts tab.

The alert can be sorted from highest to lowest or lowest to highest by clicking on the Score column in the dashboard.

The alerts can also be filtered by their score by clicking on the filter icon and then selecting score. Here the minimum and maximum scores can be specified e.g. alerts with scores between 0 and 30. These alerts can then be sorted highest to lowest or lowest to highest. This functionality ensures that prioritization can be achieved, as well as efficiency in alert management.

Alert Groups

It is possible to create Alert groups, these can be created by multiselecting alerts and choosing the 'Assign to Group' option. This option will allow users to assign selected alert to a new group or to add to an existing one of their groups. Once a user creates a group, they will automatically become the group owner. Alert Group behaviour:

• only group owners can add to or remove alerts from a group
• group owner can edit the group name
• group owner can reassigned group ownership to another user
• empty groups cannot be created
• users can remove all alerts from a group, rendering it empty
• once all alerts in a group are closed the group will be closed
• Alerts can only be in one group
• All groups are visible in the Alert Groups tab
• Group score is the sum of the alert scores contained in the group

Groups can be accessed from the Groups tab on the main Alert Dashboard.

Create group can be done from My Alerts or All Alerts:

Clicking into a groups will show:

• Group owner
• Group description
• Alerts within the group

Group Actions: Available for the group owner

• Edit group information - rename group or update description
• Edit group owner, reassign group ownership

Alert Actions from within a group:

Available per alert or can be applied in bulk to alerts

• Assign to me
• Assign to others
• Remove from group
• Assess (depending on assignment)

Bulk Actions

Alerts can now be managed in bulk (max 20 alerts), there are multiple actions available once a number of alerts are selected:

• Assign to me
• Assign to others
• Assess
• Remove from group

The availability of these bulk actions is dependent on the context, e.g. Bulk assess is available from My Alerts and not All Alerts.

Where a bulk action is selected and applied to a group of alerts the users will get onscreen feedback on the effectiveness of that action. E.g.

Where the action cannot be applied to the selected alerts, a summary of the success of the bulk action is provided and where the action has Not been applied will remain selected, with an icon indicating that the "Alert could not be assigned". Where an action was not executed, these alerts will remain selected so an alternative action can be taken, if not required users can clear the selection using the "Clear" option.

Bulk Assignment

• If alerts are already assigned to you, including these alerts in a bulk "Assign to me" will show that the action wasn't successful
• When selecting the bulk "Assing to others" all tenant users are available for selection, but the action will only be applied if the user selected can be assigned to this alert. e.g. if they are in the relevant team assigned to this assessment task.
• 4 eyes validation on assignment will be done on execution, which mean as user may be assigned to an assessment task but might not be able to complete that task.

Bulk Assessment

It is possible to bulk assess alerts, users can select the alerts they would like to bulk assess from "My alerts" or from a group. From my alerts, the alerts are all assigned and can be assessed. From a Group, the assess option will only be available if all selected alerts are assigned to the user. Process:

• select multiple alerts - regardless of stage
• ensure that these are assigned to you
• select "Assess" for these alerts
• add an alert assessment result
• add an assessment comment to multiple alerts

This assessment will propagate to all the transactions in this alert for the stage they are at and the alert will progress to the next stage in their assessment journey.

Entity Access Layers on Alerts

Entity access layers are in place on the alert grids, without the correct access to an entity a user will not see alerts relating to that entity on any of the alert grids. This includes Groups, so users will see only see the alerts in a group that they have entity access layer for.

Prerequisite checklist

In order to get started with Alerts in Fenergo, the following items must be in place

• User Permissions - there are specific permission for alerts and alert configuration required
• Journey configuration is required
  • Alert journey type is Alert Assessment
  • Alert assessment tasks are in one stage
  • Alert assessment tasks are assigned to a team
  • Last alert assessment is set to compliance
  • Journey scoping and event triggers are set up
• Alert Assessment Category and Outcome set up correctly
• Alert metadata is initialised

Transaction Monitoring Permissions Catalogue

Permissions can be found in the Security configuration > Permissions > Transaction Monitoring domain

Permission Name	Description	Notes
Alert Configuration Access	Ability to access the Alert Configuration Feature.	Required by administrator to access the alert metadata.
Alert Configuration Edit	Ability to edit the Alert Configuration Feature.	Required by administrator to update the alert metadata.
Alert Configuration Approve	Ability to approve an Alert Configuration.	Required by system configuration to approve updates to the alert metadata.
Alert Dashboard Access	Ability to access the Alert Dashboard page.	This permission will allow a user to see the Alert dashboard.
Alert Dashboard Configuration Edit	Ability to edit the Alert Dashboard columns- pending.
Alert Access	Ability to access the alert.	This will allow a TM analyst to click through to an alert and see the details and transactions.
Whitelist Access	Ability to access the entity whitelist.	This will give a user access to the Entity Whitelist.
Whitelist Edit	Ability to edit an entity whitelist entry.	This will allow a user to add to or update the Entity Whitelist.
Whitelist Delete	Ability to delete an entity whitelist entry.	This will allow a user to remove a whitelist record.
Whitelist Approve	Ability to approve an entity whitelist entry.	This is required by users who should approve a whitelist added for an entity.
Entity Profile Transaction view	Ability to view transaction details for an entity.	This will allow a user to see all the transaction for an entity.
Transactions Api Access	Ability to use transactions api.	This allows a user to use the transaction API.
TM Risk Configuration Edit	Ability to edit risk configuration.	Required by system configuration to update the TM risk configuration.
TM Risk Configuration Access	Ability to access risk configuration.	Required by system configuration to access the TM risk configuration.
TM Risk Configuration Approve	Ability to approve risk configuration.	Required by administrator to approve the risk configuration, not typically granted to users in Production environment.

External Alerts

Clients can create their own Alerts through Event Ingress. For more information visit: Event Ingress - CreateAlert overview