Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The Tiller Verifications API is divided into three main components: Authentication, Verifications, and Ongoing Monitoring.
Before using the API, clients must authenticate their requests. The authentication service ensures that all interactions with the API are authorized and secure.
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 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.
Authenticate: Begin by authenticating your API client and obtaining a bearer token. This token is required for all subsequent API calls.
Submit a Verification Request: Use the Verifications API to perform compliance checks on an individual. Configure checks and provide the necessary profile details.
Enable Monitoring (Optional): For continuous monitoring of PEP & Sanctions or Adverse Media, include enableOngoingMonitoring: true in your verification request.
Retrieve Results: Access results directly from the response (synchronous) or poll using the correlation ID (asynchronous).
Manage Monitoring Subscriptions: Use the Ongoing Monitoring endpoints to subscribe to notifications, retrieve results, or unsubscribe when no longer needed.
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 support@tillertech.com.
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.
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.
When runAsync is true, a correlationId is returned, which must be used to fetch the results via the GET /api/v1/verifications/{correlationId} endpoint.
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 Request Structure.
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.
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.
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.
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. -
info@tillertech.com.
Safeguard your credentials; it is required for authorization. Treat it like a password—never share it or expose it publicly.
To authenticate your requests, you need to retrieve an access token by sending a POST request to the authentication /connect/token endpoint. The request should include the following form data:
grant_type
Yes
Specifies the OAuth 2.0 grant type. Use client_credentials.
client_id
Yes
Your client unique identifier provided by Tiller.
client_secret
Yes
Your secret key provided by Tiller.
scope
Yes
Use VerificationsAPI as the scope.
To use the access token with the Verifications service, include it in the Authorization header of your HTTP requests.
Token Renewal: Monitor the token’s expiry and implement logic to request a new one before making further API calls.
Secure Transmission: Always use HTTPS to prevent interception of the access token during transmission.
Scope Management: Use minimal scopes necessary for each request to enhance security.
By including the access token in your requests, you gain secure and authenticated access to the Verifications service, protecting sensitive information.
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.
Endpoint:
GET /api/v1/ongoingmonitoring/{correlationId}
Description:
Retrieves the verification statuses and results for a specific ongoing monitoring record using the correlationId provided during the initial verification request.
Path parameters:
correlationId (string, required): The unique ID associated with the monitoring request.
Query Parameters:
fromDate (date-time, optional): Filter results starting from this date.
toDate (date-time, optional): Filter results up to this date.
Endpoint:
POST /api/v1/ongoingmonitoring/subscribe
Description:
Subscribes to the ongoing monitoring service by registering a return URL and API key. This URL will receive webhook notifications for updates in monitored results.
Endpoint:
POST /api/v1/ongoingmonitoring/unsubscribe
Description:
Unsubscribes the provided return URL from ongoing monitoring. After unsubscribing, you will no longer receive updates for monitored profiles.
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.
Required Profile Information
To perform a UK Bank Account Check, 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.
dateOfBirth (Required): Validates the individual against the bank’s internal records.
Bank Account Details:
bankDetails.accountNumber (Required): The 8-digit bank account number.
bankDetails.sortCode (Required): The 6-digit bank sort code in the format XXXXXX.
bankDetails.openedDate (Optional): The date the account was opened, for additional accuracy.
Customer Data Submission:
The customer provides their personal details (e.g., first name, last name, and date of birth) and bank account information (account number and sort code).
This data is included in the profile section of the verification request payload.
Data Matching:
The provided account details are matched against the bank’s internal records, ensuring that the account is registered to the named individual.
This process confirms that the customer owns the supplied bank account.
Validation Process:
The service validates the format and accuracy of the sort code and account number.
If the bank account exists and matches the individual’s personal details, the check returns a "Pass" result.
In cases of mismatched or incomplete data, the check provides specific failure details.
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.
dateOfBirth (Optional): Improves match accuracy when included.
Address Details:
currentAddress.structured (Preferred): A structured address format that includes:
flatApartmentSubBuilding (Optional)
BuildingNumber (Optional)
BuildingName (Optional)
RoadStreet (Optional)
townCity (Optional)
postZipCode (Required)
countryCode (Required): Must be a valid ISO 3166-1 alpha-2 code.
currentAddress.unstructured (Fallback): If structured data is unavailable, unstructured data can be provided, though this decreases match accuracy.
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.
Match Process: Verify matches the provided address details with available data sources. A positive match confirms residency at the stated address.
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.
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.
This quick start guide will help you set up and execute your first verification request in just a few steps.
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. -
info@tillertech.com.
Safeguard your credentials; it is required for authorization. Treat it like a password—never share it or expose it publicly.
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.
client_id: Your client ID, provided by Tiller.
client_secret: Your client secret, provided by Tiller.
Example request:
Example response:
Include the retrieved access token in the Authorization header of all subsequent API requests:
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).
mock - We return mock data for testing purposes if True
checks - This controls which checks will be performed in this request and includes some parameters around how the check will be performed. Keep to the default values in the example payload below for address check.
profile - The personal information about the individual you are making a request about.
Example payload:
Making your first request:
See for more information on structuring a request.
See for more information on structuring a request.
Please see for more information.
Authorization
Bearer YOUR_ACCESS_TOKEN (Replace YOUR_ACCESS_TOKEN with your valid token)
Content-Type
application/json
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.
Our API versioning is designed to ensure backward compatibility and minimise disruptions to your integration.
Version Format: We use a simple versioning, vX, where X is the major version.
Major Versions: Changes in the major version indicate significant updates that may not be backwards compatible. These changes could include modifications to existing endpoint functionality or removing endpoints. This will alter the API base URL.
Minor Changes: Minor version updates involve backward-compatible additions or enhancements, such as adding or extending new endpoints. These will not change the base URL.
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.
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.
Identifies close associates of PEPs as part of the screening.
Watchlist Checks:
Screen individuals against global watchlists maintained by international organisations.
Adverse Media Screening:
Conducts extensive scans across 120,000+ media sources.
Categorises media events by risk type (e.g., fraud, abuse) and lifecycle stage.
Detects potential risks linked to individuals or entities.
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.
dateOfBirth (Required): Critical for accurate screening results.
middleName (Optional): Improves the accuracy of matches.
titleId (Optional): Helps differentiate individuals with similar names.
Additional Information:
nationalityCountryCode (Optional): Enhances accuracy by considering the individual’s nationality.
placeOfBirthTownCity (Optional): Provides additional context to improve match quality.
See Request Structure for more information on structuring a request.
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.
Please see below a list of sanctions sources that the individuals is checked
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.
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.
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.
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.
Accuse
Arraign
Appeal
Acquit / Not Guilty
Allege
Arrest
Confession
Disciplinary
Conspire
Audit
Plea
Regulatory Action
Probe
Charged
Settlement or Suit
Arbitration
Suspected
Complaint Filed
Trial
Associated
Indict
Censure
Lien
Convict
Seizure
Deported
Dismissed
Expelled
Fine (<$10K, >$10K)
Govt Official
Revoked Registration
Sanction
Served Jail Time
Suspended
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
Should the individual have a potential match within adverse media sources they will be flagged up for review.
Critical - Risk Stages 1, 2, 3 & 4
Valuable - Risk Stages 2, 3 & 4
Investigate - Risk Stages 3 & 4
Probative - Risk Stages 4
Obtain an authentication token using client credentials.
client_credentials{{scope}}{{client_id}}{{client_secret}}Verification check request DTO
External reference ID
The Tiller Verifications API is a flexible, secure solution tailored to the complexities of modern compliance needs. Whether integrating it directly into your systems or using it as part of the Verify platform, this API empowers your business to:
The Tiller Verifications API is designed with developers in mind, offering:
RESTful Design: Simplify integration with predictable, resource-based URLs.
Customisable Workflows: Tailor verification processes to fit your specific business needs.
Scalable Infrastructure: Handle verifications for businesses of all sizes, from start-ups to large enterprises.
Real-Time Updates: Stay informed with webhook notifications for screening events.
Comprehensive Security: Ensure data privacy and integrity with encryption and strict authentication protocols.
Get started today with our Quick Start Guide. Learn how to:
Sign up for an API credentials.
Authenticate your requests.
Perform your first Address Verification check.
Dive a little deeper and start exploring our API reference to get an idea of everything that's possible with the API:
What error codes are there and how to handle errors.
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.
Comment
Code
Description
200
OK - The request has succeeded.
201
Created - The request has been fulfilled and has resulted in one or more new resources being created.
202
Accepted - The request has been accepted for processing, but the processing has not been completed.
204
No Content - The server successfully processed the request, but is not returning any content.
303
Redirect - Provides redirections to another resource.
Code
Description
400
Bad Request - The server cannot process the request due to a client error (e.g., malformed request syntax).
401
Unauthorised - The request lacks valid authentication credentials for the target resource.
404
Not Found - The server can't find the requested resource.
408
Request timeout
500
Internal Server Error - The server encountered an unexpected condition that prevented it from fulfilling the request.
502
Bad gateway
504
Gateway timeout
Example:
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.
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:
External Reference: 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.
Options: This section configures the behaviour of the request. Options such as asynchronous or synchronous processing and mock mode for testing.
Checks: 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.
Profile: This section contains the personal and address details of the individual or entity being verified. Depending on the type of check, the profile must include specific fields such as names, date of birth, and addresses. Addresses can be provided in either structured or unstructured formats, though structured formats are recommended for higher match accuracy.
The externalReferenceId parameter is used to uniquely identify a request.
externalReferenceId
string
Yes
A unique identifier for your request, provided by your system. This helps in tracking specific requests.
Example:
The options parameter defines how the request is processed.
runAsync
boolean
Yes
Determines whether the request is processed asynchronously or synchronously.
- true: Returns a correlation ID; the results must be fetched in a subsequent request.
- false: Returns the results directly.
mock
boolean
No
When set to true, the request is processed in a simulated environment for testing purposes.
Example:
The checks array contains details about the verification checks to perform.
The following checks are currently supported by the Verifications API:
Address Verification Verifies the subject’s address against trusted data sources.
Background Checks Performs PEP (Politically Exposed Persons) & Sanctions screening and Adverse Media checks.
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.
checkTypeId
1 (required)
2 (required)
3 (required)
externalCheckReferenceId
Required
Required
Required
maximumSources
Required (default: 3)
Required (default: 3)
Required (default: 3)
checkMethod
Required (default: 1)
Required (default: 1)
Required (default: 1)
matchesRequired
Required (default: 1)
N/A
N/A
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:
The profile contains personal, address and bank details for the individual being verified.
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
Optional
Optional
firstName
Required
Required
Required
lastName
Required
Required
Required
middleName
Optional
Optional
Optional
dateOfBirth
Optional
Optional (preferred)
Required
currentAddress.structured
Required (preferred)
N/A
N/A
currentAddress.unstructured
Required (if structured address unavailable)
N/A
N/A
bankDetails.accountNumber
N/A
N/A
Required
bankDetails.sortCode
N/A
N/A
Required
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.
dateOfBirth: While optional for Address Verification and Screening, it is needed for UK Bank Account checks to ensure accurate matches.
currentAddress.structured: A structured address is preferred for Address Verification, as it improves the likelihood of a positive match.
currentAddress.unstructured: If structured data is unavailable, an unstructured address may be used for Address Verification, though it reduces accuracy.
bankDetails.accountNumber / bankDetails.sortCode: These fields are mandatory for UK Bank Account checks to validate the account details.
titleID
integer
- 1: Mr
- 2: Mrs
- 3: Ms
- 4: Miss
genderType
integer
The individual's gender.
- 1: Male
- 2: Female
firstName
string
The individual's first name.
middleName
string
The individual's middle name (if available).
lastName
string
The individual's last name.
dateOfBirth
string
The individual's date of birth in YYYY-MM-DD format.
The currentAddress parameter provides the individual's current residence details.
flatApartmentSubBuilding
string
No
Flat or apartment number (if applicable).
buildingNumber
string
No
Building number (if applicable).
buildingName
string
No
Name of the building (e.g., "Example House").
At least one of building number, building name , flat number or road street is required.
roadStreet
string
No
Street or road name (e.g., "Example Street").
district
string
No
Name of the town or city (e.g., "Exampleton").
townCity
string
No
District name (if applicable).
stateProvinceName
string
No
State or province name (e.g., "Exampleshire").
stateProvinceCode
string
No
State or province code (e.g., "FL" for US state Florida).
postZipCode
string
No
Postcode or ZIP code (e.g., "EX12AB").
countryCode
string
Yes
dateFrom
string
No
Date when the individual started living at this address (in YYYY-MM-DD format).
Example:
If you are unable to map a client’s address to the structured format, you can provide an unstructured address in the request.
Note that using an unstructured address decreases the likelihood of achieving a positive match since it may lack the precision of a structured format. Unstructured addresses should only be used as a fall-back when structured details are unavailable.
address1
string
Yes
address2
string
No
address3
string
No
address4
string
No
address5
string
No
townCity
string
No
stateCounty
string
No
postZipCode
string
No
countryCode
string
Yes
dateFrom
string
No
Example
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.
accountNumber
string
Yes
The 8-digit bank account number.
sortCode
string
Yes
The 6-digit bank sort code in the format XXXXXX.
openedDate
string
Optional
The date the bank account was opened, provided in format (YYYY-MM-DD). Optional but recommended for added precision.
Example:
Accuracy and Completeness: Always include all required fields for the checks you are performing to maximize the chances of successful verification.
Structured Data: Use structured addresses and complete profile details wherever possible to achieve higher match rates.
Traceability: Leverage unique identifiers such as externalReferenceId and externalCheckReferenceId for efficient tracking and troubleshooting.
Security: Ensure all requests are securely transmitted with the required JWT authentication token.
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 support@tillertech.com.
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.
: Validate international addresses with trusted, regulatory-quality data from 53 countries.
: Identify politically exposed persons, individuals on watchlists and sanctions lists and adverse media.
: Securely confirm bank account details to ensure accurate financial transactions.
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.
The individual's title. See for full details.
ISO 3166-1 alpha-2 country code (e.g., "GB" for the United Kingdom). See for more details.