A global processor or an issuer with cardholders across the European Union and Australia cannot simply pick one regulatory regime and apply it everywhere. EU cardholders fall under PSD2’s Strong Customer Authentication rules today and the incoming PSD3/Payment Services Regulation framework as it phases in, while Australian-issued cards fall under AusPayNet’s CNP Fraud Mitigation Framework, part of Volume 7 of the Issuers and Acquirers Code Set. Multi-jurisdictional 3DS compliance is fundamentally an architecture problem: can one Access Control Server apply different exemption thresholds, reporting obligations and fraud-monitoring rules to different cardholder populations, or does every jurisdiction require its own deployment? This article walks through the current state of PSD2, the incoming PSD3/PSR regime, and AusPayNet’s framework, and sets out what a single, well-configured ACS needs to do to serve issuers operating across all three.

Why Multi-Jurisdictional Compliance Is an Architecture Problem, Not Just a Legal One

Compliance teams tend to treat PSD2, PSD3 and AusPayNet obligations as separate legal work streams, each owned by a different regional counsel. From an ACS operator’s perspective, however, every one of those obligations eventually resolves to a configuration decision inside the authentication platform: which transactions qualify for a low-risk exemption, what data must be logged for a regulator’s audit, and which fraud-reporting thresholds trigger an internal escalation. An issuer or processor operating in only one jurisdiction can hard-code these rules into its ACS deployment. An issuer or processor operating across the EU, the UK and Australia – or a programme manager hosting issuing clients from each of those markets on shared infrastructure – needs an ACS that treats jurisdictional rules as configuration, applied per cardholder population or per issuing tenant, rather than as a fixed property of the whole platform. Getting this wrong does not just create legal exposure, it forces a choice between over-applying the strictest regime everywhere, adding unnecessary friction for cardholders in less prescriptive markets, or maintaining separate ACS deployments per jurisdiction, which reintroduces the integration and certification overhead a single platform was meant to avoid. Neither outcome is acceptable at scale, which is why regulatory readiness deserves the same architectural scrutiny as any other platform requirement rather than being treated purely as a compliance sign-off.

PSD2 Today, and the Incoming PSD3/Payment Services Regulation

PSD2’s Regulatory Technical Standards on Strong Customer Authentication remain the operative EU requirement today, and EMV 3DS is the mechanism most issuers and acquirers use to meet the two-factor authentication and dynamic linking requirements it sets out. The next phase of EU payments regulation is now taking shape: the European Parliament, Council and Commission reached final agreement on the text of PSD3 and its companion Payment Services Regulation (PSR) in 2026, following several years of negotiation, and the package is expected to be published in the Official Journal shortly after. Based on current legal commentary, the PSR – which will apply directly across member states without national transposition – is anticipated to enter into force around 2027 after a transition period, while PSD3 itself requires national transposition and is targeted for applicability around 2028.

The PSR is expected to strengthen fraud-liability rules, including for authorised push payment fraud, and tighten payee-verification style obligations, alongside carrying forward and refining the SCA regime issuers already comply with under PSD2. Because these dates depend on final Official Journal publication and each member state’s transposition timetable, issuers should treat the 2027-2028 window as directional rather than fixed, and confirm the current position with EU counsel or the European Commission’s payments policy pages before setting internal deadlines.

AusPayNet’s CNP Fraud Mitigation Framework for Australian Issuers

In Australia, card-not-present fraud obligations sit under AusPayNet’s CNP Fraud Mitigation Framework, which forms Volume 7 of the Issuers and Acquirers Code Set and has applied since 1 July 2019. Under the Framework, issuers are required to keep fraud levels across their card base below an industry benchmark and must notify cardholders of online transactions above a set threshold unless the cardholder has opted out. AusPayNet’s current focus, through 2025 and 2026, is on overseas card-not-present fraud specifically: AusPayNet reports that while overseas spend accounts for only around 3 per cent of total Australian card spend, it accounts for roughly 51 per cent of all card fraud, and the industry body is working with members on root-cause analysis and mitigation options for this specific exposure.

For an ACS operating in Australia, this means risk rules need to be sensitive to transaction geography specifically, not just device or behavioural signals, and reporting needs to be structured to demonstrate the issuer’s fraud rate against the industry benchmark AusPayNet monitors. Issuers should also expect this focus area to sharpen further as AusPayNet’s root-cause work on overseas fraud progresses, so an ACS with configurable, geography-aware risk rules is better placed to adapt without a platform change.

