How a German private bank resolved its Schrems II transfer risk and met DORA on bare-metal EU infrastructure

The deadline that forced a decision

The trigger was a BaFin pre-audit letter. A mid-sized German private bank, around 1,200 employees, was running its real-time transaction monitoring platform on a US hyperscaler. The letter flagged the cross-border data transfer mechanisms underpinning that arrangement as legally contested under the Schrems II ruling and demanded documented remediation before the bank’s DORA compliance attestation could proceed. The bank had roughly four months.

This was not a theoretical risk. The European Court of Justice had invalidated Privacy Shield in 2020, and subsequent standard contractual clause arrangements had faced sustained scrutiny from German data protection authorities. For a private bank handling client transaction data, the exposure was direct: continue on contested infrastructure and fail the audit, or migrate fast enough to meet the ICT third-party risk documentation requirements DORA now imposed.

The compliance team had already identified the workload in question. The transaction monitoring system processed intraday settlement flows and flagged anomalies in near real-time. It was latency-sensitive, tightly coupled to the bank’s core banking middleware, and carried the kind of personal financial data that left no room for ambiguous jurisdictional claims.

What BaFin’s DORA requirements actually demanded

DORA’s ICT third-party risk framework is specific. Regulated entities must maintain a register of ICT providers, assess concentration risk, and demonstrate that contractual arrangements with critical providers meet minimum requirements on auditability, data location, and exit provisions. For a bank whose transaction monitoring ran on infrastructure governed by US law, satisfying those requirements meant either renegotiating terms with a hyperscaler that had no obligation to comply, or moving the workload to a provider whose legal basis was unambiguously European.

The bank’s internal audit team had already attempted to use the hyperscaler’s EU-region offering. The problem was structural: EU-region nodes on a US-headquartered platform remain subject to US law through the parent entity, a point BaFin auditors had specifically raised. Standard contractual clauses did not resolve that because the legal exposure was not about where data sat at rest but about which jurisdiction could compel access to it.

What the auditors required was a provider incorporated and operating under EU law, with infrastructure physically located in the EU, contractual data residency commitments, and documented ICT third-party risk controls that could be presented in a single audit cycle. That combination ruled out every major US hyperscaler regardless of which region the bank selected.

The migration approach: bare metal in Munich, no shared tenancy

DIVERSITY’s MUC1 facility in Munich was the natural anchor. The bank’s operations are concentrated in the DACH region, latency to its core banking systems was a hard constraint, and MUC1’s position within the DACH finance and industry cluster meant the interconnects the bank needed were already present. The decision to run on bare-metal dedicated servers rather than virtualised cloud instances was driven by two factors: per-core software licensing costs and the auditability requirement.

On licensing, the bank’s transaction monitoring vendor priced on physical cores. On a shared hyperscaler instance, the bank was paying for cores it could not fully account for because the hypervisor layer introduced uncertainty about physical core mapping. On dedicated bare metal, every licensed core corresponded to a physical core on hardware the bank exclusively occupied. Consolidating onto a defined server configuration reduced per-core licensing spend materially while also simplifying the vendor’s audit trail.

On auditability, bare metal gave the bank’s auditors something concrete: a specific set of physical servers, a specific facility, a specific jurisdiction, and a contractual framework that named all of those things explicitly. DIVERSITY’s ISO 27001 certification and Tier III infrastructure classification provided the baseline documentation layer. The ICT third-party risk register entry for DIVERSITY could reference physical asset identifiers, not just a cloud account in a named region.

Jurisdiction is not a configuration option. If the legal entity operating your infrastructure answers to a foreign government, no regional setting changes that. The only fix is a different provider.

Architecture: keeping latency within tolerance

The transaction monitoring platform required sub-200-millisecond round-trip latency to the bank’s core banking middleware, which remained on premises in Frankfurt. MUC1 to Frankfurt over DIVERSITY’s backbone, with direct peering arrangements in place, kept observed latency well inside that threshold. The migration team ran a parallel operation period of six weeks, with both the legacy hyperscaler environment and the new bare-metal environment processing the same transaction feeds and reconciling outputs before cutover.

Storage for the monitoring platform used DIVERSITY’s block storage for the active transaction log and local NVMe on the bare-metal nodes for the hot working set. The cold archive, retained for regulatory purposes, moved to object storage with contractual EU-only replication, satisfying the data residency requirement for historical records as well as live data.

Network segmentation followed the bank’s existing security zoning model. DIVERSITY’s engineers worked with the bank’s internal security team to replicate the firewall policy and VLAN structure the bank had used on the hyperscaler, adapted for the bare-metal environment. No new security architecture was introduced mid-migration; the priority was a clean lift with documented equivalence, not a redesign that would introduce new variables into an already time-pressured audit process.

What the audit cycle produced

The bank submitted its ICT third-party risk documentation to BaFin within the required window. The DIVERSITY engagement produced three artefacts the auditors specifically requested: a data residency attestation covering both live and archived data, a contractual summary confirming DIVERSITY’s incorporation and operational jurisdiction under EU law, and a physical infrastructure inventory mapping the bank’s workloads to specific assets at MUC1.

The Schrems II exposure was eliminated at the legal entity level, not papered over with contractual workarounds. The contested transfer mechanisms that had triggered the pre-audit letter were simply absent: no US-headquartered provider, no cross-border transfer, no mechanism to contest.

Per-core licensing costs fell by consolidating onto dedicated hardware with a defined core count. The bank’s infrastructure team also recovered operational simplicity: a fixed hardware configuration is easier to capacity-plan and patch than a dynamic cloud environment where the underlying physical layer is opaque. Four months after the pre-audit letter, the bank’s transaction monitoring workloads were running on EU-sovereign bare metal, its auditors had what they needed, and the DORA compliance attestation proceeded without further qualification.