Skip to main content

Validation suite tests for checks

Tests for custom check types

For INDIVIDUAL_CUSTOM and COMPANY_CUSTOM check types, a few tests are run to ensure that your response contains the minimal data required and the correct format is followed.

These tests:

  • Provide a decision in the check result

  • Provide a summary in the check result

  • Have a check result summary that is non-empty

  • Have a check result summary that is of appropriate length or shorter than 450 characters

As per the other check types, these tests are performed by assessing the response to the demo_result value of ANY. The following response can be used to pass the validation suite.

Tests for screening check types

If your integration is an INDIVIDUAL_SCREENING or COMPANY_SCREENING check type, in addition to the standard tests, the following tests are also performed, using the following demo_result values.

Note

Your integration must support at least REFER as well as any other relevant flag types.

Note

A hit is considered an object in the screening_hits array.

A flag is considered an entity in the screening_hits.[n].flags array.

Flags refer to one or more of the event types of INTERNAL_WATCHLIST, WATCHLIST, PEP, REFER, SANCTION, and ADVERSE_MEDIA.

  • ANY

    This expects any valid response as per the screening check type.

  • SCREEN_ALL_FLAGS_SEPARATE_HITS

    This expects a response containing all flags, as specified in your /config supported_features, spread across separate hits.

  • SCREEN_ALL_FLAGS_SAME_HIT

    This expects a response containing all flags, as specified in your /config supported_features, in the same hit. A hit is considered an object in the screening_hits array. A flag is considered an entity in the screening_hits.[n].flags array.

  • SCREEN_NO_HITS. This expects a response where no hits were found. This can simply return the screening_hits field with an empty array, along with the other required fields in this response.

  • SCREEN_SINGLE_INTERNAL_WATCHLIST

    This expects a response with only the INTERNAL_WATCHLIST flag. This is only tested if your integration specifies support for this flag type.

  • SCREEN_SINGLE_WATCHLIST

    This expects a response with only the WATCHLIST flag. This is only tested if your integration specifies support for this flag type.

  • SCREEN_SINGLE_ADVERSE_MEDIA

    This expects a response with only the ADVERSE_MEDIA flag. This is only tested if your integration specifies support for this flag type.

  • SCREEN_SINGLE_PEP

    This expects a response with only the PEP flag. This is only tested if your integration specifies support for this flag type.

  • SCREEN_SINGLE_REFER

    This expects a response with only the REFER flag. You must support REFER flag types, so this should always be tested.

Tests for company data check types

