PSD2 fraud reporting under Article 96(6) — what counts, who files, and the six-month cycle

PSD2 fraud reporting is not a fraud report — it is a statistical return, and the two most common mistakes are counting the fraud you stopped and counting it in the wrong period. Article 96(6) of Directive (EU) 2015/2366 requires every payment service provider to give its competent authority statistical data on fraud relating to different means of payment, and requires authorities to pass it to the EBA and the ECB in aggregated form. The detail lives in EBA Guidelines EBA/GL/2018/05, as amended by EBA/GL/2020/01. This walks through what counts, who files, the six-month cycle and the home-host split.

1. The instrument and its dates

The EBA published the guidelines on 18 July 2018. They apply from 1 January 2019, with one carve-out: the data relating to the exemptions from strong customer authentication in Commission Delegated Regulation (EU) 2018/389 apply from 14 September 2019, the date the SCA regime itself became applicable. On 22 January 2020 the EBA published EBA/GL/2020/01, amending the original guidelines; those amendments apply from 1 July 2020. The consolidated text is what firms report against today.

They are addressed to payment service providers as defined in Article 4(11) of PSD2 — except account information service providers — and to competent authorities. An AISP is outside the reporting population; a payment initiation service provider is squarely inside it, with its own data breakdown. The guidelines are also expressly subject to proportionality: all providers in scope must comply with each guideline, but the precise requirements, including on frequency of reporting, may differ depending on the payment instrument, the type of services provided or the size of the provider.

2. What counts as a fraudulent transaction

Guideline 1.1 defines the population in two limbs, and both have to be captured.

The first is unauthorised payment transactions — transactions made including as a result of the loss, theft or misappropriation of sensitive payment data or a payment instrument, whether or not detectable to the payer before the payment, whether or not caused by the payer’s gross negligence, and including transactions executed in the absence of the payer’s consent.

The second is manipulation of the payer — transactions made as a result of the payer being manipulated by the fraudster to issue a payment order, or to give the instruction to do so to the provider, in good faith, to a payment account the payer believes belongs to a legitimate payee. This is the authorised-push-payment population, and it sits in the statistical return on exactly the same footing as an unauthorised transaction.

Within the unauthorised limb, two named sub-types matter for the card and credit transfer breakdowns. Issuance of a payment order by the fraudster is a fake order issued after the fraudster obtained sensitive payment data by fraudulent means. Modification of a payment order by the fraudster is interception and alteration of a legitimate order in the electronic communication between the payer’s device and the provider — malware and man-in-the-middle attacks are the examples given — or alteration of the instruction inside the provider’s own system before clearing and settlement.

3. Fraud losses, recovery and the period they land in

Two figures are reported and they behave differently. Total fraudulent payment transactions covers all transactions in Guideline 1.1 regardless of whether the amount has been recovered — a recovered fraud stays in the numerator. Losses due to fraud per liability bearer is a separate measure: losses borne by the reporting provider, by its payment service user, or by others, reflecting the actual impact of fraud on a cash-flow basis.

Because loss recognition lags the transaction, the guidelines break the link deliberately: final fraud losses are reported in the period in which they are recorded in the provider’s books, so that reported data are not revised purely because of that timing lag. And final loss figures should not take into account refunds by insurance agencies, on the stated basis that insurance recoveries are not related to fraud prevention for PSD2 purposes.

The transaction itself is dated differently again. Guideline 6.1 fixes the recording date as the day the transaction was executed; in a series, each individual transaction takes its own execution date. Guideline 6.2 requires all fraudulent transactions to be reported from the time fraud has been detected — through a customer complaint or otherwise — regardless of whether the case has been closed by the time the data are reported. Guideline 6.3 then requires adjustments to any past period at least up to one year old to be made in the next reporting window after the information is discovered, flagged as revised figures.

Facts: a card issuer detects, in March, a set of remote card frauds executed in the previous November. The chargeback recoveries land in June and the residual loss is booked in July.

What the rule says: the transactions belong to the reporting period containing their November execution date and go in as an adjustment to that past period in the next reporting window after detection. They stay in the total fraudulent transaction figure even though part of the amount was recovered. The residual loss enters “losses due to fraud per liability bearer” in the period in which it was recorded in the books — July.

What the practitioner does: builds the return on two separate date keys — execution date for transactions, booking date for losses — instead of one fraud-case date. A single case timestamp cannot produce both figures correctly, and reconciling them afterwards is the usual source of restatements.

4. Who reports which side of the transaction

Guideline 2.11 sets the anti-double-counting rules, and they are instrument-specific rather than uniform.

• The payer’s provider reports in its issuing or initiating capacity as the general rule.
• Card payments are the exception: reported by both the payer’s provider and the acquiring provider, as two separate perspectives with different breakdowns. Where more than one acquirer is involved, the one with the contractual relationship with the payee reports.
• Direct debits are reported by the payee’s provider only, because the payee initiates them.
• A provider executing a credit transfer initiated by a payment initiation provider flags that volume and value inside its own credit transfer breakdown, so the initiation provider’s separate return does not double-count it.
• For money remittance, the payer’s provider reports the leg from itself to the money remitter; the beneficiary’s provider does not. The money remitter reports transfers from its own accounts to a beneficiary account, including where value is settled through netting arrangements.
• For e-money, transfers to a beneficiary account are reported by the e-money provider, including where the payer’s and payee’s provider are the same entity; where they differ, only the payer’s provider reports.

