minFraud Release Notes

Today, on September 11, 2026, between approximately 03:57 and 07:00 UTC, some requests to our minFraud and GeoIP web services saw elevated response times. The impact was greatest between about 04:15 and 04:50 UTC, when affected requests could take several seconds to complete.

This was limited to traffic routed through one network path into our US-East data center. Requests served from other regions and paths were not affected. Affected requests completed with correct responses. We saw elevated latency rather than failures.

Our investigation found packet loss on the network path between our edge network provider’s Ashburn point of presence and our US-East data center. Lost packets were retransmitted, which added delay. Our servers, databases, and application code were healthy throughout, and no change on our side triggered the event.

We are working with our network providers to identify the source of the loss and to prevent a recurrence. We are also improving monitoring of this kind of network degradation.

If you have questions about specific requests, please send the request times to our support team and we will review.

We have added a residential sub-object to the anonymizer object returned in the ip_address object for minFraud Insights and Factors, providing data about residential proxy networks:

The residential object may be present even when none of the other anonymizer fields are populated.

This change will be reflected in the following products and services:

• minFraud Insights
• minFraud Factors
• GeoIP Insights web service

The minFraud Legacy and Proxy Detection web services now return meaningful HTTP status codes for error conditions, so you can act on them in your monitoring or an internal proxy, without parsing the response body:

• 400 Bad Request for a malformed request
• 401 Unauthorized for a missing or invalid license key
• 402 Payment Required when your account is out of queries
• 403 Forbidden when your account does not have permission to use the service
• 5xx for a server error

The response body and its error-code strings are unchanged, and a valid IP that isn’t in our database still returns a 200 OK status (with a warning in the response body). Note that Proxy Detection now returns 400 Bad Request for a malformed request, such as a missing or invalid IP address, that previously returned 200 OK.

See the minFraud Legacy and Proxy Detection documentation for details.

Based on user feedback, we have updated the risk reasons module within the minFraud Transactions Details screen for improved readability.

For increased clarity, we have renamed ‘Multiplier’ to ‘Signal Strength’ and added a color gradient and visual scaling to provide a baseline reference and show the magnitude of each risk reason.

We have also updated the explainer text under ‘Risk Reason’ to include more details.

Learn more about risk score reasons.

You can now integrate a selection of risk score reasons into your custom rules. This update is available in the minFraud Score, Insights, and Factors service tiers.

Risk score reasons are a set of data that provide you with specific and understandable reasons for why a risk score is high or low. Learn more about risk score reasons, or learn how to create a custom rule.

The current risk score reasons able to be used as part of a custom rule are:

• Email first seen
• Email local part
• Email velocity
• Email domain new
• IP email velocity
• Intracountry distance
• Org distance risk
• IIN/shop ID velocity
• IIN on shop ID

If you would like other risk score reasons to be added, please reach out to our Product team at product@maxmind.com.

You can now clear a transaction report tag if the initial classification was or is now incorrect. The new clear tag restores a transaction to an untagged state. This is distinct from the not_fraud tag which signals the transaction is legitimate.

Reporting transactions as chargebacks, suspected fraud, spam/abuse, or false positives helps MaxMind detect 10–50% more fraud and reduce false positives for you.

The clear tag is available via the Report Transaction API, the transaction report web form, and minFraud Interactive.

Learn more about reporting transactions.

minFraud device tracking is now available for native Android and iOS apps.

Each SDK and the web-based JavaScript returns a trackingToken you pass as an input to your minFraud request—a meaningful improvement for mobile networks where many devices share a single IP.

The MaxMind Device SDK for Android collects device data and sends it to MaxMind so that the minFraud service can assign a Device ID and begin collecting fingerprint information.

The MaxMind Device SDK for iOS collects device data and sends it to MaxMind so that the minFraud service can assign a Device ID and use it to detect fraud across sessions. The SDK exposes both a Swift API and an Objective-C API; Objective-C classes use an MM prefix.

Learn more about minFraud device tracking.

