We use cookies to give you the best experience on our site. Cookies are files stored in your browser and are used by most websites to help personalise your web experience. By continuing to use our website without changing the settings, you are agreeing to our use of cookies.
Read policy.

Frequently asked questions about the Keesing AuthentiScan Web API:

1.1   How does the Authentiscan Web API Work?

The diagram below provides an overview of how the Authentiscan Web API works:

Authentiscan Diagram


1.2   How does the system distinguish real documents from fake ones?

Authentiscan Web API solution makes use of a template database trained on real documents that allows it to identify fake documents from the real ones.

  • Checking a range of security features (presence and correct pattern of holograms and other optical security features, biometrical features, background pattern matching)
  • Checking MRZ: comparing data in the MRZ to the corresponding Visual Inspection Zone data and verifying MRZ checksums
  • Matching selfie to document photo ID


Here is an example overview of the security features checked by the system:

ID Examples


The system is also optimised to detect and reject submissions of a copy of a document (a printed copy or a copy as photographed from a screen). Please note that the SDK needs to be integrated to ensure this functionality.


1.3   What is a liveness check and why is it important?

A liveness check is performed to ensure that the person submitting the document and selfie images is genuinely present during the transaction. They are required to actively move (blink, smile showing their teeth), the SDK recognises this required movement and can thus confirm that the person is truly present.

The liveness detection happens on the phone of the end user: while the phone makes a short video, the programme detects the user performing the required actions. The check will only be passed successfully when the required movements are performed, random movement would not generate a positive check result. Note that the order in which the user is required to perform the actions is always random, which brings another level of anti-spoofing protection.

The selfie capture and the liveness check happen at the same time. If the user’s face is lost at any point of the process, the check fails. This approach ensures that there is no possibility for image/video spoofing, allowing for a quick and easy process at the same time.


1.4   Can this solution help with form-filling?

When the document is checked for validity, we extract data from it and pass it on to you along with the check results. The extracted data corresponds to the fields found in the document and will typically include name, surname, date of birth, document validity period and nationality.


1.5   What documents are covered by the Authentiscan Web API? What if the document I am interested in is not covered?

Our template database provides global coverage of passports, ID cards, driver licenses and other government-issued forms of ID. Contact our Sales Team to get the full list of documents covered.

We are continuously improving our system and expanding the coverage of the template engine. If the document is not yet covered in our list, please contact us for a more detailed discussion on how we could get it into the database asap.


1.6   How well does the Face Match function perform?

Authentiscan Web API is a solution with a global audience in mind.

The face match function was built for the diverse world we live in: it has been optimised to perform well on faces of all ethnic origins. It is also able to handle glasses and headscarves without any impact on accuracy.

Our current Facematch solution measures at 82% accuracy, and we are constantly working to further improve this figure.


1.7   Where can I find the documentation for the Authentiscan Web API?

You can find all the documentation on our Web API and SDK in Github:


1.8   Do I need to integrate the SDK into my front end?

At the moment, we are not allowing the use of the Authentiscan Web API without the SDK. There are several reasons for this:

  • The SDK performs the liveness check right at the moment of the data submission. Without the SDK, the liveness check is possible (the user can submit a video), but this increases the risk of spoofing.
  • The SDK ensures that document images are captured in sufficient quality to be accepted by the system for an automatic check
  • The SDK guides the customers on the capture of images, making it a quick and smooth journey (which is one of the key challenges faced when digitally on-boarding customers).


Our system is optimised for the API being used with the SDK, so we strongly recommend customers to implement both. However, we are aware that there are customers who prefer to only implement the Web API. We are currently working on developing this functionality:

  • A Beta version of non-SDK upload is available on Acceptance environment. This is available for testing only and is NOT provided on the Production environment.
  • If you chose to use the non-SDK upload during testing, please notify us of any issues you experience with it to help us make the service ready for use.


1.9   How is customer data processed and stored?

