DDoS Protection for Banks and Payment Infrastructure

Financial infrastructure does not have a bigger version of the ordinary DDoS problem. It has a differently shaped one, and the differences change which product properties matter.

At a glance

Appliance	Constraint	What it rules out	What it demands instead
Latency budget	Long detours, challenge-response on transaction paths	Measured added latency under mitigation, not at idle
Evidence deadline	Telemetry that lives only in a supplier's console	Local retention and unassisted export in your format
Supervisory interest	Architecture decisions taken purely on cost	A documented rationale, and third-party concentration analysis
Partial-failure cost	Optimising for uptime percentage alone	Transaction completion measured end to end

None of these is about absorbing more traffic. All four change which product properties matter, and three of them are commonly discovered after signature.

Latency is part of correctness

In most estates, mitigation latency is a quality-of-experience question. In payment infrastructure it can be a correctness question: a transaction that exceeds its timeout is not a slow success, it is a failure that both sides must now resolve.

The consequence is that several standard countermeasures need scrutiny before they touch a transaction path. Challenge-response mechanisms add round trips. Diversion adds a detour. Holding suspicious connections rather than refusing them converts a refusal into a timeout, which is the expensive outcome described below.

The measurement that matters is added latency while mitigating at a substantial fraction of rated capacity, not at idle — and the distinction is exactly the one the KPI list draws for everyone else and insists on here.

A practical structure that resolves most of this: separate the transaction path from the customer-facing web path, and accept different mitigation postures on each. The web front end can tolerate a challenge; the payment API generally cannot.

Degraded is sometimes worse than down

This is the sector-specific insight and it inverts a common assumption.

A cleanly refused transaction is unambiguous. The customer sees a failure, retries, and nothing is left inconsistent. A transaction that hangs and times out mid-flow leaves state on both sides, generates a support contact, frequently produces a duplicate attempt, and lands in manual reconciliation.

So an availability target expressed as a percentage of uptime is measuring the wrong thing. The figure to protect is transaction completion end to end, and the failure mode to avoid is the ambiguous middle. Mitigation postures should be evaluated on whether they refuse cleanly or hold and hope.

Evidence has a deadline

Under DORA and NIS2 a major incident has a reporting timetable, and the report requires material that either exists or does not by the time it is needed.

Three properties follow, and none of them is about stopping traffic:

Local retention. Incident telemetry that lives only in a supplier’s console is evidence you do not control. Retention on your own infrastructure must cover the reporting window with margin.

Unassisted export. Your staff must be able to produce the record without the supplier’s help, in your format, on your schedule. Test this during evaluation rather than during the incident — it is item 19 of the buyer’s checklist for exactly this reason.

Demonstrable timestamps. A reconstruction that cannot show clock synchronisation across devices is weaker than one that can.

There is a second-order risk worth naming: a flood multiplies log events, and a pipeline at its licensed ceiling drops the events that were not about the flood. That is the mechanism by which an availability incident costs you evidence about something else entirely.

The regulator is a stakeholder in the architecture

Supervisory regimes reach further into design here than in most sectors. Third-party dependency and concentration are explicit concerns under DORA, which means an architectural decision that places critical function with one supplier is a decision that has to be explainable rather than merely economical.

Two consequences for procurement:

Dependency behaviour must be documented per function. Which parts of the defence stop when a supplier is unreachable is a supervisory question as well as an engineering one, and the fail-operational specification is the straightforward way to answer it.

Exit has to be real. An arrangement that cannot be unwound within a stated period is a concentration whether or not anyone calls it one. Contract terms on exit belong in the initial negotiation, not the renewal.

Where mitigation processes customer traffic across a border, data-residency rules interact with the architecture directly. That reasoning is worked through in local versus cloud-dependent detection and, for one regional regime, in GCC data residency.

Testing, which is not optional here

DORA’s testing regime makes resilience testing an obligation rather than good practice for entities in scope, and DDoS resilience testing covers what that means in detail.

The sector-specific additions to an ordinary test plan are three:

1. Transaction completion under attack, measured end to end through the real business path rather than at the connection layer.
2. Latency percentiles under mitigation, including the 99th, because tail latency is where timeouts live.
3. Behaviour at the transaction timeout boundary: does the defence refuse cleanly or hold until something expires?

The third is rarely tested and is the one that maps directly onto reconciliation cost.

What to specify

• Added latency under mitigation at half rated capacity, with percentiles, per path.
• Clean-refusal behaviour rather than hold-and-timeout, stated per countermeasure.
• Local evidence retention covering the reporting deadline with margin.
• Unassisted export, demonstrated by your staff during evaluation.
• Dependency behaviour per function, with grace periods as numbers.
• Exit terms, with a period.
• Separate mitigation postures for transaction and customer-facing paths.

The sizing arithmetic underneath all of this is the same as anywhere else and is in capacity sizing. What changes in this sector is not how much you need but which properties you cannot compromise on, and the list above is that set.