Web Service

The guide is intended to accompany other product guides such as the Worldview Web Services KYC Quick Start Guide.

Understanding Identity Verification & “Know Your Customer” (KYC)

Identity Verification and KYC via the Worldview Web Services API is designed to achieve 3 goals:

“Prove that you are who you say you are based on available authoritative data sources”
“Utilize the sources locally in a given market in adherence to privacy guidelines and regulations”
“Provide this proof utilizing data sources within the regulatory guidelines required by Compliance"

electronic Identity Verification (eIDV) achieves the first 2 goals – are you who you say you are, using in market data sources?

KYC builds on top of eIDV by verifying a combination of individual data elements - Name, Address, Dates of Birth, and National IDs, etc. against in-country data providers until a match is made which meets the specific regulatory rules as proscribed by Compliance & AML Directives.

Specific to KYC and based on Anti Money Laundering (AML) laws, regulations, and procedures the Worldview Compliance check is designed to meet regulatory requirements & directives aimed at preventing criminals from disguising illegally obtained funds and laundering money as legitimate income.

Identity Verification & “Know Your Customer” Inputs

The Worldview platform requires a minimum number of inputs when making an identity service call. The Identity Verification & KYC checks require at a minimum a set of primary input data elements about an individual. Primary data elements include:

Name (First, Last, Middle, or Full Name)
Date of Birth (formatted MM/DD/YYYY)
National ID (ex. Social Security Number - SSN)
Address (Address Line 1, locality, postal code etc.)
Phone
Email

In some countries/markets, there is not an established National ID Number, in which case that input element is considered optional. These primary input values are included in the Identity & Address section of the input payload for a Worldview API request.

Name Elements

"identity": {
 "completename": "",
 "givenfullname": "",
 "surname_first": "",
 "nationalid": "",
 "dob": ""
 }

Address Elements

"address": {
 "addressLine1": "",
 "addressLine2": "",
 "addressLine3": "",
 "houseNumber": "",
 "houseNumberAddition":"",
 "thoroughfare": "",
 "locality": "",
 "postalCode": "",
 "province": "",
 "countryCode": ""
 }

Secondary identity data elements for input include, but are not limited to:

Email Address
Phone Number
Localized ID Numbers - Driving License & VISA number as examples

Phone Elements

"phone": {
 "phone_number": "980659496"
 }

Email Elements

"email": {
 "full_email_address": ""
 }

Variable Message inputs

Some input data elements are variable depending on the country or market in which the business is being verified. For these data elements, input message elements are included for the request as a code/value pair defining the input code and its associated value. For example, input data elements that may only exist in a singular market – for example a consent flag in a market which allows electronic delegated consent for a source. Input messages allow for these classifications to be defined on the fly and passed to the Worldview API for inclusion in the verification or check.

Input Message Elements

"messages": [
      {
      "code": "CONSENT",
      "value": "YES"
      }
]

Reliability Codes

There are 2 types of reliability in the Worldview Service for individual identity: eIDV & Compliance KYC. Reliability Codes represent a scoring system designed to be easy to understand and implement/decision. The scores work similar to a stoplight with 3 primary classifications. The determination and definition of each classification (10|20|30) is dependent on the rule set and configuration for the tenant/customer. A Compliance KYC reliability 10 is not the same as an eIDV reliability 10.

"reliability": "10"
"reliability": "20"
"reliability": "30"

10	(Good/Correct/Pass)	Messages and match types indicate that this is a passing match combination based on the defined rule set.
20	(Probable/Possible)	Messages and match types are sufficient to consider this as a possible match/pass.
30	(Did not Pass/Doubtful)	There may or may not have been matched elements but it is doubtful this is sufficient information.

Identity Verification & Compliance Reliability Codes

A reliability score is returned for an identity result. The score is based on the complete, partial or non-match of identity elements passed upon input. The status messages returned identify the specific matches returned from the input provided. See section on Codes & Messages

