Does PSD2 require a bank's cybersecurity SOC to detect payment fraud?

Not entirely, and conflating the two is the mistake this post argues against. Article 2 of Regulation (EU) 2018/389 (the RTS on strong customer authentication) requires payment service providers to run transaction-monitoring mechanisms covering five risk-based factors. Two of them — signs of malware infection during an authentication session, and abnormal use of a provider-supplied access device or software — are session and endpoint telemetry, squarely inside what a cybersecurity SOC already instruments. The other three — lists of compromised or stolen authentication elements, the amount of each transaction, and known fraud scenarios — are behavioral and transactional risk-scoring, the kind of decisioning a dedicated fraud-detection platform does, not a SOC's alert taxonomy.

So who is actually responsible for the three factors that aren't SOC territory?

PSD2 doesn't assign that internally — it just requires the payment service provider to have mechanisms covering all five, somewhere in the organization. In practice that's usually a fraud-operations or risk team running a dedicated transaction-scoring platform, often the same team handling chargeback and AML monitoring, not the security operations center. What matters for scoping a SOC engagement is being explicit about which factors the SOC is actually accountable for, instead of assuming '24/7 monitoring' silently covers all five because the regulation doesn't separate them.

Does a generic managed SOC built for a casino or crypto exchange already have detection content for the two factors that are in scope?

Not by default. 'Malware infection signs during an authentication session' and 'abnormal use of an access device or software' aren't standard EDR/XDR out-of-the-box alert categories — they're specific enough that they need to be named as detection use cases during onboarding, mapped to whatever telemetry the bank's authentication flow actually produces (mobile app SDK signals, browser fingerprinting, session-anomaly logs from the identity provider). A SOC built and tuned for a casino's bonus-abuse and credential-stuffing patterns, or a crypto exchange's wallet-drainer and outflow-spike alerts, has no reason to already have this content — it has to be added, not assumed.

How is this different from the PSD2/QWAC hardening work already covered for a payment platform?

Different article, different layer. [Hardening a fintech payment platform](/blog/fintech-payment-platform-hardening-priority-order/) covers PSD2 Article 34 — verifying a third-party provider's identity with a qualified certificate (QWAC/QSeal) before it reaches the API gateway. That's a one-time, static authentication check on the caller. Article 2's transaction monitoring is a continuous, ongoing detection requirement that runs after a caller — TPP or the bank's own customer — is already authenticated: is this specific session and this specific transaction showing signs something is wrong. Authenticating the caller and watching the authenticated session are two separate controls, and PSD2 requires both.

Where does this fit inside a standard Managed SOC engagement?

Inside the existing onboarding step where detection content gets tuned to the client's environment, not as a separate product. For a digital bank, that onboarding conversation has to explicitly walk through Article 2's five factors, confirm which of them the SOC's monitoring will cover with the log sources actually available (authentication-session telemetry, device/software usage logs from the banking app), and document which factors sit outside the SOC's scope so the bank knows to cover them with its fraud-ops tooling instead. That scoping conversation is what turns '24/7 monitoring' from an assumption into a defined, auditable boundary.

Managed SOC for a Digital Bank: What PSD2's Transaction-Monitoring Rule Actually Asks a SOC to Watch

The short answer

PSD2's regulatory technical standards on strong customer authentication — Regulation (EU) 2018/389, Article 2 — require payment service providers to run transaction-monitoring mechanisms that account for five specific risk-based factors. Two of them are squarely a cybersecurity SOC's job: signs of malware infection during an authentication session, and abnormal use of a provider-supplied access device or software. The other three — compromised or stolen authentication-element lists, transaction amount, and known fraud scenarios — are fraud-operations territory, not standard SOC alert content. A generic managed SOC built for a casino or crypto exchange has no detection use cases tuned for either half by default, and treating "24/7 monitoring" as if it silently covers all five is how a digital bank ends up with a compliance gap it doesn't know it has.

Who this is for

This is for a CISO or Head of Infrastructure at a digital bank, e-money institution, or fintech payment platform scoping a Managed SOC engagement — especially one evaluating a provider whose existing SOC coverage was built for a different vertical, or standing up 24/7 monitoring for the first time under PSD2 and DORA pressure. If the open question is what a fintech payment platform's API gateway needs to authenticate a third-party provider, hardening a fintech payment platform answers that one — this post assumes the gateway is already authenticating callers correctly and asks a different question: once someone is authenticated, what is the SOC actually watching their session for, and what part of PSD2's monitoring mandate does that leave uncovered.

The scope problem: five factors, two owners

Article 2(1) requires transaction-monitoring mechanisms that detect unauthorized or fraudulent payment transactions by analyzing activity against what's typical for a given payment service user under normal use of their personalized security credentials. Article 2(2) then names the minimum risk-based factors those mechanisms have to take into account:

