Using a Rule Engine to Tailor Your Antifraud Strategy

Using a rule engine for antifraud gives businesses more control. Users can define custom rules and conditions based on data from third-party service providers and their own data. This helps identify and prevent fraudulent transactions, and reduce operational risk.

The Advantages of Integrating with Third-Party Service Providers

One key advantage of using a rule engine for antifraud is that it can integrate with third-party service providers, such as Maxmind and FraudLabs, to access a wide range of data about potential fraud. These providers can supply useful signals and insights, but it makes sense to treat them mainly as data providers and evaluate that data yourself in a rule engine. That helps keep your antifraud strategy aligned with your business needs and risk profile.

Another advantage of using a rule engine for antifraud is that it can verify IP addresses against block lists, such as AbuseIPDB and Project Honeypot. By checking IP addresses against these lists, businesses can identify and block transactions from known malicious actors, and reduce fraud exposure.

Another benefit of using a rule engine for antifraud is that it can calculate velocities on your own data to define antifraud rules. By analyzing trends and patterns in your own transaction data, businesses can identify unusual or suspicious behavior and create custom rules to flag and prevent fraudulent transactions.

Preventing Fraud with Custom Rules for IP address

Here are five examples of rules that could be implemented using a rule engine to prevent fraud in ecommerce based on IP addresses:

  1. Block transactions from IP addresses that have been associated with high levels of fraud in the past. This rule could be based on data from third-party service providers, such as Maxmind or FraudLabs, or on your own data analysis.
  2. Require additional authentication for transactions from IP addresses that are not typically used by the customer. This rule could be based on the customer's previous transaction history or on data from third-party service providers.
  3. Block transactions from IP addresses that are known to be associated with malicious actors. This rule could be based on data from block lists, such as AbuseIPDB or Project Honeypot.
  4. Require additional authentication for transactions from IP addresses that are not in the same country or region as the customer's billing or shipping address. This rule could be based on the customer's address information or on data from third-party service providers.
  5. Block transactions from IP addresses that are associated with high levels of velocity or unusual activity. This rule could be based on your own data analysis, using velocity calculations to identify suspicious behavior.

Preventing Fraud with Custom Rules for E-mail Address

Here are five examples of rules that could be implemented using a rule engine to prevent fraud in ecommerce based on email addresses:

  1. Block transactions from customers with disposable or temporary email addresses. This rule could be based on data from third-party service providers, such as FraudLabs, or on your own data analysis.
  2. Require additional authentication for transactions from customers with newly-created email addresses. This rule could be based on the customer's previous transaction history or on data from third-party service providers.
  3. Block transactions from customers with email addresses that are known to be associated with malicious actors. This rule could be based on data from block lists or databases of known fraudulent email addresses.
  4. Require additional authentication for transactions from customers with email addresses that are not in the same domain as the customer's billing or shipping address. This rule could be based on the customer's address information or on data from third-party service providers.
  5. Block transactions from customers with email addresses that are associated with high levels of velocity or unusual activity. This rule could be based on your own data analysis, using velocity calculations to identify suspicious behavior.
Decisimo decision engine

Put these checks into a decision flow

Create rules for credit, fraud or collections, then run them on live decisions.

See pricing

Custom Rules for Browser Information and Antifraud

Here are five examples of rules that could be implemented using a rule engine to prevent fraud in ecommerce based on browser information:

  1. Block transactions from customers using browsers that are known to be associated with high levels of fraud. This rule could be based on data from third-party service providers, such as WhatIsMyBrowser or FraudLabs, or on your own data analysis.
  2. Require additional authentication for transactions from customers using browsers that are not typically used by the customer. This rule could be based on the customer's previous transaction history or on data from third-party service providers.
  3. Block transactions from customers using browsers that are known to be associated with malicious actors. This rule could be based on data from block lists or databases of known fraudulent browser information.
  4. Require additional authentication for transactions from customers using browsers that are not commonly used in the customer's country or region. This rule could be based on data from third-party service providers, such as WhatIsMyBrowser, or on your own data analysis.
  5. Block transactions from customers using browsers that are associated with high levels of velocity or unusual activity. This rule could be based on your own data analysis, using velocity calculations to identify suspicious behavior.

