When compliance teams talk about PSD2 reporting obligations, they typically mean one of two distinct regulatory frameworks: the transaction reporting obligations under PSD2 Article 96, and the Strong Customer Authentication compliance reporting requirements derived from the EBA's Regulatory Technical Standards on SCA and Common and Secure Communication (EBA RTS on SCA). These are maintained as separate workstreams in most compliance operations, with different teams, different deadlines, and different reporting formats.
The problem is that the underlying data is not separate. The same transaction data that feeds PSD2 Article 96 reporting also generates the SCA authentication events, exemption applications, and fraud-rate monitoring data required under the EBA RTS. For compliance teams managing both obligations simultaneously, the intersection of these two data streams creates a coordination challenge that is easily underestimated in the initial process design.
What the EBA RTS on SCA Requires
The EBA's Regulatory Technical Standards on Strong Customer Authentication, which entered into force under PSD2's Article 98 mandate, specify the technical requirements for SCA implementation. This includes the conditions under which SCA must be applied, the criteria for SCA exemptions, and the monitoring and reporting obligations that accompany exemption use.
The exemptions most relevant to PSD2 transaction reporting are the transaction risk analysis (TRA) exemption and the low-value transaction exemption. PSPs applying the TRA exemption must monitor their fraud rates against thresholds specified in the RTS. If an institution's fraud rate exceeds the applicable threshold for a transaction value band, it must suspend use of the TRA exemption for that band until the rate falls back within the threshold.
This monitoring and suspension obligation generates data events — specifically, records of exemption applications, fraud rate calculations, and threshold breach events — that are recorded at the transaction level in the PSP's operational systems. These events are relevant both to the institution's SCA compliance monitoring (an internal obligation with NCA oversight) and to its PSD2 transaction reporting (where the exemption status of a transaction may affect its categorisation in the report).
Where the Data Streams Intersect
The intersection point between SCA reporting and PSD2 Article 96 transaction reporting occurs at the transaction record level. A payment transaction in the PSP's systems carries attributes related to both reporting obligations:
- For Article 96 reporting: transaction value, currency, instrument type, geographic scope of originator and beneficiary, and timing within the reporting period.
- For SCA compliance monitoring: authentication method applied, exemption type applied (if any), transaction risk score, and outcome (completed, declined, fraud outcome).
These attributes are maintained in the same transaction record or in closely coupled tables within the PSP's data infrastructure. When a compliance team extracts data for PSD2 Article 96 reporting, it is often drawing from the same source tables that the SCA monitoring process reads. A change in how transactions are tagged — for example, a change in how TRA-exempted transactions are categorised internally following an update to the institution's risk engine — can affect both the SCA monitoring outputs and the PSD2 Article 96 report in unexpected ways.
The Reporting Cadence Mismatch
A further complication arises from the difference in reporting cadence between the two obligations. PSD2 Article 96 transaction reporting is quarterly — a submission at each quarter end covering the preceding three months of transaction activity. SCA fraud rate monitoring under the EBA RTS is ongoing — the institution must maintain real-time or near-real-time awareness of its fraud rates to know whether it is eligible to continue applying a given SCA exemption.
This means that SCA-related data must be maintained at higher granularity and with lower latency than the quarterly Article 96 reporting data. The quarterly extraction and aggregation process used for Article 96 reporting is not adequate for SCA fraud rate monitoring — the institution needs monthly or even weekly visibility into fraud rates by transaction value band and authentication method.
Where the two obligations create a specific coordination problem is in the preparation of quarterly reports. The Article 96 submission requires transaction-level data for a three-month period. If the institution has had an SCA fraud rate threshold breach during that quarter — even a temporary one that was corrected within weeks — the affected transactions during the breach period were subject to different SCA requirements than the transactions in adjacent periods. The Article 96 report should correctly reflect transaction characteristics across the full quarter, and the compliance team must understand whether any within-quarter SCA status changes affect the categorisation of those transactions.
Practical Implications for Compliance Operations
We are not saying that SCA compliance reporting and PSD2 Article 96 reporting should be merged into a single workflow. They have different regulatory owners, different technical standards, and different submission mechanisms. The point is that compliance teams need to maintain data lineage that is shared across both obligations, and that a change in the institution's SCA posture — a fraud rate threshold breach, a change in exemption strategy, an update to the risk engine — should trigger a review of whether that change affects the Article 96 quarterly submission.
In practice, this means three things for compliance operations at PSPs handling significant transaction volumes:
First, the data extract for Article 96 reporting should include SCA status fields. Specifically: whether each transaction was subject to SCA, which authentication method was applied, and whether an exemption was claimed. This allows the compliance team to validate that the transaction categorisation in the Article 96 report is consistent with the SCA records maintained for the same transactions.
Second, within-quarter SCA status changes should be logged as events with regulatory reporting implications. If the institution suspended use of a TRA exemption mid-quarter, that event should be recorded in a way that is traceable when preparing the quarterly Article 96 report.
Third, the schema version used for Article 96 reporting should accommodate SCA-related data fields where the NCA's schema includes them. Some NCAs have extended their PAIN.001 / Article 96 schema requirements to include authentication event data or exemption usage data. Compliance teams must verify that their report generation process correctly populates these fields — and that a schema version update from the NCA has not added or changed these fields without the team's awareness.
A Scenario: Schema Change Meets SCA Data Conflict
Consider a payment institution authorised by the DNB in the Netherlands, operating a business payments platform that regularly applies the TRA exemption for transactions below €250 from established business customers. In Q1 2025, the institution's fraud rate in the €100–€250 band briefly exceeded the EBA RTS threshold due to a cluster of fraudulent transactions. The institution suspended TRA exemption applications in this band for six weeks, reinstating them after the fraud rate recovered.
When preparing its Q1 2025 Article 96 submission, the compliance team discovered that the DNB had updated its PAIN.001 schema to include a new field for exemption application flags — a field not present in the prior schema version. The compliance team had not anticipated this field; their extraction template did not populate it. The submission failed XSD validation. Resolving the issue required both a schema update and a data backfill: the team needed to reconstruct which transactions in the quarter had been subject to TRA exemption and which had been exempted under the alternative low-value rule during the six-week suspension period.
The scenario illustrates how a schema version change can create a data quality problem that would not have surfaced under the prior schema, by introducing a new required field that demands data the compliance team had not previously needed to extract or maintain in a report-ready format. The institution in this scenario is synthetic; the failure mode is representative.
Regulatory Examination Exposure
NCAs that examine an institution's PSD2 Article 96 submissions against its SCA compliance records will, in principle, be able to identify inconsistencies between the two datasets. A transaction that appears in the Article 96 report as a standard low-value payment but was recorded in the SCA monitoring system as a TRA-exempted transaction is a data consistency issue that could attract questions during an NCA examination.
Maintaining cross-stream data consistency between SCA monitoring records and Article 96 transaction reports is not an explicit requirement spelled out in the EBA RTS — but it is the natural consequence of operating a compliant reporting programme. Compliance teams that manage both obligations without ensuring shared data lineage create audit exposure that is difficult to resolve after the fact, when the original transaction-level records may no longer be readily accessible at the required granularity.