What payments compliance looks like when it's built into the infrastructure

PSD2, 3DS, PCI DSS, and AML explained.

PSD2, Strong Customer Authentication, 3DS, PCI DSS, AML, KYC: payments compliance is dense. For platform businesses embedding payments, getting it right is table stakes and doing so efficiently is the competitive edge.

Compliance makes product and commercial teams reach for the mute button. It evokes slow-moving regulators, legal review cycles, and a long tail of "no," a cost center standing between you and shipping.

For platform businesses building on payments infrastructure, that framing misses the point entirely. Compliance is what lets you move money, onboard merchants, and operate across markets. The question is whether you build that compliance infrastructure yourself, or work with a payments partner that already has it in place.

Below: the 4 most consequential compliance domains for payment platforms. PSD2/SCA, 3DS, PCI DSS, and AML/KYC. What each regulation actually requires, why it exists, and how Rootline's infrastructure approach removes the weight from your team.

01 · PSD2 & SCA

Strong Customer Authentication: the rule that changed how Europe pays

Card-not-present fraud surged as ecommerce scaled. Before PSD2, the liability and enforcement landscape was fragmented: some issuers challenged transactions aggressively, others barely at all. Merchants held fraud losses inconsistently.

Card-not-present fraud in Europe doubled between 2011 and 2016, reaching €1.32 billion. That's the trend that drove PSD2's Strong Customer Authentication mandate, per the ECB. Inconsistent authentication practices created security gaps and a poor checkout experience: too much friction in the wrong places, too little where it mattered.

What PSD2 and SCA actually require

PSD2, the Second Payment Services Directive, mandated Strong Customer Authentication across the EU and EEA. SCA requires that authentication of an electronic payment uses at least 2 of 3 independent factors: something you know (password, PIN), something you have (phone, card reader), something you are (fingerprint, face ID).

The regulation also defines exemptions: low-value transactions, trusted beneficiaries, low-risk transactions assessed via Transaction Risk Analysis (TRA). These are how merchants can reduce friction for genuine customers without compromising security.

Correctly implementing SCA means applying authentication where it's required, applying exemptions where they're available, and routing transactions through the right flows in real time. Done well: less friction for good customers, less fraud for merchants.

Why it matters for platforms

If your platform processes payments on behalf of merchants (ticketing, POS, SaaS, marketplaces, any other vertical), your checkout flows are directly in scope for SCA. Failure to apply it correctly creates liability exposure. Over-applying it creates friction that costs conversion.

How Rootline handles this

Rootline's payment infrastructure handles SCA compliance at the infrastructure layer. Authentication flows, exemption logic, and liability shift management are built into the payment stack, so your platform inherits compliance without building it from scratch. That includes dynamic exemption selection and TRA-based optimization to maximize approval rates while staying within regulatory boundaries.

PSD2 itself is being replaced. PSD3 and a directly applicable Payment Services Regulation (PSR) reached political agreement in late 2025, with entry into force expected in 2027. The PSR refines SCA rules (particularly around merchant-initiated transactions), introduces verification of payee for credit transfers, and merges the PI and EMI license regimes into a single payment institution authorization. The headline change for platforms: a single rulebook applied directly across all member states, replacing 27 national interpretations.

02 · EMVCo 3DS

3D Secure: authentication infrastructure that actually works

3D Secure is the technical protocol that enables SCA for card payments. The original version (3DS1) was notorious for poor UX: clunky redirects, static passwords, high abandonment. Technically compliant, commercially damaging.

3DS2 changed this. It enables risk-based authentication, supports biometrics, and allows for frictionless flows where the issuer approves a transaction without interrupting the user. But implementing a 3DS Server (the technical component between your payment infrastructure and the card scheme networks) requires certification from EMVCo.

Getting EMVCo 3DS Server certification is a significant undertaking. Conformance testing, security assessments, and an ongoing obligation to maintain certification as the protocol evolves. For most platforms, building and maintaining this internally makes little sense, and only few PSPs have their own 3DS Server.

What EMVCo 3DS certification means

EMVCo is the global technical body jointly owned by American Express, Discover, JCB, Mastercard, UnionPay, and Visa. Its certification program validates that a 3DS Server correctly implements the 3DS2 protocol specification: message formatting, data elements, authentication flows, security requirements.

A certified 3DS Server is what enables liability shift from the merchant to the card issuer on authenticated transactions. Without it, merchants bear fraud losses on disputed card transactions.

Why it matters for platforms

If you're processing card payments, directly or on behalf of your merchants, your 3DS infrastructure determines your fraud rates, your liability exposure, your approval rates, and your ability to offer a competitive checkout experience.

How Rootline handles this

Rootline operates its own EMVCo-certified 3DS Server, rather than relying on third-party infrastructure. That directly impacts how authentication flows behave in practice.

Because Rootline controls the 3DS layer, it stays aligned with the latest protocol developments, including support for WebAuthn, which lets customers authenticate with biometrics instead of one-time passwords or redirects. Rootline also supports automated out-of-band (OOB) transitions, making it easier for users to complete authentication in their banking app without manually switching contexts.

Owning the 3DS Server also improves how transactions are processed overall: more transactions can be approved without interrupting the user, and when a challenge is required, it can often be handled without a full redirect. The checkout flow stays closer to the merchant experience, reducing drop-off.

