Quantexa TeamFinCrime Detection Pack 0.4 Release
We are excited to announce version 0.4 of our FinCrime Detection Pack is now available in Early Access. This release introduces new features that will increase flexibility, improve score coverage and optimise score configuration to better capture desired behaviours, characteristics and events.
This builds on the functionality released in version 0.3 of the FinCrime Detection Pack.
Feature Highlights:
- You can now apply score logic on a targeted subset of transactions to help you uncover more specific underlying patterns that might otherwise be overlooked.
- You can now configure transaction score parameters based on the segment a score subject belongs to. This allows you to account for differences and ensure that you are capturing the behaviours and events you’re interested in.
- You are now enabled to select from a range of appropriate Event Windows to ensure that a score is targeting the desired behaviour or event.
- Target new risks with additional Score Types
For full details of the release, including compatible Quantexa Platform versions and minor enhancements, please see the Quantexa Documentation site.
Target a subset of transactions with Transaction Filtering
What do we want to achieve?
Our score logic, when applied across all transactions, provides a holistic view of the behaviour, characteristic or event we aim to capture. However, we may also need to apply the same score logic on a targeted subset of transactions to help us uncover more specific underlying patterns that might otherwise be overlooked, thereby strengthening the decisions we make.
Previously, users would need to write custom code to target specific transactions with their scores, requiring Scala knowledge and incurring additional product maintenance costs. These limitations hindered our ability to efficiently and effectively analyse underlying behaviours, characteristics and events without the use of deployment-specific customisations.
Functionality Highlights
The Transaction Filter allows users to apply transaction level filters to any transaction score within the FinCrime Detection Pack.
- Each score configuration where a set of transaction filters are applied will be treated as a distinct score, which means that they can be managed independently.
- Any attributes available at the transaction level can be used to set transaction filters using QSL expressions.
Example
The example below shows the total value of transactions each month. At first glance, the total value suggests no change in behaviour. However, when we examine the underlying transactions, we observe a significant change in the value of cash deposits being made.
Users are now able to target this underlying behaviour using the Transaction Filter feature. The QSL expression in the video below creates an instance of the “Customer Rapid Monthly Increase In Value” score that targets increases in the value of cash deposits.
Benefits
- Increased flexibility and improved score coverage: Users are now enabled to apply transaction filters without writing custom Scala code or needing a new score to be prioritised and released.
- Easy to maintain and deploy new instances of existing scores.
- No Scala skills required.
Important Considerations
- Project teams will need to provide and maintain documentation for the transaction filters they’ve applied to the underlying score logic.
- Users require basic QSL knowledge to apply transaction filters.
Configure transaction score parameters based on the segment a score subject belongs to with Subject Level Segmentation
What is a segment?
A segment is a group of entities, such as individuals or businesses, who share common characteristics, such as interests, demographics, or behaviour.
What do we want to achieve?
Determining when and how transaction scores should be used in the decision-making process may differ depending on the segment a score subject belongs to. We need to account for these differences to improve efficiency and ensure we capture the behaviours and events we’re interested in.
Previously, there was no standard approach available within the FinCrime Detection Pack that allowed users to configure transaction score parameters based on the segment a score subject belongs to. The existing methods needed to be made available prior to a release, required additional ongoing product maintenance and at times necessitated users having sufficient Scala skills. These limitations hindered our ability to account for differences that are specific to the segment a score subject belongs to.
Functionality Highlights
Segmentation allows users to configure transaction score parameters based on the segment a score subject belongs to.
- Users can tune parameters (incl. severity) based on available segments.
- Users have the option to define all or a subset of segments from the available segmentation in their transaction data model.
Example
The example below shows the average monthly change in the value debited and credited to customers across different segments. We observe that large businesses have a much higher average compared to other segments. Suppose we want to set a threshold to only focus on large increases in funds being deposited. If we don’t consider segments when setting this threshold, we may overlook individuals or trigger false positives for large businesses.
Users are now able to configure score parameters based on the segments above using the Segments feature. The QSL expression in the video below creates an instance of the “Customer Rapid Monthly Increase In Value” score that can be configured based on the segments above.
Benefits
- Optimised score targeting: Users are now enabled to configure parameters based on a score subject’s segment without needing a new score or override method to be prioritised and released.
- Ability to account for differences that are specific to the segment a score subject belongs to.
- Easy to maintain and apply segmentation to existing scores.
- No Scala skills required.
Important Considerations
- Setting parameters based on segmentation is optional and not mandatory.
- Any attributes to be used for the segmentation of scores must be available in the transaction data source.
- This feature cannot be used to exclude segments from being scored. This functionality will be introduced in a future release.
- Time based parameters such as lookback period, observation period and event window are configured once and cannot be defined per segment.
Target your detection with Configurable Event Windows
What do we want to achieve?
The Event Window is a parameter that specifies the time period over which a targeted behaviour or event is to be observed. There are some scores which may require different Event Window settings based on the use case that the score is applied to and the behaviour or event that a score aims to identify.
Currently, the Event Window is fixed to monthly within the FinCrime Detection Pack. This fixed setting is not appropriate for all use cases and scores. We want to provide the option to select from a range of appropriate Event Windows to ensure that a score is targeting the desired behaviour or event.
Functionality
Depending on the selected score, a user can now choose between the following time periods to set the Event Window:
- 3 days
- Weekly
- Fortnightly
- Monthly
Example
“Customer With Rapid Movement Of Funds” is a score that is characterised by a large amount of funds moving through a customer’s accounts over a short interval. Both “3 days” and “Weekly” options could be used to identify this behaviour depending on the use case. Users can now select the option that best applies to their use case, or even target both time periods across different score instances.
Benefits
- Optimised score targeting: Users are now enabled to select from a range of appropriate Event Windows to ensure that a score is targeting the desired behaviour or event.
- Easy to maintain.
- No Scala skills required.
Target new risks with additional Score Types
We will be introducing 9 additional score types to the FinCrime Detection Pack which means that we will support 35 score types in the 0.4 release. These score types can be combined to create 76 distinct scores.
- Entity Linked To Entity With Listed Internal Risk Rating
- Entity With Specific Internal Risk Score
- Entity Linked To Entity With Listed Industry
- Entity With Listed Industry
- Relationship Structuring
- Customer Structuring
- Customer Rapid Movement Of Funds
- Transaction After Period Of Dormancy
- Relationship With Transaction Score Link
Additional Features
- Integration with QSL Graph Scripting
- Template expansions are provided for all of our supported scores.
- Multiple instances of the same score can now be grouped in configuration files for easy maintenance.
