minFraud Release Notes

You can now use the /device/session_age input in minFraud custom rules. Session age can be used to detect patterns of device usage across multiple sessions to help determine risk. For example, short sessions may be a higher indicator of risk.

You can select the session age input as a parameter in custom rules by selecting minFraud inputs > Session age when defining a new condition for a custom rule.

• Learn more about setting custom rule conditions on our Knowledge Base.
• Learn more about session inputs on our Knowledge Base.

You can now use the /ip_address/traits/isp output in minFraud custom rules, with the following operators: matches, does not match, contains, does not contain.

Filtering transactions by ISP can be especially helpful if you notice certain ISPs are more likely to be associated with fraudulent behavior.

You can select the ISP output as a parameter in custom rules by selecting minFraud outputs > ISP when defining a new condition for a custom rule.

• Learn more about setting custom rule conditions on our Knowledge Base.

We are releasing a bug fix to our static IP scoring system today.

Previously we were returning higher static IP scores for cellular IPv6 addresses when the networks were actually more dynamic.

minFraud Insights and Factors customers will see the static IP score for cellular IPv6 addresses reduce. This should also result in improved risk scoring for these networks for all minFraud customers.

Learn more about static IP scores in minFraud on our Knowledge Base.

You can now use the /email/is_free output in minFraud custom rules. This output is available for transactions submitted through minFraud Insights and minFraud Factors when you pass the /email/address input as plaintext, or when you pass an MD5 hash of the /email/address and the plaintext /email/domain input.

Use of free email providers (e.g. Gmail, Yahoo, Outlook, etc.) by consumers is the norm, so filtering transactions on this data point is often useful only in business-to-business contexts where you expect transactions to be conducted using a business email domain.

You can select the free email output as a parameter in custom rules by selecting minFraud outputs > Is free email when defining a new condition for a custom rule.

• Learn more about setting custom rule conditions on our Knowledge Base.
• Learn more about free email detection on our Knowledge Base.
• Learn more about passing email inputs on our Knowledge Base.

You can now add up to 2000 emails to a stored list and use it within minFraud custom rules to automatically apply a disposition to all matching transactions. Previously, you would have to create a custom rule for each separate email address.

Learn more about stored lists on our Knowledge Base.

We have made some improvements to the IP risk score, and minFraud customers may see an average increase of 1.5% in their risk scores beginning Monday, October 2. These changes to risk scoring should improve the accuracy of risk scoring. This change will apply to the following data:

• Overall risk score (available in all current and Legacy minFraud services)
• IP risk score (available in minFraud Score, Insights, and Factors)
• Proxy score (available in our Legacy Proxy detection web service)

When using minFraud’s custom rules, you can now group and join up to 20 conditions. The previous limit was 4 conditions.

Learn more about custom rules on our Knowledge Base.

Effective September 1, 2023 we will be flagging more virtual payment cards from select digital banks in minFraud. In transactions where the IIN is submitted, the minFraud services will be able to accurately tag more payment cards as virtual. Virtual cards do not have a physical card associated with the card number. Customers may use virtual cards for added security, though they are also popular with resellers who use them to attempt to bypass order limits.

To benefit from increased virtual payment card detection, you must pass the IIN or BIN (credit_card/issuer_id_number) of the payment card:

• Learn more about the IIN input on our Knowledge Base.
• See the documentation for this input in the API schema on our Developer Portal.

Users of the minFraud Insights and Factors services will be able to see whether a submitted payment card is virtual using the credit_card/is_virtual output:

• Learn more about prepaid and virtual card detection on our Knowledge Base.
• See the documentation for this output in the API schema on our Developer Portal.

To improve our server infrastructure and allow for better performance and efficiency, MaxMind will begin enforcing our policies around our API and database download requests in March 2024. To help customers get ready for this change, we will have a planned, temporary enforcement of these policies on October 17, 2023.

What are the policies?

• MaxMind will only accept API and database download requests sent with the more secure HTTPS protocol.
• MaxMind will only accept API and database download requests that are sent to the appropriate hostname as documented in the integration instructions on our Developer Portal (see direct links below).

