Virtual documents are now available for Screening in all tenants. Two new endpoints let you attach a document to a screening entity or to an individual match by supplying a link to a file hosted outside Fenergo's storage, instead of uploading the file through the signed-URL flow. The link must be an absolute https:// URL.

The document list endpoints for entities and matches now return a documentUrl field. It is populated for virtual documents and null for documents uploaded through the signed-URL flow.

Added normalized variants of the v4 entity policy fields evaluate endpoint, for collection data groups with many items. Each collection data group returns every unique evaluated field once in its evaluatedFields list, and each item carries only an ordered evaluatedFieldRefs list of integer indices into that list, reducing payload size. To rebuild an item, resolve each index against the list in order. Indices are assigned per response and are not stable across requests.

The normalized endpoint takes the same request as the existing endpoint and returns the same evaluations; only the shape of the collection data groups differs. The existing endpoint is unchanged.

The read-only/normalized endpoint returns a slimmer field shape intended for read-only and display scenarios: only the single fields and collection data groups, each with the properties needed for display. Values evaluation is always skipped, validation errors are not returned, and access layers filtering is always applied, so these options are not part of the request.

A new endpoint is available to evaluate the Screening Expiry snapshot for a journey. Given a journey ID and a list of process IDs, it returns the expiry status of each process's active screening batch, broken down by provider.

The endpointCertificate object now accepts an optional validationMode property that controls how the server certificate of your endpoint is validated for mTLS. Supported values are PinLeafThumbprint (default when omitted, existing behaviour) and SignerChainValidationOnly. The same property applies to oAuthConfiguration.clientCredentialsConfig.endpointCertificate, and is returned when a configuration is retrieved. Existing configurations are unaffected.

Direct callers of the Document Management Command API v2 could get a false "Entity DocumentModel with id {id} not found" error on these endpoints when acting on a document whose real entity type is Screening (or any other type with no dedicated mirrored route) — entity type was previously derived only from the route name (product/deal/else Entity). Each endpoint now accepts an optional documentEntityType query parameter; when supplied, it is used to resolve the document's entity type instead of the route name. Omitting the parameter reproduces the previous behaviour exactly, so this is fully backward compatible. (AB#552592)

Affected Endpoints​

• PUT /documentmanagementcommand/api/v2/documentmanagement/{id}
• DELETE /documentmanagementcommand/api/v2/documentmanagement/{id}
• PUT /documentmanagementcommand/api/v2/documentmanagement/{id}/access-layers
• PUT /documentmanagementcommand/api/v2/documentmanagement/{id}/clone
• PUT /documentmanagementcommand/api/v2/documentmanagement/{id}/requirement-ids
• PUT /documentmanagementcommand/api/v2/documentmanagement/{id}/datakey
• PUT /documentmanagementcommand/api/v2/documentmanagement/{id}/updateDocumentUploadedByUserName
• PUT /documentmanagementcommand/api/v2/documentmanagement/error/{id}
• PUT /documentmanagementcommand/api/v2/documentmanagement/custom-error/{id}

Screening now supports uploading, reusing, and deleting documents at both the entity level and the individual match level within a batch, using the same upload-URL/reuse pattern as other document flows in the platform. New materiality endpoints let users escalate and de-escalate a materiality task on an entity, trigger aggregate entity materiality calculation for a batch, and retrieve the full materiality assessment history for an entity.

A number of existing Batch, Entity, and Match endpoints have also been extended with new fields to support this materiality workflow: journey type and main legal entity on batch creation and retrieval, entity-level materiality assessment/escalation/impacted-client details, and match-level classification data and last-actioned-by information.

The partial-properties endpoint is now unconditionally available to all callers. Request/response schema is unchanged.

Affected Endpoints​

• POST /entitydataquery/api/v2/entity/drafts/partial-properties

New endpoint returning a page of draft entity/journey membership ({ EntityId, EntityDraftId }) per matching draft, for callers that need journey draft membership without the full draft payload. Same authorization/filtering rules as the existing search endpoint. Request gains an optional page options object (page size, pagination token, sort order); response is now a page of items plus a pagination token instead of a bare array. Omitting page options defaults to a page size of 100; page size accepts 1-500.

Affected Endpoints​

• POST /entitydataquery/api/v2/drafts-in-scope/search-entity-drafts-light

The Observability API is now subject to a per-tenant rate limit.

The Rule Execution and Rule Execution Status APIs are now subject to per-tenant rate limits.