How a fraud rules engine decides online card payments
One device ran a string of small payments through your checkout overnight, changing cards as it went. Your morning dashboard shows the pattern after the run has ended, and the checkout team says a threshold change can go out in its next release. Then someone asks how many good customers the rule would have stopped last month. You do not have an answer ready. A limit on distinct cards per device may be easy to describe, but it still changes which payments reach approval.
A fraud rules engine decides each payment before authorisation
A fraud rules engine checks an online card payment before it goes to authorisation, then returns an outcome for your checkout to carry out. A fraud decision flow can run rules in order and use scores, data sources, lists and counts. It can return approve, step-up, manual review or decline, and record which rules fired.
A score and cut-off are a natural starting point. The score gives each payment one risk measure, and the cut-off connects that measure to an action. But a run of cards on one device is activity across payments. A score measures one payment. A count across payments captures that activity. Card testing can start with small payments and then intensify, as the BIN attack pattern describes.
The outcome matters at checkout: approve sends the payment to authorisation, step-up asks the checkout to request more authentication, manual review holds it for your team, and decline stops it there. Decide who owns the review queue and what happens after a reviewer records a decision.
The identifier changes who a velocity rule stops
The velocity tool replays past applications in time order. A rule fires on the application that brings the count for the same identifier within the chosen window to the threshold. Its generated demo uses a count of three in one day. The generated demo gives a simple example of why the identifier matters.
| Identifier | Flagged | Bads caught | Goods stopped | Precision |
|---|---|---|---|---|
| 0 | 0 | 0 | – | |
| phone | 35 | 24 | 5 | 82.8% |
| device_id | 33 | 22 | 5 | 81.5% |
| ip | 128 | 4 | 95 | 4.0% |
| Any identifier | 178 | 38 | 102 | 27.1% |
Phone and device rules in the demo catch bad activity and stop few good customers. The IP rule catches fewer bads and stops many good customers. That has a cost at checkout.
To answer how many good customers your rule would have stopped, replay your own past payments with their known outcomes. For each candidate identifier, count the payments the rule would flag, then separate known bads from known goods. Use each match to identify a payment for investigation. Check its outcome against known evidence. The velocity rules tool can compare counts and windows for the identifiers it supports. For distinct cards on one device, test that exact count using payment history that includes both the device and card identifiers.
A distinct-card count changes the payment decision
Consider an online payment carrying a card number and BIN, a device fingerprint, an IP address, an email and a shipping address. The following illustrative sequence applies documented flow and list behaviour to a hypothetical online payment. The flow can call a BIN lookup and device check, check card prefixes, devices and emails against lists, run its rules, then return an outcome.
An ordinary payment arrives with low counts and is approved to go to authorisation. Now suppose three distinct cards have already appeared on the same device inside the chosen hour. If the rule fires on the fourth distinct card, that payment goes to review or decline. To measure the effect on good customers, run that same rule over your past payments and count the known-good payments it would have flagged. The count identifies who the rule would have stopped. Investigate each match to establish whether it was fraud.
If the transaction history needed for a count is missing, an empty numeric value can read as zero. A separate missing-value check gives the flow a way to handle that condition instead of treating it as a low count.
After an analyst confirms fraud, they can add the device to a block list with an expiry. A later attempt using that device can then be declined. The list change is visible on the next request without a new release.
Make sure each count reaches the decision flow
The engine decides one request at a time, so the count has to arrive with the payment. It can come from your systems, a data source, or a DataFlow rule that analyses recent transactions sent with the request. For a distinct-card count, verify that the source calculates distinct cards per device. Use transaction history to calculate the distinct cards used on each device.
Check missing counts, failed data sources and unavailable lists before rules rely on their results. When a data source fails, its own step is marked as failed and the rest of the flow continues. When a list is unavailable, its hit can be empty, so check the list status too.
A fork with no matching branch stops the run. Make the final branch a safe default, usually manual review, so an unmatched payment has a defined outcome.
Set concentration caps against your usual payment mix
Velocity counts repeated activity on an identifier. Concentration rules ask whether an unusually large share of orders is tied to one place or group. For payments, that can mean one shipping address, one BIN range or one country of card issue. Concentration rules extend the check from repeated attempts to a cluster in your payment activity.
Set a cap using your own history. Compare the share for each address, BIN range or country with its usual share over comparable periods. Then test candidate caps against known payment outcomes. Choose the cap that gives your team a useful intervention at a tolerable level of good payments flagged.
When a cap is breached, step-up is one possible outcome. Set that outcome deliberately, then check the changed decisions in a backtest before the rule reaches checkout.
Use lists for confirmed, trusted and investigated values
Lists let the flow use changes to known values on the next request, rather than requiring a new release for every addition. Block, allow and watch lists have different jobs:
- Block lists hold confirmed fraud values, such as cards, BIN prefixes, devices or emails.
- Allow lists hold customers or devices you have defined as trusted and that can skip a check.
- Watch lists hold values under investigation that should send a payment to review.
Require evidence that a customer meets your criteria before allowlisting them. Decide what evidence qualifies a value as trusted, which check it skips, and when the entry expires. An analyst can add a confirmed device from a case, and an entry can carry an expiry. A prefix entry matches values that start with that BIN prefix.
Backtest the release and monitor chargebacks
A backtest runs a release against decisions your production endpoints have already made. It reports which decisions would change and, where outcomes are available, how the applications behind them performed. The backtest replays decisions with each list as it stood when the original request arrived. Data sources remain outside the replay. The fraud rule backtest tool reports flagged payments, fraud caught, good payments flagged and unique catches per rule.
Review each changed decision alongside the total catches. Check which known-good payments would have been sent to review, step-up or decline, and whether more than one rule would have flagged the same payment. Then decide whether the release is ready for checkout.
After release, monitor the chargeback ratio using your acquirer’s counting rules and limits. Check what counts as a chargeback and which transactions belong in the period. The chargeback ratio tool lets you enter those acquirer-specific terms.
Set the device rule from your own payment history
Return to the device that ran several cards overnight. Before changing the checkout threshold, establish how many good customers the rule would have stopped and what the flow does when a count or check is unavailable.
- Write down what approve, step-up, manual review and decline mean at checkout. Name the person or team that owns the review queue, who covers it when needed, and what decision reviewers can return.
- List the identifiers each payment carries. For each count, record whether it comes from your systems, a data source or transactions sent with the request for a DataFlow rule to analyse.
- For each identifier, test candidate counts and windows against past payments with known outcomes. For the device rule, count distinct cards per device inside the window and check how many known-good payments each candidate would flag.
- For concentration, compare each address, BIN range and country-of-issue share with its usual level in comparable history. Test candidate caps against known outcomes and choose the action for a breached cap.
- Define what qualifies for block, allow and watch lists. Give entries an expiry where appropriate, and specify what each list does to the payment decision.
- Make missing counts, failed data sources and unavailable lists explicit before rules use them. Finish the fork with a branch that sends unmatched payments to review.
- Backtest the proposed release against past production decisions. Review changed decisions, known outcomes, good payments flagged and overlapping rule hits.
- Release only after reviewing those results. Then monitor chargebacks using your acquirer’s counting rules and limits. Choose identifiers, counts, windows and concentration caps from your own payment history, define the missing-data outcomes, and backtest the release before it reaches checkout.
Questions about payment fraud rules
How do fraud rules engines work for online payment protection?
They run checks and rules for each payment before authorisation, then return an outcome for your checkout to carry out. Decide what each outcome means at checkout and who owns manual review.
What is a velocity check in payment fraud?
It counts activity for the same identifier within a time window, or counts distinct values such as cards used on one device. Test the identifier, count and window against your own payment history.
What are concentration rules in fraud prevention?
They flag an unusually large share of activity tied to a place or group, such as orders going to one address or using one BIN range. Compare that share with its usual level and test candidate caps against known outcomes.
How do you choose the threshold and window for a velocity rule?
Replay past payments for each identifier and compare bads caught with good customers stopped. Treat a match as a reason to investigate, then select the count and window that fit your book.
What is the difference between a fraud rules engine and a fraud score?
A score is one input or check, while an engine can run rules and use lists and data sources to select an outcome. Decide how the score fits with the other checks in your flow.
How do you test a new payment fraud rule before it goes live?
Backtest the release against past production decisions and review which decisions would change and how known outcomes performed. After release, monitor chargebacks using your acquirer’s counting rules and limits.
