Commonly asked Q&A related to ‘Rules’ in DFP
Hello Microsoft DFP Customers,
We’re excited to share some answers to commonly asked questions about D365 Fraud Protection (DFP)! Each week, we intend to spotlight a particular topic to help you maximize the benefit of our product and post the answers to questions here. This week, we’re diving into DFP ‘Rules’.
Should you have any questions regarding the commonly asked Q&A provided, please do not hesitate to reach out here in the Fraud Protection Tech Community. Your feedback is incredibly valuable to us, and we genuinely appreciate your ongoing collaboration.
Best regards,
DFP Product Team
——————
1. What are the different inputs that can be passed into rules?
In Microsoft Dynamics 365 Fraud Protection, you can create rules that utilize various inputs to convert an assessment into a decision, such as Approve, Reject, Review, or Challenge. The inputs for these rules can include:
Attributes sent in the API request for the assessment, including custom data which can be accessed with the @ operator. For example, @”user.userId”.
Scores generated from Fraud Protection’s artificial intelligence models, such as @”riskscore”.
Lists that you have uploaded to Fraud Protection. You can reference these lists in your rules after uploading them.
Velocities that you have defined in Fraud Protection to perform velocity checks.
External calls that you have created in Fraud Protection.
Functions that you have created within Fraud Protection.
References:
Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn
2. Why did a particular transaction not hit rule ‘X’?
There could be several reasons why a transaction did not trigger a specific rule (Rule X) in Microsoft Dynamics 365 Fraud Protection. Here are some common factors to consider:
Rule Configuration: Ensure that Rule X is correctly configured with the appropriate conditions and logic. If the conditions are not met, the rule will not trigger.
Rule Order: The order of rules matters. If Rule X is lower in the order and a previous rule has already made a decision on the transaction, Rule X may not be evaluated.
Rule Scope: Check if Rule X is scoped correctly to apply to the transaction in question. It might be limited to certain types of transactions or channels.
Data Availability: The necessary data to evaluate Rule X must be present in the transaction. If the required data is missing or incorrect, the rule may not trigger.
Rule Status: Verify that Rule X is active and not disabled or in ‘observe’ mode, which would prevent it from taking action on transactions.
For a specific transaction, you can review the Rule analyst reports and Summary report in Dynamics 365 Fraud Protection, which provide insights into the transaction volume, rule decision distributions, and the impact of rules that you’ve enabled [1][2]. These reports can help you understand why Rule X did not trigger for a particular transaction.
If you’re still unable to determine why Rule X did not hit, you may need to consult with your Dynamics 365 Fraud Protection support team or review the service logs for more detailed information. There might have been a recent update or an issue escalated that could be related to the rule’s behavior.
References:
[1] Rule analyst reports – Dynamics 365 Fraud Protection | Microsoft Learn
[2] Summary report – Dynamics 365 Fraud Protection | Microsoft Learn
3. Why do we need to set up rules if the score can help evaluate risk?
In Microsoft Dynamics 365 Fraud Protection, while the score generated by the AI model provides a valuable assessment of risk, setting up rules is crucial for several reasons:
Customization: Rules allow you to tailor the fraud protection system to your specific business needs and risk appetite. You can create rules that threshold the score to make decisions that suit your business, such as approving transactions below a certain score and challenging or rejecting those above it.
Complex Scenarios: Scores alone may not capture the complexity of certain fraud scenarios. Rules can incorporate additional parameters from the transaction payload, enabling you to detect business policy violations or emerging fraud patterns specific to your business.
Control: Rules give you control over the decision-making process. You can define what actions to take based on the score and other attributes, such as triggering MFA or reviewing transactions from certain geographies.
Adaptability: Fraud patterns evolve, and rules can be quickly adjusted to respond to new threats, whereas model retraining for scores might take longer.
Segmentation: You can segment your traffic and set custom score cutoffs for different segments, optimizing fraud control for various product lines or transaction types .
For a more detailed understanding of the role of rules in fraud protection, you can refer to the official documentation on Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn which provides comprehensive guidance on rule management within the system.
4. What rule can help catch more fraud based on past data?
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
How does inheritance work for rules?
5. How does inheritance work for rules?
In Microsoft Dynamics 365 Fraud Protection, rule inheritance works within a multi-environment hierarchy. If your Fraud Protection instance has multiple environments, you can manage rules in a specific environment using the environment switcher. Rules in the top-level parent environment are evaluated first. If the rule settings for the top-level parent environment are set to “Run all matching rules until a decision is made,” the rules in the second-level parent environment are evaluated next. This process continues unless the rule settings for an environment are set to “Run only the first matching rule,” or until all the rules for the parent environment and the current environment are evaluated [1].
However, it’s important to note that all resources, such as velocities, external calls, lists, and external assessments, are always local to an environment. Even in a hierarchy, resources defined in a parent environment are not inherited for use in rules in child environments. They are inherited for aggregation purposes but not for use in rules. For example, a velocity defined in a parent environment would increment based on transactions to a child environment, but if you wanted to reference that velocity in a rule, the rule would have to be in the same (parent) environment [2].
For functions, you can create them in any environment in the multi-hierarchy stack. When a function references resources available in the environment, the lower environments that invoke the function also inherit the resources that the function references
For a more detailed understanding of how inheritance works for rules in Microsoft Dynamics 365 Fraud Protection, you can refer to the official documentation on Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn
References
[1] Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn
[2] Functions – Dynamics 365 Fraud Protection | Microsoft Learn
6. How often should we revisit the rule and make adjustment?
In Microsoft Dynamics 365 Fraud Protection, it’s important to regularly revisit and adjust rules to ensure they remain effective against evolving fraud patterns. While there is no one-size-fits-all answer, here are some best practices:
Regular Review: Rules should be reviewed on a regular basis, such as monthly or quarterly, to ensure they align with current fraud trends and business strategies.
Performance Analysis: Utilize the Rule analyst reports to monitor the performance and impact of your rules. Adjustments may be necessary if you notice changes in fraud patterns or false positive rates.
After Major Events: Review and potentially adjust rules after major events such as product launches, holiday seasons, or known fraud attacks, as these can change the fraud landscape significantly.
Feedback Loop: Incorporate feedback from customer service and fraud investigation teams into your rule adjustments to address any new types of fraud they are encountering.
It’s also beneficial to stay informed about updates to Dynamics 365 Fraud Protection features and capabilities, as new functionalities may offer additional ways to enhance your rules and fraud protection strategies.
References:
Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn
7. How do I create a rule based on ASN attribute
To create a rule based on the ASN (Autonomous System Number) attribute in Microsoft Dynamics 365 Fraud Protection, you would typically use the ASN as part of the condition in a WHEN statement within the rule definition. Here’s a quick guide on how to do it:
Identify the ASN attribute: Determine the ASN attribute from the transaction data that you want to use in your rule. This could be part of the device information or network data.
Access the Rules Editor: Go to the Dynamics 365 Fraud Protection portal and navigate to the rules editor section.
Create a New Rule or Edit an Existing One: You can either create a new rule or edit an existing one to include the ASN attribute in the conditions.
Define the Rule: Use the RETURN and WHEN keywords to define your rule. The basic structure of a rule is as follows:
RETURN <decision> WHEN <condition>
For example, if you want to flag transactions from a specific ASN for review, your rule might look like this:
RETURN Review(“Suspicious ASN”) WHEN @”network.asn” == “12345”
Replace “12345” with the actual ASN you want to monitor.
Test the Rule: Before activating the rule, test it to ensure it works as expected and does not impact legitimate transactions.
Activate the Rule: Once you are satisfied with the rule’s performance, activate it to start using it for real-time transaction assessments.
You can also use the visual mode in the rules editor for an easier rule creation experience, where you can select attributes from a drop-down menu and add multiple filters to a clause.
For more detailed instructions and best practices on rule creation, you can refer to the official documentation on Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn.
8. How do I create a velocity-based rule?
Creating a velocity-based rule in Microsoft Dynamics 365 Fraud Protection involves defining velocities that monitor the frequency of events from a user or entity, which can indicate suspicious activity and potential fraud. Here’s a step-by-step guide on how to create a velocity-based rule:
Define a Velocity: Velocities are defined using the SELECT, FROM, WHEN, and GROUPBY keywords. Here’s the structure you would use:
SELECT <aggregation method> AS <velocity name>
FROM <event type>
WHEN <condition>
GROUPBY <attribute name>
For example, to define a velocity that counts the number of purchases from a specific IP address, you might use:
SELECT Count() AS numPurchases
FROM Purchase
WHEN @”device.ipAddress” == “192.168.1.1”
GROUPBY @”device.ipAddress”
Create a Velocity Set: In the Fraud Protection portal, navigate to the Velocities section and select ‘New velocity set’. Define your velocities within this set.
Publish the Velocity: After defining your velocity, you need to publish it so it can be used in rules.
Create a Rule Using the Velocity: Now that you have a defined velocity, you can create a rule that uses this velocity. In the rules editor, you would reference the velocity in a WHEN clause of a rule. For example:
RETURN Review(“High number of purchases”) WHEN numPurchases > 5
Test and Activate the Rule: Before activating the rule, test it to ensure it works as expected. Once you’re satisfied, activate the rule for it to take effect on real-time transaction assessments.
For more detailed instructions, you can refer to the official documentation on Perform velocity checks – Dynamics 365 Fraud Protection | Microsoft Learn.
9. How do I create an IP-based rule?
Creating an IP-based rule in Microsoft Dynamics 365 Fraud Protection involves using the IP address as a condition within the rule’s logic. Here’s a general guide on how to create an IP-based rule:
Access the Rules Editor: Navigate to the Dynamics 365 Fraud Protection portal and open the rules editor.
Define the Rule: Use the RETURN and WHEN keywords to define your rule. The basic structure of a rule is as follows:
RETURN <decision> WHEN <condition>
For an IP-based rule, your condition will involve the IP address attribute. For example:
RETURN Reject(“Suspicious IP”) WHEN @”device.ipAddress” == “192.168.1.1”
Replace “192.168.1.1” with the actual IP address you want to monitor.
Test the Rule: Before activating the rule, test it to ensure it correctly identifies transactions based on the IP address without impacting legitimate transactions.
Activate the Rule: Once you’re satisfied with the rule’s performance, activate it to start using it for real-time transaction assessments.
For more detailed instructions, you can refer to the official documentation on Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn.
10. Can you recommend the rule structure for MFA flow?
In Microsoft Dynamics 365 Fraud Protection, setting up a rule structure for Multi-Factor Authentication (MFA) flow would typically involve creating rules that trigger MFA challenges based on certain conditions. Here’s a recommended structure for such a rule:
Define the Condition: Identify the conditions under which you want to trigger MFA. This could be based on risk scores, user behavior, transaction details, or other attributes.
Create the Rule: Use the RETURN and WHEN keywords to define your rule. The basic structure of a rule is:
RETURN <decision> WHEN <condition>
For example, if you want to challenge a login attempt when the risk score is high, your rule might look like this:
RETURN Challenge(“MFA Required”) WHEN @”riskscore” > 800
Test the Rule: Before activating the rule, test it to ensure it correctly identifies scenarios for MFA without impacting legitimate users.
Activate the Rule: Once you’re satisfied with the rule’s performance, activate it to start using it for real-time assessments.
For more detailed instructions, you can refer to the official documentation on Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn.
Hello Microsoft DFP Customers,
We’re excited to share some answers to commonly asked questions about D365 Fraud Protection (DFP)! Each week, we intend to spotlight a particular topic to help you maximize the benefit of our product and post the answers to questions here. This week, we’re diving into DFP ‘Rules’.
Should you have any questions regarding the commonly asked Q&A provided, please do not hesitate to reach out here in the Fraud Protection Tech Community. Your feedback is incredibly valuable to us, and we genuinely appreciate your ongoing collaboration.
Best regards,
DFP Product Team
——————
1. What are the different inputs that can be passed into rules?
In Microsoft Dynamics 365 Fraud Protection, you can create rules that utilize various inputs to convert an assessment into a decision, such as Approve, Reject, Review, or Challenge. The inputs for these rules can include:
Attributes sent in the API request for the assessment, including custom data which can be accessed with the @ operator. For example, @”user.userId”.
Scores generated from Fraud Protection’s artificial intelligence models, such as @”riskscore”.
Lists that you have uploaded to Fraud Protection. You can reference these lists in your rules after uploading them.
Velocities that you have defined in Fraud Protection to perform velocity checks.
External calls that you have created in Fraud Protection.
Functions that you have created within Fraud Protection.
References:
Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn
2. Why did a particular transaction not hit rule ‘X’?
There could be several reasons why a transaction did not trigger a specific rule (Rule X) in Microsoft Dynamics 365 Fraud Protection. Here are some common factors to consider:
Rule Configuration: Ensure that Rule X is correctly configured with the appropriate conditions and logic. If the conditions are not met, the rule will not trigger.
Rule Order: The order of rules matters. If Rule X is lower in the order and a previous rule has already made a decision on the transaction, Rule X may not be evaluated.
Rule Scope: Check if Rule X is scoped correctly to apply to the transaction in question. It might be limited to certain types of transactions or channels.
Data Availability: The necessary data to evaluate Rule X must be present in the transaction. If the required data is missing or incorrect, the rule may not trigger.
Rule Status: Verify that Rule X is active and not disabled or in ‘observe’ mode, which would prevent it from taking action on transactions.
For a specific transaction, you can review the Rule analyst reports and Summary report in Dynamics 365 Fraud Protection, which provide insights into the transaction volume, rule decision distributions, and the impact of rules that you’ve enabled [1][2]. These reports can help you understand why Rule X did not trigger for a particular transaction.
If you’re still unable to determine why Rule X did not hit, you may need to consult with your Dynamics 365 Fraud Protection support team or review the service logs for more detailed information. There might have been a recent update or an issue escalated that could be related to the rule’s behavior.
References:
[1] Rule analyst reports – Dynamics 365 Fraud Protection | Microsoft Learn
[2] Summary report – Dynamics 365 Fraud Protection | Microsoft Learn
3. Why do we need to set up rules if the score can help evaluate risk?
In Microsoft Dynamics 365 Fraud Protection, while the score generated by the AI model provides a valuable assessment of risk, setting up rules is crucial for several reasons:
Customization: Rules allow you to tailor the fraud protection system to your specific business needs and risk appetite. You can create rules that threshold the score to make decisions that suit your business, such as approving transactions below a certain score and challenging or rejecting those above it.
Complex Scenarios: Scores alone may not capture the complexity of certain fraud scenarios. Rules can incorporate additional parameters from the transaction payload, enabling you to detect business policy violations or emerging fraud patterns specific to your business.
Control: Rules give you control over the decision-making process. You can define what actions to take based on the score and other attributes, such as triggering MFA or reviewing transactions from certain geographies.
Adaptability: Fraud patterns evolve, and rules can be quickly adjusted to respond to new threats, whereas model retraining for scores might take longer.
Segmentation: You can segment your traffic and set custom score cutoffs for different segments, optimizing fraud control for various product lines or transaction types .
For a more detailed understanding of the role of rules in fraud protection, you can refer to the official documentation on Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn which provides comprehensive guidance on rule management within the system.
4. What rule can help catch more fraud based on past data?
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
How does inheritance work for rules?
5. How does inheritance work for rules?
In Microsoft Dynamics 365 Fraud Protection, rule inheritance works within a multi-environment hierarchy. If your Fraud Protection instance has multiple environments, you can manage rules in a specific environment using the environment switcher. Rules in the top-level parent environment are evaluated first. If the rule settings for the top-level parent environment are set to “Run all matching rules until a decision is made,” the rules in the second-level parent environment are evaluated next. This process continues unless the rule settings for an environment are set to “Run only the first matching rule,” or until all the rules for the parent environment and the current environment are evaluated [1].
However, it’s important to note that all resources, such as velocities, external calls, lists, and external assessments, are always local to an environment. Even in a hierarchy, resources defined in a parent environment are not inherited for use in rules in child environments. They are inherited for aggregation purposes but not for use in rules. For example, a velocity defined in a parent environment would increment based on transactions to a child environment, but if you wanted to reference that velocity in a rule, the rule would have to be in the same (parent) environment [2].
For functions, you can create them in any environment in the multi-hierarchy stack. When a function references resources available in the environment, the lower environments that invoke the function also inherit the resources that the function references
For a more detailed understanding of how inheritance works for rules in Microsoft Dynamics 365 Fraud Protection, you can refer to the official documentation on Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn
References
[1] Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn
[2] Functions – Dynamics 365 Fraud Protection | Microsoft Learn
6. How often should we revisit the rule and make adjustment?
In Microsoft Dynamics 365 Fraud Protection, it’s important to regularly revisit and adjust rules to ensure they remain effective against evolving fraud patterns. While there is no one-size-fits-all answer, here are some best practices:
Regular Review: Rules should be reviewed on a regular basis, such as monthly or quarterly, to ensure they align with current fraud trends and business strategies.
Performance Analysis: Utilize the Rule analyst reports to monitor the performance and impact of your rules. Adjustments may be necessary if you notice changes in fraud patterns or false positive rates.
After Major Events: Review and potentially adjust rules after major events such as product launches, holiday seasons, or known fraud attacks, as these can change the fraud landscape significantly.
Feedback Loop: Incorporate feedback from customer service and fraud investigation teams into your rule adjustments to address any new types of fraud they are encountering.
It’s also beneficial to stay informed about updates to Dynamics 365 Fraud Protection features and capabilities, as new functionalities may offer additional ways to enhance your rules and fraud protection strategies.
References:
Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn
7. How do I create a rule based on ASN attribute
To create a rule based on the ASN (Autonomous System Number) attribute in Microsoft Dynamics 365 Fraud Protection, you would typically use the ASN as part of the condition in a WHEN statement within the rule definition. Here’s a quick guide on how to do it:
Identify the ASN attribute: Determine the ASN attribute from the transaction data that you want to use in your rule. This could be part of the device information or network data.
Access the Rules Editor: Go to the Dynamics 365 Fraud Protection portal and navigate to the rules editor section.
Create a New Rule or Edit an Existing One: You can either create a new rule or edit an existing one to include the ASN attribute in the conditions.
Define the Rule: Use the RETURN and WHEN keywords to define your rule. The basic structure of a rule is as follows:
RETURN <decision> WHEN <condition>
For example, if you want to flag transactions from a specific ASN for review, your rule might look like this:
RETURN Review(“Suspicious ASN”) WHEN @”network.asn” == “12345”
Replace “12345” with the actual ASN you want to monitor.
Test the Rule: Before activating the rule, test it to ensure it works as expected and does not impact legitimate transactions.
Activate the Rule: Once you are satisfied with the rule’s performance, activate it to start using it for real-time transaction assessments.
You can also use the visual mode in the rules editor for an easier rule creation experience, where you can select attributes from a drop-down menu and add multiple filters to a clause.
For more detailed instructions and best practices on rule creation, you can refer to the official documentation on Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn.
8. How do I create a velocity-based rule?
Creating a velocity-based rule in Microsoft Dynamics 365 Fraud Protection involves defining velocities that monitor the frequency of events from a user or entity, which can indicate suspicious activity and potential fraud. Here’s a step-by-step guide on how to create a velocity-based rule:
Define a Velocity: Velocities are defined using the SELECT, FROM, WHEN, and GROUPBY keywords. Here’s the structure you would use:
SELECT <aggregation method> AS <velocity name> FROM <event type> WHEN <condition> GROUPBY <attribute name>
For example, to define a velocity that counts the number of purchases from a specific IP address, you might use:
SELECT Count() AS numPurchases FROM Purchase WHEN @”device.ipAddress” == “192.168.1.1” GROUPBY @”device.ipAddress”
Create a Velocity Set: In the Fraud Protection portal, navigate to the Velocities section and select ‘New velocity set’. Define your velocities within this set.
Publish the Velocity: After defining your velocity, you need to publish it so it can be used in rules.
Create a Rule Using the Velocity: Now that you have a defined velocity, you can create a rule that uses this velocity. In the rules editor, you would reference the velocity in a WHEN clause of a rule. For example:
RETURN Review(“High number of purchases”) WHEN numPurchases > 5
Test and Activate the Rule: Before activating the rule, test it to ensure it works as expected. Once you’re satisfied, activate the rule for it to take effect on real-time transaction assessments.
For more detailed instructions, you can refer to the official documentation on Perform velocity checks – Dynamics 365 Fraud Protection | Microsoft Learn.
9. How do I create an IP-based rule?
Creating an IP-based rule in Microsoft Dynamics 365 Fraud Protection involves using the IP address as a condition within the rule’s logic. Here’s a general guide on how to create an IP-based rule:
Access the Rules Editor: Navigate to the Dynamics 365 Fraud Protection portal and open the rules editor.
Define the Rule: Use the RETURN and WHEN keywords to define your rule. The basic structure of a rule is as follows:
RETURN <decision> WHEN <condition>
For an IP-based rule, your condition will involve the IP address attribute. For example:
RETURN Reject(“Suspicious IP”) WHEN @”device.ipAddress” == “192.168.1.1”
Replace “192.168.1.1” with the actual IP address you want to monitor.
Test the Rule: Before activating the rule, test it to ensure it correctly identifies transactions based on the IP address without impacting legitimate transactions.
Activate the Rule: Once you’re satisfied with the rule’s performance, activate it to start using it for real-time transaction assessments.
For more detailed instructions, you can refer to the official documentation on Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn.
10. Can you recommend the rule structure for MFA flow?
In Microsoft Dynamics 365 Fraud Protection, setting up a rule structure for Multi-Factor Authentication (MFA) flow would typically involve creating rules that trigger MFA challenges based on certain conditions. Here’s a recommended structure for such a rule:
Define the Condition: Identify the conditions under which you want to trigger MFA. This could be based on risk scores, user behavior, transaction details, or other attributes.
Create the Rule: Use the RETURN and WHEN keywords to define your rule. The basic structure of a rule is:
RETURN <decision> WHEN <condition>
For example, if you want to challenge a login attempt when the risk score is high, your rule might look like this:
RETURN Challenge(“MFA Required”) WHEN @”riskscore” > 800
Test the Rule: Before activating the rule, test it to ensure it correctly identifies scenarios for MFA without impacting legitimate users.
Activate the Rule: Once you’re satisfied with the rule’s performance, activate it to start using it for real-time assessments.
For more detailed instructions, you can refer to the official documentation on Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn.
Read More
