Introduction

The World-Check One API enables developers to integrate the next generation of LSEG screening capabilities into existing workflows and internal systems (such as CRMs) in order to help streamline the processes for on-boarding, KYC and third party due diligence.

Backed by data from World-Check Risk Intelligence, this API is delivered as a REST/JSON web service, accessible exclusively over HTTPS. An API schema is available that describes all features and data used within the API. This schema is in Swagger 2.0 format (also known as the OpenAPI specification format), so developers integrating with the World-Check One API can benefit from the many supporting tools, documentation and resources available within the Swagger/OpenAPI ecosystem.

World-Check One APIs

Case Management and Audit

This variant of the World-Check One API enables clients to screen names and securely store case and match information within the World-Check One infrastructure, along with a full audit trail. This information can be accessed, modified, or deleted at any time either via the API or the Desktop interface. Cases can also be set to Ongoing Screening, allowing automated screening for Risk Intelligence updates.

Case Management & Audit - V2

Refer to this reference guide for the detailed information on the Case Management & Audit V2 API functionality available in the World-Check One platform.

Case Management & Audit - V1

Refer to this reference guide for the detailed information on the Case Management & Audit V1 API functionality available in the World-Check One platform.

Zero-Footprint Screening

LSEG World-Check One API Zero Footprint Screening (ZFS) enables customers to screen entities without the need to store data on LSEG’s platform.

No case data or matched data is stored, thus offering an ideal lightweight solution for on-demand screening.

Zero-Footprint Screening - V2

Refer to this reference guide for the detailed information on the Zero-Footprint Screening V2 API functionality available in the World-Check One platform.

Zero-Footprint Screening - V1

Refer to this reference guide for the detailed information on the Zero-Footprint Screening V1 API functionality available in the World-Check One platform.

Accounts

Two accounts are available to integrators of the World-Check One API: Pilot, and Production.

content-type: application/json
protocol: https://
gateway-host: api-worldcheck.refinitiv.com
gateway-url: /v2/
Endpoint URL: {{protocol}}{{gateway-host}}{{gateway-url}}{{endpoints-from-schema-reference}}

Pilot

This account is intended to be used for integration and testing and should be used to validate that the API integration is working as intended. Clients should not use the Pilot environment for live name screening as there are no built-in means of copying any generated data to the Production account.

By default, Pilot accounts are limited to:

  • Total Number of Cases = 1000

  • Screenings Per Hour = 5000

  • Users = 5

LSEG may clear the data on inactive Pilot accounts with prior notification via email. To ensure that integration / testing work is not affected by the case limit, clients should regularly delete old test cases from the account or after doing a round of testing. Clients can request for a limit increase, which will be reviewed primarily against the subscription volume.

Production

The Production account is used for real-world KYC/AML workflows with actual names. Once an integration has been validated on the Pilot account, it can be promoted to Production. Screenings and cases, and the number of users within the Production account count towards the contracted volumes and users.

By default, Production accounts are limited to:

  • Total Number of Cases = up to 1.5x the contracted screening volume

  • Screenings Per Hour = 10000

The default limits should address the needs of most integrations. However, there may be cases when these limits are insufficient. In this case, clients should reach out to their LSEG contacts or the Support Team for a limit increase, which will be subject to review based on the subscription volume. If more cases are expected to be saved on the account, clients should consider increasing the subscription volume.

API Management Process

Under continuous delivery, the World-Check One API is regularly updated with new functionality and enhancements, performance improvements, and bug fixes.

The API version of the Pilot account is always in sync with Production. World-Check One does not provide a sandbox account with a pre-release version of the API. Regular updates to the same major API version are always non-breaking and may not be announced prior to the release.

Non-Breaking Change

  • New endpoints

  • New optional fields in the request body of existing endpoints

  • New required fields in the request body with a default value

  • New optional URL parameters of existing endpoints

  • New fields in the response of existing endpoints

  • New or updated error message descriptions

  • New enumeration values

  • Changes to string patterns

