> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# KYB-Antwortschema: Referenz des Decision-Payloads

> Didit KYB-Entscheidungs-Payload: Registerprüfungen, Schlüsselpersonen, UBO-KYC, Dokumente, AML-Screenings. Ab $2.00 pro Prüfung.

Diese Seite dokumentiert die vollständige Payload, die [`GET /v3/session/{id}/decision/`](https://docs.didit.me/de/sessions-api/retrieve-session) 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

```json theme={null}
{
  "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](https://docs.didit.me/de/business-verification/statuses.md)) |
| `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).

```json theme={null}
{
  "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](https://docs.didit.me/de/business-verification/warnings.md). |

### 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):

```json theme={null}
{
  "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](https://docs.didit.me/de/business-verification/statuses.md#registerstatus-vom-anbieter) |
| `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](https://docs.didit.me/de/business-verification/ownership.md#überwachung-von-anteilseignern-und-ubos) 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](https://docs.didit.me/de/sessions-api/update-data.md) 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](https://docs.didit.me/de/business-verification/company-data.md#umsatzsteuer-id--und-steuernummernprüfung) |
| `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](https://docs.didit.me/de/sessions-api/retrieve-session.md), die eigenständigen [KYB-Register-Endpoints](https://docs.didit.me/de/standalone-apis/kyb-registry-ubo.md) 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](https://docs.didit.me/de/sessions-api/update-data.md) 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`)

```json theme={null}
{
  "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`)

```json theme={null}
{
  "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).

```json theme={null}
{
  "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:

```json theme={null}
{
  "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}/`](https://docs.didit.me/de/sessions-api/update-data#eine-partei-der-schlüsselpersonen-überspringen) 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:

```json theme={null}
{
  "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](https://docs.didit.me/de/business-verification/documents.md#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.

```json theme={null}
{
  "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](https://docs.didit.me/de/core-technology/aml-screening/report-aml-screening.md).

## 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](https://docs.didit.me/de/sessions-api/retrieve-session.md).

`signatures` ist vorhanden, wenn der Workflow einen Schritt [E-Signatur](https://docs.didit.me/de/core-technology/electronic-signature/overview.md) 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](https://docs.didit.me/de/core-technology/electronic-signature/report-electronic-signature.md).

## 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](https://docs.didit.me/de/core-technology/electronic-signature/warnings-electronic-signature.md).

Die vollständige Liste der Warncodes finden Sie unter [Warnungen der Unternehmensverifizierung (KYB)](https://docs.didit.me/de/business-verification/warnings.md).

## 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

> [card] [Status](https://docs.didit.me/de/business-verification/statuses.md)
>
> Was die einzelnen Statuswerte bedeuten.

> [card] [Risikobewertung](https://docs.didit.me/de/business-verification/risk-assessment.md)
>
> Was ein KYB-Ergebnis bestimmt.

> [card] [AML-Bericht](https://docs.didit.me/de/core-technology/aml-screening/report-aml-screening.md)
>
> Referenz zum vollständigen AML-Treffer-Payload.

> [card] [Schlüsselpersonen](https://docs.didit.me/de/business-verification/key-people.md)
>
> Wie Parteien aus dem Register bzw. aus der Benutzereingabe in die Bereiche `registry` und `submitted` einfließen.

> [card] [Dokumente](https://docs.didit.me/de/business-verification/documents.md)
>
> Dokumentgruppen, OCR und Querverweise.

> [card] [Sitzung abrufen](https://docs.didit.me/de/sessions-api/retrieve-session.md)
>
> Vollständige Endpoint-Referenz einschließlich Beispielantworten.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.