how do psd3 and psr affect the ATM businesses, from the business perspective?

The transition from the Second Payment Services Directive (PSD2) to the dual-track of **PSD3** and the **Payment Services Regulation (PSR)** represents a fundamental shift in the European Union’s legislative architecture: the move from "harmonization" to "uniformity." While directives require national transposition—allowing for the idiosyncratic "gold-plating" that plagued PSD2—a Regulation is directly applicable across all Member States. This shift is designed to eliminate the arbitrage opportunities currently exploited by firms headquartered in jurisdictions with more "permissive" interpretations of security mandates. ## The Legislative Roadmap and Convergence The legislative journey began with the [European Commission's proposal in June 2023](https://finance.ec.europa.eu/publications/financial-services-making-payments-and-data-sharing-safer-and-more-efficient-consumers-and_en). As of early 2024, the package is navigating the "trilogue" negotiations between the Commission, the Parliament, and the Council. 1. **Finalization (Late 2024 - Early 2025):** Expect the final texts to be adopted and published in the Official Journal of the EU. 2. **Transposition Window (18–24 Months):** Member States will have roughly 18 months to integrate PSD3 into national law, while the PSR will apply directly. 3. **The "Go-Live" (Estimated 2026):** Most provisions will become enforceable, creating a high-pressure compliance window for Payment Service Providers (PSPs). ## Beyond Compliance: The "Verification of Payee" Mandate A critical mechanism introduced in the PSR is the mandatory **Verification of Payee (VoP)**. Unlike the optional schemes currently seen in various markets (such as the UK’s Confirmation of Payee), the PSR mandates that PSPs check the match between the IBAN and the name of the beneficiary before a credit transfer is executed. > "To address new forms of fraud, such as 'social engineering' where victims are manipulated into authorizing a payment, the PSR introduces a mandatory service to check the alignment between the name and the unique identifier of the payee." — [European Commission Explanatory Memorandum](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52023PC0367) This creates a technical "handshake" requirement that forces a level of interoperability previously unseen in the SEPA (Single Euro Payments Area) zone. ## The Tension Between PSR and FIDA The PSD3/PSR package does not exist in a vacuum; it must be viewed alongside the **Framework for Financial Data Access (FIDA)**. While PSR focuses on payment accounts, FIDA extends "Open Finance" to a broader range of financial products (insurance, pensions, investments). A productive tension exists here: PSR tightens the security of the "payment rail" through stricter **Strong Customer Authentication (SCA)** rules—such as requiring SCA for the first bind of a payment instrument to a digital wallet—while FIDA simultaneously pushes for greater data liquidity. This creates a "security-friction paradox." The PSR aims to reduce fraud by adding friction (VoP and stricter SCA), while the broader EU digital strategy aims to remove friction for data sharing. For technical architects, this means the 2026 deadline is not just a regulatory hurdle, but a complex engineering challenge to maintain a seamless user experience within a significantly more rigid security framework.

While the move from Directive to Regulation ensures uniformity, the most contentious debates currently centers on a radical recalibration of liability and the technical "death sentence" for subpar banking interfaces. ## The Impersonation Fraud Liability Shift The PSR introduces a "reversal of burden" that moves the EU closer to the UK’s [Contingent Reimbursement Model](https://www.psr.org.uk/our-work/app-fraud-performance-data/). Under PSD2, victims of "social engineering" (vishing or spoofing) often faced an uphill battle proving they were not "grossly negligent." The PSR proposal explicitly targets "impersonation fraud"—where a fraudster poses as a bank employee. > "Where a consumer has been manipulated by a third party pretending to be an employee of the consumer’s payment service provider... the payment service provider shall be liable for the full amount of the fraudulent payment transaction." — [Proposed Article 59, Payment Services Regulation](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52023PC0367) This creates a high-stakes technical debate: if a bank is liable for the "human" element of a scam, they must move beyond transaction monitoring into **behavioral biometrics** and cross-channel signaling. Critics, particularly from the [European Banking Federation (EBF)](https://www.ebf.eu/payments/ebf-response-to-the-payment-services-package/), argue this may inadvertently encourage "moral hazard" by reducing consumer vigilance. ## The API Performance Parity and the Fallback Debate A major friction point in PSD2 was the unreliability of Dedicated Interfaces (APIs), which forced regulators to mandate "fallback mechanisms" (screen scraping). The PSR aims to kill screen scraping by introducing strict **Performance Parity**. 1. **Quantitative Metrics:** ASPSPs (banks) must now provide the same uptime and response times for Third-Party Providers (TPPs) as they do for their own digital banking apps. 2. **The "Permission Dashboard":** To balance data liquidity with security, the PSR mandates that banks provide users with a dashboard to manage and revoke data permissions. This turns the bank from a passive data repository into an active **Identity and Permission Provider**. ## The "Digital Exclusion" Paradox There is a growing tension between the PSR’s push for **Strong Customer Authentication (SCA)** and the [European Accessibility Act](https://ec.europa.eu/social/main.jsp?catId=1202). The PSR mandates that SCA must not depend on a single technology (like a smartphone). For technical architects, this is a "non-functional requirement" nightmare: how do you maintain a high-security posture (meeting PSR standards) while ensuring that a customer without a smartphone or biometric-capable device can still execute a payment? This "accessibility mandate" forces the industry to revisit hardware tokens or "knowledge-based" factors that were previously being phased out in favor of "inherence" (biometrics). ## Interdependence with the Instant Payments Regulation (IPR) The PSR does not act alone; it is synchronized with the [Instant Payments Regulation (EU 2024/886)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R0886). The IPR makes instant euro transfers the "new normal," requiring them to be priced no higher than standard credit transfers. This eliminates the "time buffer" previously used for fraud detection. Consequently, the **Verification of Payee (VoP)** mentioned in the Foundation becomes a real-time, sub-second requirement, turning a compliance check into a high-availability infrastructure challenge.

