OGS with LexisNexis for individuals will break if secondary identifiers are changed between First Name + Last Name and Full Name without ensuring the existing data in the screening domain is correct first.
How Fenergo entity\screening data flows in a nutshell?
Data that is used as search criteria for screening is stored separately to entity data. In a journey, this data is created or updated in the screening domain based on the secondary identifiers that are configured at the point this screening data is created. This data in the screening domain is what is sent to the screening provider, not the entity data.
How batch files for OGS with LexisNexis are created in Fenergo?
All screening entities (data retrieved from screening domain) that are marked as subscribed for OGS are retrieved. These entities are returned in a random order i.e. any entity could be first. The first entity is read and the file format for the file to be sent to LexisNexis is determined from this entity based on which search criteria this entity has:
If First Name + Last Name are present, the entire file is set as First Name + Last Name file format.
If there is no First Name + Last Name, the entire file format is set to Full Name.
All entities will be added to the same file.
How secondary identifiers are changed?
Change the checkboxes on the secondary identifier configuration page and select save. Changing this ONLY changes which fields in the screening domain new creates or updates will target.
The problem:
When new data is created in the screening domain that has different screening search criteria to entities currently in the screening domain, there is a possibility that either the Full Name or First Name + Last Name format will be used for the batch OGS screening process with LexisNexis. All entities will be provided in the format of the first entity. This will result in blank data being passed through for full name\first name + last name where that data is not in the screening domain which will throw errors in LexisNexis.
LexisNexis will ingest the a file it is not configured to ingest and read the data based purely on column order which will return unwanted results. This will result in an entity being screened based on invalid data points e.g. Date of Birth being used as the Address for an entity.
Process to avoid the problem:
As a prerequisite for changing between First Name + Last Name and Full Name in Fenergo when integrated with LexisNexis for OGS screening, there is a need to update all existing screening data to match the desired new search criteria. This involves all open journeys being pushed back to run through screening tasks again.
If there is a decision to enable OGS this same solution will need to be applied for existing entities and these entities will need to be explicitly subscribed for OGS.
Data remediation if the problem occurs:
A remediation will be required to be performed via API. All individual entities that could be affected (entities with journeys open currently that were past the screening task prior to the config change; or entities whose last screening was prior to the configuration change) will need to have their screening search criteria updated. Currently the only method to identify the screening entity ids is VIA API by bulk creating screening entities and consuming the error that entities already exist along with their screening id and then doing updates on these entities to ensure the correct data is present in the screening domain.
Depending on the volume, running new journeys against these entities is a potential option.