Overview

The Address Verification service offered enables reliable international address verification as part of the KYC process. This service covers 53 countries and leverages trusted in-country data sources, such as government agencies, credit bureaus, and utility companies. By directly accessing these sources, the system ensures that verification results are accurate and up-to-date.

Check Type ID: 1

This is the check type used for Address Verification. It validates the individual’s address against trusted data sources, such as government registries and utility records.

Required Profile Information

To perform Address Verification, the following fields are required in the profile section of the request:

• Personal Details:

  • firstName (Required): The first name of the individual.

  • lastName (Required): The last name of the individual.

See for more information on structuring a request.

How it works

1. Data Sources: Verification utilizes regulatory-quality data sources, including government registries, voter databases, and utility records. Mobile and marketing data sources are not used to ensure compliance with regulatory standards.

2. Match Process: Verify matches the provided address details with available data sources. A positive match confirms residency at the stated address.

3. Data Protection: Personal data is shared temporarily with data providers for matching purposes. Strict legal agreements ensure GDPR compliance and limit data usage.

International residential address verification uses a number of data providers with access to regional data source providers within the supported countries. Verify by Tiller uses data sources direct from government agencies, credit agencies, utility companies and landline telecommunication providers. Mobile telecommunication providers, marketing lists or other sources which do not meet regulatory standards are not used.

When verifying the address, Verify determines which in-country data sources are available and most likely to be able to obtain a match and get the provider to confirm if the credentials provided match their records. By matching directly to the original data source provider, we ensure the data is as up to date as possible. The number and degree of match is then used to confirm if the individual is a resident at their stated address.

Address sources

Tiller partners with a number of carefully selected agents who have access to specific in-country regulatory-quality data sources. Tiller’s Verify application will use one or more of the following data source types to verify the residential address of an individual:

• Credit Agency Databases,

• Government Databases (e.g., Voter, Social Security, Population/Citizenship Registries)

• Utility Company Databases (e.g., Electricity, Water, Gas, Telephone (excluding Mobile)).

Most regulators make provision for the address to be verified against such data sources and Verifications includes which data source types were used in the verification results it provides back via its API.

It is necessary to support residential address checks to temporarily share name and address PII information with a data source provider for the match check to be performed. Tillers legal agreements with our providers strictly restricts the use and retention of the PII information shared. PII data is only permitted to be used for the purposes of confirming a name and address match and may not be retained or used for any other purposes. The providers are also contractually required to adhere to all provisions of GDPR.

Tillers systems and data are hosted within the EU/EEA, however, where an individual being checked is resident outside the EU it is necessary for Tiller to share that individuals PII data with the data source providers in that individual’s country of residence. Tillers legal agreements with our providers include the modernised 2021 EU SCC (Standard Contractual Clauses) that have been “pre-approved” by the European Commission, ensuring appropriate data protection safeguards covering international transfers of PII data.

The above data handling & verification model is that same as that used by our larger enterprise customers such has HSBC, who received a confirmation of ‘no objection’ from the JSFC (Jersey Financial Services Commission) when they submitted their outsourcing request to use Tillers services to them.

Welcome to the Tiller Verifications API

The Tiller Verifications API powers KYC and CDD processes, enabling platforms to perform checks on individuals with precision and efficiency. This API also forms the backbone of our solution, helping businesses meet regulatory requirements while streamlining compliance workflows.

Overview

The Ongoing Monitoring API allows you to manage and retrieve updates for continuous background checks. When ongoing monitoring is enabled during a verification request (enableOngoingMonitoring: true), the system monitors the individual on a daily basis to identify new PEP & Sanctions, Adverse Media, or Watchlist events. Alerts are sent to the subscribed return URL whenever there is a status change, and results can be retrieved using the relevant endpoints.

Changelog and Versioning

The Verifications API is continuously evolving, with new features and updates being added to enhance functionality. This section provides information about our versioning policy and a changelog that details the historical and recent changes to the API.

The Tiller Verifications API is divided into three main components: Authentication, Verifications, and Ongoing Monitoring.

Authentication

Before using the API, clients must authenticate their requests. The authentication service ensures that all interactions with the API are authorized and secure.

Verificatons