Custom Rules for Physical Addresses and Antifraud

Here are five examples of rules that could be implemented using a rule engine to prevent fraud in ecommerce based on physical addresses:

  1. Block transactions from customers with fake or invalid addresses. This rule could be based on data from third-party service providers, such as Ekata or Google Places API, or on your own data analysis.
  2. Require additional authentication for transactions from customers with newly-created or recently-changed addresses. This rule could be based on the customer's previous transaction history or on data from third-party service providers.
  3. Block transactions from customers with addresses that are known to be associated with high levels of fraud. This rule could be based on data from third-party service providers or on your own data analysis.
  4. Require additional authentication for transactions from customers with addresses that are not in the same country or region as the customer's billing or shipping information. This rule could be based on the customer's address information or on data from third-party service providers.
  5. Block transactions from customers with addresses that are associated with high levels of velocity or unusual activity. This rule could be based on your own data analysis, using velocity calculations to identify suspicious behavior.

Conclusion

Using a rule engine for antifraud gives businesses practical control. It supports fast integration with third-party service providers, checks IP addresses and email addresses against block lists, and calculates velocities on your own data to create custom rules. By treating third-party services mainly as data providers and implementing your own rules in a rule engine, businesses can identify and prevent fraudulent transactions more effectively, and reduce operational risk.

Frequently asked questions

How can browser information help an ecommerce business detect fraud?

A rule engine can use browser information to block transactions from browsers associated with high fraud or malicious actors. It can also require additional authentication when a browser is unusual for the customer or uncommon in the customer’s country or region. Rules can use third-party data or the business’s own analysis.

How can an ecommerce business use physical-address rules to prevent fraud?

A physical-address rule can block transactions with fake, invalid, or fraud-associated addresses. It can also require additional authentication when an address is newly created, recently changed, or in a different country or region from the billing or shipping information. The rule can use third-party data or the business’s own analysis.

How can a customer’s transaction history inform antifraud rules?

A business can use a customer’s previous transaction history to identify an unfamiliar IP address or browser. A rule engine can also use that history to flag newly created email addresses or newly created or recently changed physical addresses, and require additional authentication for those transactions.

Which services can provide data for checking physical addresses for fraud?

Services such as Ekata or Google Places API can provide data for rules that block transactions with fake or invalid physical addresses. A business can also base physical-address rules on its own data analysis.

When can an ecommerce antifraud rule require additional authentication?

An ecommerce antifraud rule can require additional authentication when an IP address or browser is unfamiliar to the customer, or when the IP address is in a different country or region from the billing or shipping address. Rules can also ask for authentication for newly created email addresses or new or recently changed physical addresses.

Decisimo decision engine

Put these checks into a decision flow

Create rules for credit, fraud or collections, then run them on live decisions.

See pricing

Related Articles

  • What should an anti-fraud team own and what should it buy?

    Anti-fraud is not a product you install once and forget. It is an operating capability built from data, decision logic, traceability, and continuous tuning across the customer journey. Companies can buy parts of that stack, but if they outsource the core logic and enriched data, they often create a lock-in problem that is hard to unwind later.

  • MaxMind minFraud Insights checks and risk scores

    minFraud Insights returns the checks behind its fraud score, including details about the IP, email, addresses, card, phone and device. In live calls, an anonymous cloud IP and a billing address thousands of kilometres from the IP both scored below MaxMind's example accept line while the checks flagged them.

  • How to integrate FraudlabsPro into a decision engine

    This guide shows how to connect FraudLabsPro to Decisimo and use it inside your decision logic for eCommerce transaction evaluation. It walks through setup, required API details, and the data fields that help you review, approve, or reject transactions with clearer traceability.

  • MaxMind minFraud Factors: reason codes, pricing, and use

    Factors returns the same score as Score and Insights when the three services are called at the same moment, plus reasons that show what raised or lowered it. The reasons are most useful when a score alone would leave an order inside your accept range.

  • How to use AbuseIPDB for fraud decisions

    AbuseIPDB’s confidence score shows how sure its community is that an address is malicious, while its usage type and Tor flag show what kind of address it is. Read these signals together when shaping fraud decisions for sign-ups, logins, and other flows.