Schema de resposta KYB: referência do payload de decisão

Esta página documenta o payload completo retornado por GET /v3/session/{id}/decision/ para uma sessão de Verificação de Empresa (KYB). O endpoint é unificado: quando você informa um session_id de empresa, a resposta traz session_kind: "business" e os arrays de recursos específicos de empresas descritos abaixo.

Estrutura de nível superior

{
  "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": "..."
}

Todos os arrays de recursos aceitam múltiplas instâncias: cada item representa um nó em um fluxo de trabalho em grafo. Null significa que o recurso não estava presente no fluxo desta sessão.

Campos compartilhados de nível superior

Campo	Tipo	Descrição
`session_id`	UUID	Identificador único da sessão
`session_kind`	enum	Sempre `"business"` para sessões KYB
`session_number`	int	Número sequencial dentro da aplicação
`session_url`	URL	Link de verificação hospedado
`status`	enum	Status geral da sessão (veja status)
`status_override`	object or null	`{ overridden_at, automatic_status }` quando um revisor definiu `status` manualmente, de forma diferente do que a plataforma teria definido (por exemplo, aprovar uma empresa enquanto uma verificação de pessoa-chave vinculada está recusada). `null` quando o status é o automático. Use-o para distinguir uma aprovação manual de uma automática
`decision_trace`	object	Como a decisão foi tomada: `status`, `decided_by` (`manual`, `automatic` ou `investigator`), `decided_at`, `automatic_status`, `terminal_node_id`, `actor`, `warning_counts` e `status_warnings` (os avisos que definiram o status)
`linked_records`	object or null	Um resumo de outros registros vinculados à sessão. `null` quando não há nada a exibir
`workflow_id`	UUID	Fluxo que conduziu esta sessão
`features`	array of strings	Identificadores dos recursos que o fluxo executou (por exemplo, `KYB_REGISTRY`, `AML`, `KYB_DOCUMENTS`, `KYB_KEY_PEOPLE`, `PHONE`, `EMAIL`)
`vendor_data`	string	Seu identificador da empresa
`metadata`	object	JSON de formato livre que você anexou na criação da sessão
`callback`	URL or null	URL de redirecionamento opcional após a verificação
`contact_details`	object or null	`{ email, email_lang, send_notification_emails, phone }`, definido quando o fluxo inclui notificações por e-mail/telefone
`expected_details`	object or null	Payload de dados esperados da empresa que você informou na criação: `company_name`, `registry_country` (`XX` ou `XX-YY` com o estado para registros de empresas em nível estadual, por exemplo `US-CA`), `registration_number`
`reviews`	array	Notas mais recentes dos revisores sobre a sessão
`created_at`, `expires_at`	ISO timestamps	—

`registry_checks[]`

Cada item é uma verificação de registro de empresas (normalmente uma por sessão; várias em fluxos com grafo que usam KYB recursivo de UBOs corporativos).

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

Campo	Descrição
`status`	Status do ciclo de vida do recurso (`Approved`, `Declined`, `In Review`, `Not Finished`, `Resub Requested`)
`node_id`	Identificador do nó do grafo para esta verificação
`data_resolved`	`true` quando os dados do registro terminaram de carregar ou quando o usuário forneceu os dados manualmente
`company`	Payload completo do registro. Consulte o bloco `company` abaixo
`ownership_structure`	A tabela de capitalização (cap table) que o registro comprovou quando o nível de propriedade foi entregue: `shareholders[]` e `beneficial_owners[]`, cada um com a mesma identidade de registro e participação que em `company.beneficial_owners[]` (`name`, `entity_type`, `roles`, `ownership_min_shares` / `ownership_max_shares`, …) e seu `shareholding` canônico. `null` quando o registro comprovou que não há propriedade. Leia `company.beneficial_owners` e `company.ownership` para obter o registro atual
`warnings`	Avisos estruturados / entradas de log associados a esta verificação de registro. Consulte avisos da Verificação de empresas.

Bloco `company`

O objeto aninhado da empresa é a visão completa da pessoa jurídica conforme obtida do registro (e, opcionalmente, editada pelo usuário):

{
  "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
}

