PCI DSS version 4.0 became effective in March 2024, replacing version 3.2.1 which had been in force since 2018. For payment processors running ML-based fraud detection systems, several requirements changed in ways that are either misunderstood or not yet reflected in vendor documentation. This article covers specifically what changed for fraud detection and monitoring systems — not the full PCI DSS 4.0 scope, which is much broader.
The Anti-Phishing Requirement Is More Than Email
PCI DSS 4.0 Requirement 5.4.1 introduces a formal requirement for anti-phishing mechanisms that protect against phishing attacks targeting payment system personnel. The requirement states that processes must detect and protect against phishing attacks, which the PCI SSC interprets broadly to include transaction-level phishing detection in payment workflows.
For fraud detection purposes, this matters because phishing-enabled account takeover is a fraud vector that sits at the intersection of authentication and transaction monitoring. A cardholder whose credentials are stolen via phishing will often have their account taken over and transactions authorized through what looks like legitimate cardholder behavior — because the attacker has the cardholder's login credentials and is operating through a session that authenticated normally.
PCI DSS 4.0 4.2.1 further requires that organizations protect account data from compromise during transmission, which is broadly interpreted to require that transaction data integrity is maintained throughout the fraud scoring pipeline. For processors using third-party fraud scoring APIs, this means encrypted transmission, not just at the card data level but through the full scoring pipeline.
Requirements 6.4.1 and 6.4.2: Web Application Fraud Detection
These two requirements are the most directly relevant to ML-based fraud systems and the ones most misunderstood. Requirement 6.4.1 requires that public-facing web applications are protected against attacks by an automated technical solution that detects and prevents web-based attacks. Requirement 6.4.2 requires that if an automated technical solution is used, it must be configured to detect and generate alerts for web-based attacks.
The confusion here is that many fraud detection vendors position their ML scoring engine as satisfying these requirements, when in fact they address different threat vectors. The requirements were written to cover application-layer attacks — SQL injection, cross-site scripting, credential stuffing against cardholder-facing login pages — not transaction fraud scoring. A real-time transaction risk scoring system does not satisfy 6.4.1 by itself.
What this means practically: processors need both a transaction fraud scoring system and a web application firewall (WAF) or bot detection system with alerting configured for application-layer attacks. These are separate tools addressing separate threat vectors, and the documentation needs to reflect both.
Requirement 10.7: Detection of Critical System Failures
Requirement 10.7 in PCI DSS 4.0 extends the monitoring requirements to include detection and alerting when security controls fail or stop working. For fraud detection systems specifically, this creates an obligation to detect when the fraud scoring system itself has degraded or become unavailable, not just when fraud is occurring.
The practical implication: if your fraud scoring system goes offline and transactions start authorizing without risk scoring, that failure mode must be detected and alerted within a defined time window. Most production fraud systems have uptime monitoring, but 10.7 requires that the monitoring also covers control failures — including situations where the system is technically running but producing scores that are non-functional (all zeros, all maximums, or outside the expected distribution).
Score distribution monitoring, which fraud teams should be running for model drift detection anyway, also satisfies the 10.7 documentation requirement if it's configured with alerting thresholds and evidenced in the QSA audit trail. The security requirement and the operational requirement align here — build it once, document it twice.
Requirement 12.3.2: Technology Risk Assessments
This is a new requirement in PCI DSS 4.0 that wasn't present in 3.2.1 in this form. It requires that a targeted risk assessment is performed for each technology — including fraud detection systems — at least once every 12 months. The risk assessment must cover the risks associated with using the technology and include controls that address those risks.
For ML-based fraud systems, the risk assessment needs to address: the risk of model degradation leading to increased fraud losses, the risk of adversarial attacks against the ML model itself (model inversion, training data poisoning), the risk of data pipeline failures that cause stale features to be used in scoring, and the risk of vendor dependency if the fraud system is third-party.
Most organizations haven't formalized these ML-specific risks in a PCI-evidenced risk assessment document. The 12.3.2 requirement creates an audit expectation that they will. For QSA audits starting in 2025, expect questions about whether your fraud detection system's ML components are included in the scope of the annual technology risk assessment.
Customized Implementation and the "Defined Approach" vs. "Customized Approach"
PCI DSS 4.0 introduced a new "customized approach" alternative to the traditional "defined approach" for meeting security objectives. This is relevant for fraud detection because some of the fraud-related controls (particularly around behavioral monitoring) can be implemented in ways that don't map cleanly to the prescriptive defined requirements but that achieve the same security objective.
Under the customized approach, an organization can propose a control that achieves the stated security objective through a different mechanism, provided they can document and evidence that the alternative control is at least as effective. For ML-based fraud detection, this creates an opportunity to document controls that are technically stronger than the defined-approach minimum requirements in a way that the QSA can evaluate and credit.
The practical constraint is that customized approach requires more documentation burden — the organization must evidence not just that the control exists but that it achieves the security objective. For fraud detection teams comfortable with quantitative performance measurement (detection rates, false positive rates, model accuracy over time), this documentation should be achievable. For teams that don't have systematic performance tracking, the customized approach creates a compliance driver to implement better measurement.
What Changed for Behavioral Monitoring (Requirement 10.2.1)
Requirement 10.2.1 covers audit log generation for various security-relevant events. In PCI DSS 4.0, the event list was expanded and clarified for cardholder-facing systems. Specifically, the requirement now explicitly includes logging of authentication failures, privilege escalation, and "use of and modifications to data and system privileges."
For fraud detection systems that incorporate behavioral monitoring — tracking cardholder session behavior as a fraud signal — this creates a documentation requirement around how behavioral signals are collected, stored, and used. If your fraud scoring system collects typing velocity, navigation patterns, or session duration data, that data collection needs to be evidenced as part of the cardholder data environment boundary definition. Behavioral data that can identify specific cardholders falls within PCI DSS scope.
This is a gray area that many behavioral fraud detection vendors have not addressed clearly in their PCI compliance documentation. The safe approach is to treat session behavioral data with the same data handling requirements as other cardholder data and document accordingly, rather than assuming behavioral signals are out of scope.
Documentation Requirements That Have Gotten Stricter
PCI DSS 4.0 increased documentation requirements throughout. For fraud detection specifically, processors should expect QSAs to ask for: documented procedures for responding to fraud alerts, evidence that fraud thresholds are reviewed at defined intervals, documentation of how the fraud system is included in the annual risk assessment, evidence of fraud system testing (penetration testing if the fraud system is a cardholder-data-environment-adjacent system), and documentation of how fraud scoring output is used in authorization decisions.
The "how fraud scoring output is used in authorization decisions" documentation request is new. QSAs are beginning to ask whether fraud score thresholds are hardcoded or configurable, who can change them, and whether threshold changes are logged. This is a governance question, not a technical one, but it requires that processors have formal change control processes around fraud threshold configuration — which many don't.
What You Need to Update in Your Documentation
For payment processors under PCI DSS 4.0 scope, the fraud detection documentation items that most commonly need updating are: inclusion of the fraud scoring system in the technology risk assessment (12.3.2); score distribution monitoring with alerting as evidence for 10.7; behavioral data collection documented within the cardholder data environment boundary; fraud threshold change control procedures; and anti-phishing controls documented separately from transaction fraud scoring.
The technical changes required are generally smaller than the documentation changes. Most processors running production ML-based fraud systems already have the technical controls PCI DSS 4.0 requires; the gap is in documentation, evidencing, and formal procedures that make those controls auditable. Start with the documentation gap, work backward to identify any actual technical gaps, and address both before your next QSA assessment.
What InferX Provides for PCI Compliance Documentation
InferX provides customers with pre-written PCI DSS 4.0 compliance documentation templates covering: system description and data flow diagrams for the scoring pipeline, evidence templates for technology risk assessment inclusion, score distribution monitoring configuration with alerting thresholds pre-configured, and change control audit logs for threshold modifications. These are available as part of the Enterprise plan and do not replace a QSA assessment, but they significantly reduce the documentation preparation time before audit. Contact us at hi@getinferx.com for the compliance documentation package.