KYB-Antwortschema: Referenz des Decision-Payloads

Diese Seite dokumentiert die vollständige Payload, die GET /v3/session/{id}/decision/ für eine Sitzung zur Unternehmensverifizierung (KYB) zurückgibt. Der Endpoint ist einheitlich: Wenn Sie eine session_id eines Unternehmens übergeben, enthält die Antwort session_kind: "business" sowie die unternehmensspezifischen Funktionsarrays unten.

Aufbau auf oberster Ebene

{
  "session_id": "bs_01H...",
  "session_kind": "business",
  "session_number": 89,
  "session_url": "https://verify.didit.me/...",
  "status": "Approved",
  "status_override": null,
  "workflow_id": "wf_kyb_standard",
  "features": ["KYB_REGISTRY", "AML", "KYB_DOCUMENTS", "KYB_KEY_PEOPLE"],
  "vendor_data": "biz-acme-001",
  "metadata": { },
  "callback": null,

  "registry_checks": [ ... ],
  "aml_screenings": [ ... ],
  "document_verifications": [ ... ],
  "key_people_checks": [ ... ],

  "phone_verifications": null,
  "email_verifications": null,
  "questionnaire_responses": null,
  "ip_analyses": null,

  "reviews": [ ],
  "decision_trace": { ... },
  "linked_records": null,
  "contact_details": { ... },
  "expected_details": null,
  "created_at": "...",
  "expires_at": "..."
}

Alle Funktionsarrays sind Mehrfachinstanzen: Jedes Element steht für einen Knoten in einem Graph-Workflow. Null bedeutet, dass die Funktion im Workflow dieser Sitzung nicht vorhanden war.

Gemeinsame Felder auf oberster Ebene

Feld	Typ	Beschreibung
`session_id`	UUID	Eindeutige Sitzungskennung
`session_kind`	Enum	Immer `"business"` für KYB-Sitzungen
`session_number`	int	Fortlaufende Nummer innerhalb des Antrags
`session_url`	URL	Link zur gehosteten Verifizierungsseite
`status`	Enum	Gesamtstatus der Sitzung (siehe Status)
`status_override`	Objekt oder null	`{ overridden_at, automatic_status }`, wenn ein Prüfer `status` manuell entgegen dem Status gesetzt hat, den die Plattform gesetzt hätte (zum Beispiel ein Unternehmen genehmigt, während eine verknüpfte Verifizierung der Schlüsselpersonen abgelehnt wurde). `null`, wenn der Status automatisch festgelegt wurde. Verwenden Sie dieses Feld, um eine manuelle Genehmigung von einer automatisch erteilten zu unterscheiden
`decision_trace`	Objekt	Wie die Entscheidung zustande kam: `status`, `decided_by` (`manual`, `automatic` oder `investigator`), `decided_at`, `automatic_status`, `terminal_node_id`, `actor`, `warning_counts` und `status_warnings` (die Warnungen, die den Status gesetzt haben)
`linked_records`	Objekt oder null	Zusammenfassung anderer Datensätze, die mit der Sitzung verknüpft sind. `null`, wenn es nichts anzuzeigen gibt
`workflow_id`	UUID	Workflow, der diese Sitzung gesteuert hat
`features`	Array aus Strings	Funktionskennungen, die der Workflow ausgeführt hat (z. B. `KYB_REGISTRY`, `AML`, `KYB_DOCUMENTS`, `KYB_KEY_PEOPLE`, `PHONE`, `EMAIL`)
`vendor_data`	string	Ihre Kennung für das Unternehmen
`metadata`	Objekt	Frei definiertes JSON, das Sie bei der Erstellung der Sitzung angehängt haben
`callback`	URL oder null	Optionale Weiterleitungs-URL nach der Verifizierung
`contact_details`	Objekt oder null	`{ email, email_lang, send_notification_emails, phone }`. Wird gesetzt, wenn der Ablauf E-Mail- oder Telefonbenachrichtigungen umfasst
`expected_details`	Objekt oder null	Erwartete Unternehmensdaten, die Sie bei der Erstellung übergeben haben: `company_name`, `registry_country` (`XX` oder `XX-YY` mit dem Bundesstaat bei Registern auf Bundesstaatsebene, z. B. `US-CA`), `registration_number`
`reviews`	Array	Neueste Prüfernotizen zur Sitzung
`created_at`, `expires_at`	ISO-Zeitstempel	–

`registry_checks[]`

Jedes Element ist eine Unternehmensregisterprüfung (in der Regel eine pro Sitzung; in Graph-Workflows mit rekursivem Unternehmens-UBO-KYB können es mehrere sein).