The shift from PSD2 to the PSR (Payment Services Regulation) represents a move from regulating **access** to regulating **intent**. As we pivot from the technical plumbing of APIs to the legal accountability of "impersonation," we enter a realm where financial law intersects with cognitive science, cryptography, and information economics. ## 1. The Oracle Problem: Bridging Digital Execution and Human Intent If a transaction is cryptographically "valid" (signed with the correct private key) but "unintended" (induced by a fraudster), is the system broken, or is the human? The PSR’s liability shift treats banks as the ultimate "Oracles" of human intent. This mirrors the **Oracle Problem** in decentralized finance—the difficulty of getting real-world data (like "I am being coerced") into a deterministic system. Exploring this would unlock a new dimension: the technical impossibility of proving "negative intent" without invasive behavioral monitoring. - **Primary Source:** Nick Szabo’s seminal 1996 essay, [Smart Contracts: Building Blocks for Digital Markets](https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart.contracts.html). It provides the foundational logic for why "code as law" fails when the human interface is compromised. ## 2. The Privacy-Safety Paradox: Surveillance Capitalism as a Compliance Tool To meet PSR Article 59 requirements and stop "vishing," banks must monitor not just *what* you spend, but *how* you hold your phone, your typing cadence, and your atmospheric pressure (to detect "location spoofing"). This creates a collision course with **GDPR's principle of Data Minimization**. We are entering a "Panopticon of Payments" where financial security can only be guaranteed by total behavioral surveillance. This rabbit hole explores whether the PSR inadvertently mandates the very "Surveillance Capitalism" that European privacy laws seek to dismantle. - **Primary Source:** Shoshana Zuboff’s *The Age of Surveillance Capitalism*. Her analysis of "behavioral surplus" is essential for understanding the unintended consequences of banks becoming behavioral observers to mitigate liability. ## 3. Zero-Knowledge Proofs (ZKP) and the "Digital Exclusion" Resolution How do we solve the "Digital Exclusion Paradox" (providing SCA for non-smartphone users) without weakening security? The answer may lie in **Zero-Knowledge Proofs**, which allow a user to prove they possess a secret (knowledge) or a characteristic (identity) without revealing the data itself or relying on a high-end device. Investigating ZKPs in the context of the PSR would reveal a path toward "Privacy-Preserving Inclusion," where hardware tokens or even analog methods could generate a cryptographic proof that satisfies the regulator without requiring an iPhone. - **Primary Source:** [Eli Ben-Sasson et al., "Scalable, transparent, and post-quantum secure computational integrity"](https://eprint.iacr.org/2018/046). This work on STARKs explains how we can verify complex claims (like SCA) with minimal data overhead. ## 4. Adverse Selection and the "Lemons" Market of Financial Data The PSR mandates **API Performance Parity**, but it cannot easily mandate **Information Parity**. In a world where banks must share data with Third-Party Providers (TPPs), "Adverse Selection" suggests that banks will strategically share "clean" data while keeping the "predictive" data (the insights derived from AI) for themselves. This rabbit hole examines the economic friction of Open Finance: will mandated sharing lead to a "Market for Lemons" where the only data moving through APIs is that which has the least competitive value? - **Primary Source:** George Akerlof’s [The Market for "Lemons": Quality Uncertainty and the Market Mechanism](https://www.jstor.org/stable/1879431). This text is vital for understanding why technical parity does not equal economic equality in data ecosystems.