US-Unternehmensverifizierung per API: Technischer Leitfaden für Entwickler

Wer als deutsches oder europäisches Unternehmen Geschäftsbeziehungen mit US-amerikanischen Partnern unterhält, steht vor einer regulatorischen Herausforderung: Die Pflicht zur Unternehmensverifizierung (Know Your Business, KYB) endet nicht an der EU-Grenze. Ob Fintech, Bank, Versicherung oder B2B-SaaS-Anbieter – die Identifizierung und Überprüfung von US-Geschäftspartnern ist eine gesetzliche Pflicht nach deutschem Geldwäschegesetz (GwG) und der EU-Geldwäscherichtlinie (AMLD6). Dieser Leitfaden zeigt, wie Entwickler eine Unternehmensverifizierung API technisch einbinden, um US-Unternehmensdaten direkt aus den offiziellen Secretary-of-State-Registern abzufragen – sicher, skalierbar und DSGVO-konform.

Warum US-Unternehmensverifizierung für deutsche Entwickler relevant ist

Die sechste EU-Geldwäscherichtlinie (AMLD6) verpflichtet Institute und Verpflichtete im Sinne des GwG dazu, auch Drittstaaten-Counterparts vollständig zu identifizieren. Paragraph 10 GwG schreibt vor, dass bei Geschäftsbeziehungen mit juristischen Personen deren Existenz, Rechtsform, Vertretungsbefugnis und wirtschaftlich Berechtigte zu überprüfen sind – und das gilt ausdrücklich auch für US-amerikanische LLC, Inc. oder Corporation.

Bislang war dieser Prozess mühsam: Compliance-Teams suchten manuell auf einzelnen Websites der 50 US-Bundesstaaten, kopierten PDF-Ausdrucke und archivierten Screenshots. Das ist nicht nur fehleranfällig, sondern auch nicht skalierbar. Eine Unternehmensverifizierung API automatisiert diesen Schritt vollständig und liefert maschinenlesbare Daten in Echtzeit.

Das US Secretary-of-State-System im Vergleich zum Handelsregister

Deutsche Entwickler kennen das Handelsregister als zentrale, bundesweit einheitliche Quelle. In den USA existiert kein vergleichbares Zentralregister – stattdessen führt jeder der 50 Bundesstaaten sowie Washington D.C., Puerto Rico und die U.S. Virgin Islands ein eigenes Secretary-of-State-Register. Das macht manuelle Recherchen extrem aufwendig.

OpenSOSData: Die API für US-Unternehmensverifizierung

OpenSOSData bietet eine REST-API, die Entwicklern direkten Zugang zu offiziellen Secretary-of-State-Daten aus allen 50 US-Bundesstaaten sowie D.C., Puerto Rico und den U.S. Virgin Islands ermöglicht. Die API liefert strukturierte JSON-Antworten mit Entitätsname, Rechtsform, Registrierungs-ID, Status, Gründungsdatum sowie Registered Agent und Adresse.

Die Preisstruktur ist Pay-as-you-go und für unterschiedliche Nutzungsintensitäten ausgelegt:

• Live-Abfrage: $0,10 pro Abfrage (ca. 0,09 €), bei hohem Volumen ab $0,0314
• Cached-Abfrage: $0,01 pro Abfrage (ca. 0,009 €), bei hohem Volumen ab $0,00314

Für Compliance-Workflows, bei denen Aktualität entscheidend ist (z. B. Onboarding eines neuen Geschäftspartners), empfiehlt sich die Live-Abfrage. Für Monitoring-Szenarien oder Massenüberprüfungen im Batch-Betrieb ist der Cache-Modus kosteneffizient.

Technische Integration: API-Endpunkt und Parameter

Die API wird per HTTP POST an folgenden Endpunkt aufgerufen:

POST https://api.opensosdata.com/v1/lookup

Der zentrale Parameter zur Steuerung der Datenbeschaffung ist cache_preference mit den möglichen Werten:

• live_only – Immer direkt aus dem offiziellen Register abfragen
• cache_first – Cache bevorzugen, bei Fehlen Live-Abfrage
• cache_only – Ausschließlich gecachte Daten verwenden

Die vollständige Dokumentation ist unter opensosdata.com/docs verfügbar.

Praktisches Code-Beispiel: Python-Integration

Das folgende Beispiel zeigt eine vollständige Implementierung in Python, wie sie in einem typischen KYB-Onboarding-Workflow eingesetzt werden kann:

import requests
import json

# API-Schlüssel aus Umgebungsvariable laden (sicherheitskritisch!)
import os
API_KEY = os.environ.get("OPENSOSDATA_API_KEY")

# Endpunkt der OpenSOSData API
ENDPOINT = "https://api.opensosdata.com/v1/lookup"