The Verifications component is the heart of the API, enabling businesses to perform a variety of checks. These include Address Verification, Background Checks (PEP & Sanctions, Watchlist, and Adverse Media), and UK Bank Account Checks.

Ongoing Monitoring

Ongoing Monitoring enhances Background Checks by providing continuous updates on an individual’s PEP, sanctions, or adverse media status. This ensures businesses are alerted to compliance risks as soon as they arise.

How It Works

1. Authenticate: Begin by authenticating your API client and obtaining a bearer token. This token is required for all subsequent API calls.

2. Submit a Verification Request: Use the Verifications API to perform compliance checks on an individual. Configure checks and provide the necessary profile details.

3. Enable Monitoring (Optional): For continuous monitoring of PEP & Sanctions or Adverse Media, include enableOngoingMonitoring: true in your verification request.

This API overview serves as your starting point for integrating the Tiller Verifications API into your workflows. For detailed technical documentation and examples, explore the linked sections or contact our support team at [email protected].

The Verifications API can a variety of checks for customer verification purposes. This section outlines the available check types, the required request structure, and the specific profile details needed for each type of check.

For more details on building a request please see Request Structure.

Making a Verifications Request

Endpoint:

POST /api/v1/verifications

Description: This endpoint is used to initiate a verification request. It processes and returns the results of the specified checks.

Key Features:

• Supports synchronous (runAsync: false) and asynchronous (runAsync: true) processing.

• When runAsync is false, the response includes the verification results.

Usage: This endpoint allows users to perform one or more checks (e.g., Address Verification, Bankground Checks, Bank Account Check) in a single request. Ensure that the required information is provided for each check type. For more detail on building a request please see .

Retrieving Check Results

Endpoint:

GET /api/v1/verifications/{correlationId}

Description: Used to retrieve the results of a previously submitted verification request. This endpoint is primarily used when runAsync: true was specified in the initial request. But can be used when runAsync: false as well.

Key Features:

• Can be polled to check the status of the verification process.

• Returns the detailed results of each check once available.

Parameters:

• correlationId (path): The unique identifier returned when the initial verification request was submitted.

References

Endpoint: GET /api/v1/verifications/references

Description: This endpoint provides reference data required for verifications. It includes details such as valid check types, status codes, titles, genders, and country codes.

Key Features:

• Useful for retrieving a list of valid codes and identifiers required when making a verification request.

• Helps to ensure requests are formatted correctly with the proper values.

This quick start guide will help you set up and execute your first verification request in just a few steps.

Step 1: Get Your API Credentials

To use the Tiller Verifications API, you'll need some credentials. This is essential for authenticating your requests and ensuring secure access to the system. Here’s how to get started:

• Contact your Tiller account manager to request your API credentials. -

  • [email protected].

• Safeguard your credentials; it is required for authorization. Treat it like a password—never share it or expose it publicly.

Step 2: Set Up Authentication

The Tiller Verifications API uses token-based authentication via the OAuth 2.0 protocol. You’ll need to obtain an access token to authenticate your requests. Here’s how to do it:

Authentication Endpoint

Parameters Required

• grant_type: Always set to client_credentials.

• scope: Use VerificationsAPI as the scope.

Example request:

Example response:

Include the retrieved access token in the Authorization header of all subsequent API requests:

Please see for more information.

Step 3: Make Your First Request

This step walks you through performing an Address Verification Check using the Tiller Verifications API. Below, we explain the required payload, headers, and the structure of the request.

Endpoint:

Headers Required

Payload structure

We need some basic information in the request to be able to perform the check. The request is broken down into the following elements:

• externalReferenceId - Your reference for this request.

• options - These parameters change the behaviour of the request. Keep to the default values in the example payload below.

  • runAsync - determines whether the verification request is processed synchronously (returns results immediately) or asynchronously (returns a correlation ID to retrieve results later).

Example payload:

Making your first request:

Error Handling

What error codes are there and how to handle errors.

Success and Error codes

Each API request will return a response. A successful request will typically return a 200 OK status code along with any requested data. Errors or issues with your request will return different status codes (e.g., 400 Bad Request, 401 Unauthorized) and an error message explaining what went wrong.

Success Codes

Comment

