---
canonical: https://enum.co/de/use-cases/fintech
locale: de
---

**Fintech & Finanzdienstleistungen**

# Fintech Infrastruktur

Betreibe regulierte Services auf EU-Infrastruktur mit Residenz, Logging und Isolation, die Du Auditoren erklären kannst.

Fintechs, Banken und Finanzinstitute bauen regulierte Anwendungen auf enums europäischer Public Cloud in Frankfurt. Managed Kubernetes, S3-kompatibler Object Storage mit Object Lock und VPC-Networking unterstützen DSGVO-, DORA- und NIS2-Readiness, ohne US-CLOUD-Act-Risiko.


### Was Fintech-Teams trifft

- Datenresidenz, die Einkauf und Aufsicht akzeptieren
- Low-Latency-Pfade für Payment- und trading-nahe Workloads
- Nachweise für Zugriff, Änderungen und Aufbewahrung
- US-Cloud-Anbieter mit CLOUD-Act- und Transferrisiko

### Was Du auf enum betreibst

- Rechenzentren in Frankfurt unter deutscher und EU-Jurisdiktion
- High-Performance Kubernetes nah an Deinen Nutzern in Europa
- Infrastruktur-Audit-Logs plus Object Lock für unveränderliche Aufbewahrung
- Keine Abhängigkeit von einem US-Hyperscaler im Control- oder Data-Path

### Was sich ändert

- Eine europäische Public-Cloud-Story, die Security-Fragebögen übersteht
- Residenz- und Jurisdiktionsantworten ohne US-Cloud-Mutterkonzern
- Infrastruktur, die Du mit Standard-Kubernetes-Tooling betreibst

### So landen Fintech-Teams auf enum

Von der Risikobewertung bis zum Production-Cutover.

- **Residenz und Scope klären**: Festlegen, welche Workloads und Datensätze in der EU bleiben müssen. Frankfurt ist heute die Standardregion von enum.
- **Auf isolierten Planes deployen**: Jedes Kubernetes-Cluster bekommt eine eigene isolierte Control Plane. Segmente Umgebungen so, wie Dein Risikomodell es verlangt.
- **Sperren und loggen, was zählt**: Nutze Object Lock für aufbewahrungspflichtige Artefakte. Leite Change- und Access-Evidence in Dein bestehendes SIEM.

### Plattformteile, die zählen

Bausteine für regulierte Product- und Platform-Teams.

- **enum Kubernetes Engine**: Upstream Kubernetes mit isolierter Control Plane pro Cluster. Passt zu DORA- und NIS2-Betriebsmodellen.
- **Object Storage**: S3-kompatibler Storage mit Object Lock für Aufbewahrung und Evidence-Pakete.
- **VPC & Networking**: Privates Networking, L4 Load Balancing und Traffic-Segmentierung für regulierte Services.

### Weiterlesen

- [NIS2 & DORA](/kubernetes-nis2-dora): Wie EU-Kubernetes auf die Regeln mappt
- [Security](/security): Wie enum Plattformsicherheit angeht
- [enum Kubernetes Engine](/kubernetes-engine): Isolierte Control Planes in Frankfurt
- [Kundenstories](/customers): Produktionsteams auf enum
- [SaaS Use Case](/use-cases/saas): Multi-Tenant-Produkte auf demselben Stack
- [Kontakt](/contact): Risikomodell durchsprechen

### FAQ


**Hilft enum bei DORA und NIS2?**
enum liefert EU-betriebene Infrastruktur, isolierte Control Planes und Logging-Hooks, die Finanzunternehmen bei DORA und NIS2 unterstützen. Policies und Aufsicht bleiben bei Dir; die Plattform nimmt US-Cloud-Abhängigkeiten aus dem Stack.

**Unterliegen Kundendaten dem US CLOUD Act?**
Nein. enum ist ein deutsches Unternehmen und betreibt eine europäische Public Cloud in Frankfurt. Es gibt keine US-Muttergesellschaft, die unter dem CLOUD Act zur Herausgabe von EU-Kundendaten gezwungen werden kann.

**Können wir Produktion und Audit-Trails trennen?**
Ja. Betreibe getrennte Cluster und Projekte für Umgebungen und nutze Object-Lock-Buckets für aufbewahrungspflichtige Artefakte. Logs leitest Du wie auf jeder Kubernetes-Plattform in Dein SIEM.

**Wo gibt es mehr zu NIS2 und DORA?**
Auf der NIS2- und DORA-Seite von enum steht, wie souveränes EU-Kubernetes auf diese Rahmenwerke mappt.