Wirtschaftlich Berechtigte (UBO) per API ermitteln: 25%-Schwelle, Eigentümerketten und KYC in der Praxis

Wer steht eigentlich wirklich hinter einer GmbH? Im Handelsregister findest du den oder die Geschäftsführer:innen – aber das sind selten dieselben Personen, die das wirtschaftliche Risiko tragen und am Ende profitieren. Genau diese Lücke schließt der Begriff des wirtschaftlich Berechtigten (englisch: Ultimate Beneficial Owner, kurz UBO). Für KYC, AML und Lieferanten-Screening ist das die zentrale Frage: Wer profitiert wirklich, wer kontrolliert das Unternehmen tatsächlich? In diesem Artikel zeige ich dir, was UBOs aus juristischer Sicht sind, warum die Ermittlung in der Praxis so unangenehm ist, und wie du sie mit dem neuen feature=ubos der handelsregister.ai API in einem sauberen Workflow automatisch auflöst – inklusive 25%-Schwelle nach GwG, Coverage-Anzeige und Audit-Trail.

Was ist ein wirtschaftlich Berechtigter? GwG, 25%-Schwelle, fiktiver UBO

Der wirtschaftlich Berechtigte ist ein definierter Rechtsbegriff aus dem Geldwäschegesetz (GwG). Vereinfacht: Es geht um die natürliche Person, die ein Unternehmen letztlich besitzt oder kontrolliert – nicht die juristische Person dazwischen, sondern der Mensch am Ende der Kette.

Das GwG nennt drei Kontrollindikatoren, die für sich genommen ausreichen, um eine natürliche Person als UBO zu qualifizieren:

• Mehr als 25 % der Kapitalanteile an der Gesellschaft halten,
• mehr als 25 % der Stimmrechte kontrollieren, oder
• auf vergleichbare Weise Kontrolle ausüben (zum Beispiel über Stimmbindungsverträge, Treuhand oder Konzernstrukturen).

Die berühmte 25%-Schwelle ist also nicht beliebig, sondern gesetzlich verankert. Anteile unterhalb dieser Schwelle machen niemanden zum UBO im Sinne des GwG – sie sind aber trotzdem datenseitig interessant, weil sie das Gesamtbild der Eigentümerstruktur ergänzen.

Und wenn sich nach gründlicher Prüfung niemand finden lässt, der die Schwelle reißt? Dann greift der fiktive wirtschaftlich Berechtigte: das sind die gesetzlichen Vertreter:innen des Unternehmens – bei einer GmbH typischerweise die Geschäftsführer:innen. Wichtig: „fiktiv" ist hier kein Etikett für „erfunden", sondern ein Auffangtatbestand. Wer sich als Compliance-Verantwortliche:r nur auf den fiktiven UBO verlässt, ohne ernsthaft nach einem echten gesucht zu haben, hat seine Sorgfaltspflicht nicht erfüllt.

Drei Datenquellen, drei Antworten – und was die API wirklich nutzt

Wichtig vorab, weil das oft missverstanden wird: Die feature=ubos-Berechnung von handelsregister.ai stützt sich ausschließlich auf die Gesellschafterlisten aus dem Handelsregister – das Transparenzregister wird nicht mit ausgewertet. Das ist eine bewusste Entscheidung, denn die drei in Frage kommenden Quellen sind sehr unterschiedlich belastbar:

• Transparenzregister (§§ 19 ff. GwG): Das offizielle Register für wirtschaftlich Berechtigte, seit 2021 als Vollregister geführt. Klingt sauber, ist es aber nicht: Es handelt sich um Selbstauskünfte der Unternehmen, Datenqualität und Aktualität schwanken stark, und der Abruf ist gebührenpflichtig sowie nicht maschinenfreundlich.
• Gesellschafterlisten im Handelsregister: Die rechtlich maßgebliche Aufstellung der Anteilsinhaber – vom Notar eingereicht und gesellschaftsrechtlich wirksam. Aus ihr lässt sich auf der ersten Ebene direkt ableiten, wer mehr als 25 % hält. Ist der Gesellschafter selbst eine juristische Person, brauchst du deren Gesellschafterliste, und so weiter – manuell ist das schnell ein halber Tag pro Konzern.
• handelsregister.ai API (feature=ubos): Greift auf die Gesellschafterlisten zu, löst die Eigentümerketten rekursiv auf und liefert das Ergebnis als strukturiertes JSON. Du bekommst also die durchgerechnete Sicht auf das, was im Handelsregister tatsächlich belegt ist – nicht, was jemand dem Transparenzregister gemeldet hat.

Konsequenz für deine Compliance-Logik: Die API liefert den belegbaren UBO – die Person, deren Beteiligung sich aus offiziellen Registereinträgen ergibt. Wo du das Transparenzregister zusätzlich brauchst, sind Sonderfälle, in denen Kontrolle nicht über eingetragene Beteiligungen läuft (Stimmbindung, Treuhand, Konzernverträge). Solche Fälle erkennst du in der API-Antwort an einer niedrigen Coverage.

