Der Kontext: wertvolle Daten in einem Zugriffsmodell, das nicht mehr tragfähig war
Die Abbrevia S.p.A. ist einer der führenden italienischen Anbieter für Business Intelligence und Kreditrisikobewertung. Ihr strategisches Kapital: eine eigene Datenbank zu Millionen italienischer Unternehmen, laufend aktualisiert mit Handelsregisterdaten, Jahresabschlüssen, negativen Ereignissen, Zahlungsstörungen und Auffälligkeitsmeldungen.
Über Jahre war dieser Datenbestand über klassische Abläufe zugänglich: manuelle Abfragen, Berichte auf Anfrage, periodische Batch-Exporte. Ein Modell, das für eine bestimmte Kundengeneration funktionierte — das aber zwei zusammenlaufenden Entwicklungen nicht mehr gewachsen war:
- Die AML/KYC-Compliance wurde gesetzlich verpflichtend, mit strengen Anforderungen an Audit Trails und die laufende Überprüfung von Geschäftspartnern für Banken, Finanzintermediäre und Zahlungsinstitute.
- Die Kunden erwarteten Zugriff in Echtzeit, keine nächtlichen Exporte. Ein Kreditvorgang kann nicht auf einen Bericht am nächsten Tag warten.
Die Schlussfolgerung war eindeutig: die bestehenden Prozesse zu optimieren genügte nicht. Nötig war eine Plattform, die für die Zukunft gebaut ist, nicht aus der Vergangenheit angepasst.
Die konzeptionelle Herausforderung: Multi-Produkt, Multi-Tenant, mission-critical
Das ursprüngliche Briefing legte drei nicht verhandelbare Dimensionen fest.
Multi-Produkt. Abbrevia wollte kein einzelnes Produkt, sondern eine Plattform, die Modulsuiten mit unterschiedlicher Logik aufnimmt — Credit-Risk-Scoring, Wirtschaftsauskünfte, AML/KYC-Compliance, laufendes Monitoring — jede mit eigenen Preis-, Zugriffs- und API-Regeln. Die Plattform musste erweiterbar sein: die Produkte von morgen durften keine Neuschreibung der heutigen Architektur erfordern.
Multi-Tenant auf Enterprise-Niveau. Die Kunden von Abbrevia sind beaufsichtigte Finanzinstitute: Banken, Intermediäre, Factoring-Gesellschaften, Zahlungsinstitute. Keine Endverbraucher, die einige Stunden Ausfall oder einen ungenauen Audit Trail hinnehmen. Jedes Institut verlangt die vollständige Trennung der Daten und die Fähigkeit, den Aufsichtsbehörden genau nachzuweisen, was abgefragt wurde, von wem, wann und mit welchem Ergebnis.
Raum nach oben. Das Ziel waren 4M+ Anfragen pro Jahr, mit Enterprise-Spitzen, die ohne Leistungsverlust zu bewältigen sind. Die Plattform musste aber so entworfen sein, dass sie wachsen kann, ohne dass die Architektur bei der ersten kommerziellen Expansion zum Engpass wird.
Die erste Entscheidung, auf die es ankam, war keine technische: es ging darum, die genaue Grenze zu ziehen zwischen dem, was die Plattform übernehmen würde, und dem, was die darunterliegenden Systeme von Abbrevia weiterhin leisten sollten. Diese Linie in einem Multi-Produkt-Projekt falsch zu ziehen bedeutet zunehmende Kopplung, teure Refactorings und eine Roadmap, die dauerhaft hinterherläuft.
Wie wir das Projekt aufgebaut haben
Bevor eine einzige Zeile Code entstand: drei Wochen Discovery und Architecture Review mit dem technischen und dem Business-Team von Abbrevia. Das Ziel war nicht, ein Dokument zu erstellen — es ging darum, die Erwartungen in vier kritischen Bereichen abzustimmen:
- Die bestehenden Datenflüsse und die Integrationspunkte mit den eigenen Datenbanken von Abbrevia
- Die spezifischen regulatorischen Anforderungen: AML/KYC, DSGVO in der Anwendung auf die Verarbeitung von Unternehmensdaten, Vorgaben der Banca d’Italia für beaufsichtigte Intermediäre
- Die tatsächlichen Nutzungsmuster der Enterprise-Kunden (wie viele Anfragen, in welchen Zeitfenstern, mit welchen Spitzen)
- Die nicht verhandelbaren Performance-Ziele: maximal akzeptable Latenz für Echtzeitabfragen, Verfügbarkeits-SLA, Wiederherstellungszeit nach einem Ausfall
Erst nach dieser Vorarbeit konnten wir eine Architektur festlegen, die das reale Problem löst und nicht das angenommene.
Die Architektur: drei getrennte Schichten für drei getrennte Verantwortlichkeiten
Die Plattform Abbrevia-X ist in drei Schichten mit klar abgegrenzten Verantwortlichkeiten und wohldefinierten Schnittstellen aufgebaut.
Layer 1 — Data & Integration
Eine Integrationsschicht, die die darunterliegenden Datensysteme von Abbrevia abstrahiert und der Anwendungsschicht standardisierte APIs bereitstellt. Diese Schicht übernimmt Query-Optimierung, intelligentes Caching für häufig abgefragte Profile, die Normalisierung von Daten aus heterogenen Quellen (Handelsregisterdaten, Kreditinformationen, negative Ereignisse) und die Steuerung der Aktualisierungen. Der Wechsel einer darunterliegenden Datenquelle erfordert keinen Eingriff in die darüberliegende Schicht.
Layer 2 — Product Core
Der Kern der Plattform beherbergt die Produktmodule mit eigener Geschäftslogik: Credit Risk & Scoring für den Echtzeitzugriff auf Unternehmensprofile mit mehrdimensionalem Scoring; AML/KYC Module mit strukturierten Abläufen für Onboarding, periodische Due Diligence und laufendes Monitoring, unveränderlicher Audit Trail inklusive; Report & BI für die Erstellung ausführlicher Wirtschaftsauskünfte; Monitoring für das automatische Alerting bei Veränderungen in den Profilen der überwachten Geschäftspartner.
Layer 3 — Tenant Management & Gateway
Verwaltung des Multi-Tenant-Zugriffs mit vollständiger Isolation zwischen den Kunden, API-Key-Management, Rate Limiting je Vertragsmodell, Billing-Integration und granulare Nutzungsanalysen pro Produkt und pro Kunde. Diese Schicht ist zugleich der Einstiegspunkt für Enterprise-Integrationen über API.
Die technischen Entscheidungen, die den Unterschied gemacht haben
Event-driven für das laufende Monitoring
Für das Monitoring-Modul mit 6M+ Profilen wäre aktives Polling nicht tragfähig gewesen: Millionen von Datensätzen periodisch auf Veränderungen zu prüfen hätte unverhältnismäßige Rechenressourcen erfordert. Wir haben eine event-getriebene Architektur gewählt: wird ein überwachtes Profil in den darunterliegenden Systemen aktualisiert, wird ein Event ausgelöst, das die für diesen Kunden konfigurierten Subscriber asynchron verarbeiten. Das Ergebnis: Benachrichtigungen in Echtzeit, ohne dass die Rechenlast linear mit der Zahl der überwachten Profile wächst.
4M+ Anfragen pro Jahr, bewältigt ohne aktives Polling über Millionen von Profilen. Event-driven war keine Modeentscheidung: es war die einzige in dieser Größenordnung tragfähige Architektur.
Unveränderlicher Audit Trail für die AML-Compliance
Für beaufsichtigte Kunden ist die Fähigkeit, den Kontrollorganen nachzuweisen, wann eine Prüfung erfolgt ist, durch wen, zu welchem Geschäftspartner und mit welchem Ergebnis, keine Wunschanforderung: es ist eine regulatorische Vorgabe. Jeder Vorgang im AML/KYC-Modul erzeugt einen signierten, unveränderlichen Eintrag im Log, mit zertifiziertem Zeitstempel, Kennung des Bearbeiters, Hash der abgefragten Daten und Ergebnis der Prüfung. Dieser Audit Trail ist in einem Standardformat exportierbar, für die Meldepflichten gegenüber der Banca d’Italia und den europäischen Aufsichtsbehörden.
Die entscheidende konzeptionelle Wahl: der Audit Trail wurde als primäre Anforderung entworfen, nicht nachträglich ergänzt. Compliance-Systeme, die ihn als Nachgedanken bauen, lassen im Moment der echten Prüfung immer etwas offen.
Multi-Tenant mit vollständiger Isolation, nicht mit Shared Tenancy
Die betrieblich günstigere Lösung — ein zwischen den Tenants geteiltes Datenbankschema mit Row-Level Security — war für beaufsichtigte Finanzinstitute nicht akzeptabel. Die vollständige Trennung kostet mehr an Infrastruktur und Betriebsaufwand, ist aber die einzige Architektur, die eine regulatorische Prüfung ohne Kompromisse besteht — eine Prüfung, die den Nachweis verlangt, dass kein übergreifender Zugriff zwischen Kunden möglich ist.
Bulk-APIs für die Enterprise-Kunden
Enterprise-Kunden — Banken mit Portfolios von tausenden Geschäftspartnern — nutzen die Plattform nicht Anfrage für Anfrage. Sie müssen ihre internen Systeme in großem Umfang anreichern, neue Geschäftspartner im Batch importieren und alle überwachten Profile periodisch aktualisieren. Wir haben Bulk-APIs entworfen, mit asynchroner Job-Verarbeitung, Benachrichtigung bei Abschluss, Rate Limiting je Vertragsmodell und einem Status-Dashboard, sodass Standardkunden während der Nutzungsspitzen der Enterprise-Kunden nicht benachteiligt werden.
Die Ergebnisse
Die Plattform ist heute das wichtigste strategische Produkt von Abbrevia, mit Kunden im gesamten italienischen Finanzsektor: Geschäftsbanken, Kreditintermediäre, Factoring-Gesellschaften, Zahlungsinstitute, Unternehmensberatungen. Das AML/KYC-Modul hat Abbrevia den Zugang zu Kundensegmenten eröffnet, die vorher nicht bedient werden konnten, weil ein zertifizierbarer Compliance-Ablauf fehlte.
Wir arbeiten seit mehreren Jahren mit TC Consulting an der Entwicklung von Softwarelösungen und an Projekten mit integrierter künstlicher Intelligenz. Über die technische Kompetenz hinaus macht vor allem die Professionalität der Menschen den Unterschied: ein gut aufgestelltes Team, erreichbar und in der Lage, geschäftliche Anforderungen wirklich zu durchdringen. Ein verlässlicher, ergebnisorientierter Partner, mit dem sich Wert über die Zeit einfach aufbauen lässt.
Was uns dieses Projekt gelehrt hat
Die Grenze zwischen Plattform und Produkt ist eine strategische Entscheidung, keine technische
Die erste Frage ist nicht «welches Framework nehmen wir», sondern «wo endet die Plattform und wo beginnt das Produkt». In einem Multi-Produkt-System bedeutet eine falsch gezogene Linie eine fortschreitende Kopplung, die jede neue Entwicklung ausbremst. Wochen in die Discovery zu investieren, bevor Code entsteht, ist kein Kostenfaktor: es ist die beste Investition des Projekts.
In regulierten Branchen ist der Audit Trail keine spätere Ergänzung
Baut man ihn als Nachgedanken — «wir ergänzen ihn, wenn er gebraucht wird» — fehlt im Moment der echten Prüfung immer etwas. Der Audit Trail gehört als primäre Architekturanforderung entworfen, nicht als Feature für Release 2.0. Die Kosten einer nachträglichen Ergänzung werden systematisch unterschätzt.
«Echte» Mandantentrennung ist im Finanzsektor nicht verhandelbar
Die vollständige Trennung kostet im Betrieb mehr als Shared Tenancy. In einem Umfeld, in dem die Kunden der Aufsicht unterliegen, ist sie aber die einzige Architektur, die eine regulatorische Prüfung ohne Kompromisse und Notlösungen übersteht. Die Ersparnis bei der Infrastruktur wiegt das Risiko nicht auf, die Isolation bei einer Inspektion nicht nachweisen zu können.