The WV team recommends the customer analyze the messages for all return values for extra information. Below are 2 visuals representing and describing eIDV and Compliance Reliability definitions. The related rule sets - 1+1, 2+2, etc. are described in more detail later in this guide.

The eIDV use case is defined by default as a 1+1 configuration:

The Compliance/AML use case is defined by default as a 2+2 configuration:

Messages and Message Codes used in the response while making an Identity Verification request and determining Reliability are explained later in this guide.

Understanding Messages

The Worldview Platform is designed to make Electronic Identity Verification (eIDV) simple by providing Messages and Scores for ease of decisioning. These Messages are rolled up to form the basis for establishing the Reliability (10|20|30) of a Worldview Identity result.

To provide this validated scoring, the system requires a minimum of Complete Name, Zip Code and Country code to make a minimal Identity Verification check. Generally speaking, the more information that is provided with the request, the better the confidence in the match.

Additionally, it is best practice to provide additional inputs when making an Identity call such as DOB. Certain countries and data sources have mandatory, required fields that are necessary to successfully obtain a result from the service. The required input fields vary by country. In Argentina, China, Brazil and Mexico is best practice to provide a National Identifier. In the United States, it is best practice to provide State (Province).

You may contact your sales/account executive to know more about the best practices for the countries which you wish to activate.

Message Overview

The service runs identity checks based on this information and returns the input fields along with a series of Messages and Message Codes based on the Match/No Match/Partial Match/No Data Available verification of the submitted inputs.

There are 2 primary message types returned by Worldview.

- Autonomous Unit Messages (AU Messages)
- Match Type Messages (MT Messages)

These messages are returned from Worldview in a Code/Message Value construct and detail how input elements match against data sources. Messages are at the core of how Worldview defines and delivers reliability scores and other match scoring metrics.

Match Type Codes & Messages

Worldview generates messages at a per data source level called Match Type (or “MT” codes and messages). MT codes and messages are meant to provide the most granular level of detail for matching an individual input element to a specific match field in an underlying data source.

Match Types take the following format:

[1|3|4] MT-[Country Code]-[Data source Abbreviation]-[Match Code]

For example, a House Number element match in United States of America (US) that matched using the In-Country Postal Source (PST) would be:

{
 "code": "1MT-US-PST1-HOUSENUMBER",
 "value": "Full match was made on House Number/Street Number"
 }

Often multiples of the same type of data source are available in a specific country, therefore a number is appended to the Data Source Type (DST) abbreviation. [Example: 1MT-CH-TEL2-POSTALCODE]

Match Type Categories

1MT	Element fully matched with the data source.
3MT	Element partially matched with the data source.
4MT	Element is not contained in the data source.

Additional and custom MT Messages can be created that are provider and source specific as defined by our client’s business needs. MT messages are only surfaced when the option MessageVerbose is passed

Autonomous Unit Codes and Messages

AU (Autonomous Unit) messages provide an overall match rating on the input element provided spanning data providers and sources leveraged for scoring. The AU message is designed to be a roll-up across data sources based on the input elements. AU messages are surfaced based on the interconnection between the input elements and how they matched across the available sources. These messages provide detail on the overall match level of the input elements and are meant to be a compliment to the Match Type (MT) messages

Types of AU messages

The table below defines the different AU codes which can be returned by the service.

1AU	Indicates a complete match was made with the data source from the input element.
2AU	Indicates a non-match of the input element and the data source.
3AU	Indicates a partial match was made with the data source from the input element.

AU identity messages take the form of:

[1/2/3]AU-<Standard_Code>-<Data_Element>

A match made on LastName/Surname would take the form of:

{
 "code": "1AU-400-LASTNAME",
 "value": "Full match was made on Last Name/Surname"
}

An example subset response message could include:

{
 "code": "1AU-400-LASTNAME",
 "value": "Full match was made on Last Name/Surname"
 },
{
 "code": "1AU-275-POSTALCODE",
 "value": "Full match was made on Postal Code/Zip Code"
 }