Campo	Descrição
`registry_status`	Status informado pelo provedor (`active`, `dissolved`, `struck_off`, `inactive` etc.). Consulte status
`is_from_registry`	`true` quando os dados vieram de um registro oficial; `false` para inserção manual
`fetch_status`	`pending`, `resolved` ou `failed`: estado da consulta ao registro
`verification_status`	`verified`, `failed` ou `unknown`
`risk_level`	Valor opcional repassado pela fonte do registro. Geralmente é `null`: a Didit não calcula um nível de risco, então use `warnings[]` e o `status` da sessão para decidir
`registry_monitoring`	O monitoramento de registro mais recente da empresa, ou `null` quando não existe nenhum. Preenchido somente quando o monitoramento de registro estiver disponível. Campos: `uuid`, `status`, `unavailable_reason`, `enrolled_at`, `cancelled_at`, `last_bill_date`, `next_bill_date`, `last_event_at`, `events_count`, `watched_fields`
`is_editable`	`true` enquanto os dados obtidos do registro ainda puderem ser editados pelo usuário final
`registry_data`	O detalhamento normalizado do registro feito pela Didit: o resultado de propriedade (`ownership_error`, `section_errors`, `ubo_resolution`), as correções feitas com update-data e os fatos do registro que não têm campo próprio. Nunca contém o registro original da fonte. Suas chaves variam conforme a empresa e não constituem um contrato estável: leia os campos canônicos
`user_provided_data`	Os campos que o usuário final inseriu ou editou (úteis para comparar, em auditoria, com os valores do registro)
`confirmed_by_user_at`	Data e hora em que o usuário final confirmou / editou os dados do registro
`vat_number`	Número de VAT conforme enviado, quando coletado
`vat_validation_status`	Resultado da validação do número de VAT ou, quando não há um, do `tax_number`: `valid`, `invalid`, `format_valid`, `invalid_format`, `could_not_validate` ou `not_applicable`. Consulte Validação de VAT e identificação fiscal
`vat_validated_number` / `vat_validation_source`	O número verificado, como consta na fonte, e a fonte que determinou o status (um registro oficial ou `format_rules`)
`vat_validated_name` / `vat_validated_address`	Nome e endereço registrados na fonte, quando ela os divulga
`vat_checked_at`	Data e hora da verificação; `null` quando nenhuma verificação foi executada
`officers[]`	Administradores com enriquecimento de KYC incorporado (veja abaixo)
`beneficial_owners[]`	UBOs com enriquecimento de KYC incorporado (veja abaixo)
`addresses[]`	Todos os endereços informados pelo registro, no formato canônico de endereço abaixo. `null` quando o registro não informa nenhum
`industries[]`	As atividades sob as quais o registro classifica a empresa, no formato canônico de setor de atuação abaixo. `null` quando o registro não informa nenhuma
`accounts`	Datas dos arquivamentos societários, quando informadas: `last_annual_return_date` e `last_agm_date`. Elas se referem a arquivamentos e assembleias, não a demonstrações financeiras
`ownership`	O resultado do nível de propriedade (Acionistas / UBO), no formato canônico abaixo
`registry_tier` / `registry_tier_delivered` / `registry_ownership_status`	O nível solicitado, o nível entregue (e faturado) e o resultado de propriedade. Os mesmos valores estão em `ownership`

Um formato para todos os países e fontes de registro

A Didit consulta registros de empresas em muitos países por meio de várias fontes de registro. Cada fonte publica seu próprio layout, mas o bloco company tem sempre o mesmo formato: as chaves abaixo estão sempre presentes, com os mesmos tipos, qualquer que seja o país e a fonte de origem da empresa. Um fato que o registro não publica vem como null; você nunca precisa criar ramificações por país nem interpretar registry_data. O mesmo formato é retornado pela decisão, pelos endpoints independentes de registro de KYB e pelo fluxo de verificação hospedado. Endereço (cada item de addresses)

Campo	Descrição
`type`	Em minúsculas. `registered` para a sede registrada; outros tipos conforme o registro os nomeia (por exemplo, `postal`, `office`). `null` quando o registro não indica de que tipo é o endereço
`address`	O endereço completo em uma única linha. Sempre presente
`street`, `city`, `postal_code`, `region`	O endereço dividido em partes, quando o registro as publica
`country_code`	ISO 3166-1 alfa-2
`description`	O rótulo do próprio registro para o endereço, quando houver

Setor de atuação (cada item de industries)

Campo	Descrição
`code`	Código da atividade conforme impresso pelo registro
`description`	Rótulo da atividade, quando o registro publica um
`scheme`	Sistema de classificação, com um único nome por sistema, independentemente da fonte que o informou (`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`). Outros sistemas nacionais mantêm o nome dado pelo próprio registro; `null` quando o registro não o nomeia
`is_primary`	`true` para a atividade principal. Exatamente uma entrada é a principal

