Europe has spent the better part of a decade rewriting the rulebook for digital payments and financial resilience. First came PSD2 in 2018, which forced open banking into existence and made Strong Customer Authentication (SCA) a legal requirement rather than a nice-to-have. Now, the region is finishing the next chapter: PSD3 (still moving through the EU legislative process) and the Digital Operational Resilience Act (DORA), which became fully applicable in January 2025. 

For banks, fintechs, and payment service providers in APAC and MEA, this isn't a story happening "over there." It's a preview. Regulators across India, Southeast Asia, the GCC, and Africa are watching Europe's experiment closely — borrowing what worked, avoiding what didn't, and, in some cases, leapfrogging Europe entirely with sharper, faster-moving frameworks of their own. 

This blog breaks down what PSD2, PSD3, and DORA actually changed, what's still evolving, and — most importantly — what fraud and risk management (FRM) teams in APAC and MEA should be doing right now to stay ahead of where regulation is clearly headed. 

A Quick Primer: What PSD2, PSD3, and DORA Actually Do 

PSD2 (Revised Payment Services Directive, 2018) did three big things: 

1. Mandated Strong Customer Authentication (SCA) — requiring at least two independent factors (something you know, have, or are) for most electronic payments, closing the door on single-factor card payments for a huge share of European transactions. 

2. Opened up banking data via APIs — forcing banks to let licensed third parties (Account Information Service Providers and Payment Initiation Service Providers) access customer account data and initiate payments, with consent. 

3. Introduced liability rules — shifting fraud liability in ways that pushed banks and PSPs to actually invest in fraud prevention rather than pass the cost to consumers or card networks. 

PSD3 (proposed, still being finalized) is Europe's attempt to fix what PSD2 got wrong in practice: 

• Tackling APP fraud and impersonation scams — PSD2 was built to stop unauthorized transactions. It did very little for authorized push payment (APP) fraud, where the victim is tricked into initiating the payment themselves. PSD3, alongside the related Payment Services Regulation (PSR), is expected to introduce IBAN/name-matching checks (similar to the UK's Confirmation of Payee), extend refund rights to certain APP fraud victims, and tighten liability for banks that fail to act on fraud red flags. 

• Fixing Open Banking friction — API performance standards, better dispute resolution between banks and third-party providers, and permanent removal of the fallback screen-scraping option. 

• Extending SCA obligations and clarifying exemptions that caused confusion (and abandoned transactions) under PSD2. 

• Merging into a directly applicable Regulation (PSR) for parts of the framework — reducing the patchwork of national interpretations that made PSD2 inconsistent across EU member states. 

DORA (Digital Operational Resilience Act, applicable since January 2025)

DORA is not about payments fraud — it's about operational and cyber resilience across the entire financial sector, including banks, payment institutions, insurers, and crucially, their critical third-party technology providers (cloud vendors, core banking platforms, fraud and risk vendors, and so on). DORA requires: 

• ICT risk management frameworks with board-level accountability 

• Mandatory incident classification and reporting within tight timelines 

• Regular resilience testing, including threat-led penetration testing for larger institutions 

• Third-party risk oversight — meaning your fraud and risk vendor's resilience is now your regulatory problem 

• A registered oversight regime for "critical" ICT third-party providers, with regulators able to directly supervise big tech and cloud vendors serving finance 

Put together, PSD2/PSD3 answers "how do we stop fraud and scams in payments," while DORA answers "how do we make sure the financial system doesn't collapse when a vendor gets breached, a cloud region goes down, or a critical system fails." Both are increasingly relevant blueprints for APAC and MEA regulators who are watching the same digital payment boom — and the same fraud typologies — arrive on their own shores. 

Why This Matters Beyond Europe 

APAC and MEA are not waiting for a European-style directive to land before they act. If anything, several regulators in these regions have already moved faster than the EU in specific areas — India's SCA-equivalent requirements around card-not-present transactions and OTP-based authentication predate much of PSD2's practical enforcement. But there are three structural reasons why European regulation is still worth studying closely: 

1. Fraud typologies don't respect borders. APP fraud, mule networks, deepfake-enabled onboarding fraud, and API abuse are global patterns. Europe has years of enforcement data on what works and what doesn't — that's a shortcut APAC/MEA regulators and FRM teams don't have to build from scratch. 

2. Regulatory convergence is a business reality. Any bank, PSP, or fintech in APAC/MEA that serves European customers, partners with European banks, or uses European-headquartered technology vendors will feel DORA's third-party oversight requirements indirectly — even without being directly regulated by it. 

3. Regulators talk to each other. Central banks and financial regulators across G20 and emerging markets actively study each other's frameworks. RBI, MAS, BNM, SAMA, and the UAE's regulators all reference international standards (FATF, BCBS, and increasingly EU frameworks) when drafting local rules. What happens in Brussels today often shapes the next consultation paper in Mumbai, Riyadh, or Jakarta. 

Lesson 1: Strong Authentication Alone Doesn't Stop Fraud — It Just Moves It 

Europe's experience with SCA under PSD2 is instructive precisely because of its unintended consequence: fraud didn't disappear, it evolved. Card-not-present fraud dropped, but APP fraud and social engineering scams — where the victim authenticates the transaction themselves under a criminal's instruction — exploded. UK Finance and European Banking Authority data consistently show scam losses rising even as SCA closed off older attack vectors. 

The lesson for APAC/MEA: Markets currently rolling out or strengthening OTP, biometric, and device-binding authentication (India's RBI mandates, UAE's Central Bank Digital ID initiatives, Southeast Asia's various e-KYC frameworks) should build fraud detection for scams and social engineering now, rather than waiting for the losses to force a second wave of regulation, as Europe is currently experiencing with PSD3/PSR. 

This means FRM systems in the region need to look beyond "was this the right authentication factor" and start scoring "does this transaction behavior look like someone being coached by a scammer" — sudden large transfers to new payees, unusual time-of-day activity, victim behavior patterns during the transaction (hesitation, repeated login attempts, call activity on the device), and network-level mule account detection. 

Lesson 2: Open Banking Needs Liability Clarity Before It Needs More APIs 

PSD2's open banking mandate proved that regulation can create a market — but also that unclear liability slows adoption. Years into PSD2, disputes between banks and TPPs over who's responsible when fraud happens through a third-party-initiated payment remain a persistent friction point. PSD3/PSR is explicitly trying to fix this with clearer liability allocation and mandatory participation in dispute resolution schemes. 

The lesson for APAC/MEA: India's Account Aggregator framework, Singapore's SGFinDex, Brazil's Open Finance (a useful non-European comparator), and various GCC open banking initiatives are all at earlier stages of the same journey Europe has been on since 2018. The single biggest accelerant — or blocker — for open banking adoption in these markets will be whether liability and fraud-loss allocation between banks, TPPs, and aggregators is defined clearly before volumes scale, not after disputes pile up. 

FRM systems supporting open banking ecosystems need to be built for multi-party transaction visibility from day one — able to trace a transaction across the account-holding institution, the initiating TPP, and any intermediary, so liability questions can be answered with data rather than argument. 

Lesson 3: Real-Time Payments Need Real-Time Fraud Detection — Not Post-Transaction Monitoring 

This is arguably the most urgent lesson, and it's one where APAC in particular has real leverage. UPI in India, PayNow in Singapore, PromptPay in Thailand, and DuitNow in Malaysia already process instant payments at a scale most of Europe hasn't reached (SEPA Instant adoption still lags significantly behind UPI's daily volumes). The irony is that Europe's slower instant-payments rollout gave it a head start on regulating fraud response — DORA's incident reporting timelines and PSD3's proposed IBAN-name-matching checks are direct responses to the fact that instant payments leave almost no window for manual fraud review. 

The lesson for APAC/MEA: Markets with mature real-time rails cannot rely on the traditional "detect after settlement, claw back later" model — the money is often gone in seconds, moved through multiple mule accounts before any manual review would even begin. This is exactly why real-time, in-line fraud scoring (decisioning within the payment flow, not after it) needs to be non-negotiable infrastructure, not a premium feature. 

For regulators in these markets, there's also a lesson in how to mandate this: rather than waiting for consumer harm data to justify a rule (as happened with APP fraud in the UK and EU), proactively requiring real-time fraud monitoring as a licensing condition for real-time payment participation would close the gap before it opens. 

Lesson 4: Third-Party and Vendor Risk Is Now Core Regulatory Territory 

DORA's most structurally important idea is this: a bank's operational resilience is only as strong as its weakest critical vendor. This is not a new idea in theory (BCBS and FSB have written about third-party risk for years), but DORA is the first framework to put real regulatory teeth behind it — including the ability for EU authorities to directly oversee and sanction "critical" ICT third-party providers, even ones headquartered outside the EU. 

The lesson for APAC/MEA: As banks and fintechs in these regions increasingly rely on cloud infrastructure, core banking platforms, KYC/identity vendors, and fraud/risk management systems from a concentrated set of global and regional providers, the same systemic risk exists — a breach or outage at one major vendor could ripple across dozens of institutions simultaneously. RBI's outsourcing and IT governance guidelines, MAS's Technology Risk Management guidelines, and SAMA's Cyber Security Framework already gesture at this, but few APAC/MEA frameworks yet have DORA's teeth — mandatory incident reporting timelines, resilience testing requirements, and direct oversight of critical vendors. 

Institutions operating in this region should treat vendor resilience due diligence — including for their FRM and fraud detection stack — as a board-level governance issue now, rather than waiting for a DORA-equivalent mandate to force the conversation. Practical steps include: 

• Requiring fraud/risk vendors to provide incident response SLAs and breach notification commitments in contracts, not just uptime guarantees 

• Running resilience and failover testing on critical fraud infrastructure, not just customer-facing systems 

• Maintaining exit and portability plans for concentrated dependencies (a single fraud vendor, a single cloud region) 

Lesson 5: Regulatory Fragmentation Is a Cost Center — Push for Consistency 

One of PSD2's quiet failures was inconsistent implementation across EU member states — different interpretations of SCA exemptions, different enforcement timelines, different approaches to liability. PSD3's shift toward a directly applicable Regulation (PSR) for large parts of the framework is a direct admission that directives-with-national-discretion create compliance overhead without corresponding fraud-prevention benefit. 

The lesson for APAC/MEA: These are far more fragmented regions than the EU to begin with — different regulators, different data protection regimes, different payment rails across India, ASEAN, GCC, and Africa. Institutions operating across borders in these regions should expect (and plan for) fraud and risk compliance requirements that vary market to market for years to come. The practical response is architectural: build FRM systems with configurable rule and compliance layers per market, rather than hard-coding to a single regulatory assumption, so that adapting to Saudi Arabia's SAMA requirements versus India's RBI requirements versus Indonesia's OJK requirements is a configuration exercise, not a re-platforming project. 

What This Means for FRM Strategy in APAC and MEA 

Bringing these lessons together, a forward-looking FRM strategy for institutions in these markets should be built around a few core principles: 

• Design for scams, not just unauthorized fraud. Behavioral analytics, payee risk scoring, and real-time intervention prompts (similar to the UK's "stop and think" warnings) should be built in before scam losses force regulatory intervention. 

• Make liability traceable. Any FRM system supporting open banking or multi-party payment flows needs end-to-end transaction visibility to support fast, evidence-based liability resolution. 

• Score risk in-line, not after the fact. For any market with real-time payment rails, in-line decisioning is a baseline requirement, not a differentiator. 

• Treat vendor resilience as a first-class risk category. Ask fraud and risk vendors the same operational resilience questions European regulators are now asking under DORA — incident response times, third-party dependency mapping, business continuity testing. 

• Build for regulatory plurality. A single global rules engine won't survive contact with APAC/MEA's regulatory diversity. Configurability by market, by rail, and by product line is a resilience feature in itself. 

The Opportunity for APAC and MEA 

There's a genuine opportunity here that goes beyond just "catching up" to Europe. Because APAC and MEA markets are building (or rebuilding) their digital payments infrastructure now, with the benefit of watching Europe's decade-long experiment play out, they can skip several painful iterations. Instant payment rails can be launched with real-time fraud detection built in from day one, rather than retrofitted after scam losses mount. Open banking frameworks can define liability clearly before volumes scale into the billions. And vendor resilience oversight can be designed into licensing regimes from the start, rather than bolted on after a systemic outage forces the issue. 

Getting this right requires fraud and risk infrastructure that's built for this reality — real-time, network-aware, configurable across markets and rails, and resilient by design. That's precisely the gap M2P's FRM system is built to close: giving banks, fintechs, and PSPs across these markets the tools to detect fraud in the payment flow itself, trace risk across multi-party transactions, and adapt to a genuinely fragmented — but fast-moving — regulatory landscape. 

Europe spent a decade learning these lessons the hard way, through enforcement data, consumer harm, and iterative regulation. APAC and MEA don't have to. 

From real-time scam detection and transaction monitoring to risk orchestration and compliance support, M2P's FRM platform is designed to help banks, fintechs, and PSPs navigate a rapidly changing regulatory landscape with confidence. Whether you're preparing for future mandates or strengthening existing controls, our experts can help you build a fraud-resilient payments ecosystem. Reach out to M2P today to discuss your fraud and compliance priorities and explore the right solution for your business.

Disclaimer: PSD3 and the accompanying Payment Services Regulation were still moving through the EU legislative process as of this writing, and specific provisions may change before final adoption. Readers should verify the latest status with official EU sources or their compliance advisors before making regulatory decisions based on this article.