Zonos Screen

Ship internationally with confidence using Zonos Screen to avoid prohibited parties.

Denied party lists (or restricted party lists) are lists of individuals, organizations, and entities maintained by the government and international bodies around the world with whom it is forbidden to do business, in whole or in part

Screen allows a user to validate parties to a transaction. The denied party screening process necessitates comparing the names of the parties and entities with whom an organization is engaged in business against the names on relevant denied party lists. These parties and all respective identifying information (name, company name, and address) are stored in our database. When we receive a screening request, we attempt to match the data included in the request with anything that exists in our database of denied parties.

Zonos API 

Screen is available in the Zonos API and can screen persons and companies against denied party listings. With Screen, you can ensure recipients or any other parties to the transaction are not present on government-authored denied party listings.

How Screen works 

When we receive a screening request, we compare the data provided to the information in our party screening database. In all cases, party names are also compared against known aliases.

Screen will return matches in the following scenarios:

• When we find EXACT_MATCH or PARTIAL_MATCH on both a person and a location.
• When we find an EXACT_MATCH on the address for a denied party regardless of name.

If a match is found, a REVIEW response is returned containing either anEXACT_MATCH or PARTIAL_MATCHon the fields that were passed in the request. In both cases, details are provided on exactly which fields triggered a matching result. Matches are identified as follows:

• An EXACT_MATCH indicates that the values passed in the request were the same as a potential denied party listing.
• A PARTIAL_MATCH indicates that some of the verbiage matched but was not an exact match.

In both cases, fuzzy matching is used to account for variances between what is passed and returned.

If no matches are found, a NO_MATCHES response is returned. This means that the party data provided in the request did not trigger a match on at least the party name or address.