Digital Onboarding

Getting started with Assure

82 views November 15, 2018 December 6, 2018 1

There is a growing expectation among consumers that an onboarding process should be conducted completely online, eliminating the need for a personal meeting. Not meeting customers face-to-face creates an added pressure to comply with EU regulations such as Anti Money Laundering (AML) and Know Your Customer (KYC).

But how can you be truly certain that someone is who they claim to be without a face-to-face meeting? The key is to collect sufficient evidence, which can include anything from traditional ID documentation to real-time video assurance. Signicat Assure offers a wide variety of methods to establish the identity of a person using digital means, which can be used separately or in combination with each other to perfectly tailor the solution to your company’s needs. That is precisely where Assure’s strength lies, its flexibility and scalability, which allow you to balance convenience for the user with risk and regulatory requirements. This ensures an easy, secure process for end-users and prevents fraud and money laundering, which helps your business stay compliant.

Signicat Assure drastically simplifies the onboarding process in many industries, but especially banking and finance, which typically have complex onboarding processes.

An example of an Assure authentication process

Another big advantage of Signicat’s services is that they can all be customized. You can even use Signicat’s API in your own solutions in order to ensure a truly seamless onboarding experience for your customers.

To experience some of the possibilities of Assure, you can use our demo service and try it out yourself.

Identity methods

Signicat delivers a wide variety of identity methods that you can use to onboard your customers. Identity methods are strategies or schemes that can be used to establish the identity of a user or obtain more information about them. Some of them are built into the Signicat environment, but many of them are available through agreements with third parties. Generally speaking, they can be divided into six types:

  • Built-in identity verification methods that confirm possession of a device. For example: SMS OTP, email OTP.
  • Public eID schemes that Signicat has signed agreements with. For example: Norwegian BankID, itsme, Freja eID.
  • Automated verification of identity documents issued by an official national authority: passport, national ID, residence permit, or driver’s license.
  • Registry lookups to either obtain more information about the user or verify the information that the user has provided. For example: Bisnode, Trapets, Virk.
  • Consumer identities such as Facebook, Google, or Linkedin.
  • Liveness detection to verify the authenticity of the user’s pictures.


Methods can be organized into steps to create a customized, secure process. The illustration above shows a small overview of just some of the many identity methods that can be used and combined to authenticate a user. For example, imagine the following scenario:

Picture a potential customer, let’s call her Claire Jones, who wants to open an account with a new bank. The bank might want to take several different steps to ensure that it is indeed Claire Jones who is opening this account. The following is just one of many possible workflows.

  1. The bank asks Claire to provide some basic information about herself, such as her full name, date of birth, and mobile phone number.
  2. The bank sends a one-time password to Claire’s mobile phone by SMS.
  3. Claire enters the one-time password on the bank’s website. Now the bank can be certain that the person who is opening the account has access to the provided phone number.
  4. The bank asks Claire to upload a selfie. Now the bank knows what this person looks like.
  5. The bank asks Claire to scan and send them a page of her passport.
  6. In the background, the picture in Claire’s passport is compared to her selfie to ensure that they’re both pictures of the same person. Now the bank knows for sure that the person opening the account is the owner of the passport, and that she is indeed Claire Jones.

Integrating with Signicat’s API

Integration with Assure is typically done via the same API as it is with Signicat’s ID methods. See “Get started with Authentication” for more information. Through this single point of integration, you will get access to Signicat’s wide portfolio of integrated ID methods and services such as identity document verificationlookups, and liveness detection.

The information below is just an overview of the information you can find in ‘Get started with Authentication’.

How to start the integration

  1. Establish a Service Provider (SP) relationship with Signicat.
  2. Request the configuration of an OIDC client on your SP account. For this, you need to provide some information about your company (client name, application type, redirect URIs, scope values).
  3. Signicat will send you a Client ID and Client Secret pair, as well as the “Authentication Context Class Reference” (ACR) values.
  4. Decide what library/middleware you want to use. Signicat does not recommend a particular one, so you are free to choose the one that suits you best.

Manual integration

Note: this section only mentions URIs towards the preproduction infrastructure at Signicat for the sake of brevity. Keep in mind that all the code snippets below are just examples.

