Supporting functions for AIM

Receiving alerts is critical to AIM, which needs to manage alerts from different systems and modules to ensure continuous regulatory compliance. For this purpose, the AIM Accelerator includes the Event Driven Architecture component, which facilitates the implementation of event-driven processes. The component manages the reception of alerts and events from different sources and routes them to the appropriate applications and processes in charge of their resolution.

See EDA for the full documentation of the Event Driven Architecture component.

In AIM, application configurations are managed through a console that is accessed by clicking Configure > Financial Services > Event Management > Alert and Investigation Management (AIM) > Configuration-Supplemental for AIM. Configuration settings are organized on different tabs:

• Alert registry: The Alert registry tab shows all the alerts registered in the system for use by the AIM application. The alert registry provides information about the category of the alert, scenario, sub-scenario, payload class, and the type of Investigation Case that needs to be created for the alert.

• Investigation registry: The Investigation registry tab shows several types of Investigation Cases that the AIM application can create for different alerts received by the system.

• Action registry: During the finalization of the Investigation activity in AIM, Investigators can select post-investigation actions to be carried out. For example, generating a Suspicious Activity Report (SAR) to the local regulator. The Action registry tab shows a comprehensive list of all possible actions that can be taken within the Actions stage of the Investigation Case.

A Subject is an individual or organization that is included in an Investigation. The relationship the financial institution has with a Subject will impact the amount of data initially available. Subjects are categorized as follows:

• An active customer
• A known related party of a customer, such as a beneficial owner of an existing customer
• An external party, unknown to the financial institution

During the Alert Intake Case, Subjects are extracted directly from the available data in the Alert. Subjects can also be added during the automated Enrichment Step in this process.

AIM consolidates the relevant available information into a composite view that enables investigators to get as complete a picture as possible for each Subject involved in the Investigation.

The Data Link Analysis (DLA) module is an industry- and application-agnostic module that can be used to maintain link analysis structures and explore them in an efficient manner.

The module enables the creation of data structures, organized in a set of vertices that represent the data entities managed by the application, and a set of 'edges' that establish the relationships between those vertices. Example vertices could be a Subject, an Account, a Transaction, an Alert, or an Investigation. Example edges could be the link between a Subject involved in an Alert, or between a Transaction and its Account.

Main elements of the DLA module

The following section outlines the core elements of the DLA module:

• Vertex: A vertex represents one of the data objects managed by the application and can be anything of interest to the application. For example, a Subject, a Transaction, a Case, an address, or a date. A vertex will contain some descriptive information, as well as references to anything in the system that might provide additional information about it, for example, a customer identifier.
• Edge: An edge represents the relationship between two vertices. For example, Address A is the residential address of Subject C. The standard mode is unidirectional from one vertex to another, with an alternative bidirectional mode.
• Network: Different applications can manage their own set of vertices and edges. This set is called a network. Every vertex and edge in the system is associated to a given network. Exploration of data always takes place within the context of a given network. The data of different networks is segregated either logically (stored in the same table but marked with a certain network identifier), or physically (stored in different database tables). By default, the AIM application network is set as ‘AIM’ for all Vertices and is stored in a single table.
• Taxonomy: A taxonomy defines the different types of vertices, edges, attributes and related assets that can be used in each DLA network. For example, a network for Financial Crime can create a taxonomy to define vertex types such as Account, Transaction, and Card, and edge types such as Transaction recipient or Account holder. A different application might opt for a completely different taxonomy. Each DLA network should be associated to a given taxonomy.

During finalization of an investigation, the Investigator must review the full set of appropriate data, make a conclusion, and summarize the investigation. Assembling and formatting all this data is time consuming and difficult to enforce across departments. For this reason, AIM uses Pega GenAI™ to generate investigation reports and summaries to reduce time spent on this activity.

AIM carries out a comprehensive set of preparation steps to engineer the prompt that is sent to Pega GenAI to generate the investigation summary and reports. The steps that AIM follows are:

• Use predefined templates for generating the investigation summary and reports.
• Prepare the data objects, such as the Investigation, Alerts, Transactions, Accounts, and Subjects that need to be included in the summary and reports.
• Generate a new object with copies of all the data entities associated with the Investigation case. The object contains Personally Identifiable Information (PII) which if sent in this raw state could violate banking laws and end up being used for wider training models.
• Any of the PII data is therefore replaced with anonymized versions so that AIM can generate an object using all fake data entities.
• AIM connects through Pega GenAI and passes the data object with fake data entities as input.
• The response is de-anonymized by replacing the anonymized data with the original values. This response is then displayed on the user interface for the Investigator to review.