Clients integrating with the API should ensure that the above items are taken into consideration in the application design and ensure that the code will not fail given the above changes.

Breaking changes may cause integrated applications to break and will always be announced at least 90 days prior to release. The announcements may be done via emails to Client and Group Admins, along with in-product notification within World-Check One Desktop and posts in the Developer Portal.

Breaking Change

  • New required fields without a default value

  • Making an existing field required without a default value

  • Data type change on existing fields

  • Change in field names

  • A change in validation criteria

  • Removal of an existing enumeration value

  • Removal of existing fields in the response

Rate Limits

The World-Check One API enforces a dynamic rate limiting mechanism to prevent accounts from unduly overusing the platform and causing heavy spikes of requests that may degrade the system performance.

A rate-limited request will be responded by a HTTP 429 with no body. This rate limit is dynamically determined by the system based on:

  • API endpoint requests

  • Number of concurrent requests for the account

  • Available capacity of the system

The general rule to keep in mind is that any concurrent requests for an endpoint greater than 5 per second may be rate limited. As such, clients should ensure that the application design is able to handle HTTP 429s gracefully, and ideally via an exponential back-off mechanism with a maximum of 5 retries.

Branding

Where World-Check One content is surfaced on the client’s internal platform, it is necessary for the following text to be placed nearby so that the data is clearly attributed to LSEG: “Powered by LSEG World-Check One” or “From LSEG World-Check One”.

Where World-Check One content is surfaced on a report, the LSEG logo should be included per the LSEG co-branding guidelines. The Branding Toolkit can be downloaded from here.

Further Information

For detailed information on all requirements around integrating with the World-Check One API, please consult the following documentation.

Introduction to the World-Check One platform

Please note this section contains documentation about the wider World-Check One platform, so covers broader material than only the World-Check One API.

World-Check One API Marketing mini site

The marketing site contains a high-level introduction into the benefits of integrating the World-Check One API into a Know Your Customer/Anti Money Laundering onboarding workflow within the WC1 client’s organisation.

World-Check One Marketing mini site

For those unfamiliar with the World-Check One product, please refer to its marketing site for a high-level introduction into the benefits of using the World-Check One platform within the WC1 client’s customer/supplier onboarding workflow. The site also includes links to other products within the Risk Management portfolio offered by LSEG.

Screening and Case Manager Quick Reference Guide

Refer to this quick reference guide for an overview of the Screening and Case Management functionality available in the World-Check One platform. Please note this guide describes how the functionality works within the existing web-based user interface rather than the API; it is intended as an introduction to the case management and screening functionality offered by the platform rather than a guide on what to expect from it when using the API.

World-Check One API Development Community

World-Check One API developer portal

Refer to the LSEG Developer Portal page for the World-Check One API to keep up to date with any improvements made to the API over time, as well as to engage with a community of other API integrators. This site can also be used to engage with LSEG for additional help and support in integrating with the World-Check One API.

Downloads

Case Management and Audit - V2

Sample API HTTP requests (Postman Collection) - V2

Download sample API HTTP requests (Postman Collection) - V2, in JSON format.

World-Check One API (Postman Environment) - V2

Download World-Check One API (Postman Environment) - V2, in JSON format.

Swagger API Schema - V2

Download World-Check One API schema - V2, in YAML format.

Case Management and Audit - V1

Sample API HTTP requests (Postman Collection) - V1

Download sample API HTTP requests (Postman Collection) - V1, in JSON format.

World-Check One API (Postman Environment) - V1

Download World-Check One API (Postman Environment) - V1, in JSON format.

Swagger API Schema - V1

Download World-Check One API schema - V1, in YAML format.

Zero-Footprint Screening - V2

Sample API HTTP requests (Postman Collection) - V2

Download sample API HTTP requests (Postman Collection) - V2, in JSON format.

World-Check One API (Postman Environment) - V2