def verifiziere_us_unternehmen(unternehmensname: str, bundesstaat: str) -> dict:
    """
    Führt eine Live-Abfrage eines US-Unternehmens im Secretary of State durch.
    Gibt strukturierte JSON-Daten zurück oder wirft einen Fehler.
    """
    headers = {
        "x-api-key": API_KEY,
        "Content-Type": "application/json"
    }

    # Anfrage-Payload: Live-Abfrage für maximale Aktualität (AMLD6-konform)
    payload = {
        "entity_name": unternehmensname,
        "state": bundesstaat,          # Zweistelliges Kürzel, z. B. "DE" für Delaware
        "cache_preference": "live_only" # Für KYB-Onboarding immer Live-Daten verwenden
    }

    try:
        response = requests.post(ENDPOINT, headers=headers, json=payload, timeout=15)
        response.raise_for_status()  # HTTP-Fehler als Exception auslösen
        return response.json()
    except requests.exceptions.HTTPError as http_err:
        print(f"HTTP-Fehler bei der API-Abfrage: {http_err}")
        raise
    except requests.exceptions.RequestException as req_err:
        print(f"Netzwerkfehler: {req_err}")
        raise

# Beispielaufruf: Delaware LLC verifizieren
if __name__ == "__main__":
    ergebnis = verifiziere_us_unternehmen(
        unternehmensname="Acme Technologies LLC",
        bundesstaat="DE"  # Delaware – beliebtester Inkorporierungsstandort
    )

    # Relevante KYB-Felder extrahieren und ausgeben
    print("=== KYB-Verifizierungsergebnis ===")
    print(f"Unternehmensname:  {ergebnis.get('entity_name')}")
    print(f"Rechtsform:        {ergebnis.get('entity_type')}")
    print(f"Status:            {ergebnis.get('status')}")
    print(f"Gründungsdatum:    {ergebnis.get('formation_date')}")
    print(f"Registrierungs-ID: {ergebnis.get('entity_id')}")
    print(f"Registered Agent:  {ergebnis.get('registered_agent')}")
    print(f"Agent-Adresse:     {ergebnis.get('registered_agent_address')}")

    # Einfache Statusprüfung für automatisierten Compliance-Workflow
    if ergebnis.get("status", "").upper() == "ACTIVE":
        print("\n✅ Unternehmen ist aktiv – Onboarding kann fortgesetzt werden.")
    else:
        print("\n⚠️  Unternehmen ist NICHT aktiv – manuelle Prüfung erforderlich!")

cURL-Beispiel für schnelle Tests

# Schneller API-Test via cURL (z. B. in der CI/CD-Pipeline oder Bash-Skript)
curl -X POST https://api.opensosdata.com/v1/lookup \
  -H "x-api-key: $OPENSOSDATA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_name": "Acme Technologies LLC",
    "state": "DE",
    "cache_preference": "live_only"
  }'
# Erwartete Rückgabe: JSON mit entity_name, entity_type, status, formation_date,
# entity_id, registered_agent, registered_agent_address

DSGVO-Konformität bei der Verarbeitung von US-Unternehmensdaten

Ein häufig gestellter Frage in deutschen Entwicklerteams: Ist die Abfrage und Speicherung von US-Unternehmensdaten DSGVO-konform? Die kurze Antwort lautet: Ja, unter bestimmten Bedingungen.

Secretary-of-State-Daten sind öffentliche Registerdaten ohne Personenbezug im DSGVO-Sinne, sofern ausschließlich Unternehmens- und Agentendaten (keine natürlichen Personen als Direktoren etc.) verarbeitet werden. Wichtig ist die Rechtsgrundlage für die Verarbeitung: Artikel 6 Abs. 1 lit. c DSGVO (rechtliche Verpflichtung) und lit. f (berechtigtes Interesse) decken KYB-Prozesse ab. Eine Datenschutz-Folgeabschätzung (DPIA) ist bei systematischem Monitoring von Geschäftspartnern empfehlenswert. Für den Datentransfer in die USA gilt: Da lediglich öffentliche Daten abgerufen werden, liegt kein grenzüberschreitender Transfer personenbezogener Daten vor, der SCCs erfordern würde.

Architekturempfehlungen für den Produktiveinsatz

Für eine robuste Integration in Compliance-Systeme empfehlen sich folgende Designentscheidungen:

• Asynchrone Verarbeitung: Batche mehrere Lookups über eine Queue (z. B. Celery, AWS SQS), um API-Timeouts bei synchronen Anfragen zu vermeiden.
• Caching-Strategie: Verwende cache_first für regelmäßige Monitoring-Checks und live_only ausschließlich beim initialen Onboarding.
• Fehlerbehandlung: Implementiere exponentielles Backoff bei HTTP 429 (Rate Limiting) und logge alle API-Antworten für Audit-Zwecke.
• Audit-Trail: Speichere Zeitstempel, Rohantwort und API-Version jeder Abfrage – essenziell für die Nachweispflicht nach GwG § 8.
• Secret Management: API-Schlüssel niemals in Code oder Versionskontrolle speichern – immer über Umgebungsvariablen oder einen Secret Manager (z. B. AWS Secrets Manager, HashiCorp Vault) beziehen.e oder Git – ausschließlich über Umgebungsvariablen oder Secret Manager (HashiCorp Vault, AWS Secrets Manager).

Jetzt starten

Entwickler können sich kostenlos registrieren und sofort mit Testabfragen beginnen: app.opensosdata.com. Die vollständige API-Referenz mit allen Parametern, Fehlercode-Übersichten und Beispiel-Responses ist unter opensosdata.com/docs verfügbar.

Häufig gestellte Fragen (FAQ)