@ashish22

Please find my answers inline below,

We have done with the POC implementation and were able get response from WC1 API’s successfully. Further, we had few queries, kindly help us in providing information.

There are two queries:

Query 1: Number of API calls

In the old version of Thomson Screening, we submit a screener request which provides us with the count of records matching the search criteria.

The system then follows it up with two API calls that will fetch the complete details of the search criteria, which is then stored in our system.

> API Call 1: Name (https://screeningpilot.accelus.com/pilot-v1/name?wsdl)

> API Call 2: Content (https://screeningpilot.accelus.com/pilot-v1/content?wsdl)

But having screened through some of WC1 APIs, I see only one API that matches the set of above multiple API calls "SEQ-screen-sync-simple: Perform Synchronous Screening: Simple" (name fetched from postman scripts for better understanding).

[MK]: We offer two screening options when it comes to screening ,

a) Synchronous screening : This API gives you the screening results instantly,

As correctly noted, the sync response provides details such as : "primaryName", "category", "events", "countryLinks", "identityDocuments" which are the missing fields from async results but currently the sync screening endpoint does not have the auto-resolved attribute in its JSON response. In order to see the matches that have been auto-resolved along with the unresolved matches, you would need to call the “Get screening results” API. However, this would also mean that the additional information that you get from the sync screening endpoint will not be available in the “Get screening result” API JSON response.

API sequence would be- SEQ-screen-sync-individual: Perform Synchronous Screening: Individual -> Get Profile details.

b) Asynchronous screening: In this screening approach you first save the case->screen the case->check audit-> get screening results. Asynchronous screening queues your screening request which is why we have the audit log API to confirm if the case is screened or not , and also you get the resolution details of the matches in the response.

API Sequence would be - save the case->screen the case->check audit-> get screening results-> Get Profile details.

Based on your use case , you can determine which would be the best approach to achieve the use case.

Please confirm if we are going in the right direction. If not, please provide us with the work flow. Thanks.

Query 2: Search attribute information

In the previous version of Thomson Screening, we use to get the address information, keywords, DOB, Category. Please see PDF attachment. From the API response called, the system does not get the above-said information.

Looking at the nature of changes involved, we would like to know if there is a minimal migration strategy or list of APIs (with details) that will match the old API workflow

[MK]-

• You can obtain these details from the Sync screening API results.
• Please provide a detailed description of your use case so that we can recommend you the API sequence as per the best practices.

Thanks for the detailed answer. I will go through the same and revert with my doubts.

In the meantime, here is our use case:

• Customer registers into our system.
• Our system queries TR (Screener API) by first name and last name and receives the total match count from the TR. If match count is exactly 1, he is registered as a customer. For others, his record is pushed to the system administrator.
• The system administrator then runs the checks against TR (Name and content API) and approves/rejects the customer.
• Once approved, the customer will be able to enter our system.

Please revert if you need more clarity.

Thanks in advance for a quick API sequence recommendation.

currently the sync screening endpoint does not have the auto-resolved attribute in its JSON response. In order to see the matches that have been auto-resolved along with the unresolved matches, you would need to call the “Get screening results” API.

We did not understand the term "auto-resolve". Also we ran the screening result API and found resolution attribute as null (our assumption is that this field has something to do with auto-resolve. I guess we are wrong).

Can you provide more clarity on this concept? Is "resultReview" of any significance for our use case?

@ashish22

You will see auto-resolved matches when you screen the entity along with the secondary identifiers such as gender, Nationality, The system auto resolves the matches that do not satisfy your search criteria, suppose I pass birth year as 1951 and screen the entity Barack Obama, the actual Birth year is 1961 so the system would mark the match as auto-resolved. Since you will not be using any secondary identifiers you will not receive any auto-resolved matches.

ReviewRequired is a flag to indicate if there is any review required to the result after re-screening the case.

For more information on resolution please refer the case review section from our quick start guide on the developer portal, you can access this from the link below,

https://developers.refinitiv.com/en/api-catalog/customer-and-third-party-screening/world-check-one-api/quick-start?content=57985&type=quick_start

Now coming to your use case:

You will be screening an entity by passing only first & last name -> from the screening response you will be registering customers if there are no matches but if there are any matches to the entity screened your system admin would then fetch the profile details of the match in interest then perform remediation(approve/reject) the customer.

Kindly confirm if my understanding is correct.

Your understanding is correct in regards to use case. This is the current process of our application. Kindly recommend the best API's to be used.

@ashish22

To accommodate your use case I would recommend the below API sequence,

1. Fetch top-level groups (To be called once a day).

2. SEQ-screen-sync-individual: Perform Synchronous Screening: Individual