If your integration is a COMPANY_DATA check type, in addition to the standard tests, the following tests will also be performed, using the following demo_result values.

  • ANY

    This expects any valid response as per the COMPANY_DATA check type data schema.

  • COMPANY_INACTIVE

    This expects a response with an inactive company. This means the response should have check_output.metadata.is_active set to False.

  • NO_DATA

    This expects a situation where no company data was found. For this, respond with the following:

    {
"errors": [],
"warnings": [],
"provider_data": "Demo result. Did not make request to provider.",
}

  • COMPANY_COMPANY_OF_SIGNIFICANT_CONTROL

    This means the response contains an associated company entity identified as having significant control.

    This would mean ensuring you have an associated entity present and setting the check_output.associated_entities.relationships.tenure.tenure_type to CURRENT and setting the check_output.associated_entities.relationships.tenure.associated_role to PERSON_OF_SIGNIFICANT_CONTROL and ensuring the check_output.associated_entities.entity_type is set to COMPANY.

  • COMPANY_INDIVIDUAL_OF_SIGNIFICANT_CONTROL

    This means the response contains an associated individual entity identified as having significant control.

    This would mean ensuring you have an associated entity present and setting the check_output.associated_entities.relationships.tenure.tenure_type to CURRENT and setting the check_output.associated_entities.relationships.tenure.associated_role to PERSON_OF_SIGNIFICANT_CONTROL and ensuring the check_output.associated_entities.entity_type is set to INDIVIDUAL.

  • COMPANY_FORMER_SHAREHOLDER

    This means the response contains an associated company entity identified as being a former shareholder.

    Set the check_output.associated_entities.relationships.tenure.tenure_type to FORMER and set the check_output.associated_entities.relationships.tenure.associated_role to SHAREHOLDER.

  • COMPANY_OFFICER_WITH_MULTIPLE_ROLES

    This is expecting an associated entity with multiple roles.

    Ensure one of your associated entities has two or more items in the check_output.associated_entities.relationships array.

  • COMPANY_RESIGNED_OFFICER

    This is expecting one of the associated entities as having previously resigned.

    To do this, set the check_output.associated_entities.relationships.tenure.tenure_type to FORMER and set the check_output.associated_entities.relationships.tenure.associated_role to DIRECTOR.

  • COMPANY_SHAREHOLDER_WITH_100_PERCENT_OWNERSHIP

    This is expecting one of the associated entities to have 100% ownership.

    Set the check_output.associated_entities.relationships.tenure.tenure_type to CURRENT, set check_output.associated_entities.relationships.tenure.associated_role to SHAREHOLDER, and set the check_output.associated_entities.relationships.total_percentage to 100.0.

  • COMPANY_SHAREHOLDER_WITH_SIGNIFICANT_CONTROL

    This is expecting an associated shareholder and a person with significant control.

    To do this, set one of the entities in the check_output.associated_entities.relationships array to have check_output.associated_entities.relationships.tenure.associated_role to SHAREHOLDER and the check_output.associated_entities.relationships.tenure.tenure_type to CURRENT. Then add a second associated entity in the relationships array to have check_output.associated_entities.relationships.tenure.associated_role to PERSON_OF_SIGNIFICANT_CONTROL and the check_output.associated_entities.relationships.tenure.tenure_type to CURRENT.

Tests for document verification and document fetch data check types

If your integration is a DOCUMENT_VERIFICATION or DOCUMENT_FETCH check type, in addition to the standard tests, the following tests are also performed, using the following demo_result values.

  • ANY or DOCUMENT_ALL_PASS

  • ERROR_UNSUPPORTED_DOCUMENT_TYPE 

  • DOCUMENT_FORGERY_CHECK_FAILURE 

  • DOCUMENT_IMAGE_CHECK_FAILURE 

  • DOCUMENT_NAME_FIELD_DIFFERENT 

  • DOCUMENT_DOB_FIELD_DIFFERENT 

  • DOCUMENT_NAME_FIELD_UNREADABLE 

  • DOCUMENT_DOB_FIELD_UNREADABLE 

Tests for the identity check type

If your integration is an IDENTITY_CHECK check type, in addition to the standard tests, the following tests are also performed, using the following demo_result values.

  • ANY 

  • NO_MATCHES 

  • ONE_NAME_ADDRESS_MATCH 

  • ONE_NAME_DOB_MATCH 

  • TWO_NAME_ADDRESS_MATCHES 

  • ONE_NAME_ADDRESS_ONE_NAME_DOB_MATCH 

  • ONE_NAME_ADDRESS_DOB_MATCH 

  • MORTALITY_MATCH 

  • ONE_NAME_ADDRESS_MORTALITY_MATCH 

  • ONE_NAME_ADDRESS_ONE_NAME_DOB_MORTALITY_MATCH 

Tests for monitoring cancellation

If your integration check template is MONITORED_CALLBACK, you must have implemented the /cancel_checks endpoint.

Your integration must always return a 200 status code in response, however it must include errors or warnings under certain circumstances. These are tested in the validation suite.

This is tested by the validation suite using the following demo_result values.

  • CANCEL_WITH_SUCCESS

    This is simulating a situation where your /cancel_checks endpoint receives a valid request and the cancellation completes successfully.

  • CANCEL_BAD_REFERENCES

    This is simulating a situation where your /cancel_checks endpoint receives a request that contains invalid references.

    The references should include the values that were sent in the references array of the request.

  • CANCEL_ALREADY_CANCELLED_REFERENCES. This is simulating a situation where your /cancel_checks endpoint receives a request that contains references that have already had monitoring canceled.

    The references should include the values that were sent in the references array of the request.

Additional information

In this section: