In der Versicherung endet kein Prozess in einem einzigen System. Angebot, Police, Zahlung, Schaden und Marketingeinwilligung wandern zugleich zwischen der Core-Plattform, dem Payment-Gateway, dem Data Warehouse und mehreren Registern. Das Tempo eines Versicherers bestimmt also nicht eine Anwendung, sondern ob diese Systeme miteinander sprechen und ob sich der gesamte Datenfluss gegenüber einer Aufsicht verteidigen lässt. Schwache Systemintegration in der Versicherung und eine lose gehandhabte DSGVO können eine Einführung um Monate aufhalten.
Aus unserer Erfahrung liegt das Schwierige nicht in der Integration selbst, sondern darin, sie in den Grenzen der Compliance zu halten und trotzdem neue Funktionen auszuliefern. Wir tun nicht so, als hätten wir eine laufende Einführung bei einem konkreten Versicherer, aber wir haben etwas ebenso Relevantes: Ingenieure, die transaktionale Systeme verbinden, die Datenschicht entwerfen und unter Prüfregime arbeiten. Diese Menschen setzen wir als Team-Verstärkung oder dediziertes Team in das Team des Kunden.
Warum entscheiden Integrationen und Compliance über das Tempo in der Versicherung?
Weil jede neue Funktion viele Systeme und viele Anforderungen zugleich berührt. Onlineverkauf zu starten ist nicht eine Maske, sondern die Verdrahtung von Tarifierung, Policenausstellung, Prämieninkasso und Einwilligungen. Ist ein Glied brüchig, wird das Ganze langsam.
Compliance wirkt hier entweder als Bremse oder als Hebel. Sind Prüfspur, Aufbewahrung und Einwilligungen vom ersten Tag an in der Architektur verankert, liefert das Produktteam schneller, weil es nicht nach jeder Compliance-Prüfung zurückrudern muss. Werden sie als Nachgedanke behandelt, verlangt jede Änderung den händischen Nachweis, dass keine Daten dorthin geflossen sind, wo sie nicht hingehören. In der Praxis setzt nicht der Code, sondern die Compliance am häufigsten den Go-live-Termin.
Wie integrieren Sie Core-Versicherungssysteme (APIs, Events, Datenmapping)?
Das Herz eines Versicherers sind Policen-, Schaden- und Abrechnungssystem. Wir verbinden sie meist auf zwei Arten, je Fall gewählt:
- synchron über APIs, wo der Kunde auf eine Antwort wartet (Prämientarifierung, Policenausstellung),
- asynchron über Events, wo Belastbarkeit und Skalierung zählen (Schadenanlage, Statusaktualisierungen, Benachrichtigungen),
- in Stapeln für Abstimmung und Reporting, die nicht in Echtzeit laufen müssen.
Ein eigenes und unterschätztes Thema ist das Datenmapping zwischen dem Core-Versicherungsmodell und dem übrigen Ökosystem. Hier entstehen die teuersten Fehler: derselbe Kunde in zwei Systemen, nicht zusammenpassende Produktcodes, ein Ereignisdatum in einem anderen Format. Wir entwerfen eindeutige Mapping-Regeln und Schlüsselverzeichnisse sowie eine Fehlerbehandlung, die nie eine Transaktion verliert: Wiederholungswarteschlangen, idempotente Operationen und einen Dead-Letter-Mechanismus, damit kein Event still verschwindet.
Wie verbinden Sie Zahlungen und Prämieninkasso mit den Systemen des Versicherers?
Zahlungen in der Versicherung sind keine einzelne Transaktion, sondern ein Zyklus: Einmal- oder Ratenprämien, gebuchte Prämie, Inkasso, Rückerstattungen beim Policenrücktritt und Provisionsabrechnung. Wir bauen die Integration mit Gateways und Zahlungsdienstleistern so, dass Geld und Policenstand nie auseinanderdriften. Entscheidend ist hier die Abstimmung: Jede Zahlung muss einer konkreten Prämienposition zuordenbar sein, und jede fehlende Zahlung muss den richtigen Mahnweg auslösen.
Besondere Aufmerksamkeit widmen wir der Konsistenz zwischen einem Zahlungsereignis und dem Policensystem. Eine bezahlte Rate sollte den Deckungsstatus automatisch aktualisieren, und eine fehlgeschlagene Belastung darf den Kunden nicht formal versichert, aber im Buch unbezahlt zurücklassen. Deshalb entwerfen wir transaktionale Bestätigungen und kompensierende Mechanismen und keine schlichten Fire-and-forget-Aufrufe.
Wie verwalten Sie Einwilligungen und Kundendaten im Einklang mit der DSGVO?
Hier trifft Architektur auf Recht. DSGVO-Konformität in der Versicherung ist keine Richtlinie in einem PDF, sondern sind konkrete Mechanismen im Code. Wir bauen sie um drei Säulen herum:
- ein Einwilligungsregister mit Historie: wer wann worin eingewilligt hat, unter welcher Fassung der Bedingungen und wann er widerrufen hat,
- Aufbewahrungsrichtlinien, automatisch durchgesetzt, getrennt für Policen-, Schaden- und Marketingdaten, abgestimmt auf die Rechtsgrundlage der Verarbeitung,
- das Recht auf Vergessenwerden, umgesetzt als Prozess, der Daten in allen Systemen löscht oder anonymisiert, nicht nur in einem.
Der letzte Punkt ist in der Praxis der schwerste. Kundendaten sind über Core, Warehouse, Logs und Backups verstreut, also muss ein Löschersuchen eine verteilte Operation mit Vollzugsbestätigung in jedem System sein. Wir entwerfen sie als kontrollierten Prozess, der Nachweise der Ausführung hinterlässt, denn „wir haben den Datensatz gelöscht” genügt vor einer Prüfung nicht.
Wie bauen Sie eine Prüfspur und Compliance-Logs, die niemand bestreiten kann?
Ein Prüfer fragt nicht, ob etwas passiert ist, er verlangt den Nachweis. Deshalb muss die Prüfspur vollständig und manipulationserkennend sein. Wir zeichnen Geschäftsereignisse und Zugriffe auf sensible Daten so auf, dass sich rekonstruieren lässt, wer wann und warum eine bestimmte Police oder Einwilligung angefasst hat.
Die Integrität dieser Logs gehen wir frontal an. Wir nutzen Append-only-Schreibvorgänge, Verkettung und Prüfsummen, damit sich zeigen lässt, dass ein Eintrag nachträglich nicht verändert wurde. Wir trennen außerdem technische Logs von der Prüfspur, weil beide unterschiedliche Lebenszyklen und unterschiedliche Adressaten haben. Dadurch dauert die Antwort auf „zeigen Sie uns, was mit diesen Daten geschehen ist” während einer Prüfung Minuten und nicht Wochen manueller Grabungen über Systeme hinweg.
Wie sichern Sie Daten in Versicherungsintegrationen ab?
Jede Integration ist ein neuer Berührungspunkt und damit eine neue Angriffsfläche. Versicherungsdaten sind sensibel und betreffen oft Gesundheit und Vermögen, deshalb entwerfen wir Sicherheit in Schichten:
- Verschlüsselung im Ruhezustand und bei der Übertragung, dazu die Minimierung dessen, was wir überhaupt zwischen Systemen übertragen,
- Zugriffskontrolle auf Basis von Rollen und minimalen Rechten, einschließlich der technischen Konten der Integration,
- Tokenisierung und Pseudonymisierung identifizierender Daten, wo die volle Identität nicht gebraucht wird,
- Verwaltung von Geheimnissen und Schlüsseln außerhalb des Codes, mit Rotation und Zugriffsprotokollierung.
Genau hier treffen sich Sicherheit und Compliance: Eine gut entworfene Zugriffskontrolle ist zugleich Nachweis für den Prüfer und echter Schutz vor einem Datenabfluss.
Welche Kompetenzen stellen wir für ein solches Projekt?
Wir schneiden das Team auf die konkrete Phase und den Technologiestack des Kunden zu, nicht „für alle Fälle”. In Integrations- und Compliance-Projekten besetzen wir am häufigsten:
- einen Integrationsarchitekten, der API-Verträge, Eventmodell und Mapping-Regeln setzt,
- Backend-Entwickler, die die Integrationen selbst, die Fehlerbehandlung und die Abrechnungslogik bauen,
- einen Data Engineer, der Datenschicht, Aufbewahrung und Qualität bewacht,
- einen DevOps-/Security-Spezialisten, verantwortlich für Geheimnisse, Verschlüsselung und Observability.
Wir ersetzen weder die Compliance-Abteilung des Kunden noch den Datenschutzbeauftragten. Wir stellen Ingenieure, die Compliance-Anforderungen in funktionierenden Code übersetzen und im Prüftakt einer regulierten Organisation arbeiten.
Wie machen wir das bei RITS?
Wir machen es als Nearshore-Partner aus Polen, der sich in ein bestehendes Team und einen bestehenden Prozess einfügt, statt mit einer Plattform zum Kauf aufzutauchen. Unsere Stärke liegt in Integration und Data Engineering:
- wir verbinden transaktionale Systeme und die Datenschicht so, dass der Geschäftsstand immer konsistent ist,
- wir entwerfen Compliance als Teil der Architektur (Einwilligungen, Aufbewahrung, Prüfspur) und nicht als Flicken am Ende,
- wir prüfen die Kompetenzen vor dem Start und schneiden das Team auf die Besonderheiten der Core-Versicherung und die regulatorischen Anforderungen zu,
- wir arbeiten in einer nahen Zeitzone, steigen also ohne lange Anlaufzeit in Code Reviews, Meetings und den Compliance-Rhythmus ein.
Meistens liefern wir das als Individualsoftware, gebaut von unserem Team, und wo der Kunde bereits ein Produkt hat und schnell Hände braucht, als Team-Verstärkung.
Wo beginnen Sie mit der Verbindung von Systemen und Compliance?
Beginnen Sie mit einer Datenflusskarte für einen kritischen Prozess, zum Beispiel der Ausstellung einer Police online samt Inkasso und Einwilligungen. Sehen Sie, welche Systeme sie berührt, welche personenbezogenen Daten wandern und wo die Prüfspur entsteht. Diese eine Übung legt meist die größten Lücken in Integration und Compliance offen und definiert nebenbei die Rollen, die Sie brauchen. Die Unterschiede zwischen den Kooperationsmodellen, in denen ein solches Team aufgebaut wird, haben wir in unserem Artikel zu IT-Kooperationsmodellen beschrieben.
Sie verbinden die Systeme eines Versicherers oder ringen mit der DSGVO über Integrationen hinweg? Sprechen wir darüber - wir stellen Team und Architektur passend zu Ihrer Core-Versicherung und Ihren Prüfanforderungen zusammen.