{
  "status": "Approved",
  "node_id": "feature_kyb_registry",
  "data_resolved": true,
  "company": { ...see below... },
  "ownership_structure": { },
  "warnings": []
}

Feld	Beschreibung
`status`	Lebenszyklusstatus der Funktion (`Approved`, `Declined`, `In Review`, `Not Finished`, `Resub Requested`)
`node_id`	Knotenkennung im Graphen für diese Prüfung
`data_resolved`	`true`, wenn die Registerdaten vollständig geladen wurden oder der Benutzer die Daten manuell eingegeben hat
`company`	Vollständige Register-Payload: siehe Block `company` unten
`ownership_structure`	Die Anteilsstruktur, die das Register bei Bereitstellung der Eigentümerstufe bestätigt hat: `shareholders[]` und `beneficial_owners[]`, jeweils mit derselben Registeridentität und Beteiligung wie `company.beneficial_owners[]` (`name`, `entity_type`, `roles`, `ownership_min_shares` / `ownership_max_shares`, …) sowie deren kanonische `shareholding`. `null`, wenn das Register keine Eigentumsverhältnisse bestätigt hat. Für den aktuellen Datensatz lesen Sie `company.beneficial_owners` und `company.ownership`.
`warnings`	Strukturierte Warnungen bzw. Protokolleinträge für diese Registerprüfung. Siehe Warnungen zur Unternehmensverifizierung.

Block `company`

Das verschachtelte Unternehmensobjekt ist die vollständige Ansicht der juristischen Person, wie sie aus dem Register abgeleitet wird (und optional vom Benutzer bearbeitet wurde):

{
  "uuid": "...",
  "node_id": "feature_kyb_registry",
  "status": "Approved",
  "registry_status": "active",
  "data_resolved": true,
  "company_name": "Acme Corporation Limited",
  "registration_number": "12345678",
  "country_code": "GBR",
  "company_type": "Private Limited",
  "incorporation_date": "2010-05-14",
  "registered_address": "1 Main Street, London EC1A 1AA, United Kingdom",
  "tax_number": "SAMPLE-TAX-12345",
  "risk_level": null,
  "verification_status": "verified",
  "is_from_registry": true,
  "fetch_status": "resolved",
  "alternative_names": "Acme Ltd",
  "nature_of_business": "Software publishing",
  "registered_capital": "100000 GBP",
  "website": "https://acme.example",
  "email": "alex.sample@example.com",
  "phone": "+15550101000",
  "legal_entity_identifier": "529900XXXXXXXXXXXXX",
  "location_of_registration": "London",
  "vat_number": "GB980780684",
  "vat_validation_status": "format_valid",
  "vat_validated_number": "GB980780684",
  "vat_validation_source": "format_rules",
  "vat_validated_name": null,
  "vat_validated_address": null,
  "vat_checked_at": "2026-04-16T10:10:00Z",
  "financial_summary": { },
  "officers": [ ... ],
  "beneficial_owners": [ ... ],
  "addresses": [
    {
      "type": "registered",
      "address": "1 Main Street, London EC1A 1AA, United Kingdom",
      "street": "1 Main Street",
      "city": "London",
      "postal_code": "EC1A 1AA",
      "region": null,
      "country_code": "GB",
      "description": null
    }
  ],
  "industries": [
    { "code": "58290", "description": "Other software publishing", "scheme": "UK SIC 2007", "is_primary": true }
  ],
  "accounts": { ... },
  "ownership": {
    "status": "delivered",
    "tier_requested": "ubo",
    "tier_delivered": "ubo",
    "unavailable_reason": null,
    "direct_ownership_complete": true,
    "unresolved": []
  },
  "registry_tier": "ubo",
  "registry_tier_delivered": "ubo",
  "registry_ownership_status": "delivered",
  "registry_monitoring": null,
  "registry_data": { },
  "user_provided_data": { },
  "confirmed_by_user_at": "2026-04-16T10:10:00Z",
  "last_console_edit_at": null,
  "is_editable": false
}

