Using cumulative values in fraud detection and prevention rules
In most cases, fraud detection and prevention rules require computation of cumulative values. This could be cumulative sums, averages, or other aggregated statistics based on historical data. Once you have your fraud detection system and cumulative value calculation in place, you can combine them by monitoring cumulative values for suspicious patterns. For instance, you might look for spikes in cumulative transaction amounts or unusual changes in cumulative user activity. When the cumulative values trigger certain predefined thresholds or patterns that indicate potential fraud, you can use your fraud detection system to investigate and respond to the issue.
Bulk processing and offline computation
In the previous article we covered the use case of AML processing where cumulative values were computed during the ETL process. One of the biggest advantages of cumulative computation done during the ETL process is that all further computation and rules evaluation can fanout towards different rules in parallel without a need to query and update data base records while doing the processing. That simplifies the architecture, and according to the single responsibility principle, allow rules builders to focus only on new rules definitions, otherwise special care need to be taken in order to assure the consistency and that database updates are not somehow impacting the order in which rules are executed.
Real-Time Monitoring
For real-time fraud detection, you can continuously update cumulative values as new data comes in. This allows you to detect and respond to potential fraud in near real-time. In that regard, you can use few different patterns of execution.
If you have only one rule to trigger, you can in the rule itself at very first step update the database records, compute statistical values for that user or transaction and make use of it in the rule together with a current value.
If you need to trigger multiple of rules, you can create a first rule that only deals with data updates and then launch other rules in parallel
The last and probably the best option is that you update database records prior to calling the rules set. That is often done at the moment the payment event is sent over the message bus. As one of the first thing you can handle in that event (typically using lambda function) is to update the database record (e.g. dynamoDB, PostgreSQL etc.) and then further do the routing and rules execution.
Komentar