AU Message Generation

By default, surname level matching across multiple data sources is used to generate AU messages. However, these rules can be customized to fit specific customer use cases. Common options for customization include requiring an element of locality, date of birth, or given full name to match, along with a surname match. Some of these rules are illustrated in the following examples:

Example 1 - Default

Message Output: 1AU for Name and Address

Example 2 - Surname + Locality

Message Output: 1AU for Name and Address

Example 3 - First Initial + Surname + Locality

Message Output: 1AU for Name and Address

Name and Address Matching

The Worldview platform provides classifications of “FULL” (1MT) or “PARTIAL” (3MT) matches with the current release of the API. It also provides a (4MT) for elements not contained in the source which is tuned per country/provider.

A FULL match (1MT) can be of three types:

Exact is a precise match to the input provided.
Fuzzy is either a character distance/Levenshtein or contains match. The default distance is 70% of the characters.
Localized is taking advantage of match logic that is specific to the data provider (DP) and thus is be better tuned for concerns like localization, language and alphabet.

Data Source Codes Classification

There are 9 currently supported Data Source codes listed below. These codes give details related to what sources were matched against in MT messages and allow for 2 + 2 identity verification.

Data Source Abbreviation	Data Source Type
CRD	Credit
GVT	Government
CMM	Commercial
CNS	Consumer
UTL	Utility
PRP	Proprietary
TEL	Telco
PST	Postal

Data Sources for Best Available providers

Data Sources for Best Available providers can be found in a separate document that is provided based on your specific requirements and use cases in detail. You can find some information on our active coverage page as well.

Please contact your sales/account executive or reach out to us at help@globaldataconsortium.com for more details on coverage.

Identity Verification & Compliance Configuration

There are two basic configurations which get deployed in the Worldview platform: 1+1 or 2+2. Each of these configuration options utilizes Data Providers singularly or in combination. Identity verification is traditionally a 1+1 check while Compliance regulations and Guidelines typically require the strict 2+2 configuration deployment.

All of these described configuration/process flows which can be deployed to meet eIDV 1+1, Watchlist, and 2+2 use case requirements. From here let’s talk about some of these use case models.

Identity Verification Use Case Models

Electronic Identity Verification (eIDV) - (1+1)

Electronic identity verification (eIDV) is the use of information in various types of data sources to quickly confirm whether an individual is who they claim to be based on personal information such as their name, date of birth, national id number, and address. The result of trying to confirm an individual’s identity could be a match, nonmatch, or partial match.

AU, MT as well as the reliability score can be used to determine if eIDV requirements are met.

When a 1+1 match is achieved with the input provided a specific MT message may be generated in the results:

{
 "code": "1MT-US-MATCHED-1+1",
 "value": "Full Match for 1+1 verification"
 }

Compliance Verification & AML Check (2+2)

The second type of identity verification is 2+2 verification, which is an extension of the standard IDV 1+1. This is used when customers require a verification that the same data elements are matched against 2 or more (2+2) different data sources.

Our Standard 2+2 configuration is designed to give a match when the following conditions are met. However, we also have additional configurations which may be more suited to your specific use cases and we encourage you to discuss those requirements during your onboarding process.

	Source 1	Source 2
Condition 1	A match on First initial, Last Name and Address	A match on First Initial, Last Name and Address
Condition 2	A match on First initial, Last Name and Address	A match on First initial, Last Name and Date of Birth

Address Match Case Scenarios:

For cases where address elements are matched, we provide an MT message to show that.

{
 "code": "1MT-GB-TEL2-ADDRESS",
 "value": "Full match was made on address elements provided in Address Lines"
},

For both 1+1 and 2+2 verifications, an address is said to be a match when one of the following conditions is met.

Match on House Number + City

Match on Street + City

Match on Building + City

Match on District + City

Match on House Number + Postal Code

Match on Street + Postal Code