Feld	Beschreibung
`registry_status`	Vom Anbieter gemeldeter Status (`active`, `dissolved`, `struck_off`, `inactive` usw.). Siehe Status
`is_from_registry`	`true`, wenn die Daten aus einem amtlichen Register stammen; `false` bei manueller Eingabe
`fetch_status`	`pending`, `resolved` oder `failed`: Status der Registerabfrage
`verification_status`	`verified`, `failed` oder `unknown`
`risk_level`	Optionaler Wert, der unverändert aus der Registerquelle übernommen wird. Meist `null`: Didit berechnet keine Risikostufe. Verwenden Sie daher `warnings[]` und den Sitzungsstatus (`status`), um eine Entscheidung zu treffen.
`registry_monitoring`	Die neueste Registerüberwachung für das Unternehmen, oder `null`, wenn keine existiert. Wird erst befüllt, sobald die Registerüberwachung verfügbar ist. Felder: `uuid`, `status`, `unavailable_reason`, `enrolled_at`, `cancelled_at`, `last_bill_date`, `next_bill_date`, `last_event_at`, `events_count`, `watched_fields`
`is_editable`	`true`, solange der Endbenutzer die aus dem Register stammenden Daten noch bearbeiten kann
`registry_data`	Die normalisierten Registerdetails von Didit: das Ergebnis der Eigentümerstruktur (`ownership_error`, `section_errors`, `ubo_resolution`), Korrekturen über update-data und Registerangaben ohne eigenes Feld. Es enthält nie den eigenen Datensatz der Registerquelle. Die Schlüssel variieren je nach Unternehmen, und das Objekt stellt keinen stabilen Vertrag dar. Verwenden Sie stattdessen die kanonischen Felder.
`user_provided_data`	Die Felder, die der Endbenutzer eingegeben oder bearbeitet hat (nützlich für den Audit-Abgleich mit den Registerwerten)
`confirmed_by_user_at`	Zeitstempel, zu dem der Endbenutzer die Registerdaten bestätigt oder bearbeitet hat
`vat_number`	Übermittelte VAT-Nummer, sofern erfasst
`vat_validation_status`	Ergebnis der Validierung der VAT-Nummer oder, falls keine vorliegt, der `tax_number`: `valid`, `invalid`, `format_valid`, `invalid_format`, `could_not_validate` oder `not_applicable`. Siehe VAT- und Steuernummernvalidierung
`vat_validated_number` / `vat_validation_source`	Die geprüfte Nummer, so wie die Quelle sie kennt, und die Quelle, die den Status festgelegt hat (ein amtliches Register oder `format_rules`)
`vat_validated_name` / `vat_validated_address`	Bei der Quelle registrierter Name und Adresse, sofern die Quelle sie offenlegt
`vat_checked_at`	Zeitstempel der Prüfung; `null`, wenn keine Prüfung stattfand
`officers[]`	Organmitglieder mit eingebetteter KYC-Anreicherung (siehe unten)
`beneficial_owners[]`	UBOs mit eingebetteter KYC-Anreicherung (siehe unten)
`addresses[]`	Jede Adresse, die das Register angibt, im kanonischen Adressformat unten. `null`, wenn keine angegeben ist.
`industries[]`	Die Tätigkeiten, unter denen das Register das Unternehmen einordnet, im kanonischen Branchenformat unten. `null`, wenn keine angegeben ist.
`accounts`	Termine von Unternehmensmeldungen, sofern gemeldet: `last_annual_return_date` und `last_agm_date`. Sie beschreiben Meldungen und Versammlungen, nicht Jahresabschlüsse.
`ownership`	Ergebnis der Gesellschafter- / UBO-Stufe im kanonischen Format unten
`registry_tier` / `registry_tier_delivered` / `registry_ownership_status`	Die bestellte Stufe, die gelieferte (und abgerechnete) Stufe und das Ergebnis der Eigentümerstruktur. Dieselben Werte stehen in `ownership`.

Ein Format für alle Länder und Registerquellen

Didit liest Unternehmensregister in vielen Ländern über mehrere Registerquellen aus. Jede Quelle veröffentlicht ihr eigenes Layout, doch der company-Block hat immer dieselbe Struktur: Die folgenden Schlüssel sind stets vorhanden, mit denselben Typen, unabhängig von Land und Quelle des Unternehmens. Eine Angabe, die das Register nicht veröffentlicht, ist null. Eine Unterscheidung nach Land oder das Auswerten von registry_data ist nie nötig. Dieselbe Struktur liefert die Entscheidung, die eigenständigen KYB-Register-Endpoints und der gehostete Verifizierungsablauf. Adresse (jedes Element von addresses)

Feld	Beschreibung
`type`	Kleingeschrieben. `registered` für den eingetragenen Sitz; andere Typen, so wie das Register sie benennt (zum Beispiel `postal`, `office`). `null`, wenn das Register nicht angibt, um welche Adresse es sich handelt
`address`	Die vollständige Adresse in einer Zeile. Immer vorhanden.
`street`, `city`, `postal_code`, `region`	Die Adresse in Teilen, sofern das Register sie veröffentlicht
`country_code`	ISO 3166-1 Alpha-2
`description`	Die eigene Bezeichnung des Registers für die Adresse, sofern es eine angibt

