Software, die im Nachhinein belegen kann, was sie getan hat.

In der Finanz- und Versicherungsbranche entsteht der teure Teil eines Systems selten beim Bauen. Er entsteht dann, wenn ein Prüfer, ein Kunde oder eine Aufsichtsbehörde fragt, wie ein bestimmtes Ergebnis zustande gekommen ist — und die Antwort in Logdateien liegt, die nach 30 Tagen rotieren.

Was in diesem Umfeld anders ist

Nachvollziehbarkeit ist eine Anforderung an das Datenmodell, kein Log-File. Die Frage ist nie „was steht heute im System“, sondern „was stand am 14. März im System, wer hat es geändert und auf welcher Grundlage“. Systeme, die das können, speichern Historie statt Zustand: fachliche Ereignisse, unveränderliche Datensätze, versionierte Regelstände. Nachträglich lässt sich das kaum einbauen — es ist eine Architekturentscheidung am Anfang.

Auditierbarkeit heißt: Jemand sieht wirklich nach. Interne Revision, Wirtschaftsprüfung, Aufsicht, Kundenaudits. Software für dieses Umfeld muss ihre eigene Geschichte erzählen können: Welcher Stand lief wann in Produktion, wer hat ihn freigegeben, welche Berechtigungen bestanden zu diesem Zeitpunkt, welche Zugriffe gab es. Wir bauen diese Nachweise als Funktion des Systems, nicht als jährliche Handarbeit vor dem Prüfungstermin.

Betriebsstabilität ist reguliert, nicht bloß erwünscht. Ein Ausfall ist hier keine Unannehmlichkeit, sondern ein Vorfall mit Meldeweg und Frist. Deshalb gehören Wiederanlaufziele, Notfallpläne, geübte Wiederherstellung aus Backups und ein definierter Eskalationsweg für uns zur Erstlieferung. Ein System ohne Betriebskonzept ist in dieser Branche nicht fertig, sondern ein offenes Risiko.

Systemlebenszyklen sind lang — länger als Verträge, Frameworks und Anbieter. Ein Vertrag in der Lebensversicherung läuft dreißig Jahre. Ein Bestandssystem überlebt mehrere Anbietergenerationen. Bei dieser Zeitspanne ist die entscheidende Frage nicht, was die Erstentwicklung kostet, sondern ob es in acht Jahren noch Entwickler für die eingesetzte Technologie gibt und ob jemand den Code dann noch lesen kann. Genau diese Frage müssen wir uns seit 2012 für unser eigenes Produkt selbst beantworten.

Datenhaltung kommt vor der Architektur, nicht danach. Wo liegen die Daten, wer kann technisch darauf zugreifen, wie lange müssen sie aufbewahrt werden und wann müssen sie verschwinden? Aufbewahrungspflicht und Löschpflicht widersprechen einander regelmäßig. Das klärt man vor dem ersten Schema, nicht im Abnahmetest.

Was wir mitbringen

Historie im Datenmodell. Fachliche Ereignisse und Änderungsverfolgung als Teil der Anwendung: nachlesbar, exportierbar, mit Aufbewahrungs- und Löschregeln, die zu Ihren Fristen passen.

Nachvollziehbare Auslieferung. Jede Änderung ist einem Auftrag, einem Freigebenden und einem Zeitpunkt zuordenbar. Deployment-Historie, Umgebungstrennung, Vier-Augen-Prinzip auf Wunsch technisch erzwungen.

Betrieb mit belastbaren Zusagen. Monitoring, definierte Reaktionszeiten, dokumentierte Eskalation, geübte Wiederherstellung. Monatlicher Bericht darüber, was passiert ist und was ansteht.

Datenhaltung in Österreich oder der EU — auf Wunsch vollständig in Ihrem Rechenzentrum, inklusive der KI-Anteile.

Zuarbeit für Ihr Auslagerungsmanagement. Wir liefern die Angaben, die Sie für Ihr Informationsregister, Ihre Risikobewertung und Ihre Verträge brauchen — inklusive schriftlichem Ausstiegsszenario mit Code, Daten, Dokumentation und Zugängen.

KI nur mit Beleg. Wo Sprachmodelle eingesetzt werden, gilt: Quellenangabe zu jeder Antwort, Nachvollziehbarkeit der Eingaben, bestehende Berechtigungen werden respektiert, und bei Unsicherheit entscheidet ein Mensch. Ein Modell, dessen Ausgabe niemand prüfen kann, hat in einem regulierten Prozess nichts verloren.

DORA in der Praxis

Die EU-Verordnung zur digitalen operationalen Resilienz (DORA, Verordnung (EU) 2022/2554) gilt seit Jänner 2025. Sie betrifft Finanzunternehmen — und über die Vertragskette auch deren IKT-Dienstleister. Für ein Softwarevorhaben heißt das konkret drei Dinge:

• Verträge müssen mehr enthalten als Leistung und Preis. Zugriffs-, Auskunfts- und Prüfrechte, Standorte der Datenverarbeitung, Meldewege bei Vorfällen, Kündigungs- und Ausstiegsregelungen. Wir bringen diese Punkte von uns aus in den Vertragsentwurf ein, statt sie in der Rechtsprüfung nachreichen zu lassen.
• Sie brauchen Angaben über uns, nicht nur von uns. Für Ihr Informationsregister und Ihre Risikobewertung liefern wir die technischen und organisatorischen Angaben strukturiert zu.
• Ausstieg muss geplant sein, bevor er nötig wird. Übergabefähigkeit ist bei uns ohnehin Standard: Repository-Zugang ab Tag eins, Dokumentation als Teil der Lieferung, vollständige Rechteübertragung. Für dieses Umfeld schreiben wir es zusätzlich als Szenario auf.

Eine Einschränkung, die wir lieber vorher sagen: Die aufsichtsrechtliche Bewertung Ihrer Auslagerung ist Ihre Aufgabe, nicht unsere. Wir liefern das technische Fundament und die Nachweise dazu.

Typische Vorhaben

• Fach- und Nebensysteme rund um Bestands-, Kern- oder Vertragsverwaltungssysteme
• Antrags-, Schaden- und Freigabe-Workflows mit vollständiger Historie
• Schnittstellen zwischen Kernsystem, Archiv, Dokumentenmanagement und Partnersystemen
• Aufbereitung und Plausibilisierung von Daten als Zulieferung für Meldewesen und Reporting
• Kunden- und Vermittlerportale mit strenger Rechtelogik
• Ablösung gewachsener Excel- und Access-Fachprozesse, die längst geschäftskritisch sind
• Dokumentenverarbeitung und Wissenssuche mit lokal betriebenen Modellen

Wofür Sie jemand anderen brauchen

Wir bauen keine Kernbanken- oder Bestandsführungssysteme auf der grünen Wiese und ersetzen keine etablierten Standardprodukte in diesem Bereich. Wir sind auch keine Rechts- oder Compliance-Beratung. Unser Platz ist daneben und dazwischen: die Fachsysteme, Portale, Schnittstellen und Auswertungen, die Ihr Kernsystem nicht abdeckt — und deren Betrieb über Jahre.