Error codes

Error Message Standard

Error handling for all API methods must adhere to the RFC7807 standard, ensuring standardized and informative error responses for clients. Please see . Please see below of a standard example.

Example:

The Tiller Verifications API uses token-based authentication via the OAuth 2.0 protocol. To ensure secure communication and protect sensitive data, every request to the API requires a valid access token in the Authorization header.

Prerequisities

To use the Tiller Verifications API, you'll need some credentials. This is essential for authenticating your requests and ensuring secure access to the system. Here’s how to get started:

Overview

The UK Bank Account Check is a specialised service designed to verify the ownership of a UK bank account by an individual. This verification process ensures that the bank account details provided by a customer match their personal information, enabling businesses to confirm account authenticity and ownership with high confidence.

Check Type ID: 3

This is the check type used to validate the ownership of a UK bank account. It ensures the provided bank account details match the personal information of the account holder.

Overview

Background Checks currently include PEP (Politically Exposed Persons) & Sanctions, Watchlist, and Adverse Media Screening. These services help businesses assess compliance risks and identify individuals involved in activities that may pose financial or reputational risks.

Components

• PEP & Sanctions Screening:

  • Uses daily updated databases of PEPs and sanctioned individuals.

  • Sources include HM Treasury, UN Security Council Committees, OFAC, and other government and international agencies.

Check Type ID: 2

This is the check type used for Background Check, which includes PEP & Sanctions, Watchlists, and Adverse Media screening. It helps identify individuals who pose financial, legal, or reputational risks.

Required Profile Information

To perform Background Checks, the following fields are required in the profile section of the request:

• Personal Details:

  • firstName (Required): The first name of the individual.

  • lastName (Required): The last name of the individual.

See for more information on structuring a request.

PEP & Sanctions / Watchlist Screening

PEP and Sanction screening uses an external data provider. They maintain a correlation database of PEP Tier 1, 2, 3 & PEP by association OECD categorises lists which are updated daily from various sources, such as official government websites or national assemblies of foreign offices, CIA World leaders lists, open source verified repositories and selected media websites.

For Sanction screening, the database is collated and updated daily from the following sources: UK HM Treasury, US Department of the Treasury - Office of Foreign Assets Control (OFAC), US Department of State - Bureau of International Security & Non-Proliferation Sanctions, UN Security Council Committees, EU Sanction records, US Defence Trade Controls and other international government and local authority resources.

Sanctions Sources

Please see below a list of sanctions sources that the individuals is checked

PEP Sources and Types

The individual is checked against various global sources to assess whether they are potentially a politically exposed person. Each PEP type helps categorise the type of PEP (e.g. HOS - Head of State).

PEPs are categorised into tiers of risk. With Tier 1 being the highest potential risk, including heads of state and high ranking government positions.

PEPs by Association

Family members and personal and business associates of PEPs, typically individuals who are not PEPs in their own capacity but serve on a board of directors alongside PEPs. Based on FATF, Close Associates are considered to be: (known) (sexual) partners outside the family unit (e.g., girlfriends, boyfriends, mistresses); prominent members of the same political party, civil organisation, labour, or employee union as the PEP; business partners or associates, especially those that share (beneficial) ownership of legal entities with the PEP, or who are otherwise connected (e.g., through joint membership of a company board). In the case of personal relationships, the social, economic, and cultural context may also play a role in determining how close those relationships generally are (FATF Guidelines, 2013).

Should the individual have a potential match within the PEP & Sanctions sources they will be flagged up for review.

Adverse Media

The Adverse Media check offers a comprehensive screening against negative media sources to ascertain any potential risks associated with an individual. This feature conducts daily scans across a vast array of media outlets, including newspapers, magazines, TV/radio transcripts, and more, encompassing over 120,000 sources. With a formidable database established from screening over 2.5 billion media articles, it boasts an extensive collection of negative news, encompassing individuals ranging from terrorists and fraudsters to criminals and influencers.

The core of this feature lies in its ability to categorise Adverse Media Events based on their Risk Stage and Risk Type. The Risk Stage determines where an event is in its lifecycle, while the Risk Type provides insights into the nature of the event, such as abuse, arson, fraud, cybercrime, and more. These classifications work in tandem to decide if a particular Adverse Media Event should be included in the results, ensuring a thorough and precise assessment for every individual screened.

