Registermodernisierung bei virtual7
RegMo: Behördernübergreifender Datenaustausch für Millionen Bürger:innen – Teil 2

Karlsruhe, 27.08.2026 (PresseBox) - Im ersten Teil dieser virtual7-Blogreihe habe ich die grundlegenden Ziele von RegMo vorgestellt und erläutert, warum ein verlässlicher Datenaustausch zwischen Behörden für Millionen Bürger:innen drei zentrale Herausforderungen mit sich bringt: Wie stellt man eine gemeinsame Eindeutigkeit über verteilte Register sicher? Wie sichert man die Datenqualität bei der Identifizierung? Und wie schafft man Transparenz für Bürger:innen? In diesem zweiten Teil vertiefe ich die ersten beiden Fragestellungen und zeige, wie sie sich in der technischen Anbindung an das BVA konkret niederschlagen.

Gemeinsame Eindeutigkeit: Zwei Abrufarten mit gegensätzlichen Profilen

Beim Identitätsdatenabruf muss man zwei grundverschiedene Abrufarten unterscheiden, die jeweils ihr eigenes Lastprofil mitbringen. Bei den Massendaten (Batch) werden große Mengen auf einen Schlag abgerufen, entweder bei der Erstbefüllung eines Registers oder bei einer Aktualisierung des gesamten Registerbestands. Bei den Einzeldaten (Online) geht es dagegen um den interaktiven Abruf einzelner Personen im laufenden Betrieb. Dieser Unterschied ist nicht nur konzeptionell, sondern schlägt sich in unterschiedlichen Schnittstellen beim BVA nieder.

Um zu prüfen, ob die geforderten Vorgaben in der Praxis eingehalten werden, stellt das BVA zwei Umgebungen bereit: eine Testumgebung, die dauerhaft zur Verfügung steht, sowie eine Lasttestumgebung, die man rechtzeitig beim BVA beantragen muss. Sowohl der dem Massendaten- als auch der Einzeldatenabruf sollte vor dem Produktivbetrieb über diese Umgebungen verifiziert werden.

Massendaten

Für die Massendaten werden die Abrufe zu Personenpaketen geschnürt. Viele Datensätze werden also gebündelt in Paketen übermittelt und verarbeitet, statt einzeln abgerufen zu werden. Das Zusammenstellen dieser Pakete nimmt einem die Schnittstelle aber nicht ab: Man muss sie selbst zusammenbauen. Die abrufende Stelle ist dafür verantwortlich, die einzelnen Datensätze regelkonform in Personenpakete aufzuteilen, sinnvoll zu dimensionieren und in der korrekten Struktur zu übergeben. Ebenso kommt die Antwort des BVA wieder in Form eines Pakets zurück und muss auf der eigenen Seite entsprechend entpackt werden, bevor sich die einzelnen Ergebnisse den ursprünglich übergebenen Personen zuordnen lassen. Die Paketierung betrifft also sowohl den Versand als auch den Empfang. Technisch ist ein solches Personenpaket als XML aufgebaut und folgt dabei dem Schema XBasisdaten.

Man könnte an dieser Stelle vermuten, dass sich das Bilden solcher Pakete über klassische Datenbankmechanismen wie Partitionierung oder Partition Switching automatisieren ließe, da diese Mechanismen im Regelfall genau das Aufteilen großer Datenmengen übernehmen. Das funktioniert hier aber nicht, weil eine Partitionierung entlang einzelner Personenpakete in eine sehr große Zahl kleinteiliger Partitionen münden würde, die sich kaum noch sinnvoll verwalten ließe.

Die Zusammenstellung der Pakete bleibt also Aufgabe der abrufenden Stelle und damit ein Stück Implementierungsaufwand, das man beim Anbinden von Anfang an einplanen sollte. Zur Paketierung gehört dabei mehr als das reine Bündeln der Datensätze: Pakete müssen nummeriert übergeben und in der vom BVA vorgegebenen Größe gebildet werden, und auch beim Entpacken der zurückkommenden Antwortpakete muss die Zuordnung sauber eingehalten werden.

Für die Massendaten gilt eine harte Mengenanforderung: Beispielsweise müssen 33 Millionen Datensätze in maximal 48 Stunden verarbeitet werden. Diese Frist wurde nicht von RegMo selbst festgelegt, sondern stammt vom Auftraggeber und ergibt sich aus dessen internen Prozessen. Wird sie nicht eingehalten, hat das im Echtbetrieb spürbare Konsequenzen in Form von Eskalationen beim Auftraggeber. Die Einhaltung ist deshalb kein optionales Qualitätsziel, sondern eine feste Randbedingung für die gesamte Architektur des Massendatenpfads. Rechnet man die Vorgabe auf einen konstanten Durchsatz herunter, ergeben sich rund 191 Personen pro Sekunde, die über zwei volle Tage hinweg ununterbrochen durch die Verarbeitung laufen müssen, inklusive Validierung, Abgleich, Verschlüsselung und Persistierung je Datensatz.