Warum Eigentümerketten so schwer aufzulösen sind

Bei einer kleinen GmbH mit zwei natürlichen Gesellschaftern ist UBO-Ermittlung trivial. Sobald aber juristische Personen Anteile halten, fängt die eigentliche Arbeit an: Du musst über jede Ebene durchrechnen.

Typisches Beispiel: Die Ziel-GmbH gehört zu 60 % einer Holding-GmbH. Die Holding gehört zu 80 % einer zweiten Holding. Die zweite Holding gehört zu 50 % einer Stiftung und zu 50 % einer Familie aus drei Personen. Durchgerechnet auf die Ziel-GmbH: Familienmitglieder je rund 8 %, Stiftung 24 %. Damit reißt keine einzelne natürliche Person die 25%-Schwelle.

Heißt das automatisch „kein UBO"? Nein – Kontrolle kann auch über Stimmrechte, Konzernverträge oder Geschäftsführungseinfluss laufen, und Stiftungen sind ein Sonderfall (dazu später). Diese Mehrebenen-Logik manuell durchzurechnen ist fehleranfällig und für ein Onboarding-Volumen jenseits einer Handvoll Cases im Monat schlicht nicht skalierbar.

UBOs mit feature=ubos abrufen: Endpoint, Antwort, Kosten

Genau hier setzt das neue Feature an. Der Aufruf ist denkbar schlank – ein einziger HTTP-Request auf /v1/fetch-organization mit dem zusätzlichen Feature-Flag:

curl -X GET 'https://handelsregister.ai/api/v1/fetch-organization?q=Beispiel%20Holding%20GmbH&feature=ubos&ai_search=on-default' \
     -H 'x-api-key: YOUR_API_KEY'

Was kommt zurück? Drei Dinge, die im KYC-Kontext den Unterschied machen:

• Aufgelöste Eigentümer – natürliche Personen, deren Beteiligungsquote über die gesamte Kette durchgerechnet wurde. Personen ab 25 % werden direkt als UBO nach GwG markiert; Anteile darunter erscheinen mit dem Hinweis „unter 25 %", damit du sie für deine eigene Risikobewertung nicht verlierst.
• Nicht aufgelöste Eigentümer – juristische Personen oder Konstrukte, deren Eigentümer nicht weiter rückverfolgbar waren (typisch: Auslandsgesellschaften, Stiftungen ohne öffentlich verfügbare Begünstigtenliste, fehlende Daten in der Kette).
• Coverage – ein Maß dafür, welcher Anteil der gesamten Eigentümerstruktur tatsächlich aufgelöst werden konnte. Eine Coverage von 100 % heißt: jede Stimme, jede Quote landet am Ende bei einer natürlichen Person. Eine Coverage von 70 % heißt: 30 % der Struktur sind im Dunkel – und das musst du für deine Akte wissen.

Genau diese Coverage-Angabe ist das, was den API-Aufruf von einem reinen Bauchgefühl-Lookup unterscheidet. Du bekommst nicht nur „hier sind die UBOs", sondern auch „so vollständig ist diese Antwort". Das ist die Information, die ein Auditor sehen will.

Kosten und Fair Use: Das ubos-Feature kostet 10 Credits pro Abfrage, wird aber nur berechnet, wenn tatsächlich Daten geliefert werden. Findet die API nichts (zum Beispiel bei einer ausländischen Briefkasten-Konstruktion), zahlst du nichts. Das Feature ist in den Plänen Plus, Pro und Max enthalten und befindet sich aktuell in der Beta.

Ein KYC-Workflow von Suche bis Audit-Trail

So sieht ein robuster Onboarding-Flow aus, wenn du UBO-Checks per API in dein KYC einbettest. Der Ablauf bewährt sich gleichermaßen für CRM-Onboarding, Lieferantenfreigabe und periodische Reviews:

1. Eindeutig identifizieren. Ein Firmenname allein ist mehrdeutig. Wenn du die Handelsregisternummer hast, nimm sie. Sonst suche zuerst über /v1/search-organizations und fixiere die entity_id.
2. UBOs abrufen. Ein Aufruf auf /v1/fetch-organization?feature=ubos. Optional zusätzlich feature=related_persons für Geschäftsführung – spart spätere Folge-Calls.
3. Coverage prüfen. Liegt die Coverage unter deinem internen Schwellwert (z. B. 80 %), markiere den Fall als „enhanced due diligence". Das ist das Risikosignal, das ein normaler UBO-Lookup nicht liefert.
4. Schwellen-Logik anwenden. Filtere alle aufgelösten Eigentümer mit ≥ 25 % als regulatorisch relevante UBOs. Personen unter 25 % wandern in einen Beobachtungstopf für interne Zwecke.
5. Fiktiven UBO verankern. Reißt nach Schritt 4 niemand die Schwelle, dokumentierst du das ausdrücklich und fällst auf den fiktiven UBO zurück (Geschäftsführung). Die Begründung gehört in die Akte, nicht nur das Ergebnis.
6. Audit-Trail schreiben. Speichere Zeitstempel, Identifier, vollständige API-Antwort (inkl. Coverage), angewendete Schwellen-Logik und Sachbearbeiter:in. Genau diese Dokumentation wollen GwG-Audits sehen.

