PCI DSS fraud detection requirements have evolved significantly under version 4.0. Where previous assessments focused on whether a fraud-detection system existed, qualified security assessors now verify that the system monitors specific transaction behaviours and that those behaviours are documented, tested and tuned. For CISOs and fraud managers at Saudi payment firms—card issuers, acquirers, payment service providers and e-commerce platforms—this shift means that generic threshold alerts are no longer sufficient. The QSA will ask to see evidence that your fraud rules detect the patterns most commonly associated with payment fraud, and that you can demonstrate how each pattern is configured, triggered and investigated.
This article identifies the five transaction patterns that PCI DSS v4.0 expects every fraud-detection system to monitor, explains why each matters, and shows how to document them in a way that satisfies both the assessment and your own vendor evaluation process.
Why PCI DSS v4.0 Changed the Standard for Fraud Detection
The Payment Card Industry Security Standards Council introduced Requirement 6.4.3 to address a persistent gap: payment entities were deploying fraud-detection systems but often relying on out-of-the-box rules that had never been tailored to their transaction profile or threat landscape. QSAs reported that many systems generated alerts only when a single transaction exceeded a monetary threshold, missing the behavioural patterns that characterise modern card-not-present fraud, account takeover and money-laundering typologies.
Under PCI DSS v4.0, the requirement is explicit. Payment entities must implement automated mechanisms to detect and respond to suspected or confirmed security incidents, including fraud. The QSA will review your fraud-detection rules, ask for evidence that they monitor transaction behaviours rather than static thresholds alone, and verify that alerts are investigated and documented. This means your fraud system must be configured to detect patterns, not just amounts, and that you must be able to show the QSA exactly which patterns you monitor and why.
The Five Transaction Patterns Every Fraud Rule Must Monitor
The following five patterns represent the behaviours that QSAs expect to see in a compliant fraud-detection system. Each pattern corresponds to a known fraud typology, and each should be documented in your fraud rule library with a clear description, threshold, and investigation workflow.
1. Velocity
Velocity rules detect an unusual number of transactions within a defined time window. This includes multiple transactions on the same card within minutes, multiple cards used from the same device or IP address, or multiple failed authorization attempts followed by a successful one. Velocity is the most common indicator of card testing, where fraudsters validate stolen card details by attempting small purchases before committing larger fraud.
Your fraud system should monitor velocity across multiple dimensions: per card, per device, per merchant, per IP address and per customer account. The QSA will ask to see evidence that these rules exist, that thresholds are set based on your transaction profile, and that alerts are investigated within a defined timeframe.
2. Geography
Geographic anomalies occur when a card is used in two locations that are physically impossible to reach within the time between transactions, or when a transaction originates from a high-risk jurisdiction that does not match the cardholder's profile. This pattern is a strong indicator of card-not-present fraud, particularly when the cardholder's previous transactions have been domestic and the new transaction originates from a different continent.
Your fraud rules should include geolocation checks that compare the origin of the current transaction with recent transaction history, flag transactions from jurisdictions on your risk list, and alert when a card is used in a new country for the first time. The QSA will expect to see evidence that you maintain a geographic risk list, that it is reviewed periodically, and that alerts are escalated appropriately.
3. Device Mismatch
Device mismatch rules detect when a transaction is initiated from a device or browser that has never been associated with the cardholder's account, or when device fingerprinting reveals attributes that do not match the customer's known profile. This pattern is central to detecting account takeover, where a fraudster gains access to legitimate credentials but uses a different device to initiate transactions.
Your fraud system should capture and compare device attributes—operating system, browser version, screen resolution, time zone, language settings—and flag transactions when these attributes change suddenly or when a new device is used for high-risk actions such as adding a payee, changing contact details or initiating a large transfer. The QSA will review your device fingerprinting capability and ask for evidence that device mismatches trigger alerts and investigation.
4. Merchant-Category Anomaly
Merchant-category anomaly rules detect when a cardholder makes a purchase in a category that is inconsistent with their transaction history. For example, a cardholder who has only ever made grocery and fuel purchases suddenly buys electronics or cryptocurrency. This pattern is particularly relevant for detecting compromised cards and for identifying transactions that may indicate money laundering or sanctions evasion.
Your fraud rules should classify merchants by category code, build a profile of each cardholder's typical merchant categories, and flag transactions that fall outside that profile. The QSA will expect to see evidence that your system maintains merchant-category profiles, that thresholds are set to balance detection and false positives, and that alerts are investigated with reference to the cardholder's broader transaction history.
5. Time-of-Day Deviation
Time-of-day deviation rules detect transactions that occur at times inconsistent with the cardholder's normal behaviour. A cardholder who typically transacts between 08:00 and 22:00 suddenly makes a purchase at 03:00. While this pattern alone is rarely sufficient to block a transaction, it is a valuable signal when combined with other anomalies—particularly velocity, geography or device mismatch.
Your fraud system should record the time of each transaction, build a time-of-day profile for each cardholder, and flag transactions that fall outside normal hours. The QSA will review your time-based rules and ask for evidence that time-of-day deviations are considered in your overall fraud score and investigation workflow.
How to Document These Patterns for the QSA
The QSA will not simply accept a statement that your fraud system monitors these patterns. You must provide evidence in the form of rule documentation, test results and investigation records. The following documentation satisfies the requirement and also serves as the foundation for your vendor RFP scorecard if you are selecting a new fraud system.
Rule library. Maintain a document that lists every fraud rule by name, describes the pattern it detects, specifies the threshold and time window, and identifies the alert severity and investigation workflow. For each of the five patterns above, include at least one rule and show how it is configured in your system.
Test evidence. Demonstrate that each rule triggers correctly by running test transactions that simulate the pattern. Record the test date, the transaction details, the alert generated and the investigation outcome. The QSA will review this evidence to verify that your rules are active and effective.
Investigation logs. Maintain a case-management system that records every alert, the investigation steps taken, the decision (approve, decline, escalate) and the rationale. The QSA will sample investigation logs to verify that alerts are reviewed within your defined timeframe and that decisions are documented.
Tuning records. Show that you review and adjust rule thresholds periodically based on false-positive rates, fraud losses and changes in transaction volume. The QSA will expect to see evidence that your fraud rules are not static but are tuned in response to operational data.
When to Select or Optimize Your Fraud-Detection System
If your current fraud system cannot monitor all five of these patterns, or if you cannot produce the documentation described above, you face a choice: enhance your existing system or select a new one. The decision depends on the capability of your current platform, the cost and timeline of customization, and the broader requirements of your payment business.
Signs it is time to act. You are preparing for a PCI DSS v4.0 assessment and your QSA has raised observations about fraud-detection coverage. Your fraud team reports high false-positive rates or missed fraud. Your system cannot ingest device data, geolocation or merchant-category codes. You are launching a new payment channel—instant payments, digital wallet, cross-border remittance—and your current system does not support the transaction types or data fields.
What a good outcome looks like. Your fraud system monitors all five patterns with rules tailored to your transaction profile. Your QSA reviews your rule library, test evidence and investigation logs and finds no gaps. Your fraud team investigates alerts efficiently, with clear workflows and low false-positive rates. Your vendor RFP process is structured, scored and documented, and the selected system integrates with your core banking, payment switch and case-management platforms without custom development.
How the Fraud Management Solution Delivers This Outcome
The Fraud Management Solution is a vendor-independent selection and implementation of a fraud management system, covering requirements, vendor evaluation, rules and models, integration and go-live.
The process follows four phases. Define establishes requirements, data sources and target operating model. Select runs an RFP, demonstrations, proof of concept and scoring. Implement covers integration, rules, models and case management. Go live includes testing, cut-over and hypercare.
Deliverables include a requirements specification, vendor evaluation report and recommendation, implementation oversight reports, and go-live test evidence.
Features include detection, case-management and integration requirements; fair, scored vendor evaluation with proof of concept; rule and model build, migration and testing; and go-live readiness and hypercare.
Duration is 4–9 months.
The service applies PCI DSS and SAMA Cyber Fraud Framework requirements.
The firm does not resell any fraud system and is vendor-independent, declaring any relationship before an evaluation starts. The firm can help with an existing system, starting at implementation or optimization rather than selection.
Closing: Prepare Your Fraud System for the QSA
PCI DSS v4.0 has raised the bar for fraud detection. QSAs now verify that your system monitors specific transaction behaviours, not just thresholds, and that you can demonstrate how each pattern is detected, investigated and tuned. If your current system cannot monitor velocity, geography, device mismatch, merchant-category anomaly and time-of-day deviation—or if you cannot produce the documentation the QSA will request—it is time to act.
The Fraud Management Solution provides the structure, independence and technical rigour to select the right fraud platform and implement it in a way that satisfies both the PCI DSS requirement and your operational needs. The outcome is a fraud system that detects the patterns that matter, a rule library that passes the QSA's review, and a vendor evaluation process that you can defend to your board and your regulator.