As a security improvement, MaxMind will begin hashing all email addresses and phone numbers submitted to the minFraud service before storing them on our servers. No changes to your integration are required. We will continue to accept plaintext values in API requests, and API responses will be unaffected.

Starting July 6, 2026, minFraud Interactive will display the hashed form of email addresses (plus the plaintext domain) and phone prefixes (the first 6-7 digits identifying country code and carrier) in place of full plaintext values, both in your transaction list and when drilling into individual transactions.

If your team relies on viewing full email addresses or phone numbers during manual review, you can opt in to plaintext display in minFraud Interactive by emailing product@maxmind.com.

You may opt in at any time after the transition date; however, plaintext display will apply only to transactions received after your opt-in date. Transactions processed after July 6 but before your opt-in will remain hashed.

Starting tomorrow, Tuesday, March 24 2026, we’re deploying updates to our geolocation confidence factors to make them more accurate.

For networks located outside of the United States, we will be adjusting country level confidence to be higher in circumstances where those networks are used exclusively in a single country.

For all networks, we will be improving the accuracy of our subdivision, city, and postal confidence. These will be minor changes. Most significantly, some subdivision confidence values of 99 will be reduced to 95.

The following products and services will be improved:

• minFraud Insights web services
• minFraud Factors web services
• GeoIP Insights web service
• GeoIP Enterprise database

Between Tuesday March 3 and Friday, March 6, 2026 (and possibly longer), we are making daily updates to the user count data to more often return a value of 0 or 1 for residential proxies.

Previously, approximately 50% of residential proxy IPs on single household IPs had a user count value of at least 2, and 50% had a value of 0 or 1. This update will make it easier to flag a high volume of customer profiles on a residential proxy as anomalous in relation to a lower user count value of 0 or 1.

Please see an explanation of user counts below:

Learn more about user counts on our Knowledge Base.

You are now able to add up to 100 custom inputs in minFraud.

Custom inputs allow you to pass data that is relevant to your business and fine-tune minFraud custom rules to help identify suspicious transactions and reduce fraud.

Custom inputs are available to users of all minFraud service tiers: Score, Insights, and Factors.

Learn how to use custom inputs on our Knowledge Base.

On January 21, 2026, we released data with significant changes to autonomous_system_organization and less significant changes to isp and organization data.

Customers can expect to see in many cases improved, more readable versions of autonomous_system_organization and, in some cases, small changes to isp and organization data.

This change is reflected in the following products and services:

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

We have added new fields to the email/domain sub-object in our minFraud Insights and Factors web services. This enhancement provides you with more granular data for risk modeling and workflows, which is especially useful in B2B account opening/onboarding use cases.

These data points will only be returned when you pass the domain or the unhashed email address as an input to the minFraud Insights and Factors web services. Learn more about domain risk data on our knowledge base.

Client APIs have been updated to reflect this change.

We have released additional inputs and possible input values for all minFraud web service customers.

event/type now supports the additional values below. View the full list of possible values for event/type on our developer portal.

Passing the additional inputs above can help us improve our risk scoring accuracy for you by increasing the context available to our machine learning models and heuristics.

Our client APIs have been updated to support these inputs so you may need to refresh yours to submit them in your minFraud requests if you are not interfacing directly with our REST API.

Effective tomorrow, Thursday, December 18, 2025, we will be blanking out the subdivision, city, and postal fields more often in the following countries. This change will result in fewer resolutions in:

• Amman, Jordan
• Budapest, Hungary
• Reykjavik, Iceland
• All cities in Austria
• All cities in South Africa
• All cities in Vietnam

We will also be blanking out city and postal fields more often for cell networks in:

• India
• Mexico
• United States

This change is to reduce false positives when the end users of a network are dispersed all over the country.

The update will be reflected in the following products and services:

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

Effective Monday, December 1, 2025, we will be blanking out the subdivision, city, and postal fields more often in the following countries. This change will result in fewer resolutions in:

• Belgium
• Israel
• Italy
• The Netherlands
• Portugal
• Sweden
• Ukraine