The basic implementation must be capable of:

  1. Crafting an authorization URI to send to end-users for login. For example:
  2. Receiving the authorization response when end-users are redirected to the redirect URI.
  3. Doing an HTTP POST to the token endpoint to receive access tokens. For example:
    curl -XPOST "" -H "Authorization: Basic ZGVtby1wcmVwcm9kOm1xWi1fNzUtZjJ3TnNpUVRPTmI3T240YUFaN3pjMjE4bXJSVmsxb3VmYTg=" -d "client_id=demo-preprod&redirect_uri= GOES HERE"
  4. Doing an HTTP GET to fetch the end-user information using the access token towards the userinfo endpoint. For example:
    curl -XGET "" -H "Authorization: Bearer YOUR_ACCESS_TOKEN"​

The output of the userinfo request might look something like the block below:

{"sub":"c_D8vNOfz4Yhm2IE7nW0iNbqnmUebmG9","birthdate":"1983-11-01","paper.document_number":"SPECI2014","gender":"F","paper.nationality":"NLD","name":"Magda Eleonora Martens","paper.document_type":"I","given_name":"Magda Eleonora","assure.manual_approval_document_ref_id":"2018-11-263k7j4nu2el91e52k21eq146t1wla0cl88evspsxrf0yyty1fjk","family_name":"Martens","paper.issuing_authority":"Burg, van Stad en Dorp","assure.paper_evaluation_result":"true"}

All this information can be used to confirm the user’s identity, register them in your system, or create a user account for them. Additionally, several pieces of information can be identified. In the example above, we can extract the following information about the user:

  • Birthdate (1983-11-01)
  • Gender (F)
  • Identity document number (SPECI2014)
  • Nationality (Netherlands)
  • Given name (Magda Eleonora)
  • Family name (Martens)

For further details about the implementation and all possible options, see our OIDC documentation for Authentication.

What can be done in a method configuration

Basic Assure operations can contain any of the proofing methods explained above. They can be adjusted to each merchant’s needs through several parameters. Additionally, an Assure operation can be configured to include any of the following:

  • A request form.
  • ID document verification. In this step, the user is asked to upload a picture of an identity document, which is sent to the Signicat Paper plugin for validation. This step is commonly used in combination with other proofing steps, to verify the correctness of the obtained data.
  • Face matching to ID document pictures. The process has two possible phases:
    1. Selfie matching and liveness test.
    2. Matching a selfie to the picture in the ID document.

Additionally, flow integrity checks can be configured. A flow integrity check ensures that certain information pieces involved in an Assure operation match. Exactly which pieces of information must match depends on the configuration. This is done, for instance, to check if the name provided by the user in one of the fields of the request form matches the name linked to the eID method they used to identify themselves.

Operation types

In order to understand the possibilities of a method configuration, it is important to know the difference between ProofID operations and EstablishID operations.

ProofID operations execute an identity method to verify the identity of the user and return data which can be stored by merchants in their own repository. Signicat does not store any information, so any subsequent executions of the same operation will not benefit from previous executions in any way.

EstablishID operations work like ProofID operations with the exception that they also create an account in Signicat’s ID store. The account is created after a successful execution of the identity method and before returning a response to the caller. Typical EstablishID operations first collect information through a request form and then send out a one-time password (optional) or allow the user to set a password for the account (also optional). The optional steps facilitate authentication of the user later on.

This means that EstablishID operations are the right choice for merchants who can’t or don’t want to maintain their own repository.

Request forms

Request forms are used to gather basic information from the user, such as name, email address, or phone number. Typically, there are two main reasons to use a request form:

  • To get the necessary information to create an account for the user.
  • To verify one or several devices (optional).

Request forms are a mandatory step at the end of EstablishID operations (to create an account in Signicat’s ID store). Optionally, they may also be placed as a step at the beginning of the process in both EstablishID and ProofID operations, to collect information that will be verified in subsequent steps. A request form might look as follows:

If you decide to configure a request form as one of your steps, it must include the following fields at the minimum:

  • First name
  • Last name
  • Mobile phone number

You can also add an email address field. If you include both mobile phone and email address fields, you can choose to either just store the phone number and email address or verify them (just one of them or both). You can even make it possible for the end-user to decide which of the two they would like to be used for verification.

The field “Account name”, which defines the name of the account, can be used in different ways. You may choose to show it to the user, allowing them to enter the name that they want, or you can define it based on another field. For example, it is possible to use the value entered in the email address field as an account name.