Branche (jedes Element von industries)

Feld	Beschreibung
`code`	Tätigkeitscode, so wie das Register ihn ausweist
`description`	Bezeichnung der Tätigkeit, sofern das Register eine veröffentlicht
`scheme`	Klassifikationssystem, mit einem einheitlichen Namen je System, unabhängig davon, welche Quelle es gemeldet hat (`UK SIC 2007`, `US SIC`, `NACE Rev. 2`, `NACE Rev. 2.1`, `NAF Rev. 2`, `CNAE`, `SBI`, `NOGA 2008`, `CAE Rev. 4`, `Canada SIC 1977`). Andere nationale Systeme behalten den Namen, den das Register ihnen gibt; `null`, wenn das Register keinen Namen nennt.
`is_primary`	`true` für die Haupttätigkeit. Genau ein Eintrag ist als primär markiert

Wenn das Register Tätigkeiten, aber keine Unternehmensbeschreibung angibt, wird nature_of_business aus den Tätigkeitsbezeichnungen befüllt. Kontaktdaten und alternative Namen werden befüllt, sofern verfügbar. Explizite Änderungen durch Benutzer oder Prüfer haben immer Vorrang. Eigentümerstruktur (ownership)

Feld	Beschreibung
`status`	`delivered`; `not_held`, wenn das Register für Eigentümerstrukturen geantwortet hat und das Unternehmen gar nicht aufführt, sodass kein Eigentümerdatensatz vorliegt; `unavailable`, wenn die Daten aus einem anderen Grund nicht bereitgestellt wurden (ein Datensatz ohne Eigentümer, ein nicht zurückgegebener Abschnitt zur Eigentümerstruktur oder ein Anbieter, der nicht angefragt werden konnte); `pending`, solange das Register den Eigentümerabschnitt noch abruft; `not_requested` auf der Basic-Stufe
`tier_requested` / `tier_delivered`	`basic`, `shareholders` oder `ubo`. Eine UBO-Anfrage, die nur mit direkten Gesellschaftern beantwortet wird, gilt als `shareholders` bereitgestellt und wird auch so abgerechnet
`unavailable_reason`	Grund, warum eine angeforderte Eigentümerstufe nicht bereitgestellt wurde: `no_owners_on_record`, `no_natural_person_owner`, `ownership_section_unavailable`, `company_not_found`, `ambiguous_company_match`, `missing_registration_number`, `entity_type_not_covered`, `provider_unavailable` oder `other`. `null`, wenn die Eigentümerstruktur bereitgestellt wurde
`direct_ownership_complete`	`true`, wenn sich die angegebenen Anteile der direkten Gesellschafter auf 100 % addieren (mit einer Rundungsabweichung von höchstens einem Prozentpunkt), `false`, wenn nicht, `null`, wenn die Eigentümerstruktur nicht bereitgestellt wurde oder ein Anteil nicht angegeben ist
`unresolved[]`	Teile der Eigentümerkette, die das Register nicht auflösen konnte, als `{ reason, section }` (zum Beispiel `no_group_structure_on_record` für `group_structure`: die direkten Eigentümer sind bekannt, die Konzernstruktur darüber ist im Register nicht verzeichnet)

Registerdetails (registry_data) Didits eigene Details zur Registerprüfung, niemals der Datensatz der Registerquelle. Jeder Schlüssel ist optional und nur dann vorhanden, wenn das Unternehmen dafür einen Wert hat. Neue Schlüssel können hinzukommen: Für alles, was die kanonischen Felder oben abdecken, gilt deren Beschreibung.

Feld	Beschreibung
Registerangaben (`legal_address`, `registered_address`, `registration_date`, `dissolution_date`, `registry_status`, `verification_status`, `company_type` sowie die übrigen Felder, die update-data akzeptiert)	Zeichenketten. Die mit update-data vorgenommenen Korrekturen sowie Angaben des Registers, für die es kein eigenes Feld gibt (`registration_date`, `dissolution_date`)
`ownership_error`	Grund, warum eine angeforderte Eigentümerstufe nicht bereitgestellt wurde, mit denselben Codes wie `ownership.unavailable_reason` (`no_owners_on_record`, `ownership_section_unavailable`, `company_not_found`, `provider_unavailable`, `other`, …)
`section_errors`	Abschnitte, die das Register nicht zurückgegeben hat, nach Abschnitt geordnet (`officers`, `shareholders`, `group_structure`), jeweils `{ status_code }`
`ubo_resolution`	Wie die UBO-Stufe die Kette durchlaufen hat: `parent_chain[]` und `subsidiaries[]` als `{ name, country_code, registration_number }` sowie `unresolved[]` als `{ reason, section }`
`lite_enrichment`	Leere Lite-Felder, die eine andere Registerquelle des Landes befüllt hat: `{ fields[], people_added }`
`registry_metadata`, `registry_sources[]`, `previous_names[]`, `parent_companies[]`, `documents_available`	Nur ältere Registerdatensätze: die eigenen Felder des Registers, die gelesenen amtlichen Register (`{ name, source_type }`, nur amtliche Register werden genannt), frühere Namen, Namen der Muttergesellschaften und die Anzahl der verfügbaren Einreichungen