Quando o registro informa atividades, mas nenhuma descrição da empresa, nature_of_business é preenchido a partir dos rótulos das atividades. Dados de contato e nomes alternativos são preenchidos quando disponíveis, e edições explícitas do usuário ou do revisor sempre têm precedência. Propriedade (ownership)

Campo	Descrição
`status`	`delivered`; `not_held` quando o registro de propriedade respondeu e não lista esta empresa de forma alguma, portanto não há registro de propriedade a fornecer; `unavailable` quando os dados não foram fornecidos por qualquer outro motivo (um registro que não nomeia nenhum proprietário, uma seção de propriedade não retornada ou um fornecedor que não pôde ser consultado); `pending` enquanto o registro ainda está obtendo a seção de propriedade; `not_requested` no nível Basic
`tier_requested` / `tier_delivered`	`basic`, `shareholders` ou `ubo`. Uma requisição de UBO respondida apenas com acionistas diretos é entregue, e cobrada, como `shareholders`
`unavailable_reason`	Por que um nível de propriedade solicitado não foi entregue: `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` ou `other`. `null` quando a propriedade foi entregue
`direct_ownership_complete`	`true` quando as participações declaradas dos acionistas diretos somam 100% (com margem de um ponto percentual de arredondamento), `false` quando não somam, `null` quando a propriedade não foi entregue ou alguma participação não está declarada
`unresolved[]`	Partes da cadeia de propriedade que o registro não conseguiu resolver, no formato `{ reason, section }` (por exemplo, `no_group_structure_on_record` para `group_structure`: os proprietários diretos são conhecidos, mas o grupo empresarial acima deles não consta no registro)

Detalhes do registro (registry_data) Detalhes próprios da Didit sobre a verificação de registro, nunca o registro da própria fonte. Todas as chaves são opcionais e só aparecem quando a empresa tem um valor para elas, e novas chaves podem ser adicionadas: para tudo o que os campos canônicos acima cobrem, leia esses campos.

Campo	Descrição
Fatos do registro (`legal_address`, `registered_address`, `registration_date`, `dissolution_date`, `registry_status`, `verification_status`, `company_type` e os demais campos que update-data aceita)	Strings. As correções feitas com update-data e os fatos informados pelo registro que não têm campo próprio (`registration_date`, `dissolution_date`)
`ownership_error`	Por que um nível de propriedade solicitado não foi entregue, com os mesmos códigos de `ownership.unavailable_reason` (`no_owners_on_record`, `ownership_section_unavailable`, `company_not_found`, `provider_unavailable`, `other`, …)
`section_errors`	Seções que o registro não retornou, indexadas por seção (`officers`, `shareholders`, `group_structure`), cada uma no formato `{ status_code }`
`ubo_resolution`	Como o nível UBO percorreu a cadeia: `parent_chain[]` e `subsidiaries[]` no formato `{ name, country_code, registration_number }`, e `unresolved[]` no formato `{ reason, section }`
`lite_enrichment`	Campos Lite em branco que outra fonte de registro do país preencheu: `{ fields[], people_added }`
`registry_metadata`, `registry_sources[]`, `previous_names[]`, `parent_companies[]`, `documents_available`	Apenas em registros mais antigos: os campos próprios do registro, os registros oficiais consultados (`{ name, source_type }`; somente registros oficiais são nomeados), os nomes anteriores, os nomes das empresas controladoras e o número de documentos arquivados disponíveis

Formato do item de administrador (dentro de `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 é preenchido somente quando o registro fornece uma data completa. Se o registro informar apenas o ano, ou o mês e o ano, use date_of_birth_year e date_of_birth_month; o dia ausente nunca é inferido. Nomes, dados de nascimento, endereço e datas de nomeação continuam disponíveis tanto na lista de administradores da empresa quanto na lista de pessoas-chave do registro.

Formato do item de beneficiário final (dentro de `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 usa uma projeção adequada para B2C: Approved, Declined ou Pending (os estados completos da sessão são reduzidos a Pending até que o KYC termine). shareholding informa o que o proprietário detém, no mesmo formato para todos os países e fontes de registro: share_class, number_of_shares, currency, nominal_value, total_value e percentage (a participação exata, com quatro casas decimais). É null quando o registro não informa nenhuma participação. Uma faixa, como os 25-50% de um PSC do Reino Unido, não é uma participação: percentage é null e a faixa permanece em ownership_min_shares / ownership_max_shares. Acionistas e UBOs são listados em beneficial_owners; roles os diferencia.

`key_people_checks[]`

Esta é a verificação agregada de todos os administradores e UBOs da sessão. Ela expõe dois grupos para que o console possa exibir lado a lado “extraído do registro” e “enviado pela empresa”, além de um resumo geral do KYC dos 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: partes extraídas da verificação do registro de empresas.
submitted.parties: partes que o administrador da empresa adicionou explicitamente durante o fluxo de pessoas-chave (registros com source = "USER").

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

Os dados do registro de empresas correspondem a company.officers / company.beneficial_owners acima. As pessoas-chave incluem, além disso, o status AML e o vínculo detalhado com a verificação, como kyc_session_id e os campos do fluxo de verificação. As listas da empresa mantêm o status de KYC simplificado e a URL de verificação que já tinham.

`submitted.parties[]`

As partes enviadas pelo usuário trazem o vínculo com o KYC ou com o KYB da sessão filha:

{
  "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": { }
}

As partes corporativas (entity_type: "company") trazem também company_name, registration_number e kyb_sub_session_id / kyb_sub_session_status / kyb_sub_session_deleted quando o KYB aninhado está ativado para UBOs corporativos. kyc_session_deleted (e seu equivalente corporativo kyb_sub_session_deleted) é true quando a sessão filha da parte foi excluída. Uma sessão filha excluída mantém o status que tinha no momento da exclusão e nunca pode ser concluída, então leia esse indicador em vez do status: o *_session_url correspondente é retornado como null porque o link não funciona mais, e a verificação de pessoas-chave passa para In Review em vez de esperar indefinidamente. Excluir uma sessão filha nunca conta como aprovação. Isente a parte com PATCH /v3/session/{id}/kyb/parties/{party_uuid}/ para permitir que o KYB seja concluído.

`ubo_kyc_summary`

Progresso agregado do KYC dos UBOs, útil para um único card no painel:

Campo	Significado
`total`	Número de UBOs ativos que têm uma sessão de KYC vinculada
`approved`	UBOs cuja sessão de KYC está `Approved`
`flagged`	UBOs cuja sessão de KYC está `Declined` ou `In Review`
`pending`	Todos os demais (ainda não concluídos)

Retorna null quando nenhum UBO tem sessões de KYC vinculadas.

`document_verifications[]`

Documentos agrupados por nó:

{
  "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": []
}

Campo	Descrição
`items[]`	Linhas de documentos individuais: cada uma tem seu próprio `status`, `document_type` e `document_group` (o grupo), `document_subtype`, `file_url` (assinada), `document_metadata` e a extração de OCR
`groups`	Contadores de progresso por grupo, indexados pelo valor do grupo (`LEGAL_PRESENCE`, `COMPANY_DETAILS`, `OWNERSHIP_STRUCTURE`, `REPRESENTATIVES_AUTHORIZATION`, além de `OTHER` para documentos não classificados). Cada grupo contém `total`, `approved`, `pending`, `declined`, `in_review`, `other` e `missing`. Veja os grupos de documentos de KYB
`required_groups`	Grupos que seu fluxo marcou como obrigatórios; condicione a aprovação da sessão ao cumprimento de todos eles

Metadados de documentos corporativos

Para documentos corporativos em PDF, items[].document_metadata.overlay_manipulation pode incluir evidências forenses de possível edição por sobreposição de texto. Quando presente, inclui:

Campo	Descrição
`detected`	Se foram detectadas evidências de manipulação por sobreposição de texto
`analyzed`	Se foi possível analisar o PDF
`signals`	Sinais forenses acionados, como `duplicate_font_subset` ou `glyph_fragmentation`
`manipulated_regions`	Retângulos em coordenadas de página do PDF ao redor do texto possivelmente editado: `page`, `x`, `y`, `width`, `height`, `page_width`, `page_height`

O campo é null quando nenhuma evidência de manipulação por sobreposição de texto foi encontrada, quando o documento não é um PDF ou quando não foi possível analisar o PDF.

`aml_screenings[]`

Análises AML no nível da empresa e (quando o fluxo as configura) no nível de pessoas.

{
  "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": []
}

Quando total_hits > 0, cada ocorrência inclui a pontuação de correspondência, a pontuação de risco, as fontes das listas de monitoramento e um review_status por ocorrência que você pode atualizar pelo endpoint update-aml-hit-status. Veja o relatório de Análise AML para a estrutura das ocorrências.

Arrays de recursos compartilhados

phone_verifications, email_verifications, questionnaire_responses e ip_analyses usam as mesmas estruturas de cada item das sessões de usuário (KYC). Eles são null quando o fluxo não os inclui. Veja a resposta de KYC para os schemas dos itens. signatures está presente quando o fluxo tem uma etapa de Assinatura eletrônica. Uma sessão de empresa tem um item por pessoa-chave que assina pela empresa, com signer.capacity: "company", o nome da empresa e as funções da pessoa-chave. Veja o relatório de Assinatura eletrônica.

Grupos de recursos dos avisos

Os avisos da Verificação de empresas são agrupados pelo recurso que os gerou:

KYB_REGISTRY para problemas de disponibilidade do registro, propriedade, atividade da empresa e restrição de país.
KYB_DOCUMENTS para problemas de extração de documentos corporativos, verificação cruzada, metadados, manipulação, subtipo, idade e limite de tentativas.
AML para correspondências na análise AML da empresa ou dados de análise ausentes.
KYB_KEY_PEOPLE para problemas relacionados a pessoas ligados a diretores, administradores, UBOs ou representantes.
PHONE para problemas de risco do número de telefone, duplicidade, lista de bloqueio e tentativas do código de verificação.
EMAIL para problemas de risco do e-mail, entregabilidade, duplicidade, lista de bloqueio e tentativas do código de verificação.
QUESTIONNAIRE para regras de status personalizadas baseadas nas respostas do questionário.
LOCATION para problemas de Análise de dispositivo e IP, rede privada, lista de bloqueio de IPs, lista de bloqueio de dispositivos e dispositivos/IPs duplicados.
SIGNATURE para recusas de Assinatura eletrônica, falhas na confirmação do código, divergências no nome do signatário, signatários não verificados, documentos alterados e dados ausentes nos campos. Veja os avisos de Assinatura eletrônica.

Veja os avisos da Verificação de empresas para a lista completa de códigos de aviso.

Filtragem de campos por fluxo

Os fluxos podem limitar quais campos aninhados aparecem em cada item de funcionalidade por meio de response_attributes. Campos sempre incluídos, independentemente da configuração, são: status, warnings, node_id. Todos os outros campos recebem valor nulo quando não estão na lista de permissões; a chave permanece na resposta para manter a estabilidade do schema.

Próximos passos

Status

O que significa cada valor de status.

Avaliação de risco

O que determina o resultado de um KYB.

Relatório AML

Referência completa do payload de ocorrências de AML.

Pessoas-chave

Como as partes vindas do registro ou do envio do usuário são distribuídas nos grupos registry / submitted.

Documentos

Grupos de documentos, OCR e verificação cruzada.

Recuperar sessão

Referência completa do endpoint, incluindo exemplos de resposta.

Primeiros passos

Recursos

Perfis de empresas

Referência

Console

Schema de resposta KYB: referência do payload de decisão

Estrutura de nível superior

Campos compartilhados de nível superior

`registry_checks[]`

Bloco `company`

Um formato para todos os países e fontes de registro

Formato do item de administrador (dentro de `company.officers`)

Formato do item de beneficiário final (dentro de `company.beneficial_owners`)

`key_people_checks[]`

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

`submitted.parties[]`

`ubo_kyc_summary`

`document_verifications[]`

Metadados de documentos corporativos

`aml_screenings[]`

Arrays de recursos compartilhados

Grupos de recursos dos avisos

Filtragem de campos por fluxo

Próximos passos

Status

Avaliação de risco

Relatório AML

Pessoas-chave

Documentos

Recuperar sessão

​Estrutura de nível superior

​Campos compartilhados de nível superior

​registry_checks[]

​Bloco company

​Um formato para todos os países e fontes de registro

​Formato do item de administrador (dentro de company.officers)

​Formato do item de beneficiário final (dentro de company.beneficial_owners)

​key_people_checks[]

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

​submitted.parties[]

​ubo_kyc_summary

​document_verifications[]

​Metadados de documentos corporativos

​aml_screenings[]

​Arrays de recursos compartilhados

​Grupos de recursos dos avisos

​Filtragem de campos por fluxo

​Próximos passos

Status

Avaliação de risco

Relatório AML

Pessoas-chave

Documentos

Recuperar sessão

Estrutura de nível superior

Campos compartilhados de nível superior

`registry_checks[]`

Bloco `company`

Um formato para todos os países e fontes de registro

Formato do item de administrador (dentro de `company.officers`)

Formato do item de beneficiário final (dentro de `company.beneficial_owners`)

`key_people_checks[]`

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

`submitted.parties[]`

`ubo_kyc_summary`

`document_verifications[]`

Metadados de documentos corporativos

`aml_screenings[]`

Arrays de recursos compartilhados

Grupos de recursos dos avisos

Filtragem de campos por fluxo

Próximos passos