Adverse Media Stages

The Risk Stage describes where in its lifecycle an Adverse Media Event is. Risk Stages are used in conjunction with Risk Types to determine if the Adverse Media Event is to be included in the results.

Risk types

The Risk Type describes the nature of the Adverse Media Event. Risk Types are used in conjunction with Risk Stage to determine if the Adverse Media Event is to be included in the results.

These include

• 🔴Critical - Risk Stages 1, 2, 3 & 4

• 🟠Valuable - Risk Stages 2, 3 & 4

• 🟡Investigate - Risk Stages 3 & 4

Should the individual have a potential match within adverse media sources they will be flagged up for review.

This guide details all the parameters required for a request to the Tiller Verifications API. The parameters are grouped into four sections: External Reference, Options, Checks, and Profile.

Introduction to the Request Structure

The Tiller Verifications API uses a well-defined request structure to ensure that all the required information is included to perform verification checks effectively. Each request is composed of several key sections. Understanding these sections is essential for building robust integrations and achieving reliable results.

The request is divided into the following components:

1. : This provides a unique identifier for tracking your request. It acts as a client-generated reference to link API responses to specific operations in your system.

2. : This section configures the behaviour of the request. Options such as asynchronous or synchronous processing and mock mode for testing.

3. : This is the core of the verification request. It specifies what checks need to be performed. Multiple check types can be included in a single request, provided the necessary information for each check is supplied.

External Reference

The externalReferenceId parameter is used to uniquely identify a request.

Example:

Options

The options parameter defines how the request is processed.

Example:

Checks

The checks array contains details about the verification checks to perform.

Available Check Types

The following checks are currently supported by the Verifications API:

1. Address Verification Verifies the subject’s address against trusted data sources.

2. Background Checks Performs PEP (Politically Exposed Persons) & Sanctions screening and Adverse Media checks.

3. UK Bank Account Check Verifies the subject's ownership of a UK bank account.

You can request one or more of these services in a single verifications request.

Check Type Fields

checkTypeId: Identifies the type of verification being performed.

• 1 = Address Verification

• 2 = Screening (PEP & Sanctions/Adverse Media)

• 3 = UK Bank Account Check

externalCheckReferenceId: A unique client-provided identifier for the check, useful for tracking.

maximumSources: Specifies the maximum number of sources to query for the check. The default value is 3 for most checks.

CheckMethod: Determines how the check is performed.

• 1 = Sequentially (default)

• 2 = In parallel

matchesRequired: Specifies the minimum number of matches required for the check to pass. The default value is 1.

Example - one check in request:

Example - multiple checks in request:

Profile

The profile contains personal, address and bank details for the individual being verified.

Profile Requirements by Check Type

The table below outlines the specific profile fields required for each check type supported by the Tiller Verifications API. Each column specifies whether the field is required, optional, or not applicable (N/A) for the respective check type.

• titleId: Optional, but useful for added clarity, especially in Screening checks, but optional for all check types.

• firstName / lastName: The subject's first and last names are required across all check types to identify the individual.

• middleName: Including the middle name can enhance the accuracy of checks but is optional for all check types.

Profile parameters

Current Address

The currentAddress parameter provides the individual's current residence details.

Structured address fields

Example:

Unstructured Address

If you are unable to map a client’s address to the structured format, you can provide an unstructured address in the request.

Example

Bank Details

The bankDetails object in the profile section is required for performing a UK Bank Account Check (CheckTypeId: 3). It contains the necessary information to validate the ownership of a UK bank account against an individual.

Bank Account Fields

Example:

Key Best Practices

1. Accuracy and Completeness: Always include all required fields for the checks you are performing to maximize the chances of successful verification.

2. Structured Data: Use structured addresses and complete profile details wherever possible to achieve higher match rates.

3. Traceability: Leverage unique identifiers such as externalReferenceId and externalCheckReferenceId

By following these guidelines, you can build robust integrations with the Tiller Verifications API, enabling efficient, secure, and accurate compliance and verification processes. If you need further assistance or guidance, please contact [email protected].