Building the PSD2 fraud return — from case to file
The PSD2 fraud return is decided at case creation, months before anyone opens the reporting template. If the fraud case record does not carry the instrument and the fraud type as separate structured attributes, no amount of reporting effort will produce the required breakdowns — and the workaround, deriving them later from scheme reason codes, works for cards and for nothing else.
1. Two attributes, captured at the start
The taxonomy in the EBA fraud reporting guidelines is two-dimensional. Every reportable case needs a position on both axes:
| Axis | Values |
|---|---|
| Instrument | Credit transfer, direct debit, card payment, e-money transaction, cash withdrawal — each with its own reporting lines |
| Fraud type | Unauthorised — split into issuance of a payment order by the fraudster and modification of a payment order by the fraudster — or manipulation of the payer |
For cards, a third level applies within issuance by a fraudster — lost or stolen card, card not received, counterfeit card, card details theft, other — and the whole breakdown is reported separately for transactions authenticated with strong customer authentication and those without.
2. The population rules that surprise people
Three counting rules determine what enters the file, and each removes something a firm would naturally want to report:
- Only initiated and executed transactions. Providers report only payment transactions that have been initiated and executed, and should not report transactions that, however linked to a fraud circumstance, were not executed and did not result in a transfer of funds. Every blocked or prevented attempt is out of scope.
- Recovery does not reduce the count. Total fraudulent payment transactions include all such transactions regardless of whether the amount has been recovered.
- Volume and value, both, in actual units with two decimals for values.
The first rule has a strategic consequence worth stating internally: your prevention performance is invisible in this return. A firm that improves its blocking rate reports lower fraud without any published metric evidencing why — so if you want to be able to explain a fall, you need to measure prevented attempts yourself, outside the regulatory dataset.
3. The loss figure will not reconcile, by design
Losses due to fraud per liability bearer are reported on a cash-flow basis, split between the reporting provider, its payment service user, and others. Two drafting choices make the figure behave unlike the transaction counts:
- final fraud losses are reported in the period when they are recorded in the provider’s books, deliberately, to avoid endless revision of earlier periods as disputes and recoveries settle; and
- the figures do not take into account refunds by insurance agencies.
So the losses in a period do not correspond to the fraud transactions in that period, and any internal control reconciling the two will fail by design. Reconcile the loss figure to the general ledger and the transaction figure to the fraud case records — and keep the net-of-insurance number separately for management reporting, because the regulatory figure is gross of it.
4. Who reports which leg
Allocation rules prevent double counting across a chain. In money remittance, where funds move from the payer’s provider to the payer’s money remitter, it is the payer’s payment service provider that reports — not the money remitter, and not the beneficiary’s provider. Funds transferred by a money remitter from its own accounts to a beneficiary account, including under netting arrangements, are reported by the money remitter. And for e-money transferred to a beneficiary account, the e-money provider reports; where the payer’s and payee’s providers differ, only the payer’s provider reports.
These are the rules that make cross-firm reconciliation impossible without accounting for them, and they are the reason two firms in one chain can both be right while reporting different numbers.
5. The build sequence
Facts: a firm plans to build its fraud return from its existing dispute data.
What the analysis produces: dispute data is organised around a commercial process — chargebacks, claims, outcomes — and its categories are scheme categories. The return needs supervisory categories, on two axes, for every instrument the firm offers.
What the practitioner does: changes the case record before touching the reporting layer. Instrument and fraud type become mandatory structured fields at case creation, with the card sub-type and the authentication status captured where applicable. The return then becomes an aggregation over the case base rather than a translation exercise — and, as a by-product, the firm gains a fraud dataset it can actually analyse, which the dispute data never was.
FAQ
Do blocked fraud attempts count?
No. Only transactions initiated and executed are reported; anything that did not result in a transfer of funds is outside the statistics.
Why won’t losses reconcile to transactions?
Because losses are reported in the period they are recorded in the books, deliberately, to avoid revising earlier periods as disputes settle — and they exclude insurance refunds.
What is the single change that makes this buildable?
Capturing instrument and fraud type as structured fields at case creation, rather than deriving them later from payment-scheme reason codes.
Related: PSD2 fraud reporting · The supervisory fraud taxonomy · Fraud losses by liability bearer
