Private Anycast for a Digital Bank: When a Single CDN Becomes a DORA Concentration Risk
DORA's concentration-risk assessment asks whether a critical ICT provider is easily substitutable — for a bank running its entire edge through one CDN, the honest answer is usually no.
The short answer
DORA Article 29 requires a financial entity to assess, before signing an ICT contract for a critical function, whether it's "contracting an ICT third-party service provider that is not easily substitutable" — the exact language of the regulation. A digital bank or fintech payment platform that routes 100% of customer-facing traffic through a single CDN or hyperscaler edge is precisely the arrangement that question is aimed at: if that provider changes terms, has an outage, or takes an account action, there is no fallback path, because the network itself was never the bank's to control. Owning a private Anycast network — your own ASN, your own IP blocks, your own BGP announcements across multiple points of presence — is one way to answer "not easily substitutable" with "actually, it is, because it's ours."
Who this is for
This is for a CTO, Head of Infrastructure, or DORA compliance lead at a digital bank, e-money institution, or fintech payment platform who is running a concentration-risk assessment — either ahead of renewing a CDN contract, onboarding a new critical ICT provider, or populating the DORA Register of Information — and is asking whether the edge network itself belongs in the "hard to substitute" column.
It's not for the general case for owning a private edge that applies to any privacy-sensitive operator — casinos included — regardless of regulatory driver. That reasoning (account-ban risk, jurisdictional shutdown exposure, cost-at-scale economics) is covered in building a private Anycast edge from scratch and this post doesn't repeat it. And it isn't about tuning DDoS defenses on a CDN you're keeping — see DDoS protection for digital banks for that, a separate and earlier-stage decision that assumes your provider relationship stays as-is.
The regulatory question, stated plainly
DORA (Regulation (EU) 2022/2554) became fully applicable in January 2025. Article 29 requires financial entities to run a preliminary assessment before contracting an ICT arrangement supporting a critical or important function — weighing, among other things, whether the arrangement means:
- Contracting a provider "that is not easily substitutable," or
- Accumulating multiple contractual arrangements for critical functions "with the same ICT third-party service provider."
The regulation then directs the entity to weigh the advantages and disadvantages of alternatives, including using a different provider, against its own digital resilience strategy. That's a governance obligation, not a network design — NIS2 + DORA without the consultant theatre covers the broader third-party register requirement this sits inside. What it doesn't tell you is how to actually change your substitutability position for a specific critical function. For the edge network specifically, there's a direct technical answer: stop leasing the network, own it.
Why the edge network is a harder case than most ICT dependencies
Most of a bank's ICT stack has viable substitution paths on paper, even if switching is expensive — a core banking platform, a fraud-detection vendor, a cloud compute provider can all, in principle, be replaced with another vendor running the same category of service. The CDN/edge layer is structurally different for one reason: every one of those substitutes is still a single third party sitting in the same architectural position. Moving from Cloudflare to Akamai doesn't remove a single point of dependency — it relocates it. The "not easily substitutable" question DORA asks isn't really "can you find another vendor," it's "does your architecture require a vendor to sit in this position at all."
That distinction matters because concentration risk materializes even when the specific provider involved has nothing to do with a CDN. In May 2025, a network-infrastructure change at a single Fiserv data center — reported by American Banker — took down roughly 60 applications, including Zelle and ACH transfers, and disrupted service at Bank of America, Capital One, and Navy Federal Credit Union simultaneously; the outage took more than 12 hours to fully resolve. Fiserv is a payments processor, not a CDN, and this post isn't claiming otherwise — but the mechanism is the exact one Article 29 is written to catch: many financial institutions depending on one shared provider's infrastructure decision, with no independent path around it when that decision goes wrong. A CDN or edge provider sits in the identical structural position for customer-facing banking traffic, just further up the request path.
What owning the edge changes about the assessment
| Question DORA Article 29 asks | Single-CDN arrangement | Private Anycast (own ASN) |
|---|---|---|
| Is the provider easily substitutable? | No — switching CDNs relocates the dependency, it doesn't remove it | Not applicable — there's no third-party network contract in this position to substitute |
| Does a single provider's incident affect the critical function directly? | Yes — a CDN-side outage, policy change, or account action stops customer-facing traffic | The provider question doesn't arise for the network layer itself |
| What goes in the Register of Information for this function? | A third-party ICT provider entry with a criticality rating and (per Article 29) a documented substitutability assessment | The network layer is internal infrastructure, not a third-party ICT arrangement — though transit and IXP relationships still need their own, lower-criticality entries |
| Who controls the exit plan if the arrangement needs to end? | Bound by the provider's offboarding process and contract terms | You — it's your ASN and IP blocks under your legal ownership |
This isn't a claim that owning the edge eliminates every dependency — transit providers, IXP relationships, and colocation facilities are still third parties, and they belong in the register too, just at a different criticality tier than a single CDN account holding 100% of customer-facing traffic. The difference is architectural: a private Anycast network turns one high-criticality, hard-to-substitute dependency into several lower-criticality, genuinely substitutable ones (a given transit provider or IXP can be swapped without touching the ASN or the customer-facing IP space).
What's delivered, and what it doesn't include
A private Anycast engagement for a bank follows the same methodology as any other vertical, because the network build itself doesn't change based on the regulatory driver behind it:
- PoP location selection based on where the bank's customer base and traffic actually concentrate
- ASN registration and IP-block (IPv4/IPv6) coordination
- Anycast announcement and BGP setup across the selected PoPs
- Failover and health-check configuration
- Fault-injection and throughput validation before sign-off
That's the Global Private Anycast Network Setup engagement, sold in the same three tiers described in building a private Anycast edge from scratch — Setup, Setup + Operate, and Sovereign for multi-jurisdiction structures. What it doesn't include on its own: this post is not a DORA compliance certification, a legal opinion on whether your specific CDN arrangement meets the "not easily substitutable" bar, or a Register of Information template — that classification judgment sits with your compliance function and legal counsel, informed by the criticality of the function the edge network supports. It also doesn't cover moving existing live traffic onto a newly built edge without an outage, which is its own operational runbook — see migrating a live casino to private Anycast without downtime for the phased-cutover mechanics, which apply the same way regardless of industry.
Limitations
This is not a claim that every bank needs a private Anycast network to be DORA-compliant — for a platform below roughly 1–3 Gbps sustained egress, or one where the edge network genuinely isn't classified as supporting a critical function, a well-documented substitutability assessment and a credible exit plan with your existing CDN may be a defensible position without a network build. It's also not a claim that owning the edge removes concentration risk entirely — transit and IXP relationships remain third-party dependencies, just lower-criticality ones, and still belong in the third-party register. And it doesn't cover the DDoS-architecture or open-banking rate-limiting work that sits alongside this decision once a bank has an edge — whether hyperscaler-leased or privately owned — see DDoS protection for digital banks for that separate layer.
Decision: is the edge a critical function, and is it substitutable?
If your concentration-risk assessment for a CDN or edge provider is landing on "not easily substitutable" because there's genuinely no fallback path if that one contract ends badly, the fix isn't a different vendor in the same architectural slot — it's removing the slot. Request a network design review and we'll scope PoP locations, ASN and IP-block coordination, and failover architecture against your actual traffic profile and your compliance function's criticality classification.
Sources and review
DORA Article 29 text is quoted directly from the regulation as published on digital-operational-resilience-act.com, a reference mirror of Regulation (EU) 2022/2554. The May 2025 Fiserv outage details (institutions affected, ~60 applications, 12+ hour resolution) are drawn directly from American Banker's reporting. Private Anycast pricing tiers, methodology, and deliverables reflect AnySec's own published service terms, unchanged from building a private Anycast edge from scratch; no new AnySec-original statistic is introduced in this post. Author: AnySec Engineering. Published 2026-09-02; last reviewed 2026-09-02.
If you want a straight answer on whether your edge counts as a DORA concentration risk worth building around, get a fixed quote. We'll tell you if a documented exit plan is enough and a network build isn't necessary.
Related reading
- Building a private Anycast edge from scratch — the general account-ban, jurisdictional-shutdown, and cost-at-scale case for owning a private Anycast network, which this post assumes and doesn't repeat.
- DDoS protection for digital banks: the uptime-budget problem — the separate, earlier-stage decision that assumes you keep your existing CDN/DDoS provider and tunes availability architecture around a fixed regulatory KPI.
- NIS2 + DORA without the consultant theatre — the broader third-party register and control-family requirements this concentration-risk assessment sits inside.
- Private Anycast for a crypto exchange: when shared DDoS protection isn't enough — a different vertical's structural reason for the same ownership decision, driven by DDoS-mitigation queuing rather than regulatory concentration risk.
Rather not learn this in production.
Talk to the engineers behind these write-ups — no sales script, a straight read on where you stand.
Get a fixed quote