Unauthorised transactions — issuance vs modification

Unauthorised fraud has two official sub-types, and they point at completely different parts of your architecture. The EBA Guidelines on fraud reporting under Article 96(6) of PSD2 split it into issuance of a payment order by the fraudster and modification of a payment order by the fraudster. One is a consequence of stolen data. The other is an integrity failure in transit — or inside your own systems.

1. What “unauthorised” covers

The category is drafted broadly. It reaches transactions made including as a result of the loss, theft or misappropriation of sensitive payment data or a payment instrument, and it applies:

• whether or not the loss was detectable by the payer before the payment;
• whether or not it was caused by the gross negligence of the payer; and
• including transactions executed in the absence of consent by the payer.

2. Issuance of a payment order by the fraudster

Defined as a situation where 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 structure of this sub-type is worth pausing on: the fraud event and the data compromise are separated in time, often by a long interval. The payment is the last step of an attack whose decisive moment happened earlier — in a phishing page, a data breach, a compromised merchant, or a device infection. It follows that the controls with the highest leverage are upstream of the payment: credential hygiene, data-at-rest exposure, and detection of the compromise itself rather than of its downstream use.

For cards, this sub-type is broken down further into lost or stolen card, card not received, counterfeit card, card details theft, and other — a taxonomy that maps directly onto where in the card lifecycle the compromise happened.

3. Modification of a payment order by the fraudster

Defined as a situation where 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 instance through malware, or attacks allowing an attacker to eavesdrop on the communication between two legitimately communicating hosts — or modifies the payment instruction in the payment service provider’s system before the payment order is cleared and settled.

The third row is the one that most firms have never modelled as a fraud typology, because it does not look like fraud from the outside — it looks like an operational or insider-risk scenario. The guidelines put it in the fraud taxonomy anyway, which is a useful prompt: if a payment instruction can be altered between authorisation and settlement without leaving an independent trail, that is a reportable fraud pathway.

4. What this means for the numbers

Both sub-types feed the same reported category, but keeping them separated internally is what makes the data actionable. A rise in issuance-type fraud points outward, at data compromise and credential quality. A rise in modification-type fraud points inward, at channel and system integrity. Aggregated into one “unauthorised” figure, the two movements can cancel out entirely.

The reporting rules apply as elsewhere: only initiated and executed transactions count, recovery does not reduce the transaction count, and both volume and value are reported.

FAQ

Related: The supervisory fraud taxonomy · Card fraud typologies · Major ICT incident reporting