Wenn du diesen Flow in n8n abbildest, brauchst du im Kern drei Nodes plus eine Set-Stufe für die Schwellen-Logik – siehe dazu auch unsere Anleitung zur Gesellschafterliste-Einreichung für die rechtliche Einordnung.

Edge Cases, die jeder UBO-Workflow sehen wird

In der Praxis stolpert man immer über dieselben Sonderfälle. Plane sie von Anfang an mit ein:

• Stiftungen. Eine Stiftung hat formal keine Eigentümer, sondern Begünstigte (Destinatäre). Ob ein Destinatär als UBO gilt, hängt vom Stiftungszweck und der Satzung ab. Die API kann hier Stiftungen oft nicht weiter auflösen – das landet in „nicht aufgelöst" und sollte ein Eskalations-Trigger sein.
• Auslandsbeteiligungen. Sobald die Kette über die deutsche Grenze geht, hört das Handelsregister auf. Eine BV in den Niederlanden oder eine Ltd. in Irland sind nicht im deutschen Datenbestand. Erwartung: Coverage sinkt, Hinweis „nicht aufgelöst" erscheint, Risikobewertung manuell.
• Fiktiver UBO als Default. Pass auf, dass deine Logik den fiktiven UBO wirklich nur dann als Antwort akzeptiert, wenn echte Suche erfolglos war. Manche Tools (und manche Risikomodelle) springen zu früh auf den fiktiven UBO – das ist regulatorisch problematisch.
• Aktualität. UBO-Daten sind immer eine Momentaufnahme. Anteilskäufe, Erbgänge, Insolvenzen verschieben Quoten – manchmal ohne dass das sofort im Register sichtbar ist. Periodische Re-Checks (mindestens jährlich, bei Hochrisikomandanten häufiger) gehören zum Pflichtprogramm.
• Abweichungen zum Transparenzregister. Wenn du das Transparenzregister parallel selbst abrufst, wirst du gelegentlich Abweichungen zur API-Antwort sehen. Das ist kein Bug: feature=ubos rechnet aus den eingereichten Gesellschafterlisten, das Transparenzregister enthält dagegen Selbstauskünfte – auch unbelegte oder veraltete. In den meisten Fällen ist die Gesellschafterlisten-basierte Antwort die belastbarere. Dokumentiere die Abweichung trotzdem, vor allem wenn das Transparenzregister einen UBO benennt, der aus den Anteilen nicht hervorgeht – das kann ein Hinweis auf eine Stimmbindung oder Treuhand sein und sollte einen Eskalations-Schritt auslösen.

Bonus: Mit shareholdings die umgekehrte Perspektive

Im selben April-Release ist ein Schwester-Feature dazugekommen, das in jedem ernsthaften KYC-Setup nützlich wird: shareholdings. Statt zu fragen „wer hält dieses Unternehmen?" fragst du „woran ist diese Person oder Firma beteiligt?". Das ist die umgekehrte Sicht der Gesellschafterliste: nicht wem gehört X, sondern was hält Y.

Praktisch hilft das in zwei Szenarien: Bei der Personen-Risikoprüfung erkennst du sofort, welche weiteren Firmen ein potenzieller Geschäftspartner kontrolliert – inklusive möglicher Risikoflaggen (Insolvenz, Branche, Sanktionen). Und bei der Konzern-Aufklärung kannst du eine Holding einmal abfragen und alle Tochtergesellschaften strukturiert auf den Tisch bekommen, ohne dich durch jede Gesellschafterliste der Töchter zu hangeln.

shareholdings kostet 5 Credits, ist ebenfalls Beta, und funktioniert sowohl auf /fetch-organization als auch auf dem neuen Endpoint /fetch-person.

Zusammenfassung: Das nimmst du mit

UBO-Ermittlung ist kein Kosmetik-Schritt im Onboarding, sondern eine harte regulatorische Pflicht – mit der 25%-Schwelle, dem fiktiven Auffangtatbestand und der Anforderung, dass deine Akte einem Audit standhält. Manuell skaliert das ab einer Handvoll Cases pro Woche nicht mehr.

Mit feature=ubos von handelsregister.ai bekommst du in einem API-Aufruf: aufgelöste Eigentümer mit durchgerechneter Quote und automatischer 25%-Markierung, transparente Coverage-Anzeige als Risikosignal, Fair-Use-Abrechnung (nur Credits bei Datenlieferung), und mit shareholdings die umgekehrte Sicht aus Personen- oder Firmenperspektive.

Probiere feature=ubos zuerst gegen drei bis fünf Bestandskunden, vergleiche mit deiner UBO-Akte und sieh dir die Coverage-Werte an. Genau dort zeigen sich die Lücken deiner bisherigen Prozesse.