In most industries a DDoS is measured by how long the service was down. In financial services it is measured against a clock that somebody else owns.
A card network decides how long it will wait for your answer. A payment scheme decides how many seconds a transfer may take. A regulation decides when your open-banking API counts as broken. When those clocks run out, a rule you did not write takes over, and it keeps running whether or not your servers recover a minute later.
What is DDoS testing for financial services?
DDoS testing for financial services is an authorised test of whether a bank, payment firm, broker or market operator keeps meeting its external deadlines while under attack: card authorisations, instant payments, open-banking requests and market disclosures. The pass mark is not "the site stayed up". It is "no counterparty's fallback rule was triggered".
Nothing below changes how an engagement gets approved or ramped; for that, start from the complete guide to DDoS testing. Readers in Britain asking what their supervisor wants to see should read the piece on UK DDoS testing alongside this one. Here the subject is narrower: the deadlines, and what a missed one costs.
Why is a bank's DDoS outcome decided by other people's clocks?
Because almost every important transaction passes through a party that cannot wait for you.
The counterparty has its own customers
A card network holding a shopper at a till cannot leave them standing there while your authorisation host recovers. A payment scheme promising settlement in seconds cannot let one slow member stall the rail. So each one sets a timeout, and each timeout has a defined consequence.
The consequence is a rule, not an error page
When a web shop is slow, the shopper sees a spinner. When an issuer is slow, the network approves or declines on the issuer's behalf. When an open-banking API stops answering, third parties are allowed to come in another way. When a listed company cannot publish its announcements, the exchange may stop trading.
None of those outcomes waits for your incident to end, and none of them shows up as a red light on your own dashboard.
Slow counts the same as down
A request answered after the deadline is worth exactly as much as a request never answered. A flood that raises authorisation latency from 150 milliseconds to several seconds may never take a single server offline, and still hand every transaction to someone else's rules.
So the useful measurement in a financial test is latency against each external deadline, per path, not availability.
What happens to card payments when the authorisation host is flooded?
The cards keep working. That is the problem.
Stand-in processing takes the decision
Card networks offer stand-in processing: if the issuer's host does not respond in time, or is marked unavailable, the network decides on its behalf using limits the issuer set in advance. The cardholder sees an approval or a decline, never an outage.
That makes a flood on an issuer's authorisation path almost invisible from outside. It also means the issuer's real fraud and credit checks are not running.
Stand-in is a credit decision made with old parameters
Stand-in limits tend to be conservative and coarse: an amount ceiling, a few merchant categories, perhaps a velocity rule. They are often set long before the incident, by someone thinking about a network outage rather than an attack.
The values themselves are not the exposure. The window in which they apply is what matters, and its length is decided by how long your host stays slow.
In-flight authorisations hit a ceiling before CPU does
Between the scheme connection and the core sits a fixed pool: connections to the switch, threads in the authorisation service, sessions to the hardware security module that checks PINs and cryptograms. By Little's law the number of authorisations in flight is the arrival rate times the latency.
When latency climbs, the in-flight count climbs with it until it reaches the pool's cap. After that, new authorisations queue, and a queued authorisation is one that will miss the scheme's timeout.
What to test
Do not send load into a card network. Use the scheme's test environment or a switch simulator to stand in for it, and point the flood at what sits in front of your authorisation host: the internet-facing paths that share its network, its load balancers, or its dependencies.
Then measure three things: the latency at which authorisations start to time out, how much attack traffic it takes to reach it, and whether your monitoring raises an alarm before the network starts standing in. The last one is often the gap. Stand-in volume is reported by the network, usually after the fact.
How do instant payments change what a test has to prove?
They take away the deadline you could miss slowly, and the window you used to test in.
Ten seconds, end to end
The European SEPA Instant scheme sets a maximum of ten seconds for a payment to complete, and EU rules now require payment providers that offer euro transfers to offer instant ones. The UK's Faster Payments and the US real-time rails work to similarly short targets.
Ten seconds sounds generous until you split it. The sending bank checks and debits, the scheme routes, the receiving bank checks and credits, and the confirmation travels back. Each party gets a slice.
A flood on the receiving side rejects someone else's payment
If your bank is the receiver and your checks are slow, the payment is rejected and the sender is told it failed. The customer who was sending you money sees the failure, not your customer.
Their natural reaction is to try again, so a rejected instant payment often comes back as two or three attempts. Your inbound volume rises at exactly the moment you can least absorb it.
There is no quiet window
Instant payments run 24 hours a day, 365 days a year. The habit of testing at 03:00 on a Sunday assumed somebody was not using the system at 03:00 on a Sunday.
That pushes the work toward a standby site or a production-like environment for the heavy runs, and short, capped runs on the live path once that environment has been proven. Testing without disrupting production covers ceilings and kill switches in general; the financial version adds a scheme contact who knows a test is running.
What does a DDoS on an open-banking API trigger?
In the EU, a fallback that moves third-party traffic onto your online banking front end.
The dedicated interface has to match the customer interface
Under PSD2's technical standard on strong customer authentication and secure communication (Delegated Regulation (EU) 2018/389), a bank's dedicated API for third-party providers must offer the same availability and performance as the interfaces its own customers use. Article 32 also requires the bank to publish quarterly statistics on both.
So an outage on the API is not a private incident. It ends up in a published number, beside the number for your app.
Five unanswered requests start the contingency
Article 33 treats the dedicated interface as unavailable when five consecutive requests for information go unanswered within 30 seconds. Unless the bank holds an exemption from its national authority, third parties may then use the interface built for the bank's own customers, identifying themselves as they do it.
Read that as an engineer. A flood that makes the API time out does not stop third-party traffic. It moves it onto your customer login path, where it lands on top of your customers and whatever else the attacker is sending there.
What to test
Measure the API's latency under load against the 30-second line, not against your internal target. Then test the customer interface with the third-party share added on top, because that is the load it would see if the contingency fired.
UK firms should check the FCA's version of these standards rather than assume the EU text applies unchanged. The way API floods cost more per request than they appear to applies here too; the difference in open banking is that missing a deadline also changes who is allowed in.
Why can a flood on a website stop a market?
Because markets depend on disclosure, and disclosure runs on ordinary web infrastructure.
The matching engine was not the target
In August 2020, New Zealand's stock exchange halted trading on several days of the same week after volumetric attacks disrupted its website and the platform it uses to publish market announcements. The trading systems themselves were not the problem. A market that cannot publish price-sensitive announcements cannot trade fairly, so it stopped.
Find your own version of that dependency
Most firms are not exchanges, but most have a dependency of the same shape: a system that looks like marketing infrastructure and is in fact a regulatory one. Investor-relations pages, status pages that customers and regulators read during an incident, the portal where corporate clients download statements, the page brokers use to show order status.
Map which public pages carry an obligation, then test them as critical paths rather than as the website.
Brokers meet the attacker at the open
For a retail broker, the heaviest legitimate minute is usually the market open, when users log in and send orders at once. A flood timed to that minute sits on top of the peak, and a late order is worse than a refused one because the price has moved. The test has to run at open-like load, not average load.
Why do settlement cut-offs turn a short attack into a lost day?
Because batch payment systems still run on fixed submission windows, and a window missed is not reopened for you.
The file has to arrive before the gate closes
Bulk payment schemes and correspondent arrangements accept payment files up to a published cut-off. Payroll, supplier runs and direct debits are prepared hours ahead and submitted near the end of the window, often through a web portal or an internet-facing file transfer gateway.
A flood that makes that gateway unreachable for forty minutes at the wrong time of day does not cost forty minutes. It moves every payment in the file to the next cycle, which for some schemes means the next working day.
Corporate clients feel it first
The firms submitting those files are the bank's corporate customers. Their staff are paid late, or their suppliers are, and the bank hears about it from relationship managers rather than from monitoring.
What to test
List the submission paths that face the internet and the cut-off each one serves. Then test each path in the hour before its cut-off, at the volume it actually carries then, because an attacker who has read the scheme's public timetable will pick that hour too.
Why can't a bank test the way other firms do?
Third parties sit on every important path, and the regulators expect a record.
You cannot load the rails
Card networks, payment schemes and market infrastructure are not yours to flood. Use their test environments, certification simulators or recorded traffic to stand in for them, and stop the attack traffic at your own edge.
The same applies to outsourced cores and processors. If your authorisation or core banking platform is run by a provider, the right to test it sits in your contract, and the provider's other clients share the infrastructure you would be loading.
The frameworks want the test written down
Threat-led testing under DORA in the EU, and CBEST in the UK, are scoped by regulators and have their own pages here: DORA DDoS testing and CBEST DDoS testing. Whatever framework applies, record each deadline you tested against, the load at which you missed it, and what you changed.
Extortion is the common opening
Financial firms are a familiar target for ransom DDoS, where a demand arrives with a short demonstration attack. A tested answer to "how long until the stand-in window opens" is worth more in that meeting than a capacity figure. Whether to pay, escalate or ride it out is a people question, and a DDoS tabletop exercise is where a firm should argue about it first.
A financial services DDoS test checklist
- List every external deadline: card scheme timeouts, instant payment limits, open-banking response times, settlement cut-offs, disclosure duties.
- For each one, name the rule that takes over when it is missed and who reports it to you.
- Map the fixed pools in front of the authorisation host: switch connections, service threads, HSM sessions.
- Measure authorisation latency under load against the scheme timeout, using a simulator in place of the network.
- Check whether your monitoring alarms before stand-in volume rises.
- Measure the open-banking API against the 30-second contingency line and confirm whether you hold an exemption.
- Test the customer login path with the third-party share added on top.
- Load the receiving side of instant payments and watch for rejected payments coming back as retries.
- Identify public pages that carry an obligation (disclosure, status, statements) and test them as critical paths.
- Agree in writing with any outsourced provider and any scheme contact before a production run.
FAQ
Can a bank run a DDoS test against card or payment scheme systems?
No. The schemes and networks are third-party infrastructure shared by every member. Test against their test environments or a simulator, and keep attack traffic at your own edge and your own services.
Does stand-in processing mean a card issuer cannot be hurt by a DDoS?
Cards keep working, but the issuer's own fraud and credit checks stop deciding. Every transaction in the stand-in window is approved or declined on old, coarse limits, and the issuer carries that risk.
What counts as an outage for an open-banking API under PSD2?
Under Article 33 of Delegated Regulation (EU) 2018/389, five consecutive information requests left unanswered within 30 seconds is treated as unavailability. Unless the bank holds an exemption, third-party providers may then use the customer-facing interface instead.
Is a DDoS test required for DORA or CBEST?
Neither framework is a DDoS-testing regime as such. Both expect resilience to be tested and evidenced, and a DDoS test is one way to produce that evidence for availability. The details are on the DORA and CBEST pages linked above.
When can a bank test if instant payments never stop?
Run heavy tests on a standby or production-like environment, then short, capped production runs with a scheme contact and an agreed abort. There is no zero-traffic window to wait for.
The deadline is the perimeter
A financial firm's real perimeter is not its firewall or its scrubbing provider. It is the set of moments at which a counterparty stops waiting.
Crossing it takes no breach and no broken server. Lateness is enough, and the rules that take over were written by the network, the scheme, the regulator and the exchange, not by you.
So the questions worth carrying into a test are concrete. Which deadline do we miss first? At what load? Who tells us, and how long after?