Keesing makes it a priority to follow strict data security standards. We are fully GDPR-compliant and operate on the principle that our customers are in control of their data.

Once the identity is verified and the results are returned to the customer, all processing data is deleted from our servers. The customers are able to indicate if they would like to access PDF reports on the checks through the front-end. This is offered as a fall-back option to customers who have a requirement for it. During the customer set-up process, you can specify how long you want the PDF reports to be available to you in our system. These preferences typically depend on the customer’s own data policies, choice to use Keesing Helpdesk and customer data-storage needs. The customer can also change their preferences at any time by informing Keesing of the desired changes.


1.10   I previously used Keesing App; how is the Authentiscan Web API solution different?

The Authentiscan App was developed to facilitate the intake process where the customer’s employee would validate documents during a face-to-face on-boarding. The Authentiscan Web API solution is supporting the ID verification for digital on-boarding: the users are guided through capturing images of their document, making a selfie as well as a liveness check. There is no need for a trained person from the customer’s side to help them capture the data.

From a functionality perspective, there are three key differences:

  • The new solution consists of the SDK that can be integrated into the front end or app to guide the users through the data-capturing process. This makes it easy to add document verification processes into any existing workflow.
  • The new solution is using a different method of integration: all the check results are passed on to your back end via the API. Results are passed on to you as a PDF report and as a JSON file (easier to digest into existing internal systems).
  • Much more detailed results are available with the JSON file (results of all checks and scores).


1.11   Can Authentiscan Web API help me comply with AML5 Directive?

Keesing Authentiscan solutions are aimed at helping customers comply with the increasingly strict AML procedures. Our Authentiscan Web API solution allows you to verify the identity of the customer through performing the following checks:

  • Confirm the validity of the presented ID document (our system would identify and alert you to any suspicious documents).
  • Confirm the match of the customer to the ID document (selfie to ID photo comparison).
  • Confirm the ID holder is present during the submission of the document (liveness check).

Please note that the previously discussed Web API solution does not have the PEP / Sanctions list functionality enabled, but we hope to enable it in the future (it is on our roadmap).


1.12   What does Document Helpdesk do?

While the automated checks relying on a document template database is the key part of our system, in a minority of cases the machine is just not capable of arriving to a final conclusion. Our team of highly skilled document experts deals with such cases: they examine the submitted documents closely, checking the document security features closely to verify its authenticity.

If the customer opts in for this service, documents that were not assigned a final status by the system are reviewed by the Helpdesk team and then given the final status.


1.13   How long does a check take?

The document intake process can be done fully in under one minute.

The length of time it takes to do the check depends on the document submitted. In the majority of cases, the document would be validated by the automated system, so the result would be available within seconds. However, if the document requires attention of the Document Helpdesk, the result will take longer. We aim to respond within 15 minutes of submission during the working hours (8am-6pm CET, Mo-Fri).


1.14   What type of apps does the SDK Support?

The SDK supports native apps only (available on Android, iOS and Web). We currently do not support hybrid apps.


1.15   What are the time and access limits for the document check results?

Below is the outline of the verification process highlighting the access restrictions and timeline limits for getting the verification results:

  1. Data is collected by the SDK, passed on to Keesing via the Web API
  2. Verification is processed, results are ready for collection (PDF report + JSON File)
  3. Keesing sends the customer a notification that the results are ready with the URL to get the results
  4. Customer receives the notification => customer’s system pulls the results from the URL stated in the notification
    1. Once Keesing knows you received the notification, we wait for five minutes (which should be enough for the customer to retrieve the data), then deactivate the URL and delete the data
      • The Customer can access the URL only five times per minute. So in the five minutes it exists, the customer can access it to a maximum of 25 times. The customer ONLY needs to access it once to get the results; however we understand that there can be situations where the process to retrieve data fails. To address that a limited number of repeated attempts to download the data is allowed.
      • Please note that the limit is per URL, so if 100 documents were submitted in the same minute, the customer can retrieve the results for all of them at the same time (as each result has its unique URL)
      • Please note, Keesing does not monitor if the customer has pulled the data successfully. After five minutes of the customer receiving it, the link becomes inactive.
    2. If the notification was sent, but not received, we send it again. The reports are queued until the notification is successfully received.