3. SEQ-case-investigate-world-check-profile: Get a World-Check profile - You will have to fetch the profile details of the matches only of your interest and not of the entire result, suppose we have 80 matches to the entity screened you can pick the match with the highest match strength and fetch its relevant details instead of firing this API 80 times which would make your implementation inefficient and may cause unnecessary load on our platform.

Using this approach you will get screening results instantly thus reducing the number of API calls compared to an asynchronous screening where you will have to save a case then screen and then use audit log to confirm screening followed by which you can fetch the results and fire the profile details API.

I would also like to know where will the remediation be performed? Will it be done using WC1 API or the UI? or will you use your own UI?

I would recommend you to try this approach and analyze if this fits best to your use case, in case of any queries you can always reach out to us.

Regards

I would also like to know where will the remediation be performed? Will it be done using WC1 API or the UI? or will you use your own UI?

We will be using WC1 API. Also we do not have a UI. Ours is also a web service call used by our Digital clients.

Get a World-Check profile - You will have to fetch the profile details of the matches only of your interest and not of the entire result

Reference this API, it is asking for World Check Profile ID ("worldcheck-profile-id"). Which value from the results of "SEQ-screen-sync-individual: Perform Synchronous Screening: Individual"

"matchStrength": "EXACT",

In the previous TR service, we get 0 count if the user is an authentic user. Based on this count value, we create the user or submit the user through an approval process.

In the new API, I see this "matchStrength" attribute with value "EXACT". Does this mean that we will always get atleast 1 record for an authentic user? In other words, we will get 1 record whose "matchStrength" attribute is "EXACT".

@ashish22

1. Since you're using WC1 API for match resolution you will need to use two API calls for this purpose.

a) Fetch the resolution toolkit : This response can be cached if you're planning on not changing the toolkit settings.

b) Resolve results: Pass the Status, risk & reason Ids fetched from above API and resolve the matches.

2. The "referenceId" from your sync Individual screening response is your World-Check profile Id. You can utilize this ID to get the profile details of the matches.

3. The results basically depend on the entity you're passing, if you're passing the correct parameters you will get match strength as exact and if there are no hits from our database you will get an empty result as well, you can modify minimum threshold to return only exact matches from the admin section of your WC1 account.

@Mehran.Ahmed Khan

We have few concerns in regards to WC1 API integration. Can you please help us in providing the information.

1. In the legacy TR application, we used to get "0" as count when a request is submitted against "First Name" and "Last Name". When the count is 0, we treat this user as a legitimate user and registers the user in our system. Is this the same logic in the WC1 API?
2. When we ran the postman script against a test search, we got multiple results. In the same, we found this attribute "matchedTerm" a little confusing. In some result, it shows "EXACT" while in some, it shows "STRONG". Can you provide us the documentation to understand what these different terms actually mean and what are the other values possible for "matchedTerm"? Note: Just in case, you do not have the documentation, please let us know what is the difference between "STRONG" and "EXACT"? Also provide us with the "matchedTerm" enumeration.

@ashish22,

Apologies for the late response,

1. Yes, its the same logic in the WC1 API.

2. The matchedTerm basically depends on the information you're passing while screening the identity and how accurate it is to the hit received from WC1, matchedTerm is the name that the matching engine returns against the name (SubmittedTerm) screened by the user, suppose I screen "John Smith" and in my result I see one of the hits as "Michael John Smith" , so the matchedTerm here is "Michael John Smith" against my submittedTerm "John Smith", and the matchStrength in this case could be "Medium" the "matchedStrength" can be WEAK, MEDIUM, STRONG, EXACT dependin upon how close is the hit from the name screened. For example : If the matchedTerm is "Smith John" the matchedStrength would be "EXACT", Below are few examples for your reference.

Please download our technical documentation using the link below to get to know further details about matchNameTypes etc.

https://developers.refinitiv.com/en/api-catalog/customer-and-third-party-screening/world-check-one-api/downloads

Scenrio 1:
"matchStrength": "MEDIUM",
"matchedTerm": "Michael John SMITH",
"submittedTerm": "John Smith",
"matchedNameType": "PRIMARY", 


Scenario 2: 
"matchStrength": "WEAK",
"matchedTerm": "Daquan J SMITH",
"submittedTerm": "John Smith",
"matchedNameType": "PRIMARY", 


Scenario 3:
"matchStrength": "STRONG",
"matchedTerm": "SMITH,John L",
"submittedTerm": "John Smith",
"matchedNameType": "AKA" 


Scenario 4: 
"matchStrength": "EXACT", 
"matchedTerm": "John SMITH",
"submittedTerm": "John Smith",
"matchedNameType": "PRIMARY" 

Let me know if you need further details on this.