Manage alerts and investigation with AIM

There are three main Case Types provided with the AIM accelerator. These are Alert Intake (ALT-), Investigation (INV-), and Suspicious Activity Report (SAR-).

Pre-process stage

The first Step, Classify Alert, retrieves metadata from the Alerts catalog using information provided by an Alert generating system, such as Alert scenario or Sub scenario. Then, in the Enrich data Step, additional data is automatically sourced from both external and internal systems. AIM uses a combination of the Subject Profile and data retrieved from the system of record to display the full set of customer data.

Effective and efficient investigations rely on the relationships between data being established and maintained. Indexes are generated for key data within, or related to, the Alert, to form the Data Link Analysis network (DLA) in the Index data Step. These indexes are refreshed across the life cycle of the Alert Intake and Investigation Cases. Data to be indexed varies across use cases. Examples include customers, accounts, transactions, checks, and cards. DLA is used for discovery purposes.

The Resolve duplicates Step is a placeholder Step that is intended to contain additional logic to identify and flag duplicate Alerts. The last Step, Prioritize alert, executes business rules to derive the priority of the Alert based on the Alerts score and Alert type. This priority is used in calculating the urgency of the Investigation Case.

Process stage

The Discard false positives Step is a placeholder Step that is intended to include appropriate types of AI models or specific business rules that can be used to accurately identify and automatically dismiss false positive Alerts.

As investigations are conducted, the stream of Alerts will continue. Creating a new Investigation Case for each Alert is inefficient and increases the risk of lost insights that could be attained from new Alerts that are related to an ongoing investigation. The following brief overview lists the high-level logic that is used in the Assign to investigation Step to identify an inflight Investigation Case into which to merge an Alert:

1. The DLA network is queried using the Alert Intake Case ID to return a list of in-flight Investigation Cases.
2. Any cases that have a status of Pending-Triage or Pending-Investigation are retained, and the rest are removed from the list.
3. Any cases for which the entities match those of the Alert are retained and the rest are removed from the list.
4. The list of Investigation Cases is sorted based on the highest interest value.
5. The Alert is merged into the first Investigation Case from the list.

Wrap up stage

The Provide feedback Step is a placeholder Step that is used to automatically generate and submit feedback about the Alert to the source system. Knowing whether the Alert was confirmed or dismissed during the Investigation Process is useful training data for the Alert generation model.

The Alert Intake Case is designed to be fully automated to allow Straight Through Processing (STP). The Perform Quality Assurance placeholder Step allows for the creation of a manual Quality Assurance process in which a user can review the decisions made for an Alert.

Preprocessing

The Enrich data Step is a placeholder Step. Most of the data required to perform the investigation will already be available based on the Alerts and enrichment carried out during their corresponding intake Processes. The Index data Step adds the relationship between the Alert and the investigation to the Data Link Analysis network for use in investigations.

Faced with a high numbers of investigations, Financial Institutions will want to utilize their investigator resources as efficiently as possible, all while meeting business goals and compliance restrictions. The priority that is calculated in the Prioritize investigation Step will mainly drive the urgency of the investigation Case, while the complexity will be used for routing to the appropriate skill level or work queue (for example, Level 1, Level 2, Level 3). Additional data can be used as part of this process to meet the Financial Institution’s need.

Under set circumstances the Financial Institution may want to initially run certain actions before the core investigation tasks are completed, to reduce the impact of the potential suspicious activity.  The Execute preventative actions placeholder Step is intended for running such preventative actions, based on the required business logic.

Triage

Investigations conducted by Financial Institutions range in complexity and regulatory reporting needs. For example, a Currency Transaction Report (CTR) must be filed with the US regulator FinCEN for all currency transactions over $10,000. CTRs may be triggered frequently for certain segments of customers and represent a burden with manual review each time. It is therefore possible for the outcomes and resulting actions of that investigation to be determined automatically, without the need for manual triage or investigation.​ The Automatic disposition placeholder Step contains business logic and AI models to automatically determine the conclusion of the investigation and proceed directly to the Post-investigation actions Stage.​

Investigators must be able to efficiently triage Alerts in an investigation and determine the next steps, such as escalating or finalizing the investigation outcome. To make these determinations quickly, Investigators must be able to access the appropriate data without losing context. In the Triage Alerts Step, a Level 1 investigator is presented with a list of Alerts with summary data to triage. Details of each Alert are also accessible.

The work of investigators is complicated and involves making subjective decisions with outcomes that can materially impact the Financial Institution. For this reason, the necessary checks and balances must be in place throughout the process. The risk is especially high when staff members are new to their role. The Perform Quality Control placeholder Step contains logic to divert a subset of investigations to a member of staff or team that can review the Alert triaging activities. The overall Investigation is halted until the review is complete and any required feedback is addressed.​

Investigate

Pega applications offer a wide array of ways to align work with investigators, both automated and manual. These include, but are not limited to, skills, workload, SLAs, and availability. The Accept investigation Step is required when more senior investigators are manually picking their own work. The Investigator confirms ownership of the Investigation Case and prevents other investigators from trying to also work on it.

In the Perform investigation Step, following triage activities, an Investigator must conduct a sufficient level of research to be able to determine if suspicious activity has taken place.

After the investigation work has been carried out, a conclusion must be made in the Finalize investigation Step, and a set of follow-up actions must be determined. An additional work area is displayed for review of the finalization conclusion. The investigator is presented with the investigation data to finalize and review. ​If a Suspicious Activity Report must be filed, then the investigator has the option to review a basic representation of that report before submitting their conclusion.​ The Money Laundering Reporting Officer (MLRO), or their manager, or an equivalent individual will review the overall investigation and either accept or reject it.

Action

The Execute actions Step runs follow-up actions from an investigation, such as a Suspicious Activity Report.

Wrap up

The Provide feedback placeholder Step is used to automatically generate and submit feedback about Alerts contained within the Investigation Case to the source system, based on the required API interface of said system. ​

The Perform Quality Assurance placeholder Step allows for the creation of a manual Quality Assurance activity where a user can review any decisions made for the overall investigation. The resulting review would be used to improve this end-to-end investigation Process.​

The last Step, Wrap up, contains automated finalization activities of the Investigation Case. For example, updating Alert tracking mechanisms, updating status and synchronization of Data Link Analysis network.​

Review SAR

When the MLRO requests an update to the SAR narrative, a member of the FI's SAR filing committee can make these changes.

Generate SAR

Every SAR must follow a specific format to be accepted by the local regulator when filed. In this step, an XML file is automatically generated in the GoAML format using data from the Investigation Case. The underlying infrastructure of the data mapping and file format can be extended to other formats.

GoAML is a United Nations Office of Drugs and Crime standard, which is actively used by 65 countries for filing to local regulators

MLRO Approval

This Step presents the MLRO with all the key investigation information in a single View, to enable them to accept, reject or request a Case narrative update before proceeding with filing of the Suspicious Activity Report.

File SAR

This Stage is a placeholder for the actual filing of the SAR file to the local regulator. Standard Pega application functionality that can be used to achieve this task includes (but is not limited to), a Call to a service, Secure FTP, or secure email.

Check your knowledge with the following interaction:

This Topic is available in the following Module:

• Alert and Investigation Management accelerator v1