If you’ve used our Anti-Money Laundering solution over the years, you may have noticed that the concept of an alert, as well as the terminology surrounding an alert, has changed. In this post, I’d like to discuss what an alert represents in our AML solution on the Viya 4 platform and describe the important associated terminology, including how alerts are created.
At a high level, an alert is an event that is unusual and requires further attention from an analyst.
An analyst investigates two types of alerts in AML, transaction monitoring and watchlist monitoring. Transaction monitoring alerts are created when customer behavior indicates potential money laundering or terrorist financing, and watchlist monitoring alerts are generated if a potential match is detected between one of the financial institution’s customers and data provided from consolidated watchlist vendors. These alerts indicate potential sanctions targets.
Before I explain how these alerts are created, I need to define a couple more important concepts. First of which is a scenario.
Financial institutions must comply with anti-money laundering, or AML, regulations. To help financial institutions implement these regulations, SAS Anti-Money Laundering offers predefined scenarios, or rules.
These scenarios contain the logic to help financial institutions detect and report suspicious activity to be in compliance with AML laws and regulations. The scenarios that come out of the box can be used as guidelines, and custom scenarios can be created to meet your organization’s specific needs.
In SAS Anti-Money Laundering, these scenarios are run as part of a flow. A flow is the top-level container that consists of scenarios, the data sources to be evaluated by the scenarios for the behavior of interest, and can also include scorecards, which enable you to perform final processing using the events that are generated by the scenarios in the flow.
The alert generation process, or AGP, executes the flows in the system. A flow can consist of multiple scenarios. When the AGP runs, the system processes all of the logic contained in the scenarios.
Then the system includes all the scenario-fired events, by entity, in an alerting event.
Alerting events are then routed to the Visual Investigator alert service, where one alert is created per entity.
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
I just described how alerting events can be generated by executing flows within scenario administrator, but it’s important to mention that alerts can be generated by other methods. For example, alerting events can be generated by a third-party alerting system and ingested in the solution using an alert API. In addition, you can manually create an alert in the end user interface.
No matter what the method of creation, the alert service ultimately creates one alert per entity.
Regardless whether you’re an end user or an administrator, it’s important to understand the concept of an alert. To view more information about alerts and our SAS Anti-Money Laundering solution in general, please visit https://support.sas.com/en/software/sas-anti-money-laundering-support.html.
Find more articles from SAS Global Enablement and Learning here.
Registration is now open for SAS Innovate 2025 , our biggest and most exciting global event of the year! Join us in Orlando, FL, May 6-9.
Sign up by Dec. 31 to get the 2024 rate of just $495.
Register now!
Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning and boost your career prospects.