What do I need to do? To ensure that your MaxMind service is not interrupted, please ensure that you are using the correct hostname for your API requests, and that you are using HTTPS, prior to October 17, 2023. You can view the appropriate URIs for minFraud services on our Developer Portal using the links below:

• minFraud Score, Insights, and Factors web services
• minFraud Device Tracking
• minFraud Transaction Reporting
• Legacy minFraud web services
• Legacy Proxy Detection web service

Please note: This enforcement will also affect GeoIP API requests. If you are also a GeoIP user, see our GeoIP release note on this issue.

Within minFraud Interactive, the interface provided in your account portal for searching, filtering, reviewing, and submitting minFraud transactions, you can now click to filter on more transaction data.

From the log of your minFraud transactions you can click on a number of transaction inputs and immediately get a filtered log of your transactions with matching data. For example, if you have a transaction with a billing phone number of +1 123 555 7698, you could click on that transaction’s billing phone number and immediately see a list of all transactions submitted with the same billing phone number over the past four months.

You can click to filter on the following transaction inputs (newly filterable inputs with this release are marked with an asterisk):

• Device ID
• IP address
• Credit card - Issuer Identification Number (IIN)*
• Credit card - IIN + Last 4 digits*
• Email address or domain
• Shipping address*
• Billing phone number*

You can learn more about minFraud Interactive’s log of your transactions on our Knowledge Base.

Effective immediately, we will begin to retain data in minFraud Interactive for up to 5 months. Although this change is already in place, you will not notice the increased retention period until early August.

Previously, we retained data in minFraud Interactive for up to 4 months.

minFraud Interactive is the interface for searching, filtering, and viewing minFraud transactions through your account portal. Learn more about minFraud Interactive on our Knowledge Base.

On June 6, we announced that more networks would be mapped to London boroughs beginning on Friday, June 9.

This change has been delayed. It should be present in our products and services beginning on Friday, June 16.

In addition, for networks in the greater London area we will be returning the name of the town for city-level name data instead of the borough. The borough will be populated in the second level subdivision.

For example, a network that maps to the Walthamstow town will return Walthamstow for the city_name, and Walthamstow Forest for the second level subdivision.

When a network geolocates to London, we will often return the borough for the city, rather than returning London. Beginning this Friday, June 9, we will be mapping more networks to London boroughs.

This change will apply to all products and services with city-level geolocation data:

• GeoIP City database
• GeoIP City Plus web service
• GeoIP Insights web service
• GeoIP Enterprise database
• minFraud Insights web service
• minFraud Factors web service
• GeoLite City web service
• GeoLite City database

We have updated the minFraud Transactions interface in the account portal to allow users to search for and filter transactions by email domain.

Learn how to search and filter minFraud Transactions through the account portal on our Knowledge Base.

We are aware of an issue in which some minFraud Alerts were not being sent or were delayed.

We expect to restore full functionality to minFraud Alerts by the end of the day.

We have made a number of improvements to the user interface for minFraud Interactive, the interface used to view minFraud transactions through your account portal.

The functionality of the interface is not changed, but some of the features now appear in a different place on the screen, and the transaction information is now displayed differently.

Learn how to navigate the new interface on our Knowledge Base.

We have enabled velocity tracking on the account/user_id input for all minFraud customers.

If you send a user ID associated with your transactions, minFraud will now factor the velocity of the user’s transactions into the risk score.

The account/user_id input allows you to pass a unique identifier for each of your users so that the minFraud service can group transactions by user in order to identify fraud signals attached to specific users.

Learn more about the account/user_id input on our Developer Portal.

Learn more about velocity tracking on our Knowledge Base.

We have updated the format of our license keys. New license keys will be longer, with a six character prefix.

The new license keys can be used in all current versions of our Client APIs and in version 3.1.1 and higher of our GeoIP Update program.

No action is required for minFraud users. Existing license keys will still be valid and will continue to function normally.

