PSD2, SCA and DORA: What Fintechs Actually Have to Prove When They Move Payments to a Hyperscaler

Key points:

• PSD2 does not prohibit running payment infrastructure in a public cloud. Article 97 of Directive (EU) 2015/2366 and the RTS on strong customer authentication set authentication and security requirements; the EBA Guidelines on outsourcing and DORA set what you must document, control and exit. Compliance is about evidence, not hosting location.
• Strong customer authentication is mostly an application and key-management problem. Two independent elements out of knowledge, possession and inherence, dynamic linking of amount and payee, and protection of the authentication code all survive a cloud migration if your secrets, HSM/KMS and audit-trail design do.
• The operational resilience side is the harder part. DORA (applicable since 17 January 2025) requires an ICT risk framework, a register of information on all ICT third-party providers, exit strategies for critical providers, and threat-led penetration testing for significant entities.
• Concentration risk and lock-in are now explicit supervisory concerns. Regulators expect a documented, tested exit plan from your hyperscaler, which is why fintechs increasingly standardise on Kubernetes and infrastructure-as-code rather than proprietary PaaS primitives.
• Running your workloads in your own cloud account (BYOC) keeps the contract, data residency, encryption keys, audit logs and exit path in your name - the four things an auditor asks about first. Qovery provisions and operates that setup on AWS, GCP, Azure, Scaleway, or your existing Kubernetes cluster, without your team hand-rolling the platform.

I have interviewed more than 200 CTOs, and one fear comes up more than almost any other from the fintech ones: "PSD2 means we can't move payments to the cloud." It is wrong, and it is costing teams real time and money, because they build on-premise setups to satisfy a rule that does not exist.

Here is the honest version. PSD2 contains no sentence that forbids public cloud. Neither does DORA. What the regulation actually cares about is whether you can prove what you run - who holds the keys, who can read the logs, how you authenticate a payment, and how you would get off a provider if you had to. That is an architecture question you answer at migration time, not a hosting-location question.

Does PSD2 allow fintechs to run payment infrastructure on AWS, GCP or Azure at all?

Yes. PSD2 contains no prohibition on public cloud, and EU supervisors have treated cloud outsourcing as permitted as long as the regulated entity keeps accountability, control and an exit path. What changes when you move to the cloud is the evidence burden, not the legality.

Four instruments do the work, and it helps to name what each one governs:

• PSD2 - Directive (EU) 2015/2366, Article 97: when strong customer authentication must be applied (accessing a payment account online, initiating an electronic payment, or carrying out any remote action that carries a risk of fraud).
• Commission Delegated Regulation (EU) 2018/389 - the RTS on SCA and common and secure communication: the technical rules behind SCA and the API-level security between providers.
• EBA Guidelines on outsourcing arrangements (EBA/GL/2019/02): how you document, notify, audit and exit any outsourcing, cloud included.
• DORA - Regulation (EU) 2022/2554: the operational resilience framework, applicable since 17 January 2025.

The chain of responsibility is the part people miss. A payment institution or e-money institution stays fully responsible for an outsourced function. Your cloud provider is a third-party ICT provider, not a co-regulated party. You cannot outsource the accountability, only the operation.

That maps cleanly onto the shared responsibility model. The hyperscaler attests to the security of the cloud - its ISO 27001, SOC 2 and PCI DSS attestations. You are accountable for security in the cloud: identity, network segmentation, keys, logging and change management.

So the two myths worth killing: "PSD2 requires on-premise hosting" and "SCA must run inside EU borders on your own hardware." Neither is in the text. The requirements that actually bite are notifying your NCA of material outsourcing, securing contractual audit and access rights, and holding a documented, tested exit.

What does strong customer authentication actually require from your architecture?

SCA requires at least two independent elements drawn from knowledge, possession and inherence, plus dynamic linking of each remote payment to its specific amount and payee. The independence requirement is the part your system design has to prove, not just the two-factor count.

Independence of elements (RTS Article 9). The breach of one element must not compromise the reliability of the others. That becomes a live design question the moment all your authentication components run on the same cluster or share one secrets store. If a single compromised node leaks both the possession and the knowledge factor, you have two factors on paper and one in practice.

Dynamic linking (RTS Article 5). The authentication code must be specific to the amount and the payee, and any change to either has to invalidate the code. In a distributed system that means signing the (amount, payee) tuple, enforcing message integrity between services, and getting idempotency right so a retried request cannot be quietly re-pointed at a different beneficiary.

Protection of the authentication elements. Secure execution environments, device binding, and no plaintext authentication data sitting in your logs or APM traces. Key material belongs in a managed KMS or HSM - AWS KMS/CloudHSM, Google Cloud KMS, or Azure Key Vault Managed HSM - never baked into an image or an environment variable.

Exemptions, and the cost of getting them wrong. The RTS lets you skip SCA for low-value payments, trusted beneficiaries, recurring transactions and transaction risk analysis (TRA). TRA is the interesting one: the Annex to Regulation (EU) 2018/389 ties the exemption to reference fraud rates that get stricter as the transaction value rises (the bands run down toward a fraction of a percent at the higher value tiers). You can only claim it if you can measure your own fraud rate reliably, which means queryable, trustworthy transaction telemetry is a compliance dependency, not a nice-to-have.

This is why SCA is largely cloud-neutral. If your authentication flow is well-designed, a migration does not change the SCA logic. What it changes is where the keys live, who can read the audit logs, and who holds the operator credentials. Get those three right and the hosting move is uneventful.

What do the operational resilience rules require once your payment stack is in a hyperscaler?

DORA and the EBA outsourcing guidelines ask you to document and continuously evidence five things: an ICT risk management framework, a register of information on every ICT third-party provider, incident classification and reporting, resilience testing, and a tested exit strategy for critical providers.

DORA's five pillars, in plain engineering terms:

1. ICT risk management - the framework, owners and controls.
2. Incident reporting - classify, then report major incidents on the clock.
3. Digital operational resilience testing - including threat-led penetration testing (TLPT) for significant entities.
4. ICT third-party risk management - the register, contracts and exit, under Articles 28 to 30.
5. Information sharing - on cyber threats, on a voluntary basis.

The register of information is more than a spreadsheet. Supervisors expect it to show which ICT services support critical or important functions, the subcontracting chain beneath each provider, and where data sits. Your IDP, observability stack and CI/CD vendors belong in it too (more on that below).

Incident reporting clocks are tight. Under the joint technical standards on major incident reporting, a major ICT-related incident triggers an initial notification within 4 hours of classifying it as major (and no later than 24 hours from becoming aware of it), an intermediate report within 72 hours, and a final report within one month. Those deadlines are only achievable if your observability and on-call process can establish blast radius fast. If it takes you a day to work out which customers were affected, you have already missed the window.

Concentration risk is now an explicit question, and it is exactly why single-provider framing is a regulatory problem. Supervisors ask what happens if one region, one provider, or one managed service becomes unavailable or is withdrawn. Multi-AZ is table stakes. Multi-region and genuine provider portability are the questions getting harder to dodge, especially as EU bodies keep flagging how much of the sector leans on a handful of hyperscalers.

The exit strategy has to be an engineering artifact, not a Word document. Reproducible infrastructure-as-code, a portable runtime (containers on Kubernetes), a documented data-export path for every managed database, and a rehearsal you can put a date on. "We could leave if we had to" is not evidence. "We redeployed the stack into a second region on 12 September and here is the run log" is.

Which parts of your payment stack are hardest to make portable, and what does that cost you with an auditor?

The portability risk sits almost entirely in the managed services you build business logic on top of, not in your application code. Container workloads move in days. Event buses, proprietary serverless runtimes and provider-specific identity flows move in quarters.

The tension worth naming out loud: "we use the cloud's PaaS so we move fast" and "we have a tested exit plan" pull in opposite directions. That is a fine trade to make - as long as you make it deliberately, per service, and write down which side you chose and why.

Two things top an auditor's list, in order. First, the contract: your agreement must grant you and your supervisor audit and inspection rights. Hyperscalers handle this with pooled audits and financial-services addenda, so know which addendum you actually signed. Second, key custody: customer-managed keys (CMK/BYOK) versus provider-managed is the question that comes right after the contract, because it decides whether you can cryptographically cut off access on your own terms.

And do not forget sub-outsourcing. Your own vendors - identity provider, observability, CI/CD, developer platform - are themselves in the chain and have to appear in your register.

Does a managed developer platform count as outsourcing, and what should you ask your vendors?

Yes. Any vendor with access to, or control over, systems supporting a critical or important function is an ICT third-party provider under DORA and belongs in your register, with a contract that meets the Article 30 requirements. That includes internal developer platforms, CI/CD and observability tools, not just the cloud itself.

Here is the screening checklist I would run against any platform vendor:

• Where does the control plane run?
• What credentials does it hold in your cloud account, and at what scope?
• Can it read application data?
• Where are its logs stored, and under whose jurisdiction?
• Can you keep running if the vendor disappears tomorrow?

Those five answers split the market into two structurally different shapes.

Heroku, Render, Fly.io and Vercel are genuinely good products, and for plenty of workloads they are the right call. Their structural issue for a regulated payment flow is simple: the vendor sits in the data path and owns the cloud contract, so their infrastructure becomes part of your data-residency story and your exit test. Northflank and Porter also offer BYOC, which is why I put them in the same column as Qovery rather than the PaaS one.

BYOC narrows the audit surface because the hyperscaler stays your named provider under your financial-services addendum, data never leaves your account, and the exit test collapses to one question: can my cluster keep serving traffic if the control plane goes away?

Whatever you pick, require the same things contractually: Article 30 clauses, audit rights, a sub-processor list, incident-notification SLAs, exit assistance, and SOC 2 / ISO 27001 evidence.

One caveat I want to be honest about: BYOC is not automatically compliant. It shifts work, it does not remove it. You still own the ICT risk framework, the register and the testing. BYOC just keeps the four things an auditor asks about first - contract, data, keys, exit - in your name.

How should you sequence the migration so compliance evidence is produced as you go?

Sequence it so every phase ends with an artifact a supervisor would accept. Build the safe foundation first, move the least sensitive workloads before the most sensitive, and rehearse the exit before you call it done.

• Phase 0 - landing zone. Account structure, SSO and least-privilege IAM, a CMK/BYOK key hierarchy, immutable audit logging, and network segmentation of the cardholder and authentication zone. Start the register of information on day one, not after go-live.
• Phase 1 - stateless, non-payment services. Move something low-risk first to prove the deployment pipeline, the RBAC model and the rollback path.
• Phase 2 - the data layer. Document RPO and RTO per database, and run a real restore. A tested restore, not a believed one.
• Phase 3 - SCA and payment authorization paths. Key material in KMS/HSM, dynamic linking preserved end to end, and zero authentication data in logs or traces.
• Phase 4 - resilience testing and exit rehearsal. A region failover test, scenario-based testing aligned to DORA, and a dated exit drill: redeploy the stack from IaC into a second region or a second provider.

Throughout, keep the environment hygiene auditors like to see: per-environment RBAC, no production data in preview or test environments, ephemeral environments that are destroyed automatically, and a provable separation of duties between who writes the code and who approves the production release.

Where does Qovery fit for a regulated fintech moving payments to the cloud?

Qovery is an internal developer platform that provisions and operates Kubernetes inside your own AWS, GCP, Azure or Scaleway account - or on your existing Kubernetes cluster - so the cloud contract, data, encryption keys, audit logs and exit path all stay in your name while your team gets self-service deployments.

That matters for three reasons that map directly onto everything above:

• It runs in your own cloud account. The cluster, the databases backed by managed cloud services, and the traffic all live in your account. Your hyperscaler financial-services addendum and any committed-spend discounts stay yours. The control plane operates the workloads; it does not host them.
• You get Kubernetes without managing it directly. Workloads are containers described in infrastructure-as-code, which is the practical answer to the portability question. Your exit rehearsal becomes a redeploy, not a rewrite.
• You can ship without a dedicated DevOps engineer. Git-push deployments with a full deployment history, preview and ephemeral environments per pull request with auto-destroy, environment auto-stop for non-production, managed cluster upgrades (useful patching-cadence evidence), and per-environment RBAC with approval flows for separation of duties.

I want to be precise about scope. Qovery is not a compliance product. It does not implement SCA for you, it does not file your incident reports, and it does not replace your ICT risk framework. What it removes is the need to build and staff the platform layer yourself - which is exactly where under-resourced fintech teams tend to create their worst control gaps.

And the fair comparison: if you need the vendor out of the data path entirely, self-managed Kubernetes with an in-house platform team is a perfectly valid route. It just costs headcount. If you need a hosted PaaS to go live next week and your payment flows are not yet regulated, that is a legitimate choice too. The BYOC argument earns its keep specifically when the flows are regulated and the exit test has to pass.

How do I set this up from Claude Code, Cursor or another coding agent?

Install the Qovery Agent Skills once and your coding agent can provision a cluster in your own cloud account, deploy services and set up preview environments by asking in plain language, with every action surfaced for approval before it runs.

Install for every compatible agent (Claude Code, Cursor, Codex, OpenCode, Gemini CLI):

curl -fsSL https://skill.qovery.com/install.sh | bash

Prefer a project-scoped install instead of a global one:

curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

Add the MCP Server to Claude Code, read-only by default via OAuth:

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

Enable write access only when you explicitly want it (this also requires enabling write access in the Qovery Console):

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The skills (qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview, qovery-terraform) create and deploy; the MCP Server operates what already exists. For a regulated setup, start read-only and keep write access gated behind an explicit decision.

Then just ask, for example: "provision a cluster in my own AWS account and deploy this service with a preview environment per pull request." The AI agent quickstart walks through the rest.

Does PSD2 require payment data to stay in the EU or on-premise?

No. Neither PSD2 (Directive (EU) 2015/2366) nor its RTS on SCA mandates on-premise hosting or EU-only data residency. What applies is the outsourcing regime: notify your NCA of material outsourcing, secure audit and access rights, and document a tested exit. Data-residency obligations come from your own policy, your contracts, and separately from the GDPR, not from a PSD2 "no cloud" rule that does not exist.

What exactly counts as strong customer authentication under the PSD2 RTS?

Authentication based on at least two independent elements from three categories - knowledge (something you know), possession (something you have) and inherence (something you are) - where the breach of one element does not compromise the others (Article 9), plus dynamic linking of the authentication code to the specific amount and payee for remote payments (Article 5). The detail is in Commission Delegated Regulation (EU) 2018/389.

Is using AWS, GCP or Azure considered outsourcing under DORA and the EBA guidelines?

Yes. Using a hyperscaler to run functions that support your regulated activity is ICT outsourcing. It falls under the EBA Guidelines on outsourcing (EBA/GL/2019/02) and the ICT third-party risk provisions of DORA (Articles 28 to 30). The provider goes in your register of information, with a contract that meets the Article 30 requirements.

Do I need a documented exit plan from my cloud provider, and how is it tested?

For providers supporting critical or important functions, yes. DORA expects a documented exit strategy, and a credible one is an engineering artifact: reproducible IaC, a portable container runtime, a data-export path for every managed database, and a rehearsal with a date on it. The strongest evidence is a redeploy of the stack into a second region or provider that you have actually run, not a plan you believe would work.

Is an internal developer platform like Qovery an ICT third-party provider I have to register?

If it has access to or control over systems supporting a critical or important function, yes - it belongs in your register with an Article 30-compliant contract, like any CI/CD or observability vendor. A BYOC control plane narrows the exposure because data and keys stay in your account, but it does not remove the registration obligation.

Does running in my own cloud account (BYOC) make a fintech PSD2 or DORA compliant?

No. BYOC keeps the contract, data, keys, audit logs and exit path in your name, which answers the questions an auditor asks first. But you still own the ICT risk framework, the register of information, incident reporting, and the testing. BYOC shifts work closer to you and makes evidence easier to produce; it does not hand you compliance.

The regulation does not care where you run. It cares whether you can prove what you run - who holds the keys, who reads the logs, how a payment is authenticated, and how you would leave a provider on a bad day. Every one of those is an architecture decision you make at migration time, and the teams that treat them as engineering artifacts rather than paperwork are the ones that pass the audit without a scramble.