Die Geschwindigkeit selbst ist auf Wunsch des BVA auf 10 parallele Pakete mit je 200 Personen begrenzt. Diese 200 sind keine willkürliche Zahl, sondern eine Empfehlung des BVA selbst, mit der die Performance auf dessen Seite gewährleistet werden soll. Ob der geforderte Durchsatz unter dieser Drosselung tatsächlich erreichbar ist, lässt sich nicht rechnerisch beantworten, sondern nur, indem man sich der richtigen Dimensionierung der Verarbeitungen durch iterativen Tests nähert. Dabei helfen, wie eingangs beschrieben, insbesondere die Testumgebung und die Lasttestumgebung des BVA.

Im praktischen Einsatz hat sich mit einem Durchsatz von maximal 260 Personen pro Sekunde gezeigt, dass die Verarbeitung unter den veranschlagten 48 Stunden geblieben ist. Der geforderte Durchsatz ist also auch unter den vorgegebenen Drosselungsbedingungen erreichbar. Auf der Lasttestumgebung ließ sich das zusätzlich unter kontrollierten Bedingungen verifizieren: Dort lag der zuletzt gemessene, maximal erreichbare Durchsatz des BVA für Aktualisierungen bei etwa 340 Personen pro Sekunde, bei den Initialabrufen mit rund 260 Personen pro Sekunde etwas niedriger. Bemerkenswert ist dabei, dass diese Werte aus der Testumgebung und dem Produktivbetrieb ziemlich nah beieinander liegen, was zeigt, dass die Lasttestumgebung die tatsächliche Leistung des BVA recht zuverlässig vorhersagt.

Ein weiterer wichtiger Baustein ist der Einsatz eines Circuit Breakers: Kommt es beim Massendatenabruf zu wiederholten Infrastrukturfehlern, etwa weil eine nachgelagerte Schnittstelle überlastet oder zeitweise nicht erreichbar ist, verhindert der Circuit Breaker, dass immer weitere Anfragen ins Leere laufen und dadurch zusätzliche Fehler und Last erzeugen. Stattdessen wird der betroffene Pfad nach einer bestimmten Fehlerquote kurzzeitig unterbrochen, sodass sich das System erholen kann, bevor die Verarbeitung kontrolliert wieder aufgenommen wird. So bleibt die Massenaktualisierung resilient, ohne im Fehlerfall den gesamten Onlinebetrieb mit in Mitleidenschaft zu ziehen.

Einzeldaten

Für die Einzeldaten gilt umgekehrt eine harte Latenzanforderung: Ein einzelner Personenabruf muss innerhalb von 2 Sekunden beantwortet werden. Auch diese Vorgabe wurde nicht von RegMo selbst festgelegt, sondern vom Auftraggeber eine feste Randbedingung für die gesamte Architektur des Einzeldatenpfads vorgegeben. Das ist ein interaktiver Pfad, bei dem am anderen Ende jemand auf eine Antwort wartet. Hier zählt jede Millisekunde im Antwortzeitbudget. Ein Teil dieses Budgets ist zudem von vornherein vergeben: Die Anbindung erfolgt über das Netz des Bundes, wodurch der Verbindungsweg eine zusätzliche Latenz mitbringt, die sich technisch nicht wegoptimieren lässt. Diese Grundlast muss man von Beginn an einplanen.

Auch bei der Nebenläufigkeit sollte man realistisch, aber vorsichtig planen: Im Regelfall ist mit wenigen parallelen Abrufen zu rechnen, dennoch müssen bis zu 10 Personenabrufe pro Sekunde online parallel verarbeitet werden können, egal ob es sich um Aktualisierungen oder, bei neuen Personen, um Initialabrufe handelt. Anfragen dürfen dabei grundsätzlich nicht abgelehnt werden: Auch unter höherer Last müssen 95 Prozent aller Anfragen innerhalb von 2 Sekunden beantwortet werden.

Die verbleibende Zeit für die eigene Verarbeitung ist entsprechend knapper, als die 2 Sekunden auf den ersten Blick vermuten lassen. Auch die Onlinestrecke sollte man deshalb auf der Lasttestumgebung prüfen, um zu sehen, ob die Antwortzeit selbst unter Last eingehalten wird. Wie viel Zeit die einzelnen Verarbeitungsschritte tatsächlich brauchen, lässt sich am Ende nur über ein Monitoring genau auswerten.

