---
type: industry
vertical: financial-services
title: Financial Services
description: "The framework read for banks and insurers under DORA: resilience testing as a duty, the ICT third-party register, tested exit plans, Tier 2 as the default."
status: draft
sidebar:
order: 50
label: Financial Services
source_url: "https://framework.stackit.cloud/architecture/industries/financial-services/"
source_file: "docs/architecture/industries/financial-services.mdx"
---
For workloads run by or for banks, insurers and other supervised financial entities in Germany,
and the operators who build for them. The mountain is the same as for everyone; this page maps
what the supervised route demands of it, and adds nothing.
## The regulatory map
What binds here, and what each regime asks of an architecture.
**DORA.** The EU regulation on digital operational resilience for the financial sector, applied
since January 2025 and supervised in Germany by
BaFin. It is a resilience regime, not a
residency regime: it asks whether critical functions survive ICT disruption, whether resilience
is tested rather than assumed, and whether dependencies on ICT third parties are inventoried,
contracted and exitable. That maps onto `REL`, [`SEC 11`](/architecture/pillars/security/sec-11-detection-and-response/), [`OPS 9`](/architecture/pillars/operational-excellence/ops-09-incident-management/) and the exit half of `SOV`
rather than onto placement.
**The supervisory risk management frame.** BaFin's
risk management supervision
carries the German administrative practice, MaRisk and BAIT among it, including the outsourcing
rules under which a cloud workload is a material outsourcing with notification, audit and exit
obligations. The current circulars come from the compliance function.
**The ICT third-party register.** DORA requires a maintained register of information on all ICT
third-party arrangements. For an architecture that means the processing chain must be known,
current and reportable, which is [`SOV 6`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/) asked by a supervisor instead of a customer.
**Exit is a supervised property.** Concentration risk and exit strategies for critical ICT
providers are explicit supervisory topics. An exit plan that exists on paper only fails
[`SOV 11`](/architecture/pillars/sovereignty/sov-11-exit-plan/), and here a supervisor asks the same question.
## The tier default
**Tier 2, sovereignty-preferred.** No general statute forces a German bank's workloads onto
sovereign infrastructure, and DORA regulates resilience, not residency. What the criteria
describe is elevated protection need and severe reputational and supervisory damage on
compromise, which is Tier 2.
The tier is set per data set, [`SOV 1.3`](/architecture/pillars/sovereignty/sov-01-sovereignty-tier/#sov-13-classify-per-data-set-because-a-workload-rarely-sits-at-one-tier), and rises where the data does: data under banking
secrecy in its strict reading, or data whose compelled disclosure to a foreign authority would
itself be a reportable event, is a Tier 1 conversation. Deviations in either direction are
recorded reasoning, [`SOV 1.2`](/architecture/pillars/sovereignty/sov-01-sovereignty-tier/#sov-12-record-the-reasoning-rather-than-only-the-result).
## The pillar weighting
Three pillars shift; each shift traces to the map.
**Reliability leads, and it is supervised.** DORA's subject is whether critical functions
survive disruption within stated tolerances. That makes [`REL 1`](/architecture/pillars/reliability/rel-01-reliability-targets/) and [`REL 2`](/architecture/pillars/reliability/rel-02-critical-flows/) regulatory artefacts
(impact tolerances per critical function are targets per flow with an accountable owner), and it
makes the testing questions, [`REL 9`](/architecture/pillars/reliability/rel-09-disaster-recovery/) and [`REL 10`](/architecture/pillars/reliability/rel-10-health-model-and-testing/), duties rather than good practice.
**Operational Excellence is elevated for incidents.** Major ICT incidents are classified and
reported on deadlines. [`OPS 9`](/architecture/pillars/operational-excellence/ops-09-incident-management/)'s severity model, roles and timelines stop being internal
conventions, and the telemetry in [`OPS 7`](/architecture/pillars/operational-excellence/ops-07-observability/) is what reconstructs an incident for a report.
**Sovereignty & Compliance is elevated on its exit half.** The register, the jurisdictional
chain, portability and the tested exit plan ([`SOV 6`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/), [`SOV 10`](/architecture/pillars/sovereignty/sov-10-open-interfaces/), [`SOV 11`](/architecture/pillars/sovereignty/sov-11-exit-plan/)) carry the
concentration-risk and exit expectations. The residency half binds as Tier 2, per data set.
Security is elevated in the ordinary supervised way: the baseline is externally framed
([`SEC 1.1`](/architecture/pillars/security/sec-01-security-baseline/#sec-11-derive-the-baseline-from-the-frameworks-you-are-actually-assessed-against) reads DORA, MaRisk and BAIT), and detection with a rehearsed response ([`SEC 11`](/architecture/pillars/security/sec-11-detection-and-response/))
feeds the reporting duties. Performance Efficiency, Cost Optimization and Sustainability do not
shift.
## The statement core
What an assessment of a supervised financial workload accounts for regardless of where the
conversation went: each of these ends evidenced or in the risk register.
### Reliability
| Statement | What makes it mandatory here |
|---|---|
| [`REL 1.1`](/architecture/pillars/reliability/rel-01-reliability-targets/#rel-11-quantify-what-an-outage-and-what-data-loss-cost-the-business) | Impact tolerances need the cost of disruption quantified, not estimated |
| [`REL 1.2`](/architecture/pillars/reliability/rel-01-reliability-targets/#rel-12-set-availability-rto-and-rpo-per-critical-flow-rather-than-per-workload) | Tolerances are set per critical function, which is per flow, not per workload |
| [`REL 1.4`](/architecture/pillars/reliability/rel-01-reliability-targets/#rel-14-have-each-target-agreed-and-recorded-by-someone-accountable-for-the-outcome) | A supervised tolerance needs an accountable name against it |
| [`REL 2.1`](/architecture/pillars/reliability/rel-02-critical-flows/#rel-21-enumerate-flows-by-what-they-deliver-not-by-the-components-that-implement-them) | The critical functions must be enumerated before anything can be tolerable |
| [`REL 2.2`](/architecture/pillars/reliability/rel-02-critical-flows/#rel-22-rank-flows-by-the-consequence-of-failure-rather-than-by-traffic-volume) | Ranking by consequence of failure is the supervisory expectation stated as method |
| [`REL 3.2`](/architecture/pillars/reliability/rel-03-failure-mode-analysis/#rel-32-decide-and-record-the-response-to-each-failure-mode) | A failure mode without a decided response is an untested tolerance |
| [`REL 9.2`](/architecture/pillars/reliability/rel-09-disaster-recovery/#rel-92-write-the-sequence-including-who-decides-to-invoke-it) | The recovery sequence with a named invoker is what a resilience test exercises |
| [`REL 9.3`](/architecture/pillars/reliability/rel-09-disaster-recovery/#rel-93-rehearse-it-and-time-the-rehearsal-against-the-rto) | Rehearsed and timed against the tolerance, or the tolerance is fiction |
| [`REL 10.3`](/architecture/pillars/reliability/rel-10-health-model-and-testing/#rel-103-inject-faults-and-verify-the-response-matches-the-design) | Testing digital resilience means injecting faults, not reviewing documents |
| [`REL 10.4`](/architecture/pillars/reliability/rel-10-health-model-and-testing/#rel-104-rehearse-failover-on-a-cadence-in-production-where-you-can) | A failover that never ran does not count as tested anywhere, least of all here |
### Sovereignty & Compliance
| Statement | What makes it mandatory here |
|---|---|
| [`SOV 6.1`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/#sov-61-maintain-a-current-inventory-of-every-party-that-processes-your-data) | The ICT third-party register demands a current inventory of the processing chain |
| [`SOV 6.3`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/#sov-63-treat-third-party-and-marketplace-services-as-part-of-the-chain) | Marketplace and sub-provider services are in the register or the register is wrong |
| [`SOV 8.1`](/architecture/pillars/sovereignty/sov-08-compliance-mapping/#sov-81-identify-which-frameworks-actually-apply) | DORA, MaRisk and BAIT apply differently per entity; which ones bind is step one |
| [`SOV 8.3`](/architecture/pillars/sovereignty/sov-08-compliance-mapping/#sov-83-establish-the-responsibility-split-per-control) | The responsibility split per control is what an outsourcing audit walks through |
| [`SOV 10.2`](/architecture/pillars/sovereignty/sov-10-open-interfaces/#sov-102-keep-data-in-portable-formats-and-know-how-to-get-it-out) | Portable data formats are the technical half of any credible exit |
| [`SOV 10.4`](/architecture/pillars/sovereignty/sov-10-open-interfaces/#sov-104-price-the-exit-for-each-dependency-and-accept-it-explicitly) | Concentration risk is priced per dependency and accepted explicitly, not discovered |
| [`SOV 11.1`](/architecture/pillars/sovereignty/sov-11-exit-plan/#sov-111-write-the-plan-as-steps-somebody-could-follow) | The exit plan must be steps somebody could follow, because somebody may have to |
| [`SOV 11.2`](/architecture/pillars/sovereignty/sov-11-exit-plan/#sov-112-rehearse-the-parts-that-can-be-rehearsed) | Rehearsing the rehearsable parts is what separates a plan from a chapter |
| [`SOV 11.3`](/architecture/pillars/sovereignty/sov-11-exit-plan/#sov-113-know-the-timeline-and-what-dominates-it) | The exit timeline is what a supervisor compares against the contract's notice period |
### Security and incidents
| Statement | What makes it mandatory here |
|---|---|
| [`SEC 1.1`](/architecture/pillars/security/sec-01-security-baseline/#sec-11-derive-the-baseline-from-the-frameworks-you-are-actually-assessed-against) | The baseline is externally framed: DORA, MaRisk, BAIT, and what the entity adds |
| [`SEC 11.1`](/architecture/pillars/security/sec-11-detection-and-response/#sec-111-collect-security-relevant-signals-where-the-subject-cannot-alter-them) | Incident reconstruction needs records the incident cannot have altered |
| [`SEC 11.2`](/architecture/pillars/security/sec-11-detection-and-response/#sec-112-alert-on-patterns-that-indicate-compromise-rather-than-on-volume) | Detection tuned to compromise patterns is what makes deadlines meetable at all |
| [`SEC 11.3`](/architecture/pillars/security/sec-11-detection-and-response/#sec-113-define-the-response-before-an-alert-fires) | The response, including who reports what to whom, is defined before the alert |
| [`SEC 11.4`](/architecture/pillars/security/sec-11-detection-and-response/#sec-114-rehearse-it-including-the-parts-that-are-not-technical) | The non-technical parts of response, reporting included, are rehearsed |
| [`OPS 7.1`](/architecture/pillars/operational-excellence/ops-07-observability/#ops-71-emit-metrics-logs-and-traces-and-make-them-joinable) | Joinable telemetry is what turns an incident into a reportable account |
| [`OPS 9.1`](/architecture/pillars/operational-excellence/ops-09-incident-management/#ops-91-define-severity-roles-and-escalation-before-you-need-them) | Severity, roles and escalation mirror the regulatory classification and deadlines |
| [`OPS 9.4`](/architecture/pillars/operational-excellence/ops-09-incident-management/#ops-94-track-review-actions-to-completion) | Review actions tracked to completion are what a follow-up inspection asks for |
## Outside this page
**Payments-specific regimes.** Card payment workloads carry PCI DSS beside everything here; that
is a contractual scheme regime with its own assessors and is not mapped here.
**The compliance function's territory.** Which circulars apply to which entity class, notification
thresholds and supervisory correspondence are legal questions. This page maps what the
architecture must be able to evidence; it does not interpret the law.
## Related
- [Reliability](/architecture/pillars/reliability/): the pillar the supervision reads first
- [Sovereignty & Compliance](/architecture/pillars/sovereignty/): the register and the exit