Download World-Check One API (Postman Environment) - V2, in JSON format.

Zero-Footprint Screening - V1

Sample API HTTP requests (Postman Collection) - V1

Download sample API HTTP requests (Postman Collection) - V1, in JSON format.

World-Check One API (Postman Environment) - V1

Download World-Check One API (Postman Environment) - V1, in JSON format.

Sample HMAC authorization files

Sample HMAC authorization files

Download sample HMAC authorization files in ZIP format.

Branding Toolkit

Branding Toolkit

Download Branding Toolkit in ZIP format.

Appendix

Appendix A: Copyright

(c) 2018 - 2023 LSEG. All rights reserved. Republication or redistribution of LSEG content, including by framing or similar means, is prohibited without the prior written consent of LSEG. 'LSEG' and the LSEG logo are registered trademarks and trademarks of LSEG and its affiliated companies.

Appendix B: LSEG Risk Management Solutions

For more information send us a sales enquiry at https://www.lseg.com/en/contact-us.

Read more about our products at https://www.lseg.com/en/risk-intelligence.

Find out how to contact your local office at https://www.lseg.com/en/locations.

Appendix C: Changelog

The World-Check One API will be updated over time as new functionality is added to the overall World-Check One platform. To accommodate this change, the API is fully versioned, and wherever possible existing API methods will be added to newer versions of the API with a goal of backwards compatibility. To accommodate these version updates, all that a developer should need to do is update the version of the API being integrated with in their configuration management database. Integration code will only need to be modified if there are new features made available in a more recent version of the API that would like to be taken advantage of.

  • 2.61.0: Added new endpoints for case search and retrieving the available search filters to use during case search. Added new fields 'uuid', 'loginAccountStatus' and 'lastLoginDate' under 'Get all the active users visible to the authenticated user' endpoint available only for Client Admins.

  • 2.60.0: Added three new endpoints to generate single Case Dossier PDF report under a new tag "reporting". Submit async report request endpoint can be used to place request for the report by passing 'Case Id'/ 'Case System ID' and other 'Report Filters', which in turn will return the 'Report ID' on successful validation. Report status endpoint can be used to get the status of the report requested by passing the 'Report ID'. Get report endpoint can be used to download the generated PDF report by passing the 'Report ID'.

  • 2.59.0: Added new error code 410 to 'Get a record by id', 'Get a profile by id', 'Retrieves PEP details by the given profile ID' and 'Retrieves PEP details by the given record ID' endpoints for resource no longer available. Added ability to enable OGS for case creation and update operations. Created a new tag named 'upcoming' for upcoming features and changes, currently 'Search for Cases', 'Retrieves all search filters' and endpoints related to 'Reporting' are under this tag.

  • 2.58.0: Added 'DATE' tag under weblinks for Get a record by its ID endpoint. Updated 'cursorId' information for User activity monitoring endpoints.

  • 2.57.0: Added a new endpoint to retrieve the specific audit event details with the given 'auditEventId' belonging to the case identified by the given 'caseSystemId'. Added a new field to identify if a match is part of updated results either due to a case update or full re-screening.

  • 2.56.0: Updated information about escaping special characters in query expression for Get ongoing screening updates, Get a filtered list of AuditEvents for a Case by its 'caseSystemId' and User activity monitoring. Initial request endpoints. Several new fields are also added into Get a list of available providers and their sources endpoint. Updated information about a delay in retrieving aggregated summaries of Fetch Full Case endpoint.

  • 2.55.0: Added 'caseRating' in the response of User activity monitoring endpoints.

  • 2.54.0: Added a new endpoint to get information about the version of the Public API, a link to the documentation, and a date and time that can be used to verify the 'Date' header.

  • 2.53.0: A default period of 168 hours is introduced into Get a filtered list of AuditEvents for a Case by its 'caseSystemId' endpoint when no date is specified in the 'eventDate' property.

  • 2.52.0: Added SIC update date in the response of Get a record by its ID endpoint.

  • 2.51.0: Added 'lastScreeningDateByProviderType' in the screening response for Case management and audit. Added 'lastIndexDateByProviderType' in the screening response for Zero-Footprint which can now be used for Partial screening. New audit event entry when enabling/disabling Smart Filter on a case. 'mediaCheck' property added into responses of Fetch full case details, Partial case update, Synch rescreening, Delta rescreening. Added the capability of 'notes' entry into the following endpoints: Enable OGS for a Case, Disable OGS for a Case, Bulk Update OGS States, Partial update an existing Case, Update an existing Case, Create links between Cases, Delete Links between Cases, Bulk Update Case Links, Bulk Delete Cases, Assign the Case to a User, Bulk Update Case Assignments, Bulk Update Archive States.

  • 2.50.0: Screening with ID is now available for entity type 'Individual'. Added 'source' information in the endpoint for audit events.

  • 2.49.0: Added Rescreening functionality with full/delta capability and audit for it. Several new fields are also added into Partial update a case endpoint and Retrieve screening status for multiple cases endpoint.

  • 2.48.0: Added the capability of 'notes' entry into Bulk move cases across groups endpoint.

  • 2.47.0: Phase 1 for Screening with ID is released. Added 'lastScreenedDateByProviderType' in the response of Fetch Full Case endpoint. Several new fields are also added into Sync screening and Get screening results endpoints. The 'DELETE_CASE' audit entry is now exposed in the audit endpoint while the Activity Monitoring endpoint now supports 'creationDate'.

  • 2.46: Bulk Actions - Archive/Unarchive, Bulk Actions - Assign/Unassign, Bulk Actions – Delete, Bulk Actions - Move Cases between Groups, Bulk Actions - WC/MC OGS, Bulk Actions - Link/Unlink. Search cases. Gets all search filters available to the user. Quota Management for the number of screenings / hour.

  • 2.44: Partial update of an existing Case by its 'caseSystemId'. Partial Update endpoint without payload working as synchronous re-screening. OGS State in Sync Screening endpoint. Special Interest Categories retrieval. Quota management for number of cases.

  • 2.43: Retrieve smart filter on a case. Enable smart filter on a case. Disable smart filter on a case.

  • 2.42: Retrieve a World-Check record PEP details endpoint.

  • 2.41: Retrieve parent case summary. Retrieve the list of case relationships. Create links between cases. Delete links between cases. Save and screen multiple cases.

  • 2.3: New endpoints to link, unlink cases and retrieve the relationships between cases. New capabilities: enable/disable ongoing screening endpoint accepts optional request body with additional data, support for additional request query parameter in 'Monitor ongoing screening updates on cases' endpoint in order to retrieve updates by provider type, screening status endpoint is updated to return Media-Check screening information, aggregated summary for primary case.

  • 2.2: Media-Check new endpoints: retrieve risk definitions, attach/detach/retrieve articles to a case, mark all Media-Check news articles as reviewed for a case. Updated Retrieve Media Check results endpoint.

  • 2.1: Added endpoints for Passport Check MRZ generation feature.

  • 2.0: Updated getting screening results and synchronous screening to return additional information.

  • 2.0: Added endpoints for asynchronous screening of multiple cases.

  • 2.0: Media-Check early access: creation of cases with Media-Check profile, retrieval of Media-Check screening results, retrieval of Media-Check article content.

  • 1.6: Added user activity monitoring endpoints.

  • 1.5: Added Synchronous screening (including Zero-footprint) and entity purge functionality.

  • 1.4: Added Case (un)assign, (un)archive and delete functionality.

  • 1.3: Added Watchlist functionality.

  • 1.2: Added additional screening result category information as well as the ability to review and resolve results.

  • 1.1: General availability release. Added support for retrieving ongoing screening notifications.

  • 1.0: Early access release. Screening and audit functionality.