Compliance alone leaves gaps because fraud techniques evolve faster than static policy enforcement. Merchants can still face abuse from synthetic identities, behavioural fraud, and account takeover even when SCA is implemented correctly. A stronger approach combines authentication, transaction risk scoring, and behavioural monitoring so security decisions reflect the full context of each purchase.
Where compliance ends and fraud controls begin
Compliance frameworks are built to establish a minimum acceptable control baseline, but fraud programmes are judged by whether they stop abuse in the real purchase flow. A merchant can pass a compliance review and still lose money if the control set does not adapt to changing attack patterns, channel-specific abuse, or weak customer signals.
The practical gap is that compliance often measures whether a required control exists, while fraud control measures whether that control is effective against current tactics. That difference matters in card-not-present commerce, account access, and low-friction checkout flows, where attackers can exploit gaps between policy, implementation, and customer behaviour.
Well-run programmes treat compliance as a floor and then layer risk scoring, velocity checks, behavioural analytics, device intelligence, step-up authentication, and manual review around the transaction. This is where broader context becomes critical, because a transaction that is formally compliant may still be high-risk when the pattern, device, or account history looks abnormal.
Why compliance-only thinking misses modern fraud patterns
Fraudsters rarely attack the control that is easiest to see on paper. They tend to target the weakest point in the journey, such as account creation, login, credential reuse, bot-assisted checkout, refund abuse, or post-authentication account takeover. If the merchant assumes compliance equalises those risks, the control model becomes too static for an adaptive adversary.
SCA and similar controls reduce one class of abuse, but they do not eliminate synthetic identities, credential stuffing, social engineering, behavioural fraud, or mule-driven transactions. Those threats often depend on whether the merchant can correlate signals across sessions, devices, payment patterns, and customer history rather than whether a single control was present at a single point in time.
That is why many teams complement payment and access controls with monitoring that can flag anomalies before losses scale. Industry guidance on ISO/IEC 27001:2022 Information Security Management and CIS Controls v8 both support the broader principle: controls need to be selected, monitored, and tuned for operational effectiveness, not just documented for assurance.
What merchants should optimise for instead
The better question is not whether a merchant is compliant, but whether the fraud stack is capable of making proportionate decisions at transaction time. For payment businesses, that usually means combining customer authentication, authorisation logic, risk-based challenge, device and behavioural monitoring, and post-transaction feedback loops so the model improves after each confirmed fraud event.
For compliance-heavy merchants, this also means distinguishing between evidence of control existence and evidence of control performance. Policies, audits, and checklists are useful, but they should be backed by measurable outcomes such as fraud loss rate, false-positive rate, chargeback reason trends, step-up challenge completion, account takeover indicators, and time to detect abuse patterns.
Where the business is exposed to payment-card obligations, PCI DSS v4.0 helps establish the security baseline, while broader control maturity is better reflected in SOC 2 Trust Services Criteria and the NIST Cybersecurity Framework 2.0, which encourage a lifecycle view of govern, protect, detect, respond, and recover.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the technical controls, while PCI DSS v4.0 and ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Fraud control depends on restricting and reviewing access paths used in abuse. |
| 8 — Audit Log Management | Transaction and behaviour monitoring rely on usable logs to spot abuse beyond compliance checks. | |
| Recommendation — Enforce account and access reviews where payment abuse can pivot through compromised credentials. Centralise and review logs that reveal anomalous checkout, login, and account activity. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | The question hinges on authentication and access decisions that compliance alone does not fully cover. |
| DE.CM — Continuous Monitoring | Broader fraud controls require ongoing detection of behavioural and transactional anomalies. | |
| Recommendation — Apply authentication and access controls that reflect transaction risk, not only policy compliance. Monitor customer and transaction activity continuously for signals of fraud drift and abuse. | ||
| PCI DSS v4.0 | 8 — Identify Users and Authenticate Access to System Components | Payment environments need authentication controls, but fraud still requires broader transaction defence. |
| Recommendation — Use payment authentication controls as a baseline and add fraud monitoring around transaction decisions. | ||
| ISO/IEC 42001:2023 | AI Governance and Risk Management | When fraud scoring uses AI, governance must cover model risk, oversight, and outcome monitoring. |
| Recommendation — Govern model-driven fraud scoring so decisions remain explainable, monitored, and accountable. | ||
Practitioner Guidance
What to prioritise: Treat compliance controls as one input to the decision engine, not the decision itself. The first operational priority is to identify where fraud is still possible despite correct authentication, then layer transaction-level checks around those weak points.
What to verify: Confirm that your fraud model uses current signals, not only static policy states. A merchant should be able to show that risk scoring, velocity rules, and behavioural analysis influence holds, step-up challenges, or manual review when the transaction context changes.
Common mistake: Teams often over-trust a passed control, then miss abuse that arrives through a compliant path. The safer rule is that compliance validates minimum hygiene, while fraud controls must prove they reduce loss in the live environment.
Practitioner takeaway: If the control only answers “was the rule satisfied?”, it is not enough for fraud defence. The real test is whether the merchant can recognise suspicious intent, not just compliant execution.
Related resources from NHI Mgmt Group
- What happens when organisations rely on training alone instead of adaptive controls for high-risk users?
- What happens when organisations rely on compliance and cyber insurance instead of enforcing SaaS identity controls?
- What happens when hotels rely on traditional security controls alone against AI-driven fraud?
- What happens when merchants rely on guest checkout without strong fraud controls?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
