The Event-driven Architecture component
Receiving alerts is critical to Alert and Investigation Management (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 (EDA) 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.
Note: For more information about the Event-driven Architecture component, click Event-driven Architecture.
In AIM, application configurations are managed through a console and organized on three different tabs: Alert registry, Investigation registry and Action registry.
The 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. The combination of fields in each entry allows for full control over mapping a wide range of Alerts to the appropriate Investigation Types.
The following table contains example of alerts, with scenario and subscenario:
| Scenario | Subscenario |
|---|---|
| Structuring | Multiple cash deposits under threshold |
| Large cash activity | Large cash deposits above threshold |
| High risk country | Transaction to high risk country |
| Sanctioned customer | Entity sanctioned by OFAC |
The 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.
The 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 or 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.
The following actions are examples of outcomes that an investigation conclusion could generate:
- Account closure: Terminate a specific product or service contracted between the financial institution and the client.
- Customer review: Conduct a full review of all due diligence, including related parties and documentation, for a customer.
- Enhanced due diligence: Perform enhanced due diligence for a client.
- Freezing of funds: Freeze funds within certain accounts of a client to prevent them from being moved within or outside the financial institution.
- OFAC Compliance report: Submit an appropriate report to OFAC to comply with US regulatory law.
- Suspicious Activity Report: Submit a report outlining the concluded suspicious activity to the appropriate local financial regulator, such as FinCEN in the US.
- Termination of business relationship: Terminate all products and services contracted between the financial institution and the client.
- Transaction monitoring: Carry out an extended set of specific transaction monitoring activities for the products and services of a client.
These actions can occur in Pega or other systems. It is worth noting that except for the Suspicious Activity Report (SAR), all other actions will generate dummy cases that auto-complete. The Suspicious Activity Report involves a case lifecycle during which a regulatory file is generated.
This Topic is available in the following Module:
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?