Please note that the system is completely scalable, so the number of uploads does not affect the speed of the solution’s performance.

In case the notification was sent, but was not received due to the system being down at the customer’s end, once the system comes back up online, batch notification will be sent and all the notification failed will be sent again.


1.16   What mobile devices has the SDK been tested on? What are the minimum system requirements?

The Mobile Capture SDK system requirements are as follows:

  • Android: min. API level: 17; target API Level 26
  • 2GB RAM preferable 4GB
  • CPU: min. 2 core 1,0GHz ARM CPU preferable 4 Core 2,5Ghz ARM CPU; Supported instruction sets: ARMABI, ARMABI -v7a;
  • CPU: INTEL ATOM 1,2GHz, 2GB RAM, preferable 4Core 2,2GHz 4GB RAM
  • CPU: Apple A6, ARMv8 1,4GHz
  • CPU: Apple A9 & A9x, ARMv8
  • CPU: Apple A11 Bionic, ARMv8-A

The SDK has been tested on following hardware platforms:

  • Samsung S5, Samsung S6, Samsung S7, Samsung S8, Samsung S8+: Android 6, Android 7, Android 8
  • Huawei Mate 10 Android 7
  • Huawei P20 Android 8
  • LG Q6 Android 7
  • LG G K8 Android 7
  • Nokia 7 Plus Android 7, Android 8
  • ZTE Axon 7; Android 7, Android 8.1
  • Motorola G5S Android 7
  • Sony Xperia L1 Android 6.0
  • Sony Xperia E5 Android 6.0
  • Sony Xperia XA2 Android 8
  • iPhone 6, 7,8, X; IOS 11
  • BlackBerry Priv, Android 7
  • ULEFON Android 6.01
  • DOOGEE MIX Android 7
  • Cubot X18 Android 8
  • ASUS Zenbook Intel Atom
  • ASUS ZenPad tablet Z580C-1A029A (Android Version: 6.0.1, RAM: 2GB , Processor: Intel Atom 2.3 GHz 3580 Moorefield Quad Core 64 bit)
  • Asus ZenPad 7,0 Z370C-1L039A 17,78 cm (7 Zoll) Tablet-PC (Intel Atom X3-C3200, 2GB RAM, 16GB eMMC, Mali 450 MP4, Android 5.0
  • Odys Element 10 plus 3G 25,7 cm (10,1 Zoll IPS Display) Tablet-PC (Intel Atom x3-C3230RK, 1GB RAM, 16GB HDD, Mali-450MP4, 3G, Android 5.1
  • MEDION LIFETAB P8911 (MD 99118) 8,9″ Full HD-Multitouch-Display, Android 4.4, Intel Atom Prozessor, Asus ZenPad 10 LTE Z300CNL-6B020A 25,7 cm (10,1 Zoll) Tablet-PC (Intel Atom Z3560 Quad-Core, 2GB Arbeitsspeicher, 32GB eMMC, Android 6).
Contact us

Contact us

Sales & Consultancy Department +31 (0)20 7157 825

To find out what our solutions can do for your organisation and for further information, please feel free to contact our team of Sales Consultants.

How can we help you?

  • Customer Contact & Support
    +31 (0)20 7157 800 (Europe)
    +1 855 306 9875 (USA)
  • Helpdesk
    +31 (0)20 7157 857
    Monday – Friday: 08:00 – 18:00 CET
  • Sales & Consultancy Department
    +31 (0)20 7157 825 (Europe)
    +1 855 306 9875 (USA)
  • Knowledge & Education Center
    ID Academy
    +31 (0)20 7157 838