Match on Building + Postal Code

Match on District + Postal Code

To identify if 2+2 verification requirements are met examine the Match Type Codes and Messages returned.

For example, if the following set of messages are returned in the result

 {
 "code": "1MT-GB-PST1-COMPLETENAME",
 "value": "Full match was made on Complete Name"
 },
 {
 "code": "1MT-GB-PST1-FIRSTINITIAL",
 "value": "Full match was made on First Initial"
 },
 {
 "code": "1MT-GB-PST1-FIRSTNAME",
 "value": "Full match was made on First Name/Given Name"
 },
 {
 "code": "1MT-GB-PST1-LASTNAME",
 "value": "Full match was made on Last Name/Surname "
 },
 {
 "code": "1MT-GB-PST1-ADDRESS",
 "value": "Full match was made on address elements provided in Address Lines"
 },
 {
 "code": "1MT-GB-PST1-HOUSENUMBER",
 "value": "Full match was made on House Number/Street Number"
 },
 {
 "code": "1MT-GB-PST1-THOROUGHFARE",
 "value": "Full match was made on Street/Thoroughfare"
 },
 {
 "code": "1MT-GB-PST1-LOCALITY",
 "value": "Full match was made on City/Locality"
 },
 {
 "code": "1MT-GB-PST1-POSTALCODE",
 "value": "Full match was made on Postal Code/Zip Code"
 },
 {
 "code": "1MT-GB-PST1-DATEOFBIRTH",
 "value": "Full match was made on Date of Birth"
 },
 {
 "code": "1MT-GB-PST1-DAYOFBIRTH",
 "value": "Full match was made on Day of Birth"
 },
 {
 "code": "1MT-GB-PST1-MONTHOFBIRTH",
 "value": "Full match was made on Month of Birth"
 },
 {
 "code": "1MT-GB-PST1-YEAROFBIRTH",
 "value": "Full match was made on Year of Birth"
 },
 {
 "code": "1MT-GB-TEL2-COMPLETENAME",
 "value": "Full match was made on Complete Name"
 },
 {
 "code": "1MT-GB-TEL2-FIRSTINITIAL",
 "value": "Full match was made on First Initial"
 },
 {
 "code": "1MT-GB-TEL2-FIRSTNAME",
 "value": "Full match was made on First Name/Given Name"
 },
 {
 "code": "1MT-GB-TEL2-LASTNAME",
 "value": "Full match was made on Last Name/Surname "
 },
 {
 "code": "1MT-GB-TEL2-ADDRESS",
 "value": "Full match was made on address elements provided in Address Lines"
 },
 {
 "code": "1MT-GB-TEL2-HOUSENUMBER",
 "value": "Full match was made on House Number/Street Number"
 },
 {
 "code": "1MT-GB-TEL2-THOROUGHFARE",
 "value": "Full match was made on Street/Thoroughfare"
 },
 {
 "code": "1MT-GB-TEL2-LOCALITY",
 "value": "Full match was made on City/Locality"
 },
 {
 "code": "1MT-GB-TEL2-POSTALCODE",
 "value": "Full match was made on Postal Code/Zip Code"
 },
 {
 "code": "1MT-GB-TEL2-DATEOFBIRTH",
 "value": "Full match was made on Date of Birth"
 },
 {
 "code": "1MT-GB-TEL2-DAYOFBIRTH",
 "value": "Full match was made on Day of Birth"
 },
 {
 "code": "1MT-GB-TEL2-MONTHOFBIRTH",
 "value": "Full match was made on Month of Birth"
 },
 {
 "code": "1MT-GB-TEL2-YEAROFBIRTH",
 "value": "Full match was made on Year of Birth"
 }

This indicates that the requirements for 2+2 verification have been met for Name, Address, Locality, Postal Code and Date of Birth Elements because EACH has been verified by two distinct data sources – TEL (Telco) and PST (Postal). When a 2+2 match is achieved with the input provided a specific MT message may be generated in the results:

{
 "code": "1MT-GB-MATCHED-2+2",
 "value": "Full Match for 2+2 verification"
 }

As you might notice, the message for an address match states that the address elements have matched but it shows that the minimum requirements have been met for an address match.

Match Codes

Match codes are a great way of understanding in a brief message about what key elements matched. They appear in the response body like this.

{
 "code": "MatchCodes",
 "value": "PST1-NAD:TEL2-NAD:GVT3-NAD"
 }

This is usually in the format {Data Source Type and Order}-{Elements Matched} repeated to the times we found a match in different data sources. The table below gives description of the different symbols which can be found in match codes.

Element Symbol	Element
I	First Initial Match
S	Surname Match
F	First name Match
N	Name Match
A	Address match
D	Date of birth Match
T	Telephone Match
X	National ID Match

Utilizing Identity Options

The WV Platform allows per record directives or options which explicitly dictate a feature or service to be applied to the results of the initial validation/verification. These options are powerful because they give the calling application exact control over the record(s) on which a particular extended service may be applied.

For the current release, below is a list of parameters which can be applied as option(s). These parameters are passed as a semicolon delimited string of values – example “MessageVerbose;IdentityVerify.” Please note that though the options are listed here in explicit case the options values are not actually case sensitive.

Options

This guide includes options that are included in most initial Worldview configurations. While these options can be changed within a transaction, you may wish to switch 'ON' some of these options for your tenants by default. To activate that or to discuss any additional business use cases which might be deployed through an option please reach out to your sales/account executive or reach out to us at help@globaldataconsortium.com.

Identity Options
Option Parameter	Definition
IdentityVerify	For those countries that support this feature the service will attempt to verify the identity with the best match using all provided input data. Note that when running this option, the input data may be corrected in the data quality step and this may affect identity results.
MessageVerbose	Using this option in combination with Business or Identity verification options will provide all messages returned with a processed result rather than what is configured as the default, or filter messages based on the input. The default configuration is to show only the elements that matched upon input
debug	The debug option is critical to understand and leverage as you are verifying the Worldview integration. Debug instructs the service to persist and log the resulting transaction detail for 7 days. The detail is indexed by the transaction id, or detailcode returned with the request. As you are tuning and improving your integration you may activate debug and provide GDC support with the detailcode of a transaction in order to better troubleshoot and answer questions.

Understanding the Detail Code (WSID)

"detailCode": "WS-9664570.2021.5.19.0.30.7.287"

Every inquiry on the Worldview service returns a unique detail code. The detail code is the unique transaction identifier for the request and response to & from the Worldview service. This detail code is critical to be logged by customers and partners as it allows for troubleshooting and an audit trail with the WV support team. NOTE: GDC does not store PII so this transaction ID / detailCode is the first and best way to troubleshoot integration and verification result questions with the GDC team. The detail code is important for customers to utilize if there are questions about a specific record or the need to audit records. The customer should provide the detailCode (or WSID) to the support team along with the original input, whenever possible.

Programming Languages

Please refer to the Quick Start Guide for examples and information which you might find helpful. In case, you still need information on any issue, please contact us at help@globaldataconsortium.com.

Web Service

Understanding Identity Verification & “Know Your Customer” (KYC)

Identity Verification & “Know Your Customer” Inputs

Variable Message inputs

Reliability Codes

Identity Verification & Compliance Reliability Codes

Understanding Messages

Message Overview

Match Type Codes & Messages

Match Type Categories

Autonomous Unit Codes and Messages

Types of AU messages

AU Message Generation

Example 1 - Default

Example 2 - Surname + Locality

Example 3 - First Initial + Surname + Locality

Name and Address Matching

Data Source Codes Classification

Data Sources for Best Available providers

Identity Verification & Compliance Configuration

Identity Verification Use Case Models

Match Codes

Utilizing Identity Options

Options

Understanding the Detail Code (WSID)

Programming Languages

Related articles