Aufbau eines Organmitglieds (innerhalb von `company.officers`)

{
  "uuid": "...",
  "name": "Jane Doe",
  "first_name": "Jane",
  "last_name": "Doe",
  "date_of_birth": null,
  "date_of_birth_year": 1983,
  "date_of_birth_month": 2,
  "address": "1 Example Street, London",
  "appointment_date": "2024-07-01",
  "termination_date": null,
  "designation": "Director",
  "role": "director",
  "nationality": "USA",
  "is_active": true,
  "kyc_status": "Approved",
  "kyc_session_url": "https://verify.didit.me/..."
}

date_of_birth wird nur befüllt, wenn das Register ein vollständiges Datum liefert. Wenn das Register nur ein Jahr oder Monat und Jahr angibt, werden date_of_birth_year und date_of_birth_month verwendet; der fehlende Tag wird niemals ergänzt. Namen, Geburtsangaben, Adresse und Bestellungsdaten bleiben sowohl in der Liste der Organmitglieder des Unternehmens als auch in der Registerliste der Schlüsselpersonen verfügbar.

Aufbau eines wirtschaftlich Berechtigten (innerhalb von `company.beneficial_owners`)

{
  "uuid": "...",
  "name": "John Doe",
  "first_name": "John",
  "last_name": "Doe",
  "entity_type": "person",
  "date_of_birth": null,
  "country_of_birth": null,
  "email": null,
  "company_name": null,
  "registration_number": null,
  "nationality": null,
  "designation": null,
  "appointment_date": null,
  "voting_min_shares": null,
  "voting_max_shares": null,
  "roles": ["ubo"],
  "ownership_min_shares": "40",
  "ownership_max_shares": "40",
  "is_active": true,
  "kyc_status": "Pending",
  "kyc_session_url": "https://verify.didit.me/...",
  "effective_ownership_percent": 40.0,
  "shareholding": {
    "share_class": "Ordinary",
    "number_of_shares": 40,
    "currency": "GBP",
    "nominal_value": 1,
    "total_value": null,
    "percentage": 40
  }
}

kyc_status verwendet eine B2C-taugliche Darstellung: Approved, Declined oder Pending (Alle Sitzungsstatus werden bis zum Abschluss des KYC auf Pending reduziert). shareholding gibt an, was der Eigentümer hält, und hat für jedes Land und jede Registerquelle dieselbe Struktur: share_class, number_of_shares, currency, nominal_value, total_value und percentage (der exakte Anteil, auf vier Dezimalstellen gerundet). Es ist null, wenn das Register keine Beteiligung angibt. Eine Spanne, etwa die 25-50 % eines britischen PSC, ist kein Anteil: percentage ist null, und die Spanne bleibt in ownership_min_shares / ownership_max_shares erhalten. Gesellschafter und UBOs stehen beide in beneficial_owners; roles unterscheidet sie.

`key_people_checks[]`

Dies ist die Sammelprüfung über alle Organmitglieder und wirtschaftlich Berechtigten der Sitzung. Sie stellt zwei Gruppen bereit, damit die Konsole „aus dem Register extrahiert“ und „vom Unternehmen eingereicht“ nebeneinander darstellen kann, dazu eine übergeordnete KYC-Zusammenfassung für die wirtschaftlich Berechtigten (UBOs).

{
  "status": "Approved",
  "node_id": "feature_kyb_key_people",
  "registry": {
    "officers": [ ...registry-derived officers... ],
    "beneficial_owners": [ ...registry-derived UBOs... ]
  },
  "submitted": {
    "parties": [ ...user-submitted key-people records... ]
  },
  "ubo_kyc_summary": {
    "total": 2,
    "approved": 1,
    "flagged": 0,
    "pending": 1
  },
  "warnings": []
}

registry.officers / registry.beneficial_owners: Beteiligte, die aus der Registerprüfung extrahiert wurden.
submitted.parties: Beteiligte, die der Unternehmensadministrator im Schlüsselpersonen-Ablauf ausdrücklich hinzugefügt hat (Datensätze mit source = "USER").