Zusammenspiel und bewährte Praxis

Nachdem Massendaten und Einzeldaten jeweils einzeln betrachtet wurden, folgt nun der Blick auf ihr Zusammenspiel, denn beide Pfade wirken keineswegs unabhängig voneinander.

Es stehen sich zwei gegensätzliche Optimierungsziele gegenüber: Der Massendatenpfad ist auf Durchsatz getrimmt, der Einzeldatenpfad auf niedrige Latenz. Beide greifen jedoch auf denselben Datenbestand zu, und genau diese Spannung ist der Grund, warum eine saubere architektonische Trennung der beiden Wege keine Kür, sondern Pflicht ist. Der eigentlich kritische Punkt ist dabei die Datenbanklast: Eine Massenaktualisierung dieser Größenordnung erzeugt einen anhaltenden, hohen Druck beim Lesen und Schreiben auf denselben Datenbestand, der auch für den Onlinebetrieb gebraucht wird. Ohne Gegenmaßnahmen würde die Massenaktualisierung die interaktiven Abrufe ausbremsen. In der Praxis haben sich dafür getrennte Verarbeitungsstrecken bewährt, mit denen sich die beiden sehr unterschiedlichen Aufgaben sauber voneinander trennen lassen.

Ohne den Onlinedienst können Mitarbeitende keine neuen Personen anlegen, weil ihnen die IDNr fehlt, die genau über diesen Pfad abgefragt wird. Der Onlinepfad muss also durchgängig verfügbar bleiben, selbst während eine Massenaktualisierung im Hintergrund läuft.

DATENQUALITÄT BEI DER IDENTIFIZIERUNG SICHERSTELLEN: VOM ENTSCHEIDUNGSBAUM ZUM SCORING

Bleibt die zweite Herausforderung: der Abgleich der Bestandsdaten mit der richtigen Person. Naheliegend wäre ein Entscheidungsbaum. Man vergleicht Feld für Feld, also Name, Geburtsdatum, Geburtsort und Adresse, und hangelt sich über Verzweigungen zu einer Entscheidung zwischen Ja und Nein.

Schon an einem kleinen Beispiel zeigt sich das Problem. Betrachtet man nur zwei Felder und für jedes die beiden Ausgänge „passt" und „passt nicht", dann hat der Baum bereits vier Endknoten. Kommt ein drittes Feld hinzu, sind es acht, bei vier Feldern schon sechzehn. Mit jedem weiteren Feld verdoppelt sich die Zahl der Pfade; sie wächst also exponentiell mit der Zahl der Felder. Bei einer Handvoll Felder wird der Baum damit schnell unübersichtlich und kaum noch wartbar.

Das ist das Kernproblem: Je mehr Felder man einbezieht, desto komplexer wird er, weil die Zahl der zu berücksichtigenden Kombinationen und Verzweigungen rapide wächst. Der Baum wird unübersichtlich, schwer zu pflegen und spröde. Vor allem aber kommt er mit der Realität unscharfer Daten schlecht zurecht: Ein einziger Tippfehler im Namen oder ein fehlendes Feld kann eine Verzweigung „umkippen" lassen und so zu einer falschen Ablehnung führen.

Daher empfiehlt sich ein Scoring-Verfahren: Jedes Merkmal wird einzeln bewertet (z. B. per unscharfem Namensabgleich) und nach Aussagekraft gewichtet. Diese gewichteten Einzelwerte werden zu einem Gesamtscore aufsummiert, auf den man anschließend Schwellenwerte anwendet. Dabei wird festgelegt, ab welchem Wert eine Zuordnung als sicher genug für die automatische Übernahme gilt, ab wann eine manuelle Prüfung nötig ist und wann sicher keine Übereinstimmung vorliegt. Die Vorteile: Das Verfahren skaliert im Wesentlichen linear mit der Zahl der Felder, statt kombinatorisch zu explodieren. Es geht robust mit fehlenden oder unscharfen Daten um, weil ein einzelnes schwaches Feld nicht sofort die ganze Entscheidung kippt, sondern nur den Gesamtscore leicht senkt. Und es ist feinjustierbar, weil sich Gewichte und Schwellen anpassen lassen, ohne die gesamte Logik neu bauen zu müssen. Genau so wird aus dem Anspruch „prüfen, ob die Bestandsdaten wahrscheinlich übereinstimmen" ein tragfähiges, abgestuftes und nachvollziehbares technisches Verfahren.