Running One ACS Across Multiple Regulatory Regimes

A single ACS instance serving issuers or cardholder populations across the EU, UK, and Australia needs jurisdiction-aware configuration at the same level of granularity as the per-issuer configuration discussed in ACS multi-tenancy architecture. In practice this means exemption logic that reflects PSD2/PSD3 thresholds for EU cardholders without being forced onto an Australian issuing client that answers to AusPayNet instead, geography-sensitive risk rules that can flag overseas CNP transactions specifically for an Australian book, and reporting outputs structured differently per regulator – SCA exemption reporting for an EU national competent authority looks nothing like the fraud-rate reporting AusPayNet expects. The platform-level EMVCo and PCI 3DS certification remains common across all tenants and jurisdictions; what changes is the configuration layer sitting on top of it, and that is where compliance teams and payment architects need to focus their evaluation of any ACS vendor operating across borders. A useful diagnostic question during vendor evaluation is simply: if a new jurisdiction were added tomorrow, would it require a configuration change or a development request.

GPayments tip: When shortlisting an ACS for multi-jurisdictional operation, ask the vendor to show – not just describe – how an EU exemption rule and an AusPayNet-driven overseas-transaction rule can run concurrently on the same instance without cross-contaminating each other’s reporting.

Reference: AusPayNet — CNP Fraud Mitigation Framework

Conclusion

PSD2 is already mandatory, PSD3 and the PSR are on a multi-year path to applicability, and AusPayNet’s CNP Framework continues to sharpen its focus on overseas fraud – and an issuer or processor operating across these markets cannot afford an ACS that treats jurisdiction as an afterthought. The practical answer is a platform that separates shared, certified infrastructure from a configurable compliance layer applied per cardholder population or issuing tenant, so EU exemption rules and Australian fraud-rate obligations can run concurrently without contaminating each other’s reporting. GPayments builds ActiveAccess to support exactly this kind of per-tenant regulatory configuration on shared, EMVCo- and PCI 3DS-certified infrastructure.

Talk to a GPayments Solutions Architect Operating across multiple regulatory regimes? Talk to a GPayments solutions architect about configuring ActiveAccess for your specific PSD2/PSD3 and AusPayNet compliance needs, or request a demo. Contact sales@gpayments.com or visit gpayments.com/contact.

Frequently Asked Questions

What is multi-jurisdictional 3DS compliance, and why does it require more than a single rule set?

Multi-jurisdictional 3DS compliance means an Access Control Server can apply different regulatory obligations – such as PSD2/PSD3 Strong Customer Authentication rules in the EU and AusPayNet’s CNP Fraud Mitigation Framework in Australia – to different cardholder populations or issuing tenants on the same platform. A single fixed rule set cannot satisfy multiple regulators’ distinct exemption, reporting and fraud-threshold requirements simultaneously.

How should an issuer configure one ACS to meet both EU and Australian regulatory obligations?

Configure jurisdictional rules as a layer on top of the certified ACS platform, applied per cardholder population or issuing tenant rather than platform-wide. This includes region-specific exemption logic, geography-aware fraud rules for overseas transactions, and separate reporting outputs formatted for each regulator, while the underlying EMVCo and PCI 3DS certification remains shared infrastructure.

Does multi-jurisdictional compliance matter for an issuer that only operates domestically in Australia?

A domestic-only Australian issuer still needs to comply with AusPayNet’s CNP Fraud Mitigation Framework, including the current focus on overseas CNP fraud affecting Australian-issued cards used abroad, so jurisdiction-aware configuration matters even without EU exposure. Multi-jurisdictional architecture becomes essential once a processor hosts issuing clients from more than one region on shared infrastructure.

What is changing under PSD3 and the Payment Services Regulation that issuers should prepare for?

PSD3 and its companion Payment Services Regulation were finalised in 2026 and are expected to phase in from around 2027, carrying forward PSD2’s Strong Customer Authentication requirements while strengthening fraud-liability and payee-verification rules. Exact timing depends on Official Journal publication and national transposition, so issuers should treat 2027-2028 as directional and confirm details with EU counsel.