Risk

Risk rules

Cardflo's risk rules engine provides a robust framework for fraud prevention. Merchants can define and enforce specific criteria to evaluate transactions in real-time, identifying and mitigating potential threats before they impact the business.

This proactive approach safeguards revenue and maintains payment integrity across all channels.

Category
Risk
Capabilities
10
Available on
All plans
Apply now

The overview

Risk rules function as a logic-based layer within the payment gateway or orchestration stack, designed to evaluate transaction metadata against predefined criteria before an authorisation request is sent to the acquirer.

These rules allow merchants to programme specific responses to various risk indicators, such as mismatched billing and shipping addresses, high-velocity card testing attempts, or suspicious geographic origin.

By establishing a set of parameters for what constitutes legitimate behaviour, an organisation can automate the initial screening process. This logic typically triggers actions such as immediate refusal, flagging for manual review, or the mandatory requirement of 3D Secure authentication.

Effective risk rule configuration aims to balance the identification of fraudulent intent with the preservation of legitimate conversion rates.

The mechanics involve inspecting data points including IP address, BIN information, MCC codes, and device fingerprints to assign a risk score or produce a binary decision, thereby reducing the probability of chargebacks and maintaining compliance with scheme requirements.

How it works

  1. Attribute evaluation and data ingestion

    The engine ingests multifaceted data points during the checkout process. This includes structural transaction details like amount and currency, alongside technical identifiers such as IP reputation and device metadata.

    These attributes form the baseline for the risk assessment, ensuring the logic has sufficient context to evaluate the user's behaviour accurately.

  2. Logic processing and rule matching

    Once data is captured, it passes through the configured logic gates. The system checks for matches against specific criteria, such as velocity limits for a specific card or geographic blocks on certain jurisdictions.

    Each rule is processed sequentially or simultaneously to determine if any triggers have been activated by the request.

  3. Risk scoring and decisioning

    Based on the cumulative results of the individual rules, the system generates a decision. This might be a binary pass or fail, or a weighted risk score.

    Depending on the threshold, the transaction is either routed for authorisation, blocked entirely, or redirected to a step-up authentication challenge like 3DS.

  4. Real time enforcement and logging

    The final decision is enforced instantly at the gateway level. If the transaction passes, an authorisation request is sent to the issuer.

    If rejected, a specific decline reason is logged. All outcomes are recorded for audit purposes and to refine the logic through ongoing analysis of fraud patterns.

Why it matters

Reduction in involuntary churn and chargebacks

Implementing granular risk rules is a primary defence against the financial and administrative burden of chargebacks. By identifying fraudulent transactions at the point of entry, merchants can avoid the fees associated with representment and protect their merchant account standing with acquirers.

Consistent monitoring of these rules helps maintain a chargeback ratio within the limits mandated by major card schemes, preventing potential fines or the loss of processing privileges.

Optimisation of checkout friction

A strictly uniform approach to fraud prevention often results in false positives, where legitimate customers are blocked. Risk rules allow for a nuanced strategy, applying heavier scrutiny only to high-risk profiles while facilitating a smoother path for known or low-risk users.

This selective application of friction, such as conditional 3D Secure, supports higher conversion rates without significantly increasing the business's exposure to fraudulent activity or payment disputes.

Use cases

High velocity card testing defence

E-commerce merchants frequently targeted by automated scripts can use velocity rules to limit the number of attempts from a single IP or BIN within a minute, effectively stopping card testing before it exhausts gateway resources.

Geographic restriction and export compliance

Businesses operating in regulated sectors can implement rules to block transactions originating from specific jurisdictions, ensuring compliance with international sanctions and minimising the risk of processing card-not-present transactions from high-fraud regions.

Large order value verification

Retailers selling high-ticket items may set rules to trigger manual review or mandatory SCA for any transaction exceeding a specific monetary threshold, providing an extra layer of verification for significant revenue events.

Digital goods and instant delivery

Merchants providing digital downloads can apply rules that cross-reference the email domain reputation and IP location to prevent the immediate distribution of goods to users using temporary or high-risk email services.

By the numbers

20–40%
Chargeback reduction range

Typical reduction in dispute volumes observed by merchants after implementing multi-layered risk logic, depending on the baseline fraud rate and industry vertical.

<200ms
Transaction processing latency

The standard time increment added to the payment flow when executing complex internal risk rule evaluations at the gateway level.

5–15%
False positive optimisation