We will also be blanking out city and postal fields more often for cell networks in:

• Canada
• United States

This change is to reduce false positives when the end users of a network are dispersed all over the country. Many of the networks affected by this change are cell networks, which are often allocated across a wide area spanning one or more subdivisions.

The update will be reflected in the following products and services:

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

We have added the ip_risk_snapshot to the traits object in our GeoIP Insights web service and our minFraud Insights and Factors web services. This field contains the risk associated with the IP address. The value ranges from 0.01 to 99. A higher score indicates a higher risk.

The IP risk snapshot is not a replacement for the minFraud IP risk score (ip_address/risk).

The IP risk snapshot is based on an analysis of historical risk on the IP address, while the minFraud IP risk score is a responsive data field that generates an IP risk score in real time based on the transactions you send and activity from across the minFraud network.

minFraud customers may find the IP risk snapshot output useful to determine whether an IP address is risky based on historical activity versus a current, emerging issue. A lower traits/ip_risk_snapshot score combined with a higher minFraud ip_address/risk score would mean that the IP address is becoming risky in real time based on the traffic on your and other customers’ networks. A high score in both ip_risk_snapshot and minFraud IP risk score would mean that the IP address has been risky for a longer time.

Client APIs have been updated to reflect this change.

We have added an anonymizer object to our web services. This object contains the anonymizer data previously found in the traits object together with new outputs.

Anonymizer data in the traits object is being marked as deprecated. However, for backwards compatibility, anonymizer data in the traits object will continue to be populated and the functionality remains the same. This will not be a breaking change.

We recommend updating your integrations to use the new anonymizer object, which contains data points not found in the traits object:

Client APIs have been updated to reflect this change, which applies to the following web services:

• minFraud Insights
• minFraud Factors
• GeoIP Insights

Effective tomorrow, Wednesday, November 19, 2025, we will be blanking out the subdivision, city, and postal fields more often in the following cities and countries. This change will result in fewer resolutions in:

• Bangkok, Thailand
• Istanbul, Turkey
• All cities in Argentina
• All cities in France
• All cities in Germany
• All cities in Ireland
• All cities in Poland
• All cities in South Korea
• All cities in Switzerland
• All cities in Taiwan
• All cities in the United Kingdom
• All cities in Uruguay

This change is to reduce false positives when the end users of a network are dispersed all over the country.

The update will be reflected in the following products and services:

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

Effective Monday, November 10, 2025, we will be blanking out the subdivision, city, and postal fields more often in Austria, Denmark, Greece, Ireland, Norway, Spain, and Sweden where the end users are actually dispersed all over the country.

This change will result in fewer resolutions to the following cities:

• Vienna, Austria
• Copenhagen, Denmark
• Athens, Greece
• Dublin, Ireland
• Oslo, Norway
• All cities in Spain
• Stockholm, Sweden

The update will be reflected in the following products and services:

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

As of Tuesday, November 4, 2025, we are blanking out the subdivision, city, and postal fields in cases where the subdivision was previously mapped to Tokyo but end users are dispersed throughout Japan.

This change will result in fewer resolutions to the Tokyo subdivision and will be reflected in the following products and services:

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

We have added EMAIL_DOMAIN_CREATION_DATE as a new risk score reason.

The EMAIL_DOMAIN_CREATION_DATE risk reason will be returned as either EMAIL_DOMAIN_CREATION_DATE raised the overall risk score or EMAIL_DOMAIN_CREATION_DATE lowered the overall risk score to clearly indicate the effect the reason has on the score.

Please email product@maxmind.com if you have any questions.

We have resolved the bug that resulted in a number of incorrect and invalid values for postal codes.

We have identified a bug with postal code validation in our database build process.

This bug is resulting in a number of incorrect and invalid values for postal codes. We are working on a fix.

The following products and services are impacted:

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

Risk score reasons have been officially introduced and out of beta as of February 19, 2025.

