> ## Documentation Index > Fetch the complete documentation index at: https://docs.paxos.com/llms.txt > Use this file to discover all available pages before exploring further. # Enhanced Due Diligence > Manage the enhanced due diligence of an Identity on the Paxos Platform. Enhanced Due Diligence (EDD) is triggered when an identity is deemed high risk based on Paxos's risk rating methodology. This can occur during onboarding, or during the lifecycle of an active identity — for example, if identity information changes in a way that impacts risk rating, or if suspicious transaction patterns occur on the account. When an identity enters the EDD process, you are required to collect documentary evidence supporting the initial KYC information provided. You can handle EDD collection using a webhook-based or polling-based approach, leveraging [Paxos Webhooks](/guides/webhooks), the [Events API](/api-reference/events), and the [Document Upload API](/api-reference/endpoints/identity-documents/document-upload). ## Webhook-based Approach Events ### ➊ Consume Documents Required Events Setup a [Webhook Consumer](/guides/webhooks/quickstart) to receive `identity.documents_required` [events](/api-reference/events) for your end users. ### ➋ Fetch Required Documents Call [Get Event](/api-reference/endpoints/events/get-event) to fetch the event's `identity_documents_required` object. Use the `documents` array to build the document checklist for your end user. Each entry in `documents` includes: | Field | Description | | - | - | | `document_type` | The document type requested (e.g., `IDENTITY_VERIFICATION`). Corresponds to an entry in the `document_types` parameter of the [Document Upload API](/api-reference/endpoints/identity-documents/document-upload#body-document-types). | | `required` | Whether the document is mandatory. Optional documents do not block EDD completion. | | `explanation` | Human-readable context explaining why the document is requested. Empty when no explanation is provided. | > The flat `required_documents` array is deprecated. It lists required document types only; use `documents` instead, which also covers optional documents and carries per-document metadata. ### ➌ Upload the Required Documents For the event's associated `identity_id`, call [Document Upload](/api-reference/endpoints/identity-documents/document-upload) to upload each document, either synchronously if you already have the documents, or asynchronously if you need to reach back out to your customer. To track progress, call [List Identity Documents](/api-reference/endpoints/identity-documents/list-identity-documents). Each entry covers one uploaded file (or a still-missing requirement) via its `document_types` array — a single file can satisfy more than one requested type — and carries a `status` field reflecting its current upload state: | Status | Description | | - | - | | `NOT_STARTED` | No upload has been initiated for this document, or a prior upload attempt expired unused. | | `PENDING_UPLOAD` | A file exists and is awaiting the file bytes or is being processed. | | `REJECTED_UPLOAD` | The upload failed (e.g., failed processing) and must be retried. | | `COMPLETED_UPLOAD` | The file was uploaded and processed successfully. | `status` is omitted from an entry when its upload state cannot be determined — treat a missing `status` as an unresolved requirement, not as a contract violation. Each entry always includes a `required` flag (`false` means optional; an entry covering multiple types is required if any of them is). Some entries showing `PENDING_UPLOAD` also include an `upload_link` you can use to upload the file directly — it's present only while the underlying upload is awaiting file bytes and its window has not expired, not for every `PENDING_UPLOAD` entry. Re-upload any document showing `REJECTED_UPLOAD`. `status` is available only via the [List Identity Documents](/api-reference/endpoints/identity-documents/list-identity-documents) API — it is not included in the event payload. The event tells you which documents are requested; the API tells you their current state. `COMPLETED_UPLOAD` reflects successful storage processing, not compliance acceptance of the document. ### ➍ Wait for the EDD Outcome When Paxos's review of the submitted documents reaches an outcome, it emits one of the following: * **`identity.documents_accepted`** — The EDD review concluded successfully. * **`identity.documents_denied`** — The EDD review resulted in a denial. Both events return an [`identity_edd`](/api-reference/events/identity-edd-object) object from [Get Event](/api-reference/endpoints/events/get-event). Treat these as the signal to act on when they arrive, but do not treat them as a guaranteed terminator — a review can also be closed with no accepted or denied event. If you have not received one within the expected review window, reconcile by checking the identity's status and outstanding requirements rather than waiting indefinitely. A separate overall identity-status event may also fire, but only when the identity's status actually changes as a result. Which event fires depends on the identity's status when EDD was triggered: | EDD outcome | Identity context | Overall status event | | - | - | - | | Accepted | During onboarding (identity was `PENDING`) | `identity.approved` (transitions to `APPROVED`) | | Accepted | Already active (`APPROVED`) | None — the identity was already approved, so there is no status change | | Denied | During onboarding (identity was `PENDING`) | `identity.denied` | | Denied | Previously approved / active | `identity.disabled` | EDD review may take up to one full business day to complete. ## Polling-based Approach ### ➊ Poll for Documents Required Events Poll [List Events](/api-reference/endpoints/events/list-events), offsetting the `created_at.gt` filter for each subsequent poll, fetching all `identity.documents_required` events. Keep track of the [Event](/api-reference/events) IDs you've processed to ensure idempotent event handling. ### ➋ Upload the Required Documents For the event's associated `identity_id`, call [Document Upload](/api-reference/endpoints/identity-documents/document-upload) to upload the required documents. Poll [List Identity Documents](/api-reference/endpoints/identity-documents/list-identity-documents) to monitor the `status` of each document, and re-upload any showing `REJECTED_UPLOAD`. ### ➌ Poll for the EDD Outcome Poll [List Events](/api-reference/endpoints/events/list-events) for `identity.documents_accepted` or `identity.documents_denied` to determine the outcome of the review. ## Requirement Changes During an In-Flight EDD If the documents required for an in-flight EDD change — for example, because the compliance configuration for your integration is updated — Paxos re-emits `identity.documents_required` for that identity. The re-emitted event reflects the current, complete set of requested documents. When you receive a subsequent `identity.documents_required` event for the same identity: 1. Fetch the updated event object using [Get Event](/api-reference/endpoints/events/get-event) and re-display the checklist from the `documents` array. 2. Call [List Identity Documents](/api-reference/endpoints/identity-documents/list-identity-documents) and check the `status` of each entry. 3. Upload any document that is `NOT_STARTED`, `PENDING_UPLOAD`, `REJECTED_UPLOAD`, or missing a `status` to resume the review. > Questions? Contact [Support](https://support.paxos.com).