One scoping rule catches product teams: cards with an e-money function only — prepaid products — are not reported in the card breakdowns at all but as e-money. Conversely, credit transfers used to settle the outstanding balance of a credit or delayed debit card sit in the credit transfer breakdown, as do credit transfers made at ATMs with a credit transfer function. And the card breakdowns exclude cash withdrawals and deposits, which have their own breakdown covering withdrawals at ATMs (including via apps), at bank counters and through retailers as cash back.

5. Frequency, home, host and agents

Guideline 3.1 sets the cycle: providers report every six months on the applicable data breakdowns. Providers benefiting from the Article 32 PSD2 small-institution exemption, and e-money institutions benefiting from the Article 9 waiver in Directive 2009/110/EC, report annually, with the data broken down into two six-month periods. The submission deadline itself is not in the guidelines — Guideline 3.3 leaves the timelines to the respective competent authorities, and Guideline 2.6 on the authority side requires them to define the secure communication procedures and format and to allow an appropriate deadline for data quality and reporting lag.

Reporting runs to the home member state authority. Two refinements matter for a passported group. Agents: the provider records data from all its agents providing payment services in the EEA and aggregates it with the rest before reporting home — and the location of the agent is expressly irrelevant for determining the geographical perspective. Branches: an established branch of an EEA provider reports to the competent authority of the host member state where it is established, separately from the home-state reporting, within the framework of Article 29(2) PSD2 and Article 40 of Directive 2013/36/EU.

Geography is reported in three buckets — domestic, cross-border within the EEA, cross-border outside the EEA — and the test differs by channel. For non-card and remote card transactions, domestic means the payer’s and payee’s providers are in the same member state. For non-remote card transactions the POS or ATM location counts as a third element: issuer, acquirer and terminal must all be in the same member state.

Facts: a group holds one authorisation, operates a branch in a second member state and an agent network in a third. Its data team plans one consolidated fraud return filed with the home authority.

What the rule says: agent data is aggregated into the home return and the agent’s location does not change the geographical classification — so that part of the plan is right. The branch is not: it files separately with the host authority, and inside the branch’s own return “domestic” is measured against the host state, not the home state.

What the practitioner does: builds one extraction with an entity dimension that separates branch activity, and a geography rule that is parameterised by the reporting entity’s location rather than hard-coded to the licence country. Firms that hard-code home-state geography discover the problem when the host authority’s totals fail to reconcile.

6. The breakdown structure

Within the card breakdowns, fraudulent transactions are split by authentication — whether SCA was applied or not — and then by fraud type: issuance of a payment order by a fraudster, itself split into lost or stolen card, card not received, counterfeit card, card details theft and other; modification of a payment order by the fraudster; and manipulation of the payer. Where SCA was not applied, the reason is reported against the exemptions in Chapter 3 of Delegated Regulation (EU) 2018/389, or against the two categories added by EBA/GL/2020/01 — “merchant initiated transactions” and “other” — which exist precisely to capture non-application for reasons that are not an exemption. Direct debits use a shorter fraud-type list: unauthorised transactions, and manipulation of the payer to consent to a direct debit.

Mechanically: volumes and values in actual units with two decimals for values; each transaction allocated to one sub-category per row; each transaction in a series counting as one; zero where nothing occurred but “NA” where the breakdown does not apply at all. Euro-area providers and branches report in euro, others in their member state’s currency, converting at the rates actually applied or the average ECB reference rate for the period.

7. What happens to the data

Competent authorities aggregate by summing the figures reported by each provider in line with the same breakdowns, and send the aggregated data to the ECB and the EBA within six months from the day after the end of the reporting period. Authorities carry adjustments back up to 13 months after the transaction was executed — a window chosen to match the payment service user’s right under Article 71 PSD2 to notify the provider of an unauthorised or incorrectly executed transaction no later than 13 months after the debit date.

That 13-month tail is the practical reason to keep the fraud data set open rather than closing a period at submission. A firm that treats each half-year as final on filing will be unable to service an authority’s adjustment request in month twelve without a manual reconstruction.

8. FAQ

9. What to do, today

• Split your date logic. Transactions are dated on execution; losses are dated on when they are recorded in the books. One fraud-case timestamp cannot serve both.
• Remove blocked attempts from the return and keep them in management reporting, where they belong.
• Keep recovered fraud in the transaction total. Recovery affects the loss figure, not the fraud count.
• Parameterise geography by reporting entity, so a branch return measures “domestic” against the host state and card-present transactions test the terminal location as well as the two providers.
• Map every product to exactly one breakdown — prepaid card products in particular belong in e-money, not in the card breakdowns.
• Keep periods open for 13 months so authority adjustment requests can be serviced from data rather than from reconstruction.
• Reconcile the SCA fields against your exemption strategy. The non-exemption categories added in 2020 will expose any gap between what you claim and what you apply — see our note on SCA exemptions under the RTS.

Related: SCA exemptions and the RTS · Major incident reporting under PSD2 and DORA · Verification of Payee under the IPR