New license keys will have the following changes:

• The character set is changing from [a-zA-Z0-9] to [a-zA-Z0-9_].
• The length of the license key will now be 40 characters.
• License keys will have a _mmk suffix.

Please note that the length of license keys may be increased in the future.

We’ve launched a new Sandbox Environment for technical validation and testing of your integration with our minFraud and GeoIP web services. The Sandbox environment is available for all paying MaxMind customers.

Learn more about the Sandbox environment on our Knowledge Base.

You can also read more about testing minFraud web services on the Sandbox.

We have made some changes to how we determine the registered country associated with an IP address. We estimate that this change will affect around 1% of IP addresses with a registered country value. The following databases and web services will be affected:

• GeoIP Country database
• GeoIP City database
• GeoIP Enterprise database
• GeoLite Country database
• GeoLite City database
• GeoIP Country web service
• GeoIP City Plus web service
• GeoIP Insights web service
• GeoLite Country web service
• GeoLite City web service
• minFraud Insights web service
• minFraud Factors web service

In some cases where we are no longer confident in the registered country for an IP, it will be removed. In other cases, the value may be changed.

You can learn more about the /registered_country output in the API schema for GeoIP web services.

You can learn more about the difference between registered country and the IP geolocation on our Knowledge Base.

The time zone name for Kyiv, Ukraine, which covers most of the country, has been updated.

Previously, the time zone was named Europe/Kiev. It has been updated to be named Europe/Kyiv following updated naming conventions from version 2022b of the IANA time zone database.

The following products and services will see the updated time zone name:

• GeoIP City database
• GeoIP Enterprise database
• GeoIP City Plus web service
• GeoIP Insights web service
• minFraud Insights
• minFraud Factors
• GeoLite City database
• GeoLite City web service

We have completed work to fix a geolocation bug affecting some IPv6 addresses. All databases and web services should now have the updated data.

See the Geolocation Coordinate Bug Fix release note for more information about this bug.

We are aware of a bug in which databases and web services have been returning geolocation location coordinates of 0,0 for IPv6 addresses which are geolocated only down to the country-level.

The following databases and web services are affected:

• GeoIP City database
• GeoIP Enterprise database
• GeoIP Legacy City web service
• GeoIP Legacy Omni/Insights web service
• GeoIP City Plus web service
• GeoIP Insights web service
• minFraud Insights web service
• minFraud Factors web service

We have a fix, and it will be released later today.

The updated GeoIP City database is now available for download.

Web service users will see the corrected data as soon as the fix has been implemented.

We apologize for any inconvenience this may have caused.

In line with the announcement on our blog from 2020, there will be several changes to the data in our GeoIP Legacy web services beginning today. The following web services are affected:

• minFraud Legacy Standard or Premium

The following data changes have been made:

1. Region codes: The legacy web services historically returned region codes in the FIPS 10-4 standard (for all countries except for the US and Canada). Now, region codes worldwide will be returned in the ISO 3166-2 standard.
2. Area codes: Area code fields will now return blank.
3. Country/Region/City names: Country, region, and city names will now come from GeoNames.
4. IPv6: The minFraud Legacy services will now provide GeoIP Location Check outputs for IPv6 addresses.

For more information, read the full announcement on our blog from 2020.

Please note that associated changes to the GeoIP Legacy web services are also being made.

The transaction review screen in your MaxMind account portal now has expanded options to filter your transactions. You may now filter transactions by:

• Account user ID: the user ID of the end-user who initiated the transaction
• Shop ID: used to identify the storefront or merchant associated with the transaction
• Credit card issuer ID: the issuer ID number (IIN), sometimes called a bank ID number (BIN) of the card used in the transaction
• Custom rule ID: the ID for the custom rule that was triggered for the transaction

You can learn more about how to filter and search transactions using your MaxMind account portal on our Knowledge Base.

We have updated the minFraud service to handle 8 digit credit card issuer ID numbers (IINs). These are non-breaking changes.