For platforms, this translates directly into higher approval rates (equals to a higher conversion rate overall) and a smoother checkout experience, delivered as part of Rootline's infrastructure. No building, certifying, or maintaining 3DS required.

03 · PCI DSS

PCI DSS: protecting cardholder data, at scale

The Payment Card Industry Data Security Standard exists because cardholder data is valuable, frequently targeted, and, when breached, financially and reputationally catastrophic. Any organization that stores, processes, or transmits cardholder data is in scope for fraud.

The scope question is where it gets complicated for platforms. The more directly you interact with card data, the higher your PCI DSS compliance tier and the greater the audit burden. SAQ A (the lightest self-assessment) requires minimal controls; a full QSA-led (Qualified Security Assessor) Report on Compliance for Level 1 merchants requires significant effort, expertise, and ongoing maintenance.

Most platform businesses didn't set out to become card data processors. But embedded payments often pull teams into PCI scope without a clear plan: compliance obligations that consume engineering time, require specialist auditors, and need maintaining every time the standard is updated.

What PCI DSS requires

PCI DSS v4.0 organizes its requirements around 6 goals: building and maintaining a secure network, protecting cardholder data, maintaining a vulnerability management program, implementing strong access control, regularly monitoring and testing networks, and maintaining an information security policy.

The practical implication for most platforms is scope reduction. The best way to manage PCI DSS is to minimize your contact with raw card data. Payment tokenization, iframe-based card capture, and hosted payment pages are all ways to keep card data out of your environment entirely.

"The most effective compliance strategy is a system where sensitive card data never enters your environment in the first place." - Anselm Adelmann, CFO at Rootline

Why it matters for platforms

A PCI DSS breach isn't only a regulatory and financial event. It can result in card scheme fines, mandatory forensic investigations, and suspension of your ability to process payments. For platforms where payment capability is core to the product, that's an existential risk.

How Rootline handles this

Rootline's Checkout Components use tokenization and hosted card capture, including fully hosted checkout pages, to keep raw PAN data out of your environment. Card data is handled within Rootline's PCI-certified infrastructure. Platforms building on Rootline can substantially reduce their PCI scope, often to SAQ A, rather than inheriting the full compliance burden of a card data environment.

04 · AML & KYC

AML & KYC: knowing who you're paying, and why

Anti-money laundering (AML) and Know Your Customer (KYC) obligations exist to prevent the financial system from being used to launder proceeds of crime. For platforms that move money (particularly those that onboard sub-merchants or facilitate payouts), these obligations are direct and non-trivial.

The EU's Anti-Money Laundering Directives (AMLD5 and AMLD6, now in force) have progressively tightened requirements around beneficial ownership, enhanced due diligence, transaction monitoring, and Suspicious Activity Reporting obligations. Non-compliance is a criminal matter.

That framework is being replaced. The Anti-Money Laundering Regulation (AMLR) applies directly across all member states from 10 July 2027, replacing the patchwork of national AMLD implementations with a single harmonized rulebook. A new EU-level supervisor, AMLA, will coordinate AML oversight and directly supervise selected high-risk cross-border institutions. The shift also aligns with eIDAS 2.0 and the European Digital Identity Wallet, opening the path to faster, less document-heavy merchant onboarding as that infrastructure matures.

Platforms onboarding merchants at scale face a real tension: move fast enough to convert merchants, but conduct sufficient due diligence to meet AML obligations. Under-onboarding creates friction and churn. Over-onboarding creates regulatory exposure. Manual processes don't scale.

What AML and KYC actually require

At the entity level, KYC requires verifying the identity of the businesses and individuals you onboard, including Ultimate Beneficial Owners (UBOs) above the relevant ownership threshold (typically 25%). That means document verification, sanctions screening, PEP (politically exposed person) checks, and adverse media review.

Ongoing AML obligations include transaction monitoring for unusual patterns, periodic account reviews, and a clear escalation pathway for suspicious activity. It's a continuous program, not a one-time onboarding check.

Why it matters for platforms

Platforms operating under Rootline's DNB license (De Nederlandsche Bank) benefit from a regulated infrastructure layer that carries AML program obligations at the provider level. But this doesn't fully remove a platform's own obligations, particularly where platforms have direct relationships with end merchants or facilitate payouts in their own name.

Understanding the allocation of AML responsibilities between your platform and your payments provider is critical. The right structure protects you, your merchants, and the integrity of the payment flows you depend on.

How Rootline handles this

Rootline operates under a DNB license as a regulated payments institution. AML program governance, transaction monitoring, and regulatory reporting sit within Rootline's compliance infrastructure. For platforms, that means faster merchant onboarding with less internal compliance overhead: the KYC and AML framework is built into the infrastructure layer, not bolted on after the fact.

05 · Summary

The compliance stack, at a glance

For platforms embedding payments, compliance is a layered stack. Each layer has its own scope, its own regulatory owner, and its own consequence for non-compliance.

Each of these frameworks represents a substantial engineering and operational investment to build in-house. The platform businesses that scale most sustainably build on a licensed, certified infrastructure layer rather than internalizing the compliance burden themselves.

The frameworks above aren't static. PSD3/PSR replaces PSD2 in 2027. The AMLR replaces fragmented AML directives the same year. The 3DS protocol continues to evolve toward biometric, frictionless authentication. The platforms that move through this transition without rebuilding from scratch are the ones already running on infrastructure designed to absorb regulatory change, not react to it.