Wie dieser Ähnlichkeitswert je Feld zustande kommt, hängt vom Feldtyp ab, und davor steht immer eine Normalisierung. Bevor überhaupt verglichen wird, werden die Werte in eine einheitliche Form gebracht. Die Schreibung wird vereinheitlicht, überflüssige Leerzeichen entfernt und Umlaute so wie Sonderzeichen werden angeglichen. Erst auf dieser bereinigten Basis greifen die feldspezifischen Vergleichsalgorithmen, denn jede Fehlerart braucht ein anderes Verfahren. Für Ziffernfelder wie die IDNr eignet sich die Editierdistanz nach Levenshtein, die Tippfehler wie vertauschte oder falsch erfasste Zeichen erkennt. Für Namen ist ein phonetisches Verfahren wie Double Metaphone die bessere Wahl, weil es unterschiedliche Schreibweisen desselben Klangs zusammenführt, etwa „Meyer", „Maier" und „Mayr". Je nach Feld kommen weitere Verfahren hinzu; entscheidend ist, dass jedes Merkmal mit dem Algorithmus verglichen wird, der zu seiner typischen Fehlerart passt.

Wie ein solches Scoring konkret aussieht, zeigen zwei Beispiele. Angenommen, ein Bestandsdatensatz soll einer Person zugeordnet werden, und es werden vier Merkmale verglichen: Name, Geburtsdatum, Geburtsort und Adresse. Jedes Merkmal erhält einen Ähnlichkeitswert zwischen 0 und 1 sowie ein Gewicht, das seine Aussagekraft widerspiegelt.

Im ersten Fall stimmt vieles überein. Der Name „Mayer" gegenüber „Meier" ergibt phonetisch eine volle Übereinstimmung (Wert 1,0 bei einem Gewicht von 0,30). Das Geburtsdatum ist identisch (Wert 1,0, Gewicht 0,30). Der Geburtsort „München" gegenüber „Muenchen" ist nach der Normalisierung ebenfalls gleich (Wert 1,0, Gewicht 0,20). Bei der Adresse „Hauptstraße 5" gegenüber „Hauptstr. 5" bleibt nach der Normalisierung nur eine kleine Restabweichung (Wert 0,9, Gewicht 0,20). Der gewichtete Gesamtscore beträgt 0,30 plus 0,30 plus 0,20 plus 0,18, also 0,98, und liegt damit klar über der Schwelle für die automatische Übernahme.

Im zweiten Fall häufen sich die Unschärfen. Der Name passt nur teilweise „Michael Krüger" gegenüber „Michael Krause" (Wert 0,6), im Geburtsdatum ist eine Ziffer vertauscht (Wert 0,7), der Geburtsort stimmt (Wert 1,0), die Adresse weicht deutlich ab „Bahnhofstraße 12" gegenüber „Bahnhofweg 3" (Wert 0,5). Bei denselben Gewichten ergibt sich ein Gesamtscore von 0,18 plus 0,21 plus 0,20 plus 0,10, also 0,69. Dieser Wert liegt im mittleren Bereich und löst deshalb eine manuelle Prüfung aus, statt den Datensatz automatisch zu übernehmen oder abzulehnen.

Auf den Gesamtscore wendet man abschließend feste Schwellenwerte an, zum Beispiel: Ab 0,90 gilt die Zuordnung als sicher genug für die automatische Übernahme, zwischen 0,50 und 0,90 ist eine manuelle Prüfung nötig, und unter 0,50 wird von keiner Übereinstimmung ausgegangen. In der Praxis hat sich als unterer Schwellenwert allerdings eher ein Wert von 0,65 bewährt statt 0,50, da man damit auf Nummer sicher geht: Kandidaten mit einem Score zwischen 0,50 und 0,65 erweisen sich erfahrungsgemäß fast nie als tatsächliche Treffer, verursachen in der manuellen Prüfung aber unnötigen Aufwand. Durch die Anhebung der unteren Grenze auf 0,65 wird die Menge an eindeutig irrelevanten Fällen, die manuell geprüft werden müssten, spürbar reduziert, ohne dass dabei relevante Treffer verloren gehen.

Die Erfahrung zeigt, dass es sich lohnt, das Scoring-Verfahren zunächst iterativ zu testen. Gerade weil bei der Initialbefüllung sehr viele Datensätze auf einmal zugeordnet werden, sollte man das Verfahren vorab an Testläufen erproben. Dabei nimmt man die Ergebnisse einer Teilmenge manuell unter die Lupe und prüft, ob Zuordnungen, Grenzfälle und Schwellen tatsächlich sinnvoll ausfallen. So stellt man sicher, dass die Datenqualität auch bei der großen Erstbefüllung wirklich trägt, statt Fehlerquellen erst im Echtbetrieb zu entdecken.