• The credit_card/issuer_id_number input can now receive 6 or 8 digits.
• The credit_card/last_4_digits input has been renamed credit_card/last_digits, and receives 2 or 4 of the last digits of the credit card.
  • The credit_card/last_4_digits input will continue to work as an alias for the new credit_card/last_digits input.
• In some cases with longer IINs we will truncate the credit_card/last_digits input so that we process only the data required for risk scoring. If we truncate the last digits, the minFraud service will return a warning message.
• If you send 8 digits for the credit_card/issuer_id_number, but we do not recognize an 8 digit IIN, we will truncate the input to 6 digits. If we truncate the IIN, the minFraud service will return a warning message.

Learn more about how to pass the correct number of digits for credit card inputs in our developer portal:

• credit_card/issuer_id_number
• credit_card/last_digits

You can read more about these changes in the announcement on our blog.

If you would like to learn more about how to properly handle credit card numbers, you can read more at pcisecuritystandards.org.

minFraud alerts now support signed requests for webhook delivery. You can now set a secret, which can be used to verify the authenticity of a minFraud alert delivered via webhook. See our minFraud Alert documentation for instructions.

We have renamed minFraud subscores to be “risk factor scores” to make it clearer that the scores returned in our minFraud Factors web service are actionable risk scores in their own right, similar to the IP risk score. You can learn more about all of minFraud’s risk scores on our knowledge base.

Nothing has changed about how to use our web services, and no changes are required to your current integration. Specifically, the JSON response for minFraud Factors queries will continue to return risk factor scores in the subscores object. Learn more about the subscores object.

Effective October 4, 2021, the minimum accuracy radius value will be 5km across our city/postal-level geolocation products and services. Previously, the minimum accuracy radius value was 1km. This change applies to the following products and services:

• GeoIP City database
• GeoLite City database
• GeoIP Enterprise database
• GeoIP City Plus web service
• GeoIP Insights web service
• minFraud Insights and Factors web services

We are making this change in order to ensure it is clear that IP geolocation should not be used to identify a particular street address or household.

We have updated our data in a number of ways in preparation for the rollout of iCloud Private Relay. We have worked with Apple to ensure that our data accurately reflects how Private Relay works and delivers the best possible user experience for your users.

• Geolocation data across our products and services now incorporate the IP geolocation feeds published by Apple, which provides coarse city or region geolocation mappings for iCloud Private Relay IPs.
• We identify iCloud Private Relay IPs in our ISP dataset (present in our minFraud Insights and Factors web services) by tagging ranges as iCloud Private Relay.

Apple has shared the following assurances built into Private Relay:

• Geolocation information for clients is validated by the relay servers using signed tokens, and visible to origins through the IP addresses selected by relay servers.
  • A user is not able to arbitrarily select their geolocation to evade geolocation controls.
• Access to relay servers is rate-limited using device attestation to reduce fraud.
• All traffic is secured using TLS 1.3.

You do not need to take any action to receive this data. It will be returned in the /traits/isp and /traits/organization outputs.

For more information about Private Relay along with helpful technical information, visit Prepare Your Network or Web Server for Private Relay on Apple’s developer website.

We will continue to monitor these IPs and make any adjustments that are needed in the future.

We have released a couple of new features for the minFraud Score, Insights, and Factors service.

• A new input, /credit_card/was_3d_secure_successful, which allows you to send us whether the outcome of 3-D Secure verification was successful. This can help us improve your risk scoring.
• A new output, /disposition/rule_label, which returns the label of the custom rule that affected a transaction.
• A new value for the /disposition/action output, “test”. This additional disposition action can be used to separate transactions for rules which you are interested in actively testing without affecting your existing workflows.

For more information, see our blog post.

Our client APIs have been updated to support these outputs so you may need to refresh yours if you are not interfacing directly with our REST API.

We updated warning codes for minFraud Score, Insights and Factors responses in the /warnings/ object.