`registry.officers[]` / `registry.beneficial_owners[]`

Die Registerdaten entsprechen company.officers / company.beneficial_owners oben. Die Key-People-Prüfung enthält zusätzlich den AML-Status und detaillierte Verknüpfungen zur Verifizierung, etwa kyc_session_id und Felder des Verifizierungs-Workflows. Die Unternehmenslisten behalten ihren bisherigen vereinfachten KYC-Status und ihre Verifizierungs-URL.

`submitted.parties[]`

Von Benutzern eingereichte Beteiligte enthalten ihre Verknüpfung zu KYC oder untergeordnetem KYB:

{
  "uuid": "...",
  "entity_type": "person",
  "name": "Alice Chen",
  "first_name": "John",
  "last_name": "Doe",
  "email": "alex.sample@example.com",
  "role": "ubo",
  "ownership_percent": 35.0,
  "nationality": "USA",
  "position": "CEO",
  "date_of_birth": "1990-01-01",
  "phone_number": "+34612345678",
  "source": "USER",
  "requires_verification": true,
  "is_skipped": false,
  "kyc_session_id": "sess-xyz...",
  "kyc_session_status": "Not Started",
  "kyc_session_url": "https://verify.didit.me/...",
  "kyc_session_deleted": false,
  "custom_fields": { }
}

Beteiligte des Typs Unternehmen (entity_type: "company") enthalten zusätzlich company_name, registration_number sowie kyb_sub_session_id, kyb_sub_session_status und kyb_sub_session_deleted, wenn verschachteltes KYB für Unternehmen als wirtschaftlich Berechtigte aktiviert ist. kyc_session_deleted (und das entsprechende Unternehmensfeld kyb_sub_session_deleted) ist true, wenn die untergeordnete Sitzung des Beteiligten gelöscht wurde. Eine gelöschte untergeordnete Sitzung behält den Status, den sie zum Zeitpunkt der Löschung hatte, und kann nie abgeschlossen werden. Lesen Sie deshalb dieses Flag statt des Status: Die zugehörige *_session_url wird als null zurückgegeben, weil der Link nicht mehr aufgelöst werden kann, und die Schlüsselpersonen-Prüfung wechselt auf In Review, statt endlos zu warten. Das Löschen einer untergeordneten Sitzung zählt nie als bestanden. Nehmen Sie den Beteiligten mit PATCH /v3/session/{id}/kyb/parties/{party_uuid}/ von der Prüfung aus, damit das KYB abgeschlossen werden kann.

`ubo_kyc_summary`

Aggregierter KYC-Fortschritt der wirtschaftlich Berechtigten, nützlich für eine einzelne Dashboard-Karte:

Feld	Bedeutung
`total`	Anzahl aktiver UBOs mit verknüpfter KYC-Sitzung
`approved`	UBOs, deren KYC-Sitzung `Approved` ist
`flagged`	UBOs, deren KYC-Sitzung `Declined` oder `In Review` ist
`pending`	Alle übrigen (deren KYC noch nicht abgeschlossen ist)

Gibt null zurück, wenn keine UBOs verknüpfte KYC-Sitzungen haben.

`document_verifications[]`

Dokumente, nach Knoten gruppiert:

{
  "status": "Approved",
  "node_id": "feature_kyb_documents",
  "items": [
    {
      "uuid": "...",
      "document_type": "LEGAL_PRESENCE",
      "document_subtype": "CERTIFICATE_OF_INCORPORATION",
      "document_group": "LEGAL_PRESENCE",
      "status": "Approved",
      "file_url": "https://didit-storage.s3...",
      "document_metadata": {
        "file_size": 246810,
        "content_type": "application/pdf",
        "creation_date": "2024-05-15",
        "modified_date": "2024-05-15",
        "overlay_manipulation": null
      },
      "ocr_data": {
        "company_name": "Acme Corporation Limited",
        "registration_number": "12345678",
        "incorporation_date": "2010-05-14"
      }
    }
  ],
  "groups": {
    "LEGAL_PRESENCE": { "total": 1, "approved": 1, "pending": 0, "declined": 0, "in_review": 0, "other": 0, "missing": 0 },
    "OWNERSHIP_STRUCTURE": { "total": 1, "approved": 1, "pending": 0, "declined": 0, "in_review": 0, "other": 0, "missing": 0 }
  },
  "required_groups": ["LEGAL_PRESENCE", "OWNERSHIP_STRUCTURE"],
  "warnings": []
}