Additionally, if you are using the request form at the end of the process, you may choose to populate some of the fields with information obtained in previous steps. For example, if you asked the user to identify themselves using an eID method in a previous step, you can take the information obtained in that operation (such as name and last name) and use it to populate the relevant fields in the form.

This section deals with the most common type of request form, but Signicat also offers templates for other use cases, such as forms that can be filled out on behalf of a company, empty forms that can be configured with additional fields, and forms that only ask for address information (and any additional fields you want to configure).

ID document verification

ID document verification requires users to upload a picture of an identity document (passport, national ID, residence permit, or driver’s license). Signicat supports a wide variety of documents from different countries; information on specific documents is available on request. Additionally, if the document that you are interested in is not currently supported by Signicat, it can be enabled upon request. Below is an example of what a simple process of ID document verification might look like:

  1. The user is asked to select the issuing country of their identity document.
  2. The user has to take a picture of the identity document with their webcam or upload a picture of it.
  3. In the background, the authenticity of the document is checked and the information it contains is examined and, if possible, verified against data obtained in previous steps.

You can demo this functionality using our demo service.

ID document verification is often combined with face matching (see below) to make the authentication process even more reliable. Here are some of the configuration options for the ID document verification step:

  • The list of countries that you want users to be able to choose from.
  • The default country that you want to show in the selector for each ID document type.
  • Which document types should be verified. Usually, one is sufficient, but it is possible to configure verification of multiple document types as well.
  • Whether you want to allow both file uploads and webcam captures or just one of these options.
  • For each document that is uploaded, you can configure if you want to verify it or just save it. For example, you may want to ask users to upload a picture of their passport and their national ID card but only verify the passport and keep the national ID card pictures because you need them for something else.
  • How many retries the user gets to upload a picture of the document if the first try fails.
  • The process can be configured to continue even after an error occurs during the processing of the ID document. If you choose to do this, the process continues as usual, but manual approval information is generated at the end. Afterwards, manual approval can be carried out by a third party or the merchant themselves.
  • To generate manual approval information regardless of whether or not the ID document verification fails.

When it comes to extracting information from the document, ID document verification uses a combination of two different approaches:

  • If there is a machine-readable zone (MRZ), this part of the document is used to extract basic information with OCR according to the MRZ standard. The “UNIV” country category only reads the MRZ.
  • For any information that is not found in the MRZ, or if there is no MRZ, ID document verification relies on country-specific templates and OCR to decipher and interpret the available information.

A note regarding OCR: while the MRZ has an optimized font that makes it easier to read, the other fields in identity documents do not use optimized fonts, which makes these fields more prone to erroneous reading. Some of the factors that may impact readability are resolution, contrast, and straightness of the input picture.

Face matching

The face matching step provides an additional layer of confidence for the authentication process. It can be used before or after an ID document verification step. During face matching, a self-portrait of the user, as well as pictures extracted from the uploaded ID documents are compared to see if they match. Each face-matching operation has a result between 0.0 and 1.0, where 1.0 is the best possible match. Every merchant can configure their own minimum threshold for successful face matching, and the system also has a maximum threshold, to prevent identical images from being used.

There are two main options for face matching:

  • Selfie matching and liveness test
  • Matching of base selfie with ID document pictures

These processes can be performed with either one or two self-portraits. From the point of view of the user, this step is as simple as providing one or two pictures of themselves, but merchants can configure several possibilities and levels of complexity. In all cases, the user interface looks like this:

Liveness test

In order to avoid fraud, a certain randomness has been introduced when requesting a self-portrait of the user, which means that the user may be asked to supply pictures in different conditions every time (for example, smiling or not).

If the process is configured to request only one self-portrait, the only possibility available for a liveness test is smile verification, wherein the user is asked to smile for the picture.

If the process is configured to request two self-portraits, smile verification may be carried out as one of the steps. Another possibility for setups with two self-portraits is movement verification, where the end-user is asked to turn their head for the second picture, so that its similarity to the first picture can be established. In all cases, if a verification fails past the number of retries allowed, the face matching step fails.

Self-portrait matching

In processes that request one self-portrait, there is no explicit matching step. If the liveness step is passed successfully, the self-portrait is matched against the pictures extracted from ID documents (if any).

In processes that require two self-portraits, these are compared to each other. As with any other kind of face matching, the images must satisfy the minimum and maximum confidence levels. If this step is passed, the first self-portrait (the reference) will be matched against the pictures extracted from ID documents (if any).

Was this helpful?