Available for all minFraud service tiers for individual transactions on the Transaction Details page and also via API for the minFraud Factors service, risk score reasons provide specific and understandable reasons for why a risk score is high or low, helping to uncover risk patterns for individual transactions and the overall transaction stream, both at a point in time and over time.

Read our blog post to learn about the ‘why’ behind risk score reasons, and how you can use the data they provide to enhance your fraud strategy.

For minFraud legacy web services, we will no longer return A1 as a country code.

This change is due to the removal of long-deprecated fields in our GeoIP databases. See our GeoIP release note for more information.

In data released today, Tuesday, December 3, 2024, we are updating a large number of Spectrum Business networks to be classified as Spectrum residential networks. For these networks, the ISP name will change from Spectrum Business to Spectrum. This change has been reviewed, and is accurate.

This change will be reflected in the following products and services:

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

On November 13, 2024, we will release a number of updates to risk score reasons:

• All reasons will be updated to say [reason] raised the overall risk score or [reason] lowered the overall risk score to more clearly indicate the effect of a reason.
• The EMAIL_ADDRESS_NEW reason code will be removed and replaced with three distinct and more specific codes and reasons:
  • EMAIL_FIRST_SEEN
  • EMAIL_TENURE
  • EMAIL_TENURE_NO_ACTIVITY
• The CUSTOMER_ID reason code will be renamed to CUSTOMER_ID_ACTIVITY to better fit its reason description.

Please email product@maxmind.com if you have any questions.

On Monday, November 4, 2024, we will be deprecating the risk factor scores/ subscores data in the minFraud Factors service. Risk factor scores/subscores will be removed from the API response in March, 2025.

Risk factor scores have been replaced by risk score reasons, to help you more deeply understand your risk patterns and make more informed decisions. Please review the risk score reasons for specific and understandable insights into why a risk score is high or low. Learn more about risk score reasons on our Knowledge Base.

Submit a support ticket request if you have questions or concerns.

On Tuesday, October 22, 2024, we will release an improvement to our user count data to better detect IPs with multiple end users.

Many IP addresses with multiple end users that previously had a user count value of 0 or 1 will now have a value of 2.

If you have applications of the data that rely on user count values with a threshold of 0, 1, or 2, you may want to increase the thresholds by 1. For example, if you currently consider user count values of greater than 1 to be high volume, you may wish to consider user count values of greater than 2 to be high volume when this update goes live.

The following services will be impacted:

• minFraud Insights web service
• minFraud Factors web service

Learn more about user count data on our Knowledge Base.

Submit a support ticket request if you have questions or concerns.

On September 10, 2024 we pushed a model update to IP risk scoring that increased a large volume of IP risk scores (also referred to as proxy score for legacy services) at the lower end of the scale (between 0.01 and 1).

While these IP risk scores remained low (less than 1), this shifted the score distribution and may have impacted your systems depending on your score thresholds.

On September 12, 2024, we implemented an update that will decrease most of these low IP risk scores again. To remediate this sort of issue in the future, we will be increasing the sensitivity of our monitoring for scores on the lower end of the distribution before releasing model updates.

Today, we have released a new beta feature that will help minFraud Factors customers more deeply understand risk patterns and make more informed decisions.

Risk score reasons are a set of data that provide users with specific and understandable reasons for why a risk score is high or low. This data is exclusive to the minFraud Factors service.

Watch this 2-minute video to learn more.

For full details, including how to access and test this feature, check out the Risk Score Reasons knowledge base article.

To provide feedback on Risk Score Reasons, please email customersuccess@maxmind.com to schedule a feedback session.

MaxMind minFraud alert emails now include links that allow you to provide instant feedback on each request. Providing transaction feedback helps improve the risk scoring for your account.

You can mark a request as risky and we will raise the risk for similar requests.

Or, you can mark a request as not risky and we will lower the risk for similar requests.

Here is an example of the links in the minFraud alerts email body.

Please continue to report chargebacks and fraud on your account portal or via API.

The transactions screen in your MaxMind account portal now has expanded filtering options, giving you added ability to discover trends in your transactions and adjust risk strategies.

You can now filter transactions by:

