EU PSR: the Council position and unattended payments

What happened on 29 October

The vote took place at the 4205th meeting of the Council of the EU (Transport, Telecommunications and Energy) in Luxembourg. The result is recorded in Council document 15154/26 of 30 October 2026: all 27 member states voted in favour.

The Commission proposed the package on 28 June 2023: the PSD3 directive and the PSR regulation. The final political trilogue took place on 26 November 2025. The European Parliament’s ECON Committee approved the agreed text on 5 May 2026, and on 13 May its Chair wrote to the Council Presidency that she would recommend the Plenary accept the Council’s position at second reading if it matched the agreement, subject to legal-linguistic verification.

Unlike a directive, a regulation applies directly in every EU country once in force, with no national transposition. For a machine network spread across several countries, the rules will be the same everywhere.

IBAN and payee name check

The Council’s statement of reasons (document 8543/26 ADD 1 REV 1, point 12) says payment service providers must implement a checking mechanism that validates the alignment between the IBAN and the specific name of the beneficiary “prior to the execution of credit transfers”.

For euro transfers, euro-area banks have already verified the payee since October 2025 under the separate Instant Payments Regulation. Point 12 states the requirement for credit transfers without qualifying currency or speed; the exact scope will be set by the final text of the regulation.

For an operator this is mostly about incoming money: payouts from the payment provider, settlements with site landlords and network partners, customer payments against invoices. If contracts, invoices and payout settings spell the account holder’s name differently (abbreviations, an old name after re-registration), the payer’s bank will see the mismatch. Aligning those names is cheap preparation now.

Liability for bank impersonation fraud

Point 12 also establishes a rigorous liability regime for “spoofing” fraud, where fraudsters impersonate bank staff or official communication channels. If a payment service provider fails to deploy sufficient preventive systems or notice anomalies, it bears strict financial liability to reimburse defrauded consumers.

The same point requires major search engines and electronic platforms to verify the authorised status of financial advertisers and to share liability if illicit ads bypass verification. Payment institutions will be able to share fraud-related data among themselves.

This part protects consumers, not business accounts, so it does not directly change anything for a machine operator. Indirectly, banks and providers get a reason to watch anomalies more closely. A network with thousands of small payments benefits from an explainable per-device picture of revenue: if a provider asks about unusual turnover, the answer should be in the data.

Phone features for third-party apps

Point 13 reads: electronic communication services providers and manufacturers of mobile devices are required to allow third-party applications to access and utilise the device’s necessary technical features on fair, reasonable and non-discriminatory (FRAND) terms. The same point prohibits banks from artificial technical obstacles or discriminatory delays against authorised third-party providers accessing payment account data (open banking).

NFC is not named in the document: it speaks of “necessary technical features” without a list. For paying by phone at a machine, NFC is the feature that matters most, as it is what “tap your phone” runs on. That is our reading, not a quote, and how the requirement applies to specific features will be settled by the final text and practice.

What it may change at the machine: customers’ phones may gain new tap-to-pay apps from banks, national schemes or wallets such as Wero, whose participants announce point-of-sale payments via QR and NFC. The contactless reader on the machine does not change by itself: whether it accepts a new method depends on the payment scheme, the acquirer and the reader’s certification.

What an operator should do now

Nothing urgent: the rules are not in force. We do not give application dates because these two documents do not contain them; they will be in the final text published in the Official Journal.

Useful preparation does not depend on dates. Align the account holder’s name across contracts, invoices and payout settings. Keep the payment layer separate from the machine logic, so a new payment method is an integration rather than new hardware. Ask your acquirer and reader supplier which phone payment methods they plan to support.

This text explains public Council of the EU documents and is not legal advice. For the obligations of a specific company, talk to a lawyer and your bank.

Frequently asked