The most dangerous fraud in modern payments is the one the customer performs personally. Authorised push payment fraud — the victim initiates the transfer, convinced by a fake invoice, a spoofed bank call, or a fabricated investment — defeats every control built around “unauthorised” transactions. And with real-time rails now mandatory across the euro area, the stolen money moves at the speed of the infrastructure.
The typologies dominating the DACH market are familiar to every fraud team: invoice manipulation against businesses, where a supplier's IBAN is swapped in a compromised email thread; bank impersonation, where a caller “from the security department” walks a customer through the transfer that empties the account; and investment fraud, industrial-scale platforms promising crypto or forex returns, often with months of grooming before the extraction begins.
What Verification of Payee Actually Changes
Since October 2025, payment service providers in the euro area must check whether the payee name entered by the payer matches the account holder of the target IBAN — for instant and regular credit transfers alike — and warn the payer before execution when it does not. Against invoice manipulation, this is a genuinely sharp weapon: the swapped IBAN no longer matches the supplier's name, and the payer sees it before the money leaves.
Against impersonation and investment fraud, the effect is weaker, because the manipulated customer will click through warnings when the story is good enough. That is not a design failure — it is the reason verification of payee must be embedded in a layered defence rather than celebrated as one. The warning screen is a moment of friction; what the firm does with that moment — wording, risk-based escalation, cooling-off options for high-risk first-time payees — separates effective implementations from checkbox ones.
Fraudsters adapted to verification of payee before most banks finished implementing it. Controls that live in a single screen die in a single social-engineering script.
The Liability Direction of Travel
Under PSD2, authorised payments are, as a rule, the payer's problem — a rule that made sense when fraud meant stolen credentials and looks increasingly rough in the social-engineering era. The Payment Services Regulation (PSR), which is to replace PSD2 and on whose text Parliament and Council have agreed, moves the line for consumers: where a fraudster impersonates the customer's own payment service provider and the customer notifies the provider without undue delay and reports the fraud to the police, the provider must refund the full amount unless it proves fraud or gross negligence on the customer's part. Business customers are not covered; the regulation has not yet been formally adopted and will apply 21 months after it enters into force. The United Kingdom went further with mandatory reimbursement split between sending and receiving firms in 2024 — a regime DACH fraud teams study closely, because it prefigures the operational question that matters: once receiving institutions share liability, mule-account detection stops being a courtesy and becomes an economic necessity.
The Receiving Side: Where Mule Networks Live
Every authorised push payment ends in an account somebody opened. Mule networks — chains of accounts recruited, rented, or fabricated to receive and disperse stolen funds — are the logistics layer of APP fraud, and they concentrate wherever onboarding is fast and inbound monitoring is weak. The operational implications invert the traditional fraud focus: detection models tuned exclusively on outgoing payments miss the half of the problem that lives in receipts. Rapid in-and-out patterns, first-party accounts suddenly receiving unrelated third-party volumes, and clusters sharing devices or KYC artefacts are the signatures that matter.
The liability direction sharpens the incentive: in the United Kingdom, receiving firms bear half of the reimbursement, and under the agreed PSR text the payee's payment service provider is liable in the EU as well if it does not monitor incoming payments and the payer suffers a loss. Every weakly monitored inbound flow is therefore an underwritten loss. Fintechs with slick onboarding should read that sentence twice — the same funnel optimisation that wins customers also recruits mules, and supervisors increasingly ask what balances the two.
What Corporate Clients Should Demand
Business-payment fraud is preventable at the process level more than the transaction level, and sophisticated corporates now interrogate their payment providers accordingly: dual approval enforced server-side rather than in the client, out-of-band verification workflows for changed beneficiary details, payee allow-listing for recurring supplier runs, and APIs that expose verification-of-payee results to treasury systems. Payment firms serving the B2B segment should treat these capabilities as sales material — in the DACH enterprise market, a fraud-control conversation held confidently is a deal accelerant.
Building the Operational Stack
- Instrument the warning moment: risk-scored friction for first-time payees, high amounts, and unusual channels — not identical warnings for everything.
- Invest in inbound detection: mule typologies, rapid-dispersal patterns, and account-opening controls on the receiving side.
- Treat corporate clients separately: invoice-fraud education, dual-approval workflows, and IBAN-change verification processes prevent the losses that hurt most.
- Prepare data flows for cross-institution cooperation — fraud-data-sharing mechanisms are expanding across the EU framework.
- Measure by prevented value and customer trust, not alert counts.
The Human Layer: Education That Actually Works
Customer education is the most cited and worst executed fraud control. Generic “be careful” banners train blindness; what helps more is specificity at the decision moment — warnings that name the current scam pattern, quizzes embedded in onboarding for high-risk segments, and, for corporate clients, tabletop exercises that let a finance team experience a CEO-fraud attempt before the real one arrives. In our assessment, the DACH market adds a nuance: customers here respond strongly to institutional authority, which is likely to make co-branded warnings with police and supervisory bodies particularly effective compared to markets where such endorsements carry less weight.
The measurement discipline matters as much as the content: firms that A/B test warning language and track intervention outcomes treat education as a control with a conversion funnel — and they are the ones whose numbers move.
Conclusion
APP fraud is a systems problem: real-time rails, human psychology, and liability rules interacting faster than any single control can adapt. Verification of payee removed the easiest attack; the liability shift will redistribute the cost of the rest. Firms entering the DACH payments market should treat fraud operations as core product infrastructure — because their customers, their partner banks, and increasingly their regulators do. Aegiron Capital Group supports payment firms on the operational side of fraud prevention in the DACH market; legal advice comes from the law firm you engage.
Which licensing route fits your model?
The License Navigator places your business model in a few questions — free and without registration.
Start the License Navigator
Peter M. Badke
Founder, Aegiron Capital Group
Trained banker (Bankkaufmann, IHK), in sales and partnerships for fintech companies in the DACH region since 2021. Yale University online course “Financial Markets” (Coursera, with honors) and Certified Derivatives Trader (Deutsche Börse Group).
Drafted with AI tools; editorial responsibility: Peter M. Badke.
LinkedIn