• Risk score range: the likelihood that a transaction is fraudulent, scored between a minimum of 0.01 and a maximum of 99
• IP risk score range: the riskiness of an IP address, scored between a minimum of 0.01 and a maximum of 99
• ISP: the internet service provider of the end-user who initiated the transaction
• IP Country: the country for the IP address associated with the transaction

We have released additional outputs for our minFraud Insights and minFraud Factors web services. Insights and Factors customers that pass phone numbers can now make use of the following additional outputs:

• /shipping_phone/country – A two-character ISO 3166-1 country code for the country associated with the shipping phone number.

• /shipping_phone/is_voip – This is true if the shipping phone number is a Voice over Internet Protocol (VoIP) number allocated by a regulator. It is false if the shipping phone number is not a VoIP number allocated by a regulator. The key is only present when a valid shipping phone number has been provided and we have data for it.

• /shipping_phone/network_operator – The name of the original network operator associated with the shipping phone number. This field does not reflect phone numbers that have been ported from the original operator to another, nor does it identify mobile virtual network operators.

• /shipping_phone/number_type – Indicates whether the phone number is mobile or fixed.

• /billing_phone/country – A two-character ISO 3166-1 country code for the country associated with the billing phone number.

• /billing_phone/is_voip – This is true if the billing phone number is a Voice over Internet Protocol (VoIP) number allocated by a regulator. It is false if the billing phone number is not a VoIP number allocated by a regulator. The key is only present when a valid billing phone number has been provided and we have data for it.

• /billing_phone/network_operator – The name of the original network operator associated with the billing phone number. This field does not reflect phone numbers that have been ported from the original operator to another, nor does it identify mobile virtual network operators.

• /billing_phone/number_type – Indicates whether the phone number is mobile or fixed.

These values are particularly helpful to identify mismatches between data points, such as a mismatch between the billing country as indicated by the IP address and the country as indicated by the billing phone number. Another strong signal for fraud is a phone carrier that does not operate in the country indicated by the IP address.

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.

minFraud Insights and Factors customers can now use the /email/first_seen output in minFraud custom rules.

The minFraud service retains a record of when an email address or email domain was first seen on the minFraud Network. An email address that has been conducting transactions for a long time across the minFraud Network may be more trustworthy than a new email address created within the last 30 days.

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

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

Starting in May, Let’s Encrypt will no longer use a cross-signed root certificate, and the primary TLS certificate handling the *.maxmind.com domains will be impacted by this change.

Most customers will see no impact from this change.

This change should only be of concern if the servers interacting with MaxMind domains are running a very old or out of date operating system, or if you manage your own local Certificate Authority store.

• Read more about these changes on the Cloudflare blog.
• Get information about compatibility from Let’s Encrypt.

To improve our server infrastructure and allow for better performance and efficiency, our API policies are now being permanently enforced as of March 13, 2024.

What are the policies?

• MaxMind only accepts API and database download requests sent with the more secure HTTPS protocol.
• MaxMind only accepts 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? Ensure that you are using the correct hostname for your API requests, and that you are using HTTPS. Failure to do so will result in web service or database download requests failing.

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 web service and database download requests. If you are also a GeoIP user, see our GeoIP release note on this issue.

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 on March 13, 2024. To help customers get ready for this change, we will have a planned, temporary enforcement of these policies on February 7, 2024.

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 February 7, 2024.

If you have not made the requested changes before Wednesday, February 7, 2024, you might experience a period where web service or database download requests fail.

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 also affects GeoIP API requests. If you are also a GeoIP user, see our GeoIP release note on this issue.

Starting tomorrow, January 23, 2024, minFraud will no longer accept /event/time inputs with values more than one year in the past. Most customers do not need to send the /event/time input and will not be impacted by this change. Learn more about this input and how to use it to score historical transactions on our Knowledge Base.

If you send the /event/time inputs with values more than one year in the past, minFraud will:

• replace the event time with the current time
• score the transaction and return a score
• return an INPUT_INVALID warning with its response