Salv Monitoring scenarios can be divided by the alerted entity type — Person or Transaction — and scenario type — Real-time, Post-event, and Periodic. Each part is tailored to address specific aspects of AML compliance by monitoring different types of data and activities.
Alerting entity
Person
Person Monitoring focuses on scenarios related to person data. The purpose is to ensure that any suspicious activities associated with individuals are quickly identified and addressed.
Examples:
Shared IP Address: Detecting multiple clients using the same IP address can indicate potential collusion or identity theft.
Risk Level Change: Monitoring for changes in a client's risk level can help in promptly addressing individuals who may pose a higher risk of money laundering.
Frequent Changes in Personal Information: Identifying clients who frequently change their personal information, which can indicate attempts to evade detection.
Transaction
Transaction Monitoring is concerned with the transactional behavior of clients. It aims to identify suspicious financial activities that might indicate money laundering or other financial crimes.
Examples:
Frequent Small Transactions: Identifying patterns of numerous small transactions that could be structured to avoid detection thresholds.
Inconsistent Transaction Patterns: Detecting significant deviations from a client's usual transactional behavior.
Rapid Movement of Funds: Identifying rapid movement of funds between accounts, which can indicate layering in money laundering schemes.
Monitoring Scenario Types: Real-time, Post-event, and Periodic
Scenarios at Salv can be categorised into three types based on their operational nature: Real-time, Post-event, and Periodic.
❗️ The Real-time and Post-event scenario types were previously known as ONLINE and OFFLINE respectively. Some documentation or system references might still use these old names. If you encounter the terms ONLINE or OFFLINE, please understand they correspond to Real-time and Post-event scenarios in the current terminology.
| Real-time | Post-event | Periodic |
Description | Real-time scenarios are designed for real-time monitoring. They provide immediate responses through the API, indicating any scenario hits as soon as data is checked. | Post-event scenarios are not executed in real-time. Instead, they are triggered when data is uploaded to the Salv platform, whether through batch uploads or API calls. | Periodic scenarios run at regular intervals defined by the user, rather than being triggered by new data uploads or updates. |
Use case | These are ideal when you need to take immediate action, such as suspending a customer or blocking a payment. | These scenarios are suitable when immediate suspension of a customer or payment is not necessary. | These scenarios are best when long-term data analysis is needed or when alerts are preferred to be received at specific intervals, such as daily. |
Technical note | Real-time scenarios require a separate monitoring check API call to be triggered. If the API call is not made, the real-time scenarios will not run. | Person as an alerting entity: Post-event scenarios are triggered when person data is added or updated.
Transaction as alerting entity: Post-vent scenarios are triggered only when new transactions are added. Updating existing transactions does not trigger these scenarios. | Periodic scenarios continuously monitor the data after each specified time interval, making them suitable for scenarios that require extensive data analysis over months. |
Considerations | Avoid using long time periods or inefficient query logic to ensure the system can provide real-time responses. | Alerts are generated within minutes of the data being added or updated, ensuring timely but not immediate responses. | Periodic scenarios are efficient for comprehensive monitoring without the need for real-time alerts. |