Average recovery of previously declined legitimate orders when moving from binary blacklisting to nuanced, attribute-based risk scoring and 3DS triggering.

Ready to route with Risk rules?

Talk to our team about a live rollout on your acquiring stack.

Apply now

What you get with Risk rules

  • Configure custom velocity thresholds for specific card numbers, email addresses, or device fingerprints per hour.
  • Implement geographic blocking based on IP address location or the issuer's country of origin.
  • Automate the routing of suspicious transactions to 3D Secure for mandatory cardholder authentication.
  • Set granular rules for transaction amount limits to flag or block unusually large orders.
  • Analyse and block transactions originating from known high-risk IP addresses or VPN services.
  • Define logic to match billing and shipping addresses, triggering review for any significant discrepancies.
  • Apply specific rules based on the Merchant Category Code to manage sector-specific risk profiles.
  • Establish blacklists for compromised card BINs or specific email domains frequently associated with fraud.
  • Integrate third-party risk signals to augment internal logic and improve decision-making accuracy.
  • Utilise detailed reporting to analyse rule performance and minimise the occurrence of false positives.
See Risk rules on your acquiring stack.

A short scoping call, then a written plan for your MIDs.

Apply now

Questions about Risk rules

How do risk rules impact the overall transaction latency for the end user?

Processing risk rules typically introduces minimal latency, usually measured in milliseconds. Because the evaluation happens at the gateway or orchestration level before the request is sent to the acquirer, it is highly optimised.

The specific time taken depends on the number of rules and whether external third-party data calls are required. Most modern systems are designed to ensure that these checks do not noticeably degrade the checkout experience for the customer, maintaining parity with standard authorisation times.

Can risk rules be configured to allow for manual review of suspicious transactions?

Yes, common risk engine configurations include a 'flag' or 'hold' status. Instead of an outright rejection or approval, a transaction meeting certain suspicious criteria can be paused.

This allows a fraud analyst to manually inspect the transaction details, such as verifying the shipping address or contacting the customer, before deciding to capture the funds or void the authorisation.

This is particularly useful for high-value orders where the cost of a false positive is high.

What is the difference between a hard block and a soft decline in risk management?

A hard block occurs when the merchant's risk engine prevents the transaction from even being sent to the issuer, usually based on internal blacklists or logic.

A soft decline typically comes from the issuer, suggesting a temporary issue like insufficient funds or a technical timeout, which may be retried.

Risk rules aim to prevent the need for an issuer-side decline by filtering out high-risk attempts earlier in the payment flow, thus protecting the merchant's authorisation-to-decline ratio.

How should a merchant balance fraud prevention with false positive rates?

Balancing threat mitigation and conversion involves iterative testing. Merchants should start with broader, less restrictive rules and gradually tighten them as they analyse historical transaction data and chargeback patterns.

Using a 'shadow mode' where rules are active but only log outcomes without blocking allows for the assessment of a rule's impact before it goes live.

The goal is to set thresholds that capture the majority of fraud while ensuring the vast majority of legitimate users are not inconvenienced.

Do risk rules assist with PSD2 and Strong Customer Authentication compliance?

Risk rules are integral to managing SCA requirements. They can be used to identify transactions that qualify for exemptions under PSD2, such as low-value payments or recurring transactions.

Conversely, if a transaction is deemed higher risk by the internal engine, the rules can trigger a 'Step-up' to 3D Secure, ensuring the merchant meets the legal requirements for robust authentication while only applying it when necessary based on the risk profile.

Can rules be based on the specific type of card being used by the customer?

Yes, risk engines can typically parse the Bank Identification Number to determine card attributes. This allows merchants to set rules for specific card types, such as prepaid cards, which are often associated with higher fraud rates in certain industries.

Rules can also distinguish between credit and debit cards, or between domestic and international cards, allowing for different risk thresholds to be applied based on the inherent risk of the payment method itself.

How frequently should a business review and update their risk rule sets?

Risk rules should not be static. Industry standards suggest a monthly or quarterly review of rule performance, though sudden spikes in fraud may require immediate intervention.

By analysing the reasons for declines and the origins of any successful chargebacks, merchants can refine their logic. Regular audits help ensure that rules remain relevant to current fraud trends and that they are not inadvertently blocking new growth markets or changing consumer behaviours.

Get started

Ready for velocity?

Tell us about your business. We'll match you with the right acquiring partners and the right route, typically inside a week.

Apply now
Apply now