The Zignsec Register check product family contains of several different products with the purpose of enriching or validating a person’s identity towards different kinds of registers. This is being done differently in different markets and depending on use-case hence the range of products.

Zignsec offers a few different types of methods:

  • Validation of personal data. In most markets in Europe it is possible to validated collected personal information (name, address and date of birth) towards trustful local registers supplier by authorities like Governments, Credit beuros, Post- or telecomproviders. API-service that returns a match score indicating the level of assurance that the information supplied is correct.
  • Lookup Person queries. Used in the markets where it is possible to enrich data based on one single unique identifier like a phone number or a personal number. An API-call that queries a unique identifier and returns the full customer data set linking to one person.
  • Search person requests. Send in as much information as you have about a person and we will return the possible matches from one or several registers. An API-call with different level of personal information as input and a list with selected candidates as result.
  • Register assistance. A non-API-service that is used to clean a customer register. Send in a full list of people in a csv- or excel format and we will return a cleaned list with updated information.

Validation services

The Zignsec validation services are highly sophisticated data services optimized to offer the best possible conversion or match-rate by combining multiple registers in each market searching them one by one until a match is found. Zignsec offer two types of services: Validate identity and Validate address. Validate identity consider all pieces of the personal information when validating the data while Validate Address mainly focus on validating the address elements of a person.

Data quality

Data quality is always a consideration when doing checks towards registers; are the registers up-to-date, which information is found in the different registers, what is the actual quality of the data? Ultimately it is a question whether the data supplier is indeed trustful or not. One way to strengthen the trust in the data is to require data to be collected for multiple registers as a form of due diligence.  The industry is called the higher level of assurance 2+2 meaning that all validation needs to be done towards not only one but towards two independent registers. To qualify as a 2+2 match each piece of information validated should be independently matched in more than one register. The lower level of assurance is called 1+1 and require each element of the info to be validated towards at least one trustful register to be presenting a match.

A 2+2 is a much more complicated process than a 1+1 and are in some cases resulting in a slightly lower match-rate. The cost for a 2+2 is also higher as it on average requires more registers to be queried to present a positive match.

It is up to each company to choose their level of data quality based on risk level, regulation, budget and match rate requirements.

Required fields

Each country is special but also each register comes with unique requirements and limitation to be utilized. We have collected all the characteristics in one common matrix – The Zignsec required fields matrix can be downloaded here. 

Use the required fields table to get an understanding of which data points you need to send in per country. In most countries the combination of name, address and DoB is enough but some markets require personal id-numbers or references to be sent in to present true matches.

Data formats

It is important to send in the data in the right format to get the best possible match rates. The fields are found in the API-documentation

Matching criteria

The matching criteria’s are the rules the platform uses to value the results and provide a value indicating how well the validation is done.

Zignsec provides the following matching scores: HIGH, MEDIUM and LOW.

  • HIGH means Places the individual at the street address provided and/or verifies the name, date of birth, id, and an element of location.
  • MEDIUM means Partially verified identity but insufficient for a passing match.
  • LOW means could not verify identity and/or minimal match.

A company should use the match score value in the automation of you KYC-processes. Find the right level of match score that your business requires and create your automation based on that value. Also make sure to monitor the match-rate levels to make sure you only accept and approve the right customers. This is a process that Zignsec can help you with to set, to monitor and to fine-tune.

The matching criteria’s can be configured on an individual account basis to match the needs that your business is operating in.

Here are the Zignsec default settings:

  • Validate identity (1+1)
  • Validate Address (1+1)
  • Validate Identity (2+2)


Apart from the match levels and match score Zignsec provides a big range of additional information related to the search done. The results display each register that is being used with detailed data showing which data elements that have been validated. By studying the results, a company can get valuable insights. This additional data is recommended to store linked to the user’s profile in case of an audit.

Live data queries vs databases

All Zignsec’s data queries are being done towards local and live data records. The reason for using live data sources instead of static databases are many. The main advantage is the level of conversion achieved. Static databases often contain old data that no longer is reliable or even misleading.

Another element with static databases vs live data queries is that local queries are taking advantage of the matching logics performing best in each market. This is again resulting in better conversion comparing the two methods.


There are many different use-cases for validation services. Here we list a few of them:

  • Age verification
  • SDD
  • “Proof of address”