Risk factor (Article 2(2))	Natural owner	Why
Lists of compromised or stolen authentication elements	Fraud-ops / risk	Requires a maintained threat-intel feed of breached credentials, not session telemetry
The amount of each payment transaction	Fraud-ops / risk	Transaction-value risk scoring, typically inside a dedicated fraud-detection platform
Known fraud scenarios in the provision of payment services	Fraud-ops / risk	Behavioral pattern-matching against a fraud-scenario library, not a security-attack signature
Signs of malware infection during any session of the authentication procedure	Cybersecurity SOC	Endpoint/session telemetry — the same signal class a SOC already collects for account-takeover detection
Abnormal use of a provider-supplied access device or software	Cybersecurity SOC	Device/session-usage-pattern anomaly detection, the same discipline as insider-threat or compromised-credential monitoring

The regulation doesn't draw this line itself — it just requires all five to be covered somewhere. In practice, the first three sit with whoever runs transaction-level fraud scoring (often a dedicated platform purpose-built for that job), and the last two sit with whoever is already watching the authentication and session layer for attacks — which, for most digital banks, is the cybersecurity SOC. The risk isn't that either team is incompetent at its own half. It's that nobody at the bank has explicitly assigned the two SOC-shaped factors to the SOC, so they're covered by neither.

Why a generic SOC doesn't already have this content

A managed SOC's detection content is built around the threat model of whoever it was tuned for. Managed SOC for iGaming is tuned for bonus abuse and account-takeover patterns against a casino cashier. 24/7 SOC coverage models for a crypto exchange and the underlying SOC runbook are tuned for wallet-drainer sessions and outflow-spike alerts against custody infrastructure. Neither environment has an equivalent to "signs of malware infection during an authentication session" as a named, regulator-mandated detection category, because neither PCI DSS nor a crypto exchange's internal risk framework requires it in those specific terms.

That means a digital bank buying "the same managed SOC package" a casino or exchange runs is very likely buying detection content that has no tuned use case for either of Article 2's SOC-relevant factors. The gap isn't a failure of the SOC model — follow-the-sun triage, documented runbooks, and EDR/XDR-agnostic tooling all still apply — it's that "malware in an authentication session" and "abnormal access-device use" have to be named explicitly as detection requirements during onboarding, mapped to whatever session and device telemetry the bank's actual authentication stack produces (mobile banking app SDK signals, browser fingerprinting from the identity provider, device-attestation logs), rather than assumed to already be covered by a generic alert taxonomy.

What this looks like during onboarding

This sits inside the same onboarding process used for every vertical: a SIEM/log-source connector setup followed by detection content tuned to the client's environment, ahead of 24/7 triage going live. For a digital bank specifically, that tuning conversation needs to explicitly walk through Article 2's five factors line by line and confirm, in writing, which the SOC's monitoring will cover and with what log source — not leave it implied by the phrase "transaction monitoring." The three fraud-ops factors don't disappear from that conversation; they get documented as out of SOC scope, so the bank knows to have separate coverage for them rather than discovering the gap during an examination.

Limitations

This is a scoping framework for dividing PSD2's Article 2 monitoring mandate between a cybersecurity SOC and fraud-operations tooling — it is not a determination of whether a specific bank's current setup satisfies an examiner's read of the regulation, which depends on the bank's own risk assessment and national competent authority. It also isn't fraud-detection software: a Managed SOC engagement can be tuned to catch the two session/device-level factors named above, but it does not replace a dedicated transaction-scoring platform for the other three, and claiming otherwise would overstate what a cybersecurity SOC is built to do. Where a confirmed fraud event needs a response rather than detection, incident response for a digital bank covers the clock that starts once something is already confirmed — this post is entirely about the detection layer that runs before that point.

What to do next

If your current SOC coverage was scoped for a different vertical, or "transaction monitoring" has never been broken down against Article 2's five factors with an explicit owner for each, that's the gap worth closing before an examiner asks for it. Tell us your current setup and we'll map detection content against the two factors that belong in SOC scope, and document the rest so it's clear what sits outside it.

Sources and review

Regulation (EU) 2018/389 (the RTS on strong customer authentication and common and secure communication under PSD2), Article 2's transaction-monitoring requirement and its five minimum risk-based factors, is drawn from the official retained-EU-law text at legislation.gov.uk, fetched and read directly rather than taken from a secondary summary. Article 34's qualified-certificate (QWAC/QSeal) requirement, referenced for contrast, was previously verified against EUR-Lex in hardening a fintech payment platform and isn't re-fetched here. Managed SOC onboarding steps, detection-content tuning, follow-the-sun coverage, and EDR/XDR-agnostic tooling are AnySec's own published Managed SOC service terms; no third-party vendor claim, customer result, or examiner outcome is cited as fact. No new AnySec-original numeric or case claim is introduced. Author: AnySec Engineering. Published 2026-09-09; last reviewed 2026-09-09.