Risk rules
A payment risk engine allows risk strategists to define the overarching logic for transaction decisioning. Cardflo provides a configurable framework that applies boolean logic, hierarchy models and risk scoring thresholds to block, flag or route payments for authentication automatically.
- Category
- Risk
- Capabilities
- 10
- Available on
- All plans
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.
Enforcing custom fraud prevention in real time, based on geo-location and IP blacklisting, blocks suspicious transactions. This protects individual MIDs across Cardflo's extensive acquirer network.
Risk rules 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 risk rules works
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.
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.
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.
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 risk rules 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.
Risk rules use cases
Tiered checkout decision logic
Retailers with standard, restricted and age-gated product lines need different payment outcomes without maintaining separate checkout policies for every catalogue segment. Cardflo configures ordered boolean rules so decisive conditions block a payment, intermediate scores trigger 3DS2, and permitted transactions proceed before lower-priority logic is evaluated.
Subscription payment acceptance policies
Risk teams combining merchant policy, issuer response context and authentication requirements can create contradictory outcomes when several rules match the same payment. Cardflo establishes rule hierarchy, weighting and explicit if-then-else fallbacks so the payment risk engine applies one predictable decision and records which policy determined it.
Seasonal risk threshold changes
Ticket sellers and event operators face abrupt changes in purchase behaviour around release windows, making ordinary risk scoring thresholds unsuitable for short periods of concentrated demand. Cardflo schedules policy changes that adjust block, review and 3DS2 thresholds for defined sales phases, then restores the baseline rules when the release period ends.
Score based 3DS routing
Online retailers need to distinguish payments suitable for frictionless assessment from those requiring 3DS2 or immediate rejection as combined risk signals accumulate. Cardflo maps weighted rule outcomes to scoring bands, allowing low scores to proceed, intermediate scores to request authentication and scores above the merchant’s acceptance threshold to be blocked.
Risk rules by the numbers
Typical reduction in dispute volumes observed by merchants after implementing multi-layered risk logic, depending on the baseline fraud rate and industry vertical.
The standard time increment added to the payment flow when executing complex internal risk rule evaluations at the gateway level.
Average recovery of previously declined legitimate orders when moving from binary blacklisting to nuanced, attribute-based risk scoring and 3DS triggering.
Methodology: these figures are illustrative ranges drawn from published industry data and observed merchant cohorts, not guarantees. Actual results depend on your risk profile, card mix, geography and acquiring setup, and are confirmed only in your own pricing and approval terms.
Related terms
Talk to our team about a live rollout across our acquirer partners' rails.
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.
A short scoping call, then a written plan for your MIDs.
Questions about Risk rules
How does payment risk engine hierarchy resolve competing block and flag actions?
The payment risk engine evaluates matching rules according to priorities defined by the merchant’s risk policy owners.
A higher-priority block action can take precedence over a lower-priority flag, while rules at the same level can be resolved through an explicit precedence setting rather than configuration order.
This hierarchy makes the final decision reproducible and allows risk teams to document why a particular action was applied.
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.
How can payment risk scoring thresholds create graduated acceptance decisions?
Risk policy owners can divide a score range into defined decision bands, with each band linked to an acceptance, review or block action. If-then-else logic can also provide a default outcome when a score equals a boundary or falls outside the configured bands.
Recording inclusive and exclusive threshold conditions helps avoid gaps, overlaps and inconsistent treatment at exact boundary values.
When should payment risk engine rules stop evaluating further conditions?
Rule evaluation can stop when a terminal outcome, such as an unconditional block, has been reached and no later rule is permitted to replace it.
Non-terminal outcomes, including internal flags or score adjustments, can allow subsequent conditions to continue evaluating and contribute to the final decision. Risk strategists should define terminal status explicitly for each action so rule ordering does not produce unintended results.
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.
Related features.
Related guides.
See how Cardflo compares.
Ready to improve your payments setup?
Tell us about your business. We'll match you with the right acquiring partners and the right route, typically inside a week.