Spotlight on ‘Velocities’ in Dynamics 365 Fraud Protection
We are excited to bring you our latest weekly spotlight series edition. This week, we are focusing on the frequently asked questions about ‘Velocities’ in DFP. Check out all the Q&A details below. Your input is invaluable, so please feel free to reply with any questions or for more information in the Fraud Protection Tech Community. Best regards, DFP Product Team 1. What are velocities in Microsoft Dynamics 365 Fraud Protection? While Lists, ML scores, and other payload attributes give you insight into the current event that is being processed, we also have velocities that will help you consider past behavior as well. Velocities give insights into historical patterns of an individual or entity. It helps answer questions like 'how many attempted transactions coming from the same emails? Or how many unique users or IP addresses? Or how many login attempts happened in a certain amount of time such as 5 or 10 minutes? Perhaps, I want to block anyone who tries to login into the web site more than 3 times in under ten minutes then I can do that. Velocities help identify patterns of events that occur over a period of time, which can be monitored to identify potentially fraudulent activity. By defining velocities, you can set thresholds to flag activities as suspicious when they exceed certain limits. References: Perform velocity checks - Dynamics 365 Fraud Protection | Microsoft Learn 2. How would someone use velocities in fraud protection? Velocities can be used in various ways, such as: Setting Rules: Define rules using velocities to automatically flag transactions that exceed predefined thresholds. Monitoring Patterns: Keep an eye on the frequency and volume of events associated with user accounts, payment instruments, or IP addresses. Investigating Anomalies: Use velocity data to investigate and understand unusual patterns that could indicate fraudulent behavior. References: Perform velocity checks - Dynamics 365 Fraud Protection | Microsoft Learn 3. Can you provide examples of velocities? Yes, here are a few examples: Total Spending Per User: This velocity tracks the sum of money spent by each user over a specified time frame. IP Address Usage: This velocity monitors the number of times an IP address is used to create new accounts. Device ID Checks: This velocity observes how often a particular device ID is used in transactions. References: Perform velocity checks - Dynamics 365 Fraud Protection | Microsoft Learn 4. Are there any system-defined velocities? Yes, Dynamics 365 Fraud Protection creates several system-defined velocities per environment, such as email, payment instrument, IP, and device ID velocities. These can be customized to fit the specific needs of your business. References: Perform velocity checks - Dynamics 365 Fraud Protection | Microsoft Learn 5. Why isn't my velocity rule being hit by some transactions even though the conditions are met? Microsoft D365 Fraud Protection is a distributed system. In a distributed system, events can happen concurrently and there is no sequence/order between them if they arrive at the same time. (For transactions that come in at the same time, DFP does not block one transaction for the other.) From a velocity standpoint, which would mean that multiple transactions sent at the same time can be considered the “first one” and in these cases can influence the aggregate count of the velocity. One potential way to mitigate this on the customer side would be for you to sequentially execute your transactions one by one (i.e., only send the next transaction after the previous one is done being processed), however this may not be a desired behavior as it would result in longer latencies for those transactions that get executed later. References: Perform velocity checks - Dynamics 365 Fraud Protection | Microsoft Learn 6. Do you recommend using device ID to set up a velocity rule? In Microsoft Dynamics 365 Fraud Protection, setting up velocity rules using device ID can be an effective method to identify suspicious activity patterns. For instance, velocity checks can help you spot patterns such as a single credit card quickly placing many orders from a single IP address or device, which might indicate potential fraud. You can define velocities using the SELECT, FROM, WHEN, and GROUPBY keywords, and device ID can be a useful attribute to GROUPBY in your velocity definition. It is important to tailor the velocity rules to the specific patterns and behaviors that are indicative of fraud in your business context. The device ID can be a valuable attribute to monitoring, especially if device-related fraud is a concern for your organization. Always ensure that the field you want to observe for velocity is part of the API call and consider the specific conditions and thresholds that are relevant to your business when defining these rules. References: Perform velocity checks - Dynamics 365 Fraud Protection Manage rules - Dynamics 365 Fraud Protection | Microsoft Learn 7. In the recommended rules, there are velocity-based rules. How did you set the threshold for those velocity-based rules? The threshold for velocity-based rules in Microsoft Dynamics 365 Fraud Protection is typically set based on historical data analysis and the specific fraud patterns observed within your organization. It involves identifying the normal transaction velocity for legitimate users and then setting thresholds that would flag transactions as suspicious when they exceed this normal velocity. It is important to continuously monitor and adjust these thresholds as fraud patterns evolve and as you gather more data on user behavior. Collaboration with your fraud management team and using machine learning models can also help in dynamically adjusting these thresholds to improve fraud detection accuracy. 8. Where can I find more information on setting up velocities? You can find detailed instructions and examples on the official Microsoft documentation site for Dynamics 365 Fraud Protection here: Perform velocity checks - Dynamics 365 Fraud Protection | Microsoft LearnCommonly 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.Microsoft D365 Fraud Protection - Tech Community Announcement
Dear Microsoft Dynamics 365 Fraud Protection Customers, We are excited to share with you that the Microsoft Tech Community Discussion Forum for Dynamics 365 Fraud Protection (DFP) customers is ready and available for you to explore. This collaborative space is designed for DFP customers to connect, ask questions, find answers quickly, and enhance their journey with other customers, partners, and the product team. Getting started is easy! Click this link to register and create a member profile: Home - Microsoft Community Hub To register for the tech community discussion forum, click the link above, and select “Register” in the middle of the home page, then follow the prompts to create a user profile and you’re ready to start engaging. 2.To start a new post, go to the Security, Compliance, and Identity discussion space and click ‘Start a New Discussion’: Security, Compliance, and Identity - Microsoft Community Hub. 3. Before posting a new discussion thread, make sure to select the label ‘Fraud Protection’ by scrolling to the bottom of ‘Choose a Label’ section. This helps others find your posts easily and stay notified about 'Fraud Protection' discussions. 4.To ‘Reply’ to a discussion, Use the ‘Fraud Protection’ label to search for DFP-related posts. To reply, simply use this link: Discussions with Label: Fraud Protection - Microsoft Community Hub We’re also excited to share that each week we'll spotlight a particular topic in the community called ‘Customer Handbook’ where we’ll share commonly asked questions and answers to help you get the most out of our product. Here are some of the DFP product topics we intend to cover in the coming weeks: rules, device fingerprinting, bot protection, scoring, reason codes, search, external calls, case management. We are thrilled to have you join us in the Tech Community and look forward to your active participation! If you have any questions, please reach out to us at: dfppmca@microsoft.com Thanks, The DFP Product GroupAdditional commonly asked Q&A related to Search in DFP continued
Hello everyone, We are excited to continue our weekly spotlight series with a focus on frequently asked questions about DFP's Search feature. To assist you in navigating and optimizing this feature, we've compiled a comprehensive Q&A that you can find below. If you need further clarification or have additional questions, feel free to reply here in the Fraud Protection forum. We value your feedback and are here to help. Kind regards, DFP Product Team 1. What is Search and how does it work? In Microsoft Dynamics 365 Fraud Protection, the search functionality allows fraud investigators and support agents to locate and investigate specific transactions and associated data. This capability is essential for quickly resolving customer issues, analyzing fraudulent activities, and taking appropriate action. How it works: Initiate Search: The user navigates to the appropriate section (e.g., Purchase) and enters the search criteria in the search field. View Results: The system returns a list of transactions that match the search criteria. Users can click on any transaction to view expanded details. Investigate and Take Action: Based on the detailed information provided, fraud investigators can determine the legitimacy of a transaction and decide on the appropriate course of action, such as unblocking a customer or flagging a transaction for further review. References: Search - Dynamics 365 Fraud Protection | Microsoft Learn 2. How can I enable Search? To enable the Search feature in Microsoft Dynamics 365 Fraud Protection, you need to have Product Admin role permissions. Here are the steps to enable Search: Sign in to the Dynamics 365 Fraud Protection portal with your Product Admin role credentials. Go to Settings and select the Search tab. Toggle the switch to On to provision search for your Fraud Protection tenant. Once enabled, you can use the search to find and review transactions and events in Fraud Protection. Please note that you cannot turn off the search feature after enabling it. References: Search - Dynamics 365 Fraud Protection | Microsoft Learn 3. Are null values supported in search? In Microsoft Dynamics 365 Fraud Protection, null values are supported in search. The Is null operator can be used to find records that aren't required on payloads and with an unknown value: 1) not on the payload or 2) with a null value. Example: Search for payloads where a user ID value isn't required on the payload and unknown. References: Search - Dynamics 365 Fraud Protection | Microsoft Learn 4. When I exported a CSV it changed all the numbers to scientific notations. Why did this happen & how do I fix it? The issue you're experiencing with numbers changing to scientific notation in a CSV file is a common occurrence when opening CSV files in Excel. This happens because Excel automatically formats numbers that are longer than a certain length (usually more than 10 digits) into scientific notation to save space in the cell. Here's how you can fix it: Open the CSV with a Text Editor: If you open the CSV file with a text editor like Notepad, you will see the full numbers without scientific notation. This confirms that the CSV file itself is correct. Format as Text in Excel: When opening the CSV in Excel, you can prevent numbers from being displayed in scientific notation by formatting the cells as text before importing the data. Here's how: Open Excel and go to the "Data" tab. Choose "From Text/CSV" to import your CSV file. In the import wizard, select the column with the numbers. Change the column's data format to "Text". Finish the import process. Text to Columns Wizard: Another method is to use the Text to Columns wizard in Excel: Open the CSV file in Excel. Select the column with the scientific notation. Go to the "Data" tab and select "Text to Columns". Choose "Delimited" and click "Next". Uncheck all delimiters and click "Next". Select "Text" as the column data format and finish the wizard. Prevent Automatic Formatting: To prevent Excel from automatically formatting large numbers in scientific notation, you can also add an apostrophe (') before the number in the CSV file. This forces Excel to treat the number as text. Please note that these steps are general guidelines and the exact process may vary depending on the version of Excel you are using. 5. How long is search data available for? In Microsoft Dynamics 365 Fraud Protection, you can search for events and transactions within a timeframe of up to the past 13 months. References: Search - Dynamics 365 Fraud Protection | Microsoft Learn 6. Is there a cost for search to be on? Is there a downside to search being on? There is no cost or downside to enabling search. Note: You can't turn search off after you enable it. 7. Exporting data to CSV for analysis: can it be accessed or pushed to PowerPivot or similar so a large volume of data can be analyzed? Once the search data has been exported and downloaded as a CSV, the user can choose how to analyze this data, including pushing it to our tools like PowerPivot. DFP also supports event tracing if the user desires to export data regularly. Once the data has been traced to the data store defined, the customer can analyze this data in any way they choose. References: Search - Dynamics 365 Fraud Protection | Microsoft Learn Event tracing - Dynamics 365 Fraud Protection | Microsoft Learn
User app registration - exploitable for BEC?
Hello. Recently dealt with a case of BEC. I'm not trained in forensics, but doing my best. Appears the hacker used an application called eM Client for their attack, getting access to a user's mailbox and hijacking a thread. I can see the login from two weeks ago (the incident was only noticed a couple days ago, however) - from a European country that SHOULD have been blocked by Conditional Access. Come to find out, the tenant conditional access was unassigned from everyone. We're not sure how - we re-enabled it, and audited changes, but the only change that appears was us re-enabling it. Which I thought indicates it was never configured right, except we've got a ticket documenting a change to Conditional Access a couple days after the hack that ALSO does not appear in the logs. So... it's likely it was changed, yet I have no record of that change (atleast, not through Entra > Monitoring > Auditing). If anyone knows any other ways of checking this, please advise - but I can't seem to even access our Diagnostic settings, the page tells me I need an Azure Active Directory subscription (I'm on Entra ID P1, which includes AAD.... this might be related to being global admin, and not Security Admin - we don't use that role in this relationship) ANYWAY, my amateur forensic skills have found that the attacker used an app called eM Client to get access. I'm not sure yet how they obtained the password, and got past MFA... But quick research shows this application (esp it's pro version) is known for use in BEC. The app was registered in Entra, and granted certain read permissions in Entra ID for shared mailboxes, presumably to find a decent thread to hijack. I'm not 100% sure yet there was any actual exploit done using this app, but it's popularity amongst hackers implies it does SOMETHING useful (i think remember that it authenticates using Exchange Web Services instead of Exchange Online, or something similar? Will update when I have the chance to check). We're in the process of improving our Secure Score, and this incident makes me think user's ability to register apps should be locked down. Checked Secure Score for this, and while there ARE recommendations around apps, disabling user app registration is NOT one of them. Just curious about people's thoughts. I just barely understand App Registration in Entra, but if this is a known attack vector, I would think disabling app registration would be a security recommendation?Spotlight on Device Fingerprinting in DFP
We're thrilled to bring you a weekly spotlight on various topics within our Microsoft Fraud Protection Tech Community. This week, we're diving into the fascinating world of Device Fingerprinting in Microsoft Dynamics 365 Fraud Protection (DFP). Ever wondered how Device Fingerprinting works and how it can benefit you? Check out our detailed Q&A below where we answer all your burning questions about this innovative feature. If you have any questions or need further clarification on this topic, don't hesitate to reply to this thread in the Fraud Protection Tech Community. Your feedback is incredibly valuable to us. Best regards, DFP Product Team ------------------ 1. Do I really need device fingerprinting? Why is it important? Device fingerprinting is an essential feature in Microsoft Dynamics 365 Fraud Protection. It collects information about a computing device during online actions, which includes hardware, browser, geographic information, and IP address. This data is crucial as it helps the Fraud Protection service to track and link events in the fraud network, identifying patterns of fraud. The device fingerprinting feature uses artificial intelligence (AI) and machine learning to probabilistically identify devices, which can significantly improve the model detection rate for businesses by reducing false negatives. As a result, less fraud is detected on approved transactions after the fact. It's important to note that while device fingerprinting has a high accuracy, it is probabilistic and not deterministic, meaning there is a possibility of false positives. However, the benefits it brings to fraud detection and prevention are significant and can help protect businesses from fraudulent activities. References: Overview of device fingerprinting - Dynamics 365 Fraud Protection | Microsoft Learn Set up device fingerprinting - Dynamics 365 Fraud Protection Web setup of device fingerprinting - Dynamics 365 Fraud Protection | Microsoft Learn Attributes in device fingerprinting - Dynamics 365 Fraud Protection | Microsoft Learn 2. We don't use Fingerprinting will DFP still work? Yes, Dynamics 365 Fraud Protection (DFP) will still function without device fingerprinting. However, its effectiveness in detecting fraud will be reduced. Device fingerprinting is a powerful feature that enhances the ability of DFP to identify and link events in the fraud network, thereby improving the detection of fraudulent patterns. Without it, DFP can still assess risk based on other factors, but the absence of device fingerprinting data means it likely won't be as accurate in identifying fraud. 3. How to do end to end device fingerprinting integration? Integrating end-to-end device fingerprinting in Microsoft Dynamics 365 Fraud Protection involves several steps to ensure that device data is accurately collected and assessed for fraud risk. Here's a high-level overview of the process: Set up DNS and Generate an SSL Certificate: Choose a subdomain under your root domain for device fingerprinting, such as fpt.yourcompany.com. Create a CNAME record that points to fpt.dfp.microsoft.com. Generate an SSL certificate for the subdomain and upload it to the Fraud Protection portal. Implement Device Fingerprinting: Your website or application must initiate device fingerprinting requests before a transaction is sent to Fraud Protection for risk evaluation. Modify the provided JavaScript code (see documentation) and insert it on the webpage or in the application where you want to collect device fingerprinting information. Enable Client-Side Integration: Ensure that the device fingerprinting script is correctly implemented and that the client-side integration is enabled to collect the necessary data. Test and Validate: After implementation, thoroughly test the device fingerprinting functionality to confirm that it is working as expected and that Fraud Protection is receiving the required data. Please follow the best practices and guidelines provided in the Microsoft documentation to ensure a successful integration. References: Overview of device fingerprinting - Dynamics 365 Fraud Protection | Microsoft Learn Web setup of device fingerprinting - Dynamics 365 Fraud Protection | Microsoft Learn Dynamics 365 Fraud Protection mobile SDK for iOS - Dynamics 365 Fraud Protection | Microsoft Learn Dynamics 365 Fraud Protection mobile SDK for Android - Dynamics 365 Fraud Protection | Microsoft Learn 4. What do I need to provide in order for Device Fingerprinting to work? To ensure Device Fingerprinting works effectively in Microsoft Dynamics 365 Fraud Protection, you need to provide the following: DNS Configuration and SSL Certificate: Select a subdomain under your root domain for device fingerprinting, such as fpt.yourcompany.com. Create a CNAME record that points to fpt.dfp.microsoft.com. Generate an SSL certificate for the subdomain and upload it to the Fraud Protection portal. Only .pfx files are supported, and if your certificate has a password, you'll need to enter it during the upload process. Device Fingerprinting Implementation: Your website or application must initiate device fingerprinting requests a few seconds before a transaction is sent to Fraud Protection for risk evaluation. This ensures that all necessary data is received for an accurate assessment. Modify the provided JavaScript code and insert it on the webpage or in the application where you want to collect device fingerprinting information. Client-Side Integration: Ensure that the device fingerprinting script is correctly implemented and that the client-side integration is enabled to collect the necessary data. Testing and Validation: After implementation, thoroughly test the device fingerprinting functionality to confirm that it is working as expected and that Fraud Protection is receiving the required data. Please follow the best practices and guidelines provided in the Microsoft documentation to ensure a successful integration. References: Web setup of device fingerprinting - Dynamics 365 Fraud Protection ... 5. Do we need to send IP address if we use Device Fingerprinting? In Microsoft Dynamics 365 Fraud Protection, the IP address is an optional field when using device fingerprinting. While it is not mandatory to send the IP address, providing it can enhance the accuracy of the fraud protection service. The IP address can be set in the deviceFingerprinting.ipAddress field for assessments, and it helps in identifying the geographic location and network information of the device, which can be valuable in fraud detection scenarios. References: Web setup of device fingerprinting - Dynamics 365 Fraud Protection ... 6. What is the difference btw 'device.ipaddress' and 'trueIp'? In Microsoft Dynamics 365 Fraud Protection, 'device.ipaddress' refers to the IP address that the merchant's website receives when a customer uses the site. This is typically the public IP address that the customer's device is using to access the internet. On the other hand, 'trueIp' is the actual IP address of the device as identified by device fingerprinting. It is used to assess the risk of fraud and is part of the device attributes collected during the fraud assessment process The 'trueIp' can be particularly useful in identifying fraud attempts because it can reveal if a customer is using a proxy or VPN to mask their actual IP address. This can be a red flag for fraudulent activity, as fraudsters often use such methods to hide their location and identity. 7. What is TrueIP? What is “IP address (via Merchant)”? Why is TrueIP blank, while “IP address (via Merchant)” is available? In Microsoft Dynamics 365 Fraud Protection, "TrueIP" refers to the actual IP address of the device identified by device fingerprinting, which is used to assess the risk of fraud. It is part of the device attributes collected during the fraud assessment process. The "IP address (via Merchant)" is the IP address that the merchant provides to Fraud Protection, which may be different from the TrueIP if, for example, the user is connected through a proxy or VPN. If "TrueIP" is blank, it could be due to several reasons such as the device fingerprinting data not being collected properly, the user using privacy features that prevent the collection of their true IP address, or simply that the TrueIP information was not available or not passed on at the time of the transaction. However, generally speaking, the true IP address is the one assigned to a device connected to the internet, while the IP address provided by the merchant could be the one they have on record for the transaction, which might be different due to the reasons mentioned above. References: View purchase protection schemas - Dynamics 365 Fraud Protection | Microsoft Learn 8. Any information collected beyond IP address? A detailed summary of what device fingerprinting attributes we attempt to collect for web, iOS, and Android can be found here: Attributes in device fingerprinting - Dynamics 365 Fraud Protection | Microsoft Learn 9. How do I renew the DFP Device Fingerprinting SSL Green ID certificate? Multiple steps: Obtain a renewed certificate. These can be provided by whichever team within your organization manages certificates. Typically, these are IT, Security or Engineering. The certificate should be a .pfx file. Upload your certificate. From the DFP Portal, select "Integration" and "Enable device fingerprinting". For the renewal process instructions and further details, please refer to the Microsoft Learn Page: Web setup of device fingerprinting - Dynamics 365 Fraud Protection | Microsoft Learn 10. Does device fingerprinting work for different browsers and operating systems? Yes, DFP Device Fingerprinting works for different types of web browsers and operating systems. Below is more information on support and how to integrate: Web setup of device fingerprinting - Dynamics 365 Fraud Protection | Microsoft Learn Dynamics 365 Fraud Protection mobile SDK for Android - Dynamics 365 Fraud Protection | Microsoft Learn Dynamics 365 Fraud Protection mobile SDK for iOS - Dynamics 365 Fraud Protection | Microsoft Learn Dynamics 365 Fraud Protection mobile SDK for React Native - Dynamics 365 Fraud Protection | Microsoft LearnFraud Protection Release Notes
Dear Microsoft DFP Customer, We are excited to share with you several new features/capabilities we have recently added this July to D365 Fraud Protection: Device anomalous attributes Assessment Reports Warm up calls in External Call New attributes for Purchase Protection Check references Updates to Agent Name field for Case Management All the product features above are available in your DFP environment today, and further details about each are below. If you have questions regarding any of the updates provided, please don’t hesitate to ask. Your feedback is extremely valuable to us, and we really appreciate your ongoing support and collaboration as we continue to improve the product! Best Regards, D365 Fraud Protection Team ----------- Device anomalous attributes We’ve added some additional attributes in the Device Fingerprinting Assessment template to help identify anomalous sessions. The new attributes help detect anomalies both within and across sessions. For cross session data, the sessions are grouped together using the cookie id. New attributes are listed below and their descriptions are available in our documentation. i. Screen resolution anomaly ii. Session anomaly iii. User agent browser anomaly iv. User agent language anomaly v. Time zone mismatch vi. OS mismatch vii. Session count viii. IP address history Note: These attributes are only available for Assessments created using Device Fingerprinting template. We’ve also added an additional device attribute function called Device.GetSpeedOfTravel(), which returns the maximum travel speed of a device in miles per hour. The maximum speed is determined by looking at the last five consecutive fingerprinting sessions, calculating the speed of the device from session to session, and returning the maximum. The device is identified over sessions using the cookie id. More details about this function can be found here. Assessment Reports Enhanced Assessment Reports & Updates: We're excited to announce that Virtual Fraud Analyst (VFA) reports are now available for our Assessment customers, allowing these customers to get valuable insights previously available only for Purchase Protection and Account Protection. Additionally, Assessment customers can now tailor the data filters to segment the data according to their needs, configure the observation events attributes to view distributions, and aggregate figures by selecting different amount attributes. Report Relocation & Renaming: Based on feedback, we've relocated these reports to the assessment level and renamed them for clarity and ease of use: i. Virtual fraud analyst is now Reporting ii. Summary is now Summary report iii. Rule analyst is now Rule report iv. Score analyst is now Score report v. Threat analyst is now Threat report Updates to Role permissions based on feedback: Manual Review Fraud Manager (for non-PSP customers): This role has been updated to include access to all the reports, ensuring comprehensive oversight Reporting (for PSP customers): This role has been updated to include access to both reports and monitoring dashboards Warm up calls in External Call If the traffic to your External call endpoint is too low, the connection can go cold and can increase the latency of response from the external service. To mitigate this, you can now choose to enable warm-up calls from the external call setup page. To enable warm-up calls, you will be required to provide a valid keep-alive URL. If you opt in to this functionality, whenever your traffic volume dips too low DFP will automatically make anonymous warmup calls to the keep-alive endpoint using GET method only. No parameters, configurations, or configurable headers can be used in warm-up calls. New attributes for Purchase Protection We are adding the following new fields to the Purchase Protection and Assessments schemas in this release: Attribute Name Schema Section Data Type daysSinceEmailFirstSeen user Int departureDistanceFromBillingAddress travelOverview Int latitude address Double longitude address Double phoneAddressMatchStatus paymentInstrumentList/paymentInstruments String These fields will be added to the Account Creation and Account Login schemas in an upcoming release. Check references We’ve made it easy to validate if a resource (such as velocity, external call, custom list, etc.) is being referenced elsewhere in DFP. With the new ‘Check references’ feature, you can quickly and efficiently do any of the following checks: If a custom list is referenced in decision rule, post decision action, velocity set, or function If a velocity set is referenced in decision rule, post decision action, or function If an external call is referenced in decision rule, post decision action, velocity set, or function If an external assessment is referenced in a decision rule, post decision action, velocity set, or function If a case management queue is referenced in a routing rule You can click the ellipsis and find ‘Check references’ Example: If a velocity is referenced in a rule, or functions, it will be shown in the pop up. Updates to Agent Name field for Case Management To comply with Privacy requirements, going forward, Fraud Protection would not store Friendly Name of Agents who make decisions on cases using Case Management. We would only store the user Id and the conversion to name would be done at run time using Microsoft Entra Active Directory. Searching for cases decisioned by a specific agent or reviewing Case Management reporting would still be possible, with a few changes in the user experience described below The filter attribute “Agent name” in Search has been renamed to “Agent name (deprecated)”. This attribute can be used to search for cases decisioned before July 29 th 2024 but it would be blank for cases decisioned after this date to comply with the Privacy requirement. Just as before, to search using this attribute, provide the full name of the agent in the value field (e.g. first filter in the screenshot below) A new filter attribute “Agent name (new)” has been added to Search to replace old field (Agent name). This new attribute can be used to search cases decisioned after July 29 th 2024. This filter also supports autosuggest so you need not type the full name, once you type a few characters of the desired agent name, autosuggest results should help you pick the right agent from a list of all users in the Microsoft Entra Active Directory matching the characters you typed. You can use an ‘Or’ query (see screenshot below) to search for cases that were decisioned before and after July 29, 2024 Note: After August 29, 2025, any data with “Agent name (deprecated)” field populated would have aged out because of the 13-month data retention policy for Fraud Protection Search. At that point, the “Agent name (deprecated)” filter would be removed to avoid confusion, as all the data in Search would be searchable via the new field. Case Management Report has been modified as well. The filter for “Agent name” now includes autosuggest experience. Just like before, multiple selections are allowed and you can easily include or exclude cases auto-decisioned by the System (due to queue timeout). TrevorRusherFraud Protection Tech Community Live!
Learn more about improving your lines of defense with the Fraud Protection team! We will talk about some of the new assets that our customers can leverage, see some updates on the engagement model (Community Discussion Space, other ways to engage, etc.) and our experts are available to answer any other questions you might have! So tune in and get your fraud juices flowing. Ask your questions down below and the on-camera Subject Matter Experts will do their best to answer during the live session after their presentation!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 LearnAdditional commonly asked Q&A related to ‘Device Fingerprinting’ in DFP continued
We're excited to keep our weekly spotlight series going on various topics within our Microsoft Fraud Protection Tech Community to help you maximize the benefits of Microsoft Dynamics 365 Fraud Protection (DFP). This week, we're continuing our focus on commonly asked questions about DFP 'Device Fingerprinting' 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 wishes, DFP Product Team ------------------ 1. Is device fingerprinting necessary? For DFP to provide the most accurate scores, device fingerprinting is highly recommended as it provides hundreds of device attributes. These critical attributes are used by DFP's machine learning to constantly improve the accuracy of your system. For more information, see the DFP Documentation site: Overview of device fingerprinting - Dynamics 365 Fraud Protection | Microsoft Learn 2. What is DFP Device Fingerprinting and how does it work? For a description of DFP Device Fingerprinting and how it works, please refer to the following DFP documentation: Overview of device fingerprinting - Dynamics 365 Fraud Protection | Microsoft Learn 3. What data is retained by DFP Device Fingerprinting and for how long? The data collected by the device fingerprinting feature is stored in a Microsoft designated data center closest to the location of the transaction source for up to 28 days. The data could also be stored along with the transaction that was sent against this profiling session in the customer’s selected geography, if the customer has opted in to storing data with DFP. (Note – for legacy Purchase assessment, data storage is not optional) 4. How can I tell if device fingerprinting has stopped for some reason? In Microsoft Dynamics 365 Fraud Protection, you can tell if device fingerprinting has stopped by monitoring the SSL certificate status and ensuring it is up to date. If the SSL certificate used for device fingerprinting is not renewed before its expiration date, device fingerprinting will stop collecting information. You should receive notifications regarding the SSL certificate for renewal status, as it is a critical component for the device fingerprinting service. Additionally, you can monitor the health and status of device fingerprinting through the Dynamics 365 Fraud Protection portal, which provides metrics that refresh near real-time. These monitors are designed to assist in detecting unusual transaction patterns or anomalies in observation events, such as fraud attacks and faulty rule releases. References: Overview of device fingerprinting - Dynamics 365 Fraud Protection | Microsoft Learn Web setup of device fingerprinting - Dynamics 365 Fraud Protection | Microsoft Learn Monitoring - Dynamics 365 Fraud Protection | Microsoft Learn 5. Outline the device profiling capabilities you support, if any. D365 Fraud Protection (DFP) supports probabilistic device identification, which involves returning an assigned device ID to the client along with device enrichment information. 6. What kind of device metadata can be gathered from the device being used? Data categories collected for web include: UserAgent information Canvas/WebGL data HTTP data Within and across session anomaly information IP, network, VPN and geo intelligence TCP Signature SSL/TLS Signature Client hints Javascript collected information like OS, processor, screen resolution, round trip time, etc. Data categories collected for iOS and Android include: Accelerometer and gyroscope data Location data Emulator and rooted information SIM card information Device specification data like advertising ID, screen size, total memory, screen refresh rate, build ID, etc. User preference data like is closed captioning enabled, is speak screen enabled, is haptic feedback enabled, etc. For a full list of attributes we collect across web, Android, and iOS, see Attributes in device fingerprinting - Dynamics 365 Fraud Protection | Microsoft Learn. 7. How is the metadata evaluated to identify anomalies and create sticky identifiers for device recognition? D365 Fraud Protection (DFP) enriches the attributes collected from the device and runs these attributes through an embedding model, creating a vector representation of a device that remains sticky over time. DFP then checks similarity to determine device ID assignment. With device vectors, we can consistently identify returning devices. 8. What kind of challenges (e.g., CAPTCHAs) are invoked if suspicious activity is detected? D365 Fraud Protection (DFP) doesn't provide challenge capabilities in the product, however, clients can invoke different kinds of challenges that suit their own business needs (CAPTCHA, RECAPTCHA or MFA, for example), through a “challenge” decision based on the bot score rules they configure in our rule engine. 9. What if clients are using a device fingerprinting of their own and they would like to complement with MS DFP, could they use both? Yes, they could use both services. The client can integrate with DFP and their other device fingerprinting and use the data from both on their end. 10. In the portal UX for classic PP, can attributes returned by device fingerprinting only be used in the "Post Risk Scoring" clause section? No, you can reference @"deviceAttributes.trueIp" (for example; gets returned from Device Fingerprinting) in both types of rule clauses – Prior to Scoring, Post Risk Scoring – as this is different than generating a risk score.
