16 posts tagged with "Screening"

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.

New V3 Entity endpoints are now available. These replace the existing V1/V2 entity endpoints and introduce two key improvements: support for multiple addresses per entity in SearchCriteria, and per-configuration-set targeting when toggling Ongoing Screening.

Additionally, the ConfigurationSetId field is now exposed in the Ongoing Screening results callback, enabling adapters to identify which configuration set a screening result belongs to.

Added validation in the receptor for the ScreenResponseDto to ensure that entities is not null. This is not a breaking change, because sending entities as null was silently failing before, but now we've improved the endpoint so it returns a 400 with the details of the error instead of silently failing down the line.

Added DriversLicense, SocialSecurityNumber (SSN), and EmployerIdentificationNumber (EIN) to SearchCriteria in batch and to SecondaryIdentifiers in configuration. Right now it's only supported for LexisNexis and any custom providers that want to implement it.

New "AutonomyLevel" property added to BatchMetadataDto. Depending on the value, the matches will be auto-resolved using an AI Agent when they come back from the provider, and auto-close the Screening Results task. Possible values: Manual (default), Semi-Autonomous, Fully Autonomous

New "LastActionedBy" property added to MatchDto. This new property will be used to identify who actioned the resolution of the match, i.e KYRA:Screen, Screening Provider or manually by user (manuallyByUser@test.com).

Added validations in the Screening Receptor when a batch is created and results are sent back from the provider to check:

• That all the entities being returned for the batch search results to the receptor belong to the batch.
• That the match.providerId returned for the batch search results to the receptor exists in the list of the batch providers.

Also, added fields to the Screening Command API in order to support implementation of Alias Screening. For all the endpoints, entityAliases can be sent as null or an empty list if not using Alias Screening.

Update BatchExternalIds to use their own model (BatchExternalId instead of ExternalId), as it does not make sense for a BatchExternalId to have EntityAliasId since BatchExternalId is specifically related to the batch, not any of its entities. This should not affect any clients as Alias Screening has not been enabled yet.

Added fields to support implementation of Alias Screening. There are no breaking changes here, so adapter implementations will continue to work as normal without the need of making any change.

Added PassportNumber to SearchCriteria in batch and to SecondaryIdentifiers in configuration. Right now it's only supported for LexisNexis and any custom providers that want to implement it.

Added support for RDC and WCO for the feature outlined in the previous post through our RDC and WCO adapters, as well as our AdapterMock implementation.