WC1 API Integration.

Options
ashish22
ashish22 Newcomer
in World-Check One

thomsonreuters-contentresponse.pdf

Hi Team,

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).

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
work flow.

Tagged:

Best Answer

  • Mehran.Ahmed Khan
    Mehran.Ahmed Khan LSEG
    Answer ✓

    @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.

Answers

  • ashish22
    ashish22 Newcomer

    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.

  • ashish22
    ashish22 Newcomer 
    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?

  • Mehran.Ahmed Khan
    Mehran.Ahmed Khan LSEG

    @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/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.

  • ashish22
    ashish22 Newcomer

    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.

  • Mehran.Ahmed Khan
    Mehran.Ahmed Khan LSEG

    @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

  • ashish22
    ashish22 Newcomer 
    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".

  • Mehran.Ahmed Khan
    Mehran.Ahmed Khan LSEG

    @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.

  • ashish22
    ashish22 Newcomer

    @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.

  • Mehran.Ahmed Khan
    Mehran.Ahmed Khan LSEG

    @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/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.

Categories