Feld	Beschreibung
`items[]`	Einzelne Dokumentzeilen: Jede hat ihren eigenen `status`, `document_type` und `document_group` (die Gruppe), `document_subtype`, `file_url` (signiert), `document_metadata` und einen OCR-Auszug
`groups`	Fortschrittszähler je Gruppe, geschlüsselt nach dem Gruppenwert (`LEGAL_PRESENCE`, `COMPANY_DETAILS`, `OWNERSHIP_STRUCTURE`, `REPRESENTATIVES_AUTHORIZATION`, zuzüglich `OTHER` für nicht klassifizierte Dokumente). Jede Gruppe enthält `total`, `approved`, `pending`, `declined`, `in_review`, `other` und `missing`. Siehe die KYB-Dokumentgruppen
`required_groups`	Gruppen, die Ihr Workflow als erforderlich markiert hat; machen Sie die Freigabe der Sitzung davon abhängig, dass alle erfüllt sind

Metadaten von Unternehmensdokumenten

Für Unternehmensdokumente im PDF-Format kann items[].document_metadata.overlay_manipulation forensische Nachweise für vermutete Bearbeitung von Overlay-Text enthalten. Wenn vorhanden, umfasst es Folgendes:

Feld	Beschreibung
`analysis_incomplete`	Nur vorhanden und `true`, wenn die Datei nicht vollständig geprüft werden konnte. Was geprüft wurde, behält seine Ergebnisse, soweit möglich, und das Dokument löst `KYB_DOCUMENT_UNPROVEN_TEXT_REPLACEMENT` aus.
`detected`	Ob Nachweise für Manipulation von Overlay-Text erkannt wurden
`analyzed`	Ob das PDF analysiert werden konnte
`signals`	Ausgelöste forensische Signale, etwa `duplicate_font_subset` oder `glyph_fragmentation`
`manipulated_regions`	Rechtecke in den Seitenkoordinaten des PDFs um vermutlich bearbeiteten Text: `page`, `x`, `y`, `width`, `height`, `page_width`, `page_height`

Das Feld ist null, wenn keine Nachweise für Overlay-Manipulation gefunden wurden, wenn das Dokument kein PDF ist oder wenn das PDF nicht analysiert werden konnte.

`aml_screenings[]`

AML-Screenings auf Unternehmensebene und (wenn der Workflow sie einbindet) auf Personenebene.

{
  "node_id": "feature_aml",
  "status": "Approved",
  "total_hits": 0,
  "score": 0,
  "entity_type": "COMPANY",
  "screened_data": {
    "company_name": "Acme Corporation Limited",
    "country_code": "GBR"
  },
  "is_ongoing_monitoring_enabled": true,
  "next_ongoing_monitoring_bill_date": "2027-04-16",
  "last_ongoing_screening_at": "2026-09-12T04:03:11Z",
  "last_ongoing_screening_datasets_updated_at": null,
  "hits": [],
  "warnings": []
}

Wenn total_hits > 0 ist, enthält jeder Treffer Übereinstimmungswert, Risiko-Score, Quellen der Beobachtungslisten und einen für jeden Treffer geltenden review_status, den Sie über den Endpoint zum Aktualisieren des AML-Trefferstatus ändern können. Die Struktur eines Treffers finden Sie im AML-Screening-Bericht.

Gemeinsame Funktionsarrays

phone_verifications, email_verifications, questionnaire_responses und ip_analyses verwenden dieselben Elementstrukturen wie Nutzersitzungen (KYC). Sie sind null, wenn der Workflow sie nicht enthält. Die Schemas der Elemente finden Sie in der KYC-Antwort. signatures ist vorhanden, wenn der Workflow einen Schritt E-Signatur enthält. Eine Unternehmenssitzung hat ein Element pro Schlüsselperson, die für das Unternehmen unterschreibt, mit signer.capacity: "company", dem Firmennamen und den Rollen der Schlüsselperson. Siehe den E-Signatur-Bericht.

Warnungsgruppen nach Funktion

Warnungen der Unternehmensverifizierung (KYB) sind nach der Funktion gruppiert, die sie ausgelöst hat:

KYB_REGISTRY für Verfügbarkeit des Registers, Eigentümerstruktur, Unternehmensaktivität und Probleme mit Ländereinschränkungen.
KYB_DOCUMENTS für Extraktion, Querprüfung, Metadaten, Manipulation, Untertyp und Alter von Unternehmensdokumenten sowie für Probleme mit dem Versuchslimit.
AML für Treffer im AML-Screening des Unternehmens oder fehlende Screening-Daten.
KYB_KEY_PEOPLE für Probleme auf Personenebene, die Geschäftsführer, Organmitglieder, UBOs oder Vertreter betreffen.
PHONE für Risiko, Doppelung, Sperrliste und Probleme bei Versuchen mit dem Verifizierungscode bei Telefonnummern.
EMAIL für Risiko, Zustellbarkeit, Doppelung, Sperrliste und Probleme bei Versuchen mit dem Verifizierungscode bei E-Mail-Adressen.
QUESTIONNAIRE für benutzerdefinierte Statusregeln, die auf Fragebogenantworten basieren.
LOCATION für die Geräte- und IP-Analyse, private Netzwerke, IP-Sperrlisten, Gerätesperrlisten sowie doppelte Geräte oder IP-Adressen.
SIGNATURE für abgelehnte E-Signaturen, fehlgeschlagene Code-Bestätigungen, abweichende Namen der Unterzeichner, nicht verifizierte Unterzeichner, geänderte Dokumente und fehlende Felddaten. Siehe E-Signatur-Warnungen.

Die vollständige Liste der Warncodes finden Sie unter Warnungen der Unternehmensverifizierung (KYB).

Workflow-gesteuerte Feldfilterung

Workflows können über response_attributes einschränken, welche verschachtelten Felder in jedem Funktionselement erscheinen. Die Felder status, warnings und node_id sind immer enthalten. Alle übrigen Felder, die nicht in der Zulassungsliste stehen, werden auf null gesetzt; der Schlüssel bleibt in der Antwort erhalten, damit das Schema stabil bleibt.

Nächste Schritte

Status

Was die einzelnen Statuswerte bedeuten.

Risikobewertung

Was ein KYB-Ergebnis bestimmt.

AML-Bericht

Referenz zum vollständigen AML-Treffer-Payload.

Schlüsselpersonen

Wie Parteien aus dem Register bzw. aus der Benutzereingabe in die Bereiche registry und submitted einfließen.

Dokumente

Dokumentgruppen, OCR und Querverweise.

Sitzung abrufen

Vollständige Endpoint-Referenz einschließlich Beispielantworten.

Erste Schritte

Funktionen

Unternehmensprofile

Referenz

Konsole

KYB-Antwortschema: Referenz des Decision-Payloads

Aufbau auf oberster Ebene

Gemeinsame Felder auf oberster Ebene

`registry_checks[]`

Block `company`

Ein Format für alle Länder und Registerquellen

Aufbau eines Organmitglieds (innerhalb von `company.officers`)

Aufbau eines wirtschaftlich Berechtigten (innerhalb von `company.beneficial_owners`)

`key_people_checks[]`

`registry.officers[]` / `registry.beneficial_owners[]`

`submitted.parties[]`

`ubo_kyc_summary`

`document_verifications[]`

Metadaten von Unternehmensdokumenten

`aml_screenings[]`

Gemeinsame Funktionsarrays

Warnungsgruppen nach Funktion

Workflow-gesteuerte Feldfilterung

Nächste Schritte

Status

Risikobewertung

AML-Bericht

Schlüsselpersonen

Dokumente

Sitzung abrufen

​Aufbau auf oberster Ebene

​Gemeinsame Felder auf oberster Ebene

​registry_checks[]

​Block company

​Ein Format für alle Länder und Registerquellen

​Aufbau eines Organmitglieds (innerhalb von company.officers)

​Aufbau eines wirtschaftlich Berechtigten (innerhalb von company.beneficial_owners)

​key_people_checks[]

​registry.officers[] / registry.beneficial_owners[]

​submitted.parties[]

​ubo_kyc_summary

​document_verifications[]

​Metadaten von Unternehmensdokumenten

​aml_screenings[]

​Gemeinsame Funktionsarrays

​Warnungsgruppen nach Funktion

​Workflow-gesteuerte Feldfilterung

​Nächste Schritte

Status

Risikobewertung

AML-Bericht

Schlüsselpersonen

Dokumente

Sitzung abrufen

Aufbau auf oberster Ebene

Gemeinsame Felder auf oberster Ebene

`registry_checks[]`

Block `company`

Ein Format für alle Länder und Registerquellen

Aufbau eines Organmitglieds (innerhalb von `company.officers`)

Aufbau eines wirtschaftlich Berechtigten (innerhalb von `company.beneficial_owners`)

`key_people_checks[]`

`registry.officers[]` / `registry.beneficial_owners[]`

`submitted.parties[]`

`ubo_kyc_summary`

`document_verifications[]`

Metadaten von Unternehmensdokumenten

`aml_screenings[]`

Gemeinsame Funktionsarrays

Warnungsgruppen nach Funktion

Workflow-gesteuerte Feldfilterung

Nächste Schritte