Payment fraud typologies — the supervisor’s taxonomy
There is an official EU fraud taxonomy, and it is not the one most firms use internally. The EBA Guidelines on reporting requirements for fraud data under Article 96(6) of PSD2 — EBA/GL/2018/05, in the version consolidated in January 2020 — divide all reportable payment fraud into exactly two categories, then break the first into two, then break card fraud into five. Every fraud statistic a European supervisor sees is shaped by that structure, so a firm whose internal categories do not map onto it is doing a translation exercise every quarter.
1. Two categories, and the line between them
Guideline 1.1 requires a payment service provider to report, for each reporting period:
| Category | Definition |
|---|---|
| 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 by 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 |
| Manipulation of the payer | Transactions made as a result of the payer being manipulated by the fraudster to issue a payment order, or to instruct the payment service provider to do so, in good faith, to a payment account the payer believes belongs to a legitimate payee |
The dividing line is consent. In the first category the payer did not authorise the transaction; in the second the payer did authorise it, but was deceived about who the payee was. That single distinction drives liability analysis, customer communication, control design and — because the two are reported separately — the shape of the numbers a supervisor compares you against.
2. Inside “unauthorised”: issuance and modification
Guideline 1.6 defines two sub-types, and they describe genuinely different attacks:
- Issuance of a payment order by the fraudster — a fake payment order is issued by the fraudster after having obtained the payer’s or payee’s sensitive payment data through fraudulent means. The attack happened earlier, against the data; the payment is the consequence.
- Modification of a payment order by the fraudster — the fraudster intercepts and modifies a legitimate payment order at some point during the electronic communication between the payer’s device and the payment service provider (for example through malware, or attacks allowing an attacker to eavesdrop between two legitimately communicating hosts), or modifies the payment instruction in the provider’s system before the order is cleared and settled.
The second half of the modification definition is the one firms under-read: it expressly includes modification inside the provider’s own system before clearing and settlement. That is an internal-integrity scenario, not a customer-channel one, and the controls that address it live in a different team.
3. Card fraud: five sub-types, split by authentication
For card payments the guidelines break “issuance of a payment order by a fraudster” into five named types — lost or stolen card, card not received, counterfeit card, card details theft, and other — and require the whole breakdown to be reported separately for transactions authenticated via strong customer authentication and those authenticated via non-strong customer authentication.
That split is the analytically valuable part. Fraud on SCA-authenticated transactions and fraud on non-SCA transactions tell different stories: the first points at authentication compromise or social engineering, the second at exemption usage and its calibration. Reporting them together destroys the signal that the taxonomy was designed to produce.
4. What counts, and what does not
Three counting rules decide whether your numbers are comparable to anyone else’s:
- Only initiated and executed transactions. Guideline 1.2 says providers should report only payment transactions that have been initiated and executed, and should not report transactions that, however linked to the circumstances in Guideline 1.1, were not executed and did not result in a transfer of funds. Blocked and prevented attempts are excluded — which means the published fraud statistics systematically understate attack volume, and your prevention performance is invisible in them.
- Recovery does not reduce the count. Under Guideline 1.6(a), total fraudulent payment transactions include all such transactions regardless of whether the amount has been recovered.
- Volume and value, both. Guideline 2.2 requires reporting in terms of both the number and the amount of transactions, in actual units, with two decimals for values.
5. Who reports which leg
Two allocation rules prevent double counting across a payment chain:
| Situation | Who reports |
|---|---|
| Money remittance where funds move from the payer’s provider to the payer’s money remitter | The payer’s payment service provider, not the money remitter — and not the provider of the beneficiary |
| Funds transferred by a money remitter from its accounts to a beneficiary account, including under netting arrangements | The money remitter |
| E-money transferred by an e-money provider to a beneficiary account | The e-money provider; where the payer’s and payee’s providers differ, only the payer’s provider reports |
FAQ
Where does authorised push payment fraud sit in this taxonomy?
In the second category — manipulation of the payer. The payer issues the order in good faith to an account they believe belongs to a legitimate payee.
Do blocked fraud attempts get reported?
No. Guideline 1.2 limits reporting to transactions initiated and executed. Transactions that did not result in a transfer of funds are outside the statistics.
Why report SCA and non-SCA fraud separately?
Because the causes differ. Fraud surviving strong customer authentication implicates authentication compromise or manipulation; fraud on non-authenticated transactions implicates exemption usage and its calibration.
Does recovering the money reduce the reported fraud?
Not the transaction count — Guideline 1.6(a) includes fraudulent transactions regardless of recovery. Recovery affects the separate loss figures.
Related: PSD2 fraud reporting · Manipulation of the payer · SCA exemptions