• We added BILLING_REGION_NOT_FOUND and SHIPPING_REGION_NOT_FOUND codes
• We updated the warning explanations for certain warning codes to include that distance calculations (outlined below) may be impacted when certain location information is missing or cannot be found
  • /shipping_address/distance_to_ip_location
  • /shipping_address/distance_to_billing_address
  • /billing_address/distance_to_ip_location

See our developer documentation for the updated codes and warnings.

We recently made some updates to minFraud alerts, which notifies minFraud users about previously low-risk transactions that are now high-risk due to updated information. Learn more on our blog.

The client APIs for minFraud Score, Insights, and Factors now normalize emails prior to hashing them for improved risk scoring. Email normalization ensures that minor, inconsequential differences in the email input (i.e., jadoeisonline@yahoo.com and jadoeisonline-12345@yahoo.com) do not result in minFraud treating these as different email addresses.

Our client APIs for minFraud Score, Insights, and Factors have been updated to support email normalization so you may need to refresh yours in order to get automatic email normalization. If you interface directly with our REST API or use minFraud Legacy, we recommend that you normalize email addresses prior to hashing. Please see our developer’s site for guidance on how to normalize emails.

The ip_address/risk_reasons output is now available. minFraud Insights and minFraud Factors customers can now see reason codes associated with the IP risk score for high risk IP addresses. When the IP risk score is high, the field may be populated with one or more of the following reason codes:

• ANONYMOUS_IP – The IP address belongs to an anonymous network. See /ip_address/traits for more information.
• HIGH_RISK_DEVICE – A high risk device was seen on this IP address in your past transactions.
• HIGH_RISK_EMAIL – A high risk email address was seen on this IP address in your past transactions.
• BILLING_POSTAL_VELOCITY – Many different billing postal codes have been seen on this IP address in your past transactions.
• EMAIL_VELOCITY – Many different email addresses have been seen on this IP address in your past transactions.
• ISSUER_ID_NUMBER_VELOCITY – Many different issuer ID numbers have been seen on this IP address in your past transactions.
• MINFRAUD_NETWORK_ACTIVITY – Suspicious activity has been seen on this IP address across minFraud customers.

If the IP risk score is low, the risk_reasons field will be blank. Our client APIs have been updated to support this output so you may need to refresh yours in order to see the new output if you are not interfacing directly with our REST API.

On Monday, January 25 we will be updating MaxMind products and services with ISP data to consolidate naming conventions for Vodafone Germany. We will now return either Vodafone Germany Cable, Vodafone Germany DSL, Vodafone Germany Business, or Vodafone Germany. Previous values were Vodafone GmbH, Vodafone Germany, and Vodafone DSL. We are updating these values to more accurately reflect the type of connection that the IP address is associated with.

Effective January 5, 2021, the is_in_european_union flag will no longer be marked true for locations in the United Kingdom. This change will be reflected in the data in GeoLite databases and web services, GeoIP databases, GeoIP web services, and minFraud Insights and Factors services.

We have released an additional output for our web services. GeoIP Insights, minFraud Insights, and minFraud Factors customers can now see whether an IP address is likely a residential proxy:

• /traits/is_residential_proxy – This is true if the IP address is on a suspected anonymizing network and belongs to a residential ISP. Otherwise, the key is not included in the traits object.

Our client APIs have been updated to support these outputs so you may need to refresh yours if you are not interfacing directly with our REST API.

Effective October 12, 2020 we are making the IP address input optional for all minFraud Score, Insights, and Factors queries. If you use these minFraud services for transactions where the IP address is not relevant (e.g. a phone order placed through a call center), you no longer need to include an IP address with your request. Note that the more data you send (including IP addresses, when applicable), the better the scoring the minFraud service will provide. See the relevant FAQ on our Support Center for more information.

Effective October 12, 2020 we are making the IP address input optional for all minFraud Score, Insights, and Factors queries. If you use these minFraud services for transactions where the IP address is not relevant (e.g. a phone order placed through a call center), you no longer need to include an IP address with your request. Note that the more data you send (including IP addresses, when applicable), the better the scoring the minFraud service will provide. See the relevant FAQ on our Support Center for more information.