The Sixth Anti-Money Laundering Directive (AMLD6) and PSD2 are commonly managed as separate compliance workstreams within European payment institutions and e-money issuers. The regulatory owners are often different — AML/CFT compliance typically sits with the MLRO function, while PSD2 transaction reporting sits with the regulatory reporting or compliance operations team. The reporting channels are different. The deadlines are different. The format requirements are different.
What is not different is the source data. Both obligations draw from the same pool of transaction records that the institution's systems generate for every payment processed. This shared data source creates a coordination problem that compliance teams frequently underestimate: when the data pipeline for one obligation is changed, it can inadvertently affect the quality of the data available for the other. And when both obligations require data extractions for the same reporting period, the risk of inconsistency between the two datasets — inconsistency that a joint NCA and AML supervisory authority examination could identify — is a material compliance risk.
AMLD6 Data Obligations and Their Transaction-Level Scope
AMLD6, adopted in October 2018 and transposed into EU member state law with a transposition deadline of December 2020, strengthened the framework for criminal liability for money laundering and expanded the predicate offences covered. Its direct data obligations for payment institutions overlap with PSD2 in the transaction data domain in several ways.
Transaction monitoring data. AMLD6 reinforces the obligation on obliged entities — which includes payment institutions and e-money issuers — to maintain transaction monitoring systems that flag suspicious activity. The transaction records that feed these monitoring systems are the same records that feed PSD2 Article 96 reporting: originator identity, beneficiary identity, transaction value and currency, date and time, geographic endpoints, and payment instrument type.
Record-keeping obligations. AMLD6 specifies that obliged entities must retain records of customer due diligence, business relationships, and transactions for a minimum of five years. For payment institutions processing high volumes of retail transactions, the "transactions" category overlaps substantially with the transaction-level data that underpins PSD2 reporting.
Beneficial ownership data. AMLD6 and the associated AML regulatory package strengthened beneficial ownership verification requirements. For business-to-business payment transactions above certain thresholds, the beneficial ownership information for the originating business entity is relevant to both AML transaction monitoring and, in some NCA implementations, to PSD2 reporting of high-value business payment transactions.
Where Inconsistencies Arise
The data inconsistency risk between AMLD6 records and PSD2 reports is most pronounced in three situations.
Currency Conversion and Period-End Rates
PSD2 Article 96 reporting requires transaction values to be reported in a reference currency (typically EUR) using a specified exchange rate methodology. AML transaction monitoring systems may apply different exchange rate approaches — real-time rates at transaction time for alerting purposes, for example. If the PSD2 reporting team and the AML compliance team are independently extracting multi-currency transaction data for the same period but applying different exchange rate methodologies, their reported transaction values for the same population of transactions will differ.
Under ordinary circumstances, this discrepancy is invisible — the two datasets are never compared against each other. In an examination where both the PSD2 supervisory authority and the AML supervisory authority request documentation of the same period's transaction data, the inconsistency can surface and require explanation.
Transaction Categorisation Differences
PSD2 Article 96 reports categorise transactions by payment service type and instrument type. AML transaction monitoring systems categorise transactions by risk profile, counterparty type, and transaction pattern — categories that do not map directly to PSD2 reporting categories. When both systems are drawing from the same transaction database, the categorisation logic applied at extraction time determines which category a transaction falls into.
If the PSD2 reporting team and the AML monitoring team have applied different extraction logic — different period boundary definitions, different exclusions for internal transfers, different treatment of pending versus settled transactions — the same transaction might appear in one dataset but not the other, or appear in both datasets with different values.
Correction and Adjustment Timing
After a reporting period closes, the transaction record may be adjusted for corrections — chargebacks, reversals, settlement adjustments. How these post-period adjustments are handled varies between PSD2 reporting processes and AML record-keeping systems. An institution that applies post-period adjustments to its PSD2 reporting data but not to its AML transaction records (or vice versa) will have divergent records for the same population of transactions.
The Supervisory Dual-Regime Examination Risk
In the EU, AML supervision and PSD2 supervision are conducted by different authorities in most member states. The MLRO's counterpart at the AML supervisory authority is typically a different regulator from the NCA responsible for PSD2 oversight. The FCA, for example, has both PSD2 supervisory functions (as the UK equivalent under PSR 2017) and AML supervisory functions for payment institutions, but the two examination processes within the FCA operate separately.
We are not suggesting that dual-regime examinations routinely involve cross-checking PSD2 reports against AML transaction records. We are saying that as supervisory data exchange between AML and prudential authorities improves — a direction explicitly supported by AMLD6 and the AML Regulation package that followed it — the probability of cross-regulatory data comparisons is increasing, not decreasing.
More immediately, an institution subject to an AML examination that triggers substantive questions about transaction patterns may find itself explaining the same transaction population from two regulatory perspectives simultaneously — the AML explanation drawing on its transaction monitoring records, and potentially the PSD2 explanation drawing on its quarterly submission data. If those two datasets tell a different story about the same transactions, the institution has a consistency problem that is more difficult to resolve under examination conditions than before examination begins.
A Scenario: Shared Data Source, Divergent Outputs
Consider a growing e-money institution authorised by the DNB in the Netherlands, processing approximately 200,000 transactions per quarter. The institution maintains separate teams for AML compliance (reporting to the MLRO) and regulatory reporting (reporting to the head of compliance). Both teams extract transaction data from the institution's central transaction database.
In Q2 2025, the regulatory reporting team updated their extraction query to align with a DNB schema change that introduced new requirements for categorising certain cross-border low-value transactions. The update changed how a specific subset of consumer payment transactions were classified in the reporting extract. The AML compliance team's extraction was not updated in parallel — they continued to use the prior categorisation logic.
For Q2 2025, the two teams' transaction records diverged for this transaction subset: approximately 15,000 transactions appeared in one categorisation in the PSD2 report and a different categorisation in the AML monitoring dashboard. The discrepancy was not discovered until a DNB supervisory inquiry several months later referenced transaction volumes that did not match the institution's AML system records for the same period.
The institution resolved the discrepancy with a clarification and a corrected data submission, but the process required extensive effort and raised questions about the institution's data governance that went beyond the immediate transaction categorisation issue. The institution and specific details in this scenario are synthetic.
Building a Coherent Shared Data Layer
The structural solution to AML/PSD2 data consistency is not to merge the two compliance workstreams — they have different regulatory owners, different methodologies, and different supervisory relationships that should remain distinct. The solution is to ensure that both obligations draw from a single, well-governed source of transaction truth, with any categorisation or conversion logic applied at the point of obligation-specific extraction, not at the point of data storage.
In practice, this means three things. First, the institution should maintain a canonical transaction record that represents each payment event without obligation-specific processing applied. Second, the PSD2 reporting extraction and the AML monitoring extraction should both be able to reference this canonical record, with their respective categorisation logic documented and version-controlled. Third, when either extraction logic is updated — because a PSD2 schema changed, or because the AML monitoring system was reconfigured — the other team should be notified and the cross-impact assessed.
This coordination requirement is most easily met when both teams understand what data the other is extracting from shared sources. Compliance teams that operate entirely in silos, without any shared understanding of their respective data extraction configurations, are carrying an avoidable consistency risk that increases as their transaction volumes grow and as supervisory scrutiny of the underlying data intensifies.