Data centers for finance in Frankfurt

An internet exchange is a place where networks connect to each other directly instead of paying a transit provider to carry traffic between them. DE-CIX in Frankfurt is the largest such exchange by traffic, and its platform is distributed across more than two dozen data centers in the Frankfurt area, which is why a tenant in one of them can reach the exchange without crossing the city.

For a financial firm the gain is two-sided. Traffic to a counterparty, a market data vendor or a cloud region that is also present on the exchange travels a short, known path with a predictable round-trip time, and the firm negotiates with the networks it actually needs instead of buying undifferentiated transit. Several hundred networks are reachable from the Frankfurt platform, which is the reason a firm with counterparties across Europe puts its edge here and not in a cheaper location with a single upstream.

Three things pulled in the same direction over two decades and each reinforced the next. The exchange drew networks, the networks drew the companies that wanted to reach them, and the companies drew more data centers, which gave the exchange more places to put its platform. Economists call that a cluster, and it explains why capacity keeps being built where it already is.

Finance arrived at the start of that loop and not at the end. The Deutsche Bundesbank, the European Central Bank and the commercial banks were in Frankfurt before the exchange existed, and Finanzplatz Frankfurt am Main describes the financial center that resulted. A bank that needs low-latency reach to a counterparty in the same city finds it in the same buildings as everyone else, which the finance in Frankfurt page sets in its wider context.

Light in fiber covers about 200 kilometers per millisecond, so physical distance sets a floor no equipment can go under. For a firm whose strategy depends on reacting to a price before another participant does, the only way under that floor is to sit closer, which is why venues sell colocation space next to their own matching engines and why the distance from a cabinet to the engine is measured in meters.

Not every system needs it. A settlement process, a reporting pipeline or a customer-facing banking application is unaffected by microseconds, and paying for a colocation cage next to a matching engine buys such a system nothing. The honest question is which part of the latency budget the business actually competes on, and the answer for most systems in a bank is none of it. The trading in Frankfurt page covers the venues; algorithmic trading in Germany covers the strategies for which the microseconds matter.

Deutsche Boerse runs its trading systems from the Frankfurt area, with its own site in Eschborn just outside the city, and the T7 trading architecture that serves Xetra and Eurex is operated from there. A participant that wants the shortest path to those systems takes space in the facility the exchange designates for it and buys a connection with a stated latency class, which is a product with published specifications and not a matter of geography alone.

The exchange's digital asset work sits on the same infrastructure story, and the page on Deutsche Boerse and digital assets covers it. A DLT trading venue has the same hosting question as a conventional one, with the 21X DLT trading venue in Frankfurt as the local example.

The binding constraint on a new data center in Frankfurt is electricity, not land. A site needs a grid connection of tens of megawatts, the connection has to be planned years ahead with the network operator, and the city has refused or deferred projects where the demand could not be served or where the municipal planning objected. For a bank, that turns capacity into something to secure early: a contract for space that has no firm power commitment behind it is a contract for a building.

The city has also attached conditions to new projects on land use and on what the heat is used for. The practical reading for a tenant is that expansion in the existing buildings is slower and dearer than the market used to assume, and that a growth plan needs a second location, which is where the sovereign cloud question about a second provider comes back from the other side.

Germany's Energy Efficiency Act sets requirements for data centers above a threshold of connected load: minimum targets for power usage effectiveness, a share of electricity from renewable sources, and reporting into a federal register, with obligations on waste heat reuse for new sites. A facility above the threshold also has to run an energy or environmental management system.

These rules reach a bank's own calculation in two places. A colocation contract with a long term is exposed to the operator's cost of meeting them, and a bank reporting its own energy figures needs the hosting provider's data to do it. Both belong in the contract before signature, next to the resilience and exit clauses that DORA in Germany requires.

Because the counterparties, the venues and the networks are there, and reaching them from elsewhere costs latency and transit. Space and power are cheaper in several other German regions, and a workload with no latency requirement and no need for dense peering genuinely belongs in one of them. The decision splits by workload: the latency-sensitive and heavily interconnected part stays in Frankfurt, and bulk compute and archives go where power is cheaper.

Colocation means the firm owns the servers and rents space, power, cooling and connectivity in someone else's building. Cloud means the firm rents the compute and owns no hardware. The difference that matters to a supervised institution is control and the shape of the dependency: in colocation the firm holds the machines and the operator supplies the facility, so a failure of the operator is a facility problem, while in cloud the provider holds the platform and a failure reaches the application. Both count as ICT third-party arrangements under DORA, and both go in the register of information.

A supervised institution cannot inspect every facility itself, so it buys the operator's audited reports instead, and the set it looks for is narrow. ISO 27001 covers the information security management system. An ISAE 3402 or SOC 2 report gives an auditor's opinion on the operating effectiveness of the controls over a period, which is the one a bank's own auditor will ask for by name. PCI DSS matters where card data passes through the space.

Frankfurt operators publish these as a matter of course. Telehouse states ISO 27001, ISAE 3402 and PCI DSS for its Frankfurt campus, which is the level a bank should expect as a baseline and not as a differentiator. The report to read is the one covering the period the bank was a tenant, with the exceptions section first.

The numbers are worth knowing because they set what a bank can plan for. Individual Frankfurt campuses run at tens of megawatts: Iron Mountain states 38 MW across its two Frankfurt facilities and 64,500 square meters of space, with access to more than 1,000 networks through DE-CIX. Telehouse states over 500 ISPs and carriers reachable from its campus.

Power sourcing has become part of the same conversation, because a bank reporting its own emissions needs the figure from its hosting provider. Operators now state renewable sourcing explicitly, Iron Mountain naming 100 percent renewable power for its sites, and a tenant should take that claim into the contract as a reporting obligation on the operator instead of a line in a brochure.