Additional commonly asked Q&A related to ‘Rules’ in DFP continued
We’re excited to introduce a weekly spotlight on various topics within our Microsoft Fraud Protection Tech Community to help you maximize the benefits of Microsoft Dynamics Fraud Protection (DFP). This week, we’re continuing our focus on commonly asked questions about DFP ‘Rules’ which you can check out the Q&A details here:
If you have any questions, please feel free to reach out in the Fraud Protection Tech Community. Your feedback is incredibly valuable to us.
Best,
DFP Product Team
——————
1. How do we know the rule work as expected before going to production?
Before deploying rules to production in Microsoft Dynamics 365 Fraud Protection, it’s essential to test them thoroughly to ensure they work as expected. Here’s how you can validate your rules:
Utilize the sandbox (INT) environment for functional and integration testing. This allows for safe testing of new configurations, rules, and features without affecting the live production environment.
Test rules in the sandbox environment to validate their logic and outcomes. Keep in mind that the scores generated in the sandbox should not be assumed to have real meaning, as the models only see test traffic.
Consider using observe mode to see what is returned by the rules without making actual decisions.
The sandbox environment is for testing purposes. It is not scaled for high load and is not suitable for performance or stress testing.
You can manage rules in a specific environment of Dynamics 365 Fraud Protection without impacting the production environment. This includes creating branches on the Rules tab, where each branch represents a collection of rules. The default branch is the Production branch, which is executed whenever traffic is sent to an assessment.
For detailed guidance on rule testing and deployment, you can refer to the official documentation on Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn
2. Do you have ‘rule builder’ or equivalent capability to allow customer to define complex rules without vendor support?
Yes, Microsoft Dynamics 365 Fraud Protection includes a ‘rule builder’ capability that allows customers to define complex rules without vendor support. This feature is part of the rules management system within Dynamics 365 Fraud Protection and provides the flexibility to create custom rules based on various inputs such as attributes from the API request, scores from AI models, uploaded lists, defined velocities, external calls, and functions created within Fraud Protection.
The official Microsoft documentation describes the process of defining a rule using the RETURN and WHEN keywords, allowing for the creation of custom rules that can convert an assessment into a decision, such as Approve, Reject, Review, or Challenge. This system gives customers the ability to manage rules in specific environments using the environment switcher, and rules can be created and managed on the Rules tab for purchases, account creation, or account login.
References:
Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn
3. What’s MS DFP approach for reusing rules/velocity sets from either alternative Fraud Solutions or in-house Solutions?
DFP allows merchants to create their own rules based on the industry type. Rules and velocities can be cloned within the same assessment (AP, PP) to be reused and modified. If a merchant is using another fraud solution in addition to DFP, they can write equivalent rules using our Fraud Query Language (FQL).
4. How are Rules Clauses structured in Dynamics 365 Fraud Protection?
Clauses are structured using the RETURN and WHEN keywords, where RETURN specifies the decision and WHEN specifies the condition. Each rule must contain at least one clause, and each clause is assigned a unique name.
References:
Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn
5. Would a new rule affect transactions in an old/existing queue?
In Microsoft Dynamics 365 Fraud Protection, when you create a new rule, it typically applies to transactions going forward from the point of activation. Existing queues, which contain transactions that were processed before the new rule was implemented, would not be retroactively affected by this new rule. The new rule would only affect transactions that are processed after the rule has been activated and would not change the status of transactions that are already in an old or existing queue.
However, if you need to apply new rules to transactions in an existing queue, you may need to manually review those transactions or reprocess them under the new rule set, if such functionality is supported by the system. It’s important to note that manual intervention should be done carefully to avoid disrupting the customer experience or affecting the integrity of the transaction data.
For specific guidance on how new rules interact with existing queues and transactions, you can refer to the official documentation on Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn
6. Are rules case sensitive?
In Microsoft Dynamics 365 Fraud Protection, rule names must be unique and they are case-insensitive. This means that when you create or reference rule names, the system does not differentiate between uppercase and lowercase letters. However, it’s important to note that while rule names are case-insensitive, the string operations within the rules themselves may be case-sensitive by default and may require specific functions like .ToUpper() to ensure case-insensitive comparison
For example, if you have a rule named “CheckFraud” and you try to create another rule named “checkfraud,” the system will recognize them as the same due to the case-insensitivity of rule names. But when writing conditions within the rules, you might need to consider the case sensitivity of the attributes you are comparing.
For more detailed information on rule management and best practices, you can refer to the official Microsoft Dynamics 365 Fraud Protection documentation here: Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn.
7. Why is this challenge rule not working?
To troubleshoot why a challenge rule in Microsoft Dynamics 365 Fraud Protection is not working as expected, you can follow these steps:
Review the Rule Configuration: Ensure that the rule is correctly defined with the RETURN and WHEN keywords. The RETURN statement should specify Challenge as the action and it is only executed if the WHEN statement evaluates to True.
Check the Conditions: Verify that the conditions set in the WHEN statement are accurate and that they use the correct attributes from the API request for the assessment. These attributes can include custom data and should be accessed with the @ operator.
Examine the Rule Evaluations: Look into the ruleEvaluations section included in the assessment API response. This section provides a list of each rule and clause that was evaluated for a transaction, which can help identify where the rule might be failing.
Monitor the Rule Performance: Utilize the monitoring dashboards to check the rule challenged rate – the percentage of assessed transactions by count that were challenged. This can give insights into the rule’s performance and whether it is being triggered as expected. [1]
Consult the Documentation: Refer to the official Microsoft documentation on managing rules in Dynamics 365 Fraud Protection for a comprehensive guide on rule creation and management. [2]
References:
[1] Monitoring – Dynamics 365 Fraud Protection | Microsoft Learn
[2] Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn
8. Some transactions went through that by everything we can see should have been caught by a rule. What are the steps I should take to troubleshoot?
When transactions that should have been caught by a rule in Microsoft Dynamics 365 Fraud Protection slip through, it’s important to conduct a thorough investigation to understand why the rule did not trigger as expected. Here are the steps you can take to troubleshoot:
Review the Rule Configuration: Ensure that the rule is correctly set up with the appropriate conditions and actions. Check for any logical errors or misconfigurations that might have caused the rule to not trigger.
Check the Conditions: Verify that the conditions set in the WHEN statement are accurate and that they use the correct attributes from the API request for the assessment. These attributes can include custom data and should be accessed with the @ operator.
Examine the Transactions: Look at the details of the transactions that were not caught by the rule. Compare them against the rule’s criteria to see if there’s a mismatch or if the transactions have any common attributes that were not considered in the rule.
Check Rule Evaluations: In the assessment API response, there is a ruleEvaluations section that provides a list of each rule and clause that was evaluated for a transaction. This can help identify where the rule might be failing.
Monitor Rule Performance: Use the monitoring dashboards to check the rule’s performance metrics, such as the challenged rate, to gain insights into how often the rule is being triggered.
Review Integration: If you have integrated Dynamics 365 Fraud Protection with other systems, verify that the integration is functioning correctly and that data is being passed accurately between systems.
Consult the Documentation: Refer to the official Microsoft documentation on managing rules in Dynamics 365 Fraud Protection for a comprehensive guide on rule creation and management. [1]
References:
[1] Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn
9. Can you find out the common rules for the transactions that had the highest scores?
In Microsoft Dynamics 365 Fraud Protection, transactions with the highest risk scores are those that are most likely to be fraudulent. The common rules applied to these transactions are designed to identify and prevent high-risk activities. Here are some of the rules that are commonly used:
Threshold rules: These rules reject transactions that exceed a certain risk score. For example, transactions for gift cards might be rejected if the risk score is above 400.
Velocity rules: These rules identify and block rapid, repeated transactions from the same entity, which could indicate fraudulent behavior.
List checks: These rules compare transaction data against lists of known fraud indicators, such as device fingerprints or IP addresses.
Anomaly detection: These rules look for patterns of behavior that are unusual and deviate from the norm, which could indicate fraud.
For a more detailed understanding of the common rules applied to high-scoring transactions, you may want to review the “Score analyst reports” in the Dynamics 365 Fraud Protection portal, which can provide insights into the relationship between Fraud Protection scores and the rules that were executed. If you need further assistance or have specific questions you can also contact Microsoft support or your Microsoft authorized partner for additional assistance.
References:
Score analyst reports – Dynamics 365 Fraud Protection | Microsoft Learn
10. The Rule evaluation behavior is currently set to “Run only the first matching rule”, and we’re trying to get it set to “Run all matching rules until a decision is made”. This setting is set in the sandbox environment, but for some reason, we’re not able to set it in the prod environment. Can you help?
To change the Rule evaluation behavior in Microsoft Dynamics 365 Fraud Protection from “Run only the first matching rule” to “Run all matching rules until a decision is made,” you should be able to do so through the environment settings. However, if you’re encountering issues changing this setting in the production environment, here are some steps you can take:
Check User Permissions: Ensure that you have the necessary permissions to make changes to the production environment settings. You may need to have admin rights or specific roles assigned to your user account.
Review Environment Configuration: Make sure that the production environment is properly configured and that there are no locks or restrictions in place that might prevent changes to the rule evaluation behavior.
Consult Documentation: Refer to the official Microsoft documentation for Dynamics 365 Fraud Protection, which provides detailed instructions on managing rules and environment settings.
References:
Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn
We’re excited to introduce a weekly spotlight on various topics within our Microsoft Fraud Protection Tech Community to help you maximize the benefits of Microsoft Dynamics Fraud Protection (DFP). This week, we’re continuing our focus on commonly asked questions about DFP ‘Rules’ which you can check out the Q&A details here:
If you have any questions, please feel free to reach out in the Fraud Protection Tech Community. Your feedback is incredibly valuable to us.
Best,
DFP Product Team
——————
1. How do we know the rule work as expected before going to production?
Before deploying rules to production in Microsoft Dynamics 365 Fraud Protection, it’s essential to test them thoroughly to ensure they work as expected. Here’s how you can validate your rules:
Utilize the sandbox (INT) environment for functional and integration testing. This allows for safe testing of new configurations, rules, and features without affecting the live production environment.
Test rules in the sandbox environment to validate their logic and outcomes. Keep in mind that the scores generated in the sandbox should not be assumed to have real meaning, as the models only see test traffic.
Consider using observe mode to see what is returned by the rules without making actual decisions.
The sandbox environment is for testing purposes. It is not scaled for high load and is not suitable for performance or stress testing.
You can manage rules in a specific environment of Dynamics 365 Fraud Protection without impacting the production environment. This includes creating branches on the Rules tab, where each branch represents a collection of rules. The default branch is the Production branch, which is executed whenever traffic is sent to an assessment.
For detailed guidance on rule testing and deployment, you can refer to the official documentation on Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn
2. Do you have ‘rule builder’ or equivalent capability to allow customer to define complex rules without vendor support?
Yes, Microsoft Dynamics 365 Fraud Protection includes a ‘rule builder’ capability that allows customers to define complex rules without vendor support. This feature is part of the rules management system within Dynamics 365 Fraud Protection and provides the flexibility to create custom rules based on various inputs such as attributes from the API request, scores from AI models, uploaded lists, defined velocities, external calls, and functions created within Fraud Protection.
The official Microsoft documentation describes the process of defining a rule using the RETURN and WHEN keywords, allowing for the creation of custom rules that can convert an assessment into a decision, such as Approve, Reject, Review, or Challenge. This system gives customers the ability to manage rules in specific environments using the environment switcher, and rules can be created and managed on the Rules tab for purchases, account creation, or account login.
References:
Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn
3. What’s MS DFP approach for reusing rules/velocity sets from either alternative Fraud Solutions or in-house Solutions?
DFP allows merchants to create their own rules based on the industry type. Rules and velocities can be cloned within the same assessment (AP, PP) to be reused and modified. If a merchant is using another fraud solution in addition to DFP, they can write equivalent rules using our Fraud Query Language (FQL).
4. How are Rules Clauses structured in Dynamics 365 Fraud Protection?
Clauses are structured using the RETURN and WHEN keywords, where RETURN specifies the decision and WHEN specifies the condition. Each rule must contain at least one clause, and each clause is assigned a unique name.
References:
Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn
5. Would a new rule affect transactions in an old/existing queue?
In Microsoft Dynamics 365 Fraud Protection, when you create a new rule, it typically applies to transactions going forward from the point of activation. Existing queues, which contain transactions that were processed before the new rule was implemented, would not be retroactively affected by this new rule. The new rule would only affect transactions that are processed after the rule has been activated and would not change the status of transactions that are already in an old or existing queue.
However, if you need to apply new rules to transactions in an existing queue, you may need to manually review those transactions or reprocess them under the new rule set, if such functionality is supported by the system. It’s important to note that manual intervention should be done carefully to avoid disrupting the customer experience or affecting the integrity of the transaction data.
For specific guidance on how new rules interact with existing queues and transactions, you can refer to the official documentation on Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn
6. Are rules case sensitive?
In Microsoft Dynamics 365 Fraud Protection, rule names must be unique and they are case-insensitive. This means that when you create or reference rule names, the system does not differentiate between uppercase and lowercase letters. However, it’s important to note that while rule names are case-insensitive, the string operations within the rules themselves may be case-sensitive by default and may require specific functions like .ToUpper() to ensure case-insensitive comparison
For example, if you have a rule named “CheckFraud” and you try to create another rule named “checkfraud,” the system will recognize them as the same due to the case-insensitivity of rule names. But when writing conditions within the rules, you might need to consider the case sensitivity of the attributes you are comparing.
For more detailed information on rule management and best practices, you can refer to the official Microsoft Dynamics 365 Fraud Protection documentation here: Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn.
7. Why is this challenge rule not working?
To troubleshoot why a challenge rule in Microsoft Dynamics 365 Fraud Protection is not working as expected, you can follow these steps:
Review the Rule Configuration: Ensure that the rule is correctly defined with the RETURN and WHEN keywords. The RETURN statement should specify Challenge as the action and it is only executed if the WHEN statement evaluates to True.
Check the Conditions: Verify that the conditions set in the WHEN statement are accurate and that they use the correct attributes from the API request for the assessment. These attributes can include custom data and should be accessed with the @ operator.
Examine the Rule Evaluations: Look into the ruleEvaluations section included in the assessment API response. This section provides a list of each rule and clause that was evaluated for a transaction, which can help identify where the rule might be failing.
Monitor the Rule Performance: Utilize the monitoring dashboards to check the rule challenged rate – the percentage of assessed transactions by count that were challenged. This can give insights into the rule’s performance and whether it is being triggered as expected. [1]
Consult the Documentation: Refer to the official Microsoft documentation on managing rules in Dynamics 365 Fraud Protection for a comprehensive guide on rule creation and management. [2]
References:
[1] Monitoring – Dynamics 365 Fraud Protection | Microsoft Learn
[2] Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn
8. Some transactions went through that by everything we can see should have been caught by a rule. What are the steps I should take to troubleshoot?
When transactions that should have been caught by a rule in Microsoft Dynamics 365 Fraud Protection slip through, it’s important to conduct a thorough investigation to understand why the rule did not trigger as expected. Here are the steps you can take to troubleshoot:
Review the Rule Configuration: Ensure that the rule is correctly set up with the appropriate conditions and actions. Check for any logical errors or misconfigurations that might have caused the rule to not trigger.
Check the Conditions: Verify that the conditions set in the WHEN statement are accurate and that they use the correct attributes from the API request for the assessment. These attributes can include custom data and should be accessed with the @ operator.
Examine the Transactions: Look at the details of the transactions that were not caught by the rule. Compare them against the rule’s criteria to see if there’s a mismatch or if the transactions have any common attributes that were not considered in the rule.
Check Rule Evaluations: In the assessment API response, there is a ruleEvaluations section that provides a list of each rule and clause that was evaluated for a transaction. This can help identify where the rule might be failing.
Monitor Rule Performance: Use the monitoring dashboards to check the rule’s performance metrics, such as the challenged rate, to gain insights into how often the rule is being triggered.
Review Integration: If you have integrated Dynamics 365 Fraud Protection with other systems, verify that the integration is functioning correctly and that data is being passed accurately between systems.
Consult the Documentation: Refer to the official Microsoft documentation on managing rules in Dynamics 365 Fraud Protection for a comprehensive guide on rule creation and management. [1]
References:
[1] Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn
9. Can you find out the common rules for the transactions that had the highest scores?
In Microsoft Dynamics 365 Fraud Protection, transactions with the highest risk scores are those that are most likely to be fraudulent. The common rules applied to these transactions are designed to identify and prevent high-risk activities. Here are some of the rules that are commonly used:
Threshold rules: These rules reject transactions that exceed a certain risk score. For example, transactions for gift cards might be rejected if the risk score is above 400.
Velocity rules: These rules identify and block rapid, repeated transactions from the same entity, which could indicate fraudulent behavior.
List checks: These rules compare transaction data against lists of known fraud indicators, such as device fingerprints or IP addresses.
Anomaly detection: These rules look for patterns of behavior that are unusual and deviate from the norm, which could indicate fraud.
For a more detailed understanding of the common rules applied to high-scoring transactions, you may want to review the “Score analyst reports” in the Dynamics 365 Fraud Protection portal, which can provide insights into the relationship between Fraud Protection scores and the rules that were executed. If you need further assistance or have specific questions you can also contact Microsoft support or your Microsoft authorized partner for additional assistance.
References:
Score analyst reports – Dynamics 365 Fraud Protection | Microsoft Learn
10. The Rule evaluation behavior is currently set to “Run only the first matching rule”, and we’re trying to get it set to “Run all matching rules until a decision is made”. This setting is set in the sandbox environment, but for some reason, we’re not able to set it in the prod environment. Can you help?
To change the Rule evaluation behavior in Microsoft Dynamics 365 Fraud Protection from “Run only the first matching rule” to “Run all matching rules until a decision is made,” you should be able to do so through the environment settings. However, if you’re encountering issues changing this setting in the production environment, here are some steps you can take:
Check User Permissions: Ensure that you have the necessary permissions to make changes to the production environment settings. You may need to have admin rights or specific roles assigned to your user account.
Review Environment Configuration: Make sure that the production environment is properly configured and that there are no locks or restrictions in place that might prevent changes to the rule evaluation behavior.
Consult Documentation: Refer to the official Microsoft documentation for Dynamics 365 Fraud Protection, which provides detailed instructions on managing rules and environment settings.
References:
Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn
