DDoS Protection for a Fintech Payment Platform: The Card-Brand Clock

The short answer

A fintech payment platform that is a processor, gateway, or PSP — not an account-servicing bank — has no fixed regulatory uptime percentage for DDoS the way a digital bank does. PCI DSS Requirement 12.10.1 requires an incident response plan that includes notification of payment brands and acquirers "at a minimum," and explicitly tells you to reference or incorporate the payment brands' own incident procedures — it never states a downtime percentage or a fixed reporting deadline itself. That means the actual clock a payment platform is racing during a DDoS-driven outage isn't set by a single EU regulator's guideline; it's set by whichever card network's rails the affected traffic runs on, under that network's own program.

Who this is for

This is written for a CISO or Head of Infrastructure at a card processor, payment gateway, or open-banking aggregator — the kind of platform already being hardened against PCI DSS scope and open-banking API exposure — who has DDoS mitigation in place already (Cloudflare, AWS Shield, Akamai, or similar) and is asking a narrower compliance question: does this platform have the same fixed uptime KPI a digital bank has to answer to, and if not, what governs the reporting clock instead? It assumes the four-layer DDoS architecture itself — network absorption, application-layer filtering, origin isolation, rehearsed runbook — is either already built or being built the same way it is for an online casino or a digital bank; this post is specifically about what changes on the compliance and reporting side, not the mitigation architecture itself.

Why "payment platform" isn't the same as "bank" here

The EU's Open Banking operational guidelines set a quarterly uptime KPI for an account-servicing payment service provider's dedicated interface — the API a bank has to expose to registered third-party providers. That guideline is written for the account-servicing side of open banking: the bank holding the account. A processor, gateway, or PSP that initiates or routes payments on a merchant's behalf is typically sitting on the other side of that relationship, as a third-party provider or acquirer rather than an account-servicing institution, and the dedicated-interface KPI simply doesn't attach to it the same way.

What does attach to it is PCI DSS, because any platform that stores, processes, or transmits cardholder data is in scope regardless of whether it is a bank. And PCI DSS Requirement 12.10.1 takes a structurally different approach to incident response than a fixed percentage:

"An incident response plan exists and is ready to be activated in the event of a suspected or confirmed security incident. The plan includes, but is not limited to: Roles, responsibilities, and communication and contact strategies in the event of a suspected or confirmed security incident, including notification of payment brands and acquirers, at a minimum... Reference or inclusion of incident response procedures from the payment brands."

Read closely, that requirement does two things a digital bank's dedicated-interface KPI doesn't:

It sets a procedural bar, not a numeric one. The standard requires that a plan exists and names who gets called — it never states an availability percentage, an hours-per-quarter budget, or any other fixed figure for how much downtime is acceptable.
It delegates the actual severity and timing rules outward. The plan has to "reference or include" the payment brands' own incident procedures — meaning Visa's and Mastercard's respective programs, not the PCI Security Standards Council, decide what counts as a reportable incident and how fast it has to be escalated.

What that means in practice

For a platform running traffic across more than one card network, this has a concrete operational consequence a single-KPI bank doesn't face:

	Digital bank (ASPSP dedicated interface)	Fintech payment platform (processor / gateway / PSP)
Who sets the availability bar	An EU financial regulator's guideline, directly	No single regulator — PCI DSS requires a plan, not a number
What the number is	A fixed quarterly uptime percentage	No fixed percentage; severity/timing set per card brand
Who has to be told	Regulator-driven reporting chain	Payment brands and acquirers, "at a minimum," per 12.10.1
How many clocks can be running at once	One	Potentially more than one, if traffic spans multiple card networks with different programs

That last row is the practical planning problem. A DDoS-driven outage that degrades checkout or authorization traffic doesn't pause to let a SOC figure out which card network's rules apply before the clock the brand cares about starts running. A runbook built only around "notify management, then figure out compliance" leaves that triage step improvised in production, for however many card-brand programs are actually in scope for the affected traffic.

A real outage shows the shape of the problem

Adyen — a payment platform, not a bank — disclosed a DDoS attack against its own infrastructure on 2025-04-21. Per Adyen's own incident report, the attack hit services in its European datacenters supporting transaction processing and customer-facing applications, arriving in three distinct waves generating millions of requests per minute from a globally distributed, constantly shifting set of source IPs. The stated main-impact window ran from 18:51 to 19:35 CEST for e-commerce and in-person payment transaction processing, with degraded performance also affecting the Customer Area, Hosted Onboarding, and Transfer API, plus checkout-flow services including Session Integrations, Secured Fields, and Pay by Link. Adyen marked the incident fully resolved by 03:20 CEST the following day — roughly eight and a half hours after detection — after deploying anti-DDoS protections, scaling internal defenses, offloading traffic from affected services, and applying targeted filtering rules. Adyen's disclosure states the outage caused failed or delayed transactions "for some customers," without publishing a specific merchant count.

That last detail is the structural point this post is about: the impact fans out to every merchant relying on that one platform's checkout and processing services simultaneously — not one institution's own retail customers, the way an outage at a single bank's mobile app would. A processor's or gateway's blast radius is measured in merchants, and each of those merchants' card transactions may run through different card-brand programs with their own notification expectations, which is exactly the layer PCI DSS 12.10.1 asks a plan to address by pointing outward rather than fixing one internal number.

What to build before the next incident, not during it

Map which card-brand programs actually apply to your traffic. Before an incident, know which networks' rails carry your volume and pull each one's own incident/notification procedure into the plan 12.10.1 requires you to reference — don't discover this mid-attack.
Give the SOC a triage script for "is this reportable, and to whom." The runbook needs a documented decision path for classifying a DDoS-driven service disruption against each applicable card-brand program's own criteria, not a single generic "call compliance" step.
Treat merchant-facing status communication as part of the runbook, not an afterthought. Adyen's own disclosure names specific affected services (checkout, onboarding, transfer API) rather than a vague "some systems" — that level of specificity is what lets merchants downstream make their own operational decisions during the outage.
Validate the architecture and the reporting triage together. An authorized DDoS stress test proves the mitigation stack holds; a tabletop exercise built around the same scenario proves the team can correctly identify which card-brand clock started running and how fast, before a live incident forces the answer.

That's what a DDoS Protection Strategy engagement scoped for a payment processor, gateway, or PSP reviews: the same four-layer mitigation architecture used for any platform, plus runbooks built against the actual card-brand-driven reporting structure this vertical sits inside — with the option to validate the result under an authorized stress test.

If you want your DDoS runbook checked against the card-brand programs your traffic actually runs through — not a generic incident-response template — get a fixed quote and we will map where the gaps are.

Frequently asked questions

Does PCI DSS set an uptime percentage a payment platform has to hit during a DDoS attack? No. PCI DSS Requirement 12.10.1 requires an incident response plan to exist and be activated for a suspected or confirmed security incident, and that plan must include notification of payment brands and acquirers, at a minimum, plus reference or inclusion of incident response procedures from the payment brands. It does not set an availability percentage or a downtime-budget figure anywhere in the requirement text — unlike a digital bank's dedicated-interface uptime KPI, the standard hands the actual severity thresholds and reporting deadlines to Visa's and Mastercard's own programs rather than fixing a number itself.

How is that different from what a digital bank has to do? A digital bank's account-servicing dedicated interface carries a quarterly uptime KPI set directly by an EU financial regulator's guideline — a fixed number that applies regardless of what any card network says. A fintech payment platform that is a processor, gateway, or PSP rather than an account-servicing bank doesn't have that guideline's dedicated-interface KPI at all; its incident-response obligation under PCI DSS points outward to whichever payment brand's program is on the transaction, and each of those programs sets its own notification timing and severity criteria rather than the standard fixing one figure for everyone.

So who actually decides how fast we have to report a DDoS-driven outage? The payment brands whose transactions run through the affected systems, via their own compliance programs — not a single EU regulator, and not the PCI DSS text itself, which only requires that your incident response plan reference and incorporate those brand-specific procedures. If a processor's traffic runs through more than one card network's rails, that can mean more than one clock running at once, each with its own trigger criteria for what counts as reportable.

Has a payment platform actually been taken down by DDoS like this? Yes. Adyen's own incident disclosure describes a DDoS attack on 2025-04-21 that hit services in its European datacenters supporting transaction processing and customer-facing applications, arriving in three distinct waves of millions of requests per minute from a globally distributed, constantly shifting set of IP addresses. The main impact window ran from 18:51 to 19:35 CEST, with the incident fully resolved by 03:20 CEST the next day — roughly eight and a half hours — and it caused failed or delayed transactions for merchant customers across checkout, onboarding, and transfer services, not a single institution's own retail channel.

What does an AnySec DDoS Protection engagement do differently for this vertical? It scopes the architecture review and runbook against the actual reporting structure a processor or PSP sits inside — which card-brand programs apply, what each one's own incident procedures require, and how fast the SOC's triage decision needs to happen before a brand-specific clock starts running — instead of assuming a single fixed uptime number the way the review would for a licensed bank's dedicated interface.

Sources and review

PCI DSS Requirement 12.10.1's exact text is drawn directly from the PCI Security Standards Council's official Payment Card Industry Data Security Standard: Requirements and Testing Procedures, v4.0.1 (June 2024), parsed from the primary document rather than a secondary summary. The Adyen incident facts — affected services, three-wave attack pattern, 18:51–19:35 CEST main-impact window, 03:20 CEST next-day resolution, and mitigation actions taken — are drawn from Adyen's own official incident disclosure; no merchant count or region breakdown beyond "European datacenters" is stated by Adyen, and none is invented here. AnySec's DDoS Protection Strategy service scope, methodology, and pricing (from €2,899, 2-week engagement) are drawn from our own published service terms; no customer-specific case data is cited. Author: AnySec Engineering. Published 2026-09-13; last reviewed 2026-09-13.