AuthentiScan is an easy-to-use, reliable identity verification solution that delivers its results to you in mere seconds, providing you with the certainty that the ID document is real, and that the person presenting the ID is the real owner. Learn more about its broad applicability below with our dedicated FAQ page.

Do you have any product-related questions or would like to make any inquiries about Keesing AuthentiScan?

1. AuthentiScan Web API

1.1 How does it work?

The diagram below provides an overview of how AuthentiScan Web API works.

FAQ Keesing

AuthentiScan Web API makes use of a template database based on genuine documents that allows it to distinguish fake documents from real ones.

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

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

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 must be integrated to ensure this functionality.

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

The liveness detection happens on the end user’s phone: while the phone takes 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 liveness check happen simultaneously. If a user’s face is lost at any point during 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.

Document status is based on the sum of the checks performed and can be as follows:

  • Pass (OK) – the document is recognised as authentic
  • Fail (not OK) – the document is not recognised as authentic: there are strong doubts that the document is authentic
  • Needs review – document Helpdesk expert review is required to confidently determine whether the document is authentic
  • Bad scan – the quality of the images submitted was not enough to perform the analysis
  • Unknown – the document is not recognised/cannot be verified by Keesing

 

Check status shows the result of the authentication check/test for each particular check performed. Each of the checks can have the following status:

  • Attention – the check has not passed completely. This indicates that an individual authentication test result requires user attention. User attention is sometimes required to perform manual validations. For instance, if the magstripe or contactless chip on a document could not be read, it does not indicate an authentication failure. Instead, it requires manual attention to validate that these elements are present (and perhaps retry).
  • Caution – The check has not passed completely: a doubt persists, the document may be counterfeit. This indicates that an individual authentication test was inconclusive and that further (manual) inspection may be necessary.
  • Failed – the check has failed. This indicates that an individual authentication test failed and that the document may be considered “suspect”. The result does not prove that the document is fraudulent but indicates that manual inspection is necessary to make a final decision.
  • Passed – the check has successfully passed. This indicates that an individual authentication test passed. The result does not prove that the document is authentic but rather provides a degree of assurance.

1.2. What can it do?

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.

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

The Facematch function was built for the diverse world we live in and has been optimised to perform on faces of all ethnicities. It is also able to handle eyeglasses and headscarves without any impact on accuracy.

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

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

  • Confirm the validity of a 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 document submission (liveness check)

Please note that the Web API solution does not have the PEP/Sanctions list functionality enabled at this time. Contact us [sales@keesingtechnolpogies.com]to further discuss this option.

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

If the customer opts in for this service, documents that were assigned a “needs a review” status by the system are reviewed by the Helpdesk team and then given the final pass/fail status.

Our Document Helpdesk team consists of experts with years of experience in forensic document investigation. They have also received training by former members of the Dutch Identity Fraud and Documents Centre of Expertise (ECID) as well as thorough in-house training.

Our Document Helpdesk team members are trained at Doc I and Doc II levels, attesting to their in- depth knowledge of global identity documents. Our senior experts are similarly trained at DOC III level and have been teachers of Doc II and Doc III courses in their previous roles while working for immigration authorities around the globe.

The AuthentiScan App was developed to facilitate the intake process whereby the customer’s employee would validate documents during a face-to-face onboarding session. The AuthentiScan Web API solution supports the ID verification for digital onboarding: users are guided through capturing images of their document, taking a selfie and liveness check. There is no need for a trained person from the customer’s side to help the user capture the data.

From a functionality perspective, there are three key differences:

  • The new solution consists of an SDK that can be integrated into the frontend or app to guide users through the data-capturing process. This makes it easy to add document verification into any existing workflow.
  • AuthentiScan Web API uses 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).

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

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

  1. Data is collected with the SDK and 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 results are ready, with a URL to obtain them
  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 for a maximum of 25 times. The customer ONLY needs to access it once to get the results; however, we understand that there can be instances when the process to retrieve the data fails. To address that, a limited number of repeat 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 own unique URL).
      • Keesing does NOT monitor if a customer has pulled the data successfully. After five minutes of the customer receiving it, the link automatically becomes inactive.
    2. If the notification was sent but not received, we send it again. The reports are queued until the notification is received successfully.

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

If a notification was sent but not received, a batch notification will be sent once the system comes back up online (failed notifications will be sent again).

Currently, AuthentiScan Web API only supports Latin characters.

  • For documents where there are both Latin and other characters, only Latin characters will be read.
  • For documents that have no information in Latin script, but are ICAO-compliant and have an MRZ, template checks and data extraction is still possible; however the number of cross-checks (i.e. matching data on the visual part of the document vs. MRZ) will be limited.

While we currently cannot OCR or cross-check non-Latin characters, we welcome customer feedback on what languages would be most useful. Please share your views with your Sales Manager or e-mail our Product Manager directly.

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 a majority of cases, the document would be validated by the automated system, so the result would still be available within seconds. However, if the document requires the attention of the Document Helpdesk, the result will take longer. We aim to respond within 15 minutes of submission during working hours (8am-6pm CET, Mo-Fri).

1.3 What does it include?

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 as soon as possible.

Yes, it is possible to use the service without the selfie and liveness check component. When integrating the SDK, you can decide if you would like the selfie and liveness check to be turned on or off.

The selfie and liveness check results do not influence the document check result (i.e. a third party may present a real document that does not belong to them). The PDF and JSON report clearly indicate the detailed check and overall verification results. If you opt to not include selfie and liveness check data, they will not appear in the report.

Please note that excluding selfie and liveness checks lowers the security of the solution: a real document can be stolen and presented by an impostor. Therefore we recommend that customers include the selfie and liveness checks into the process.

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 the 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).

1.4 Integration, Setup and Other Processes

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

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, a liveness check is still 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 customers on image capturing, making it a quick and smooth process, one of the key challenges faced when digitally onboarding 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 implement the Web API only, so this functionality is available on request.

We understand that some of our customers may choose to perform the data capture as part of their own process. While AuthentiScan is optimised to work with the input as created by the SDK, the customer can feed the data directly into the AuthentiScan Web API. The documentation includes detailed specifications on the images accepted by the system.

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 an identity is verified and results are returned to a customer, all processed data is deleted from our servers. Customers are able to indicate if they would like to access PDF reports on the checks through the frontend. This is offered as a fall-back option to customers who requireme it. During the customer setup 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 the Keesing Helpdesk and customer data-storage needs. The customer can also change their preferences at any time by informing us of the desired changes.

Each scanned document goes through a number of checks, these vary depending on the document (different documents have different security features), but can be broadly categorised into the following groups:

Data cross-checks – checking that the same data matches across different sources (e.g., does the surname on the MRZ match the surname on VIZ? Does the photo on VIZ match the photo stored on the chip?)

Template checks – checking that the expected security elements are in place (e.g., does the document have microtext / protection elements in the place indicated by the template?)

Security checks – checking that the expected coded elements are present and correct (e.g., are elements such as MRZ check digits in order? Is the chip read correctly?)

Each of the checks results in a ‘risk factor’ value from 0 to 100, where 0 is ‘all good’ and 100 is ‘definitely fake’.

All checks are given the same ‘priority’.

All the scores are then summarised to get a total score for the Calculated Risk Value, which then determines the overall status of the document:

Less than 40 points => the document is viewed as genuine

From 40 to 80 points => the document requires additional review and is sent to Helpdesk

More than 80 points => the document is viewed as NOT genuine. Please note that we cap the total number of points at 100 (i.e. while the total sum of all points in individual checks could be, for example, 250, in the report the Calculated Risk Value will be shown as 100).

You can see the details on the risk factor score assigned to each check in the JSON result file. In the PDF result file contains the indication is whether each of the checks is passed or not and the total Calculated Risk Value.

Please note that if the document has been through a Helpdesk review, the Calculated Risk Value will NOT change. That is why there can be documents that have received an OK / Not OK status, while a score between 40 and 80 points is indicated as the Calculated Risk Value.

2.  AuthentiScan Scanner-Based Solutions

2.1 How does it work?

The diagram below provides an overview of how AuthentiScan Scanner-based solutions work:

Keesing’s AuthentiScan Web API solution performs a range of checks from a document’s security elements as seen in different light conditions.

  • Checking a range of security features (presence and correct pattern of holograms and other optical security features, biometric features and background pattern matching)
  • Checking MRZ: comparing data in the MRZ to the corresponding visual inspection zone (VIZ) data and verifying MRZ checksums
  • Performing passive and active RFID chip verification (if applicable)

Specific checks performed depend on the document checked and the AuthentiScan module the customer has selected. Customers using the AuthentiScan Premium module also make use of a template database.

Document status is based on the sum of the checks performed and can be as follows:

  • Pass (OK) – the document is recognised as authentic
  • Fail (not OK) – the document is not recognised as authentic. There are strong doubts that the document is real.
  • Needs review – document Helpdesk expert review is required to confidently determine whether the document is authentic.
  • Bad scan – the quality of the images submitted was not enough to perform the analysis.
  • Unknown – the document is not recognised/cannot be verified by Keesing.

Check status shows the result of the authentication test for each particular check performed. Possible check status indicators include:

  • Attention – The check has not passed completely. This indicates that an individual authentication test result requires user attention which is sometimes required to perform manual validations. For instance, if the magstripe or contactless chip could not be read on a document, it does not indicate an authentication failure. Instead, it requires manual attention to validate that these elements are present (and perhaps for the user to retry).
  • Caution – The check has not passed completely; doubt persists and the document may be a counterfeit. This indicates that an individual authentication test was inconclusive and that further (manual) inspection is necessary.
  • Failed – the check has failed. This indicates that an individual authentication test failed and that the document may be considered “suspect”. This result does not prove that the document is fraudulent but indicates that manual inspection is necessary to make a final decision.
  • Passed – the check has successfully passed. This indicates that an individual authentication test passed. This result does not prove that the document is authentic but rather provides a degree of assurance.

2.2 What can it do?

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.

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

If the customer opts in for Document Helpdesk service, documents that were assigned a “needs a review” status by the system are reviewed by the Helpdesk team and then given the final pass/fail status.

Our Helpdesk team consists of experts with years of experience in forensic document investigation. They have also received training by former members of the Dutch Identity Fraud and Documents Centre of Expertise (ECID) as well as thorough in-house training.

Our Document Helpdesk team members are trained at Doc I and Doc II levels, attesting to their in-depth knowledge of global identity documents. Our senior experts are likewise trained at DOC III level and have been teachers of Doc II and Doc III courses in their previous roles within global immigration authorities.

Viewing the check results: AuthentiScan Online platform and verification result reports can be viewed in nine languages: English, French, German, Spanish, Italian, Dutch, Swedish, Norwegian and Danish.

Document reading: At the moment, AuthentiScan scanner-based solutions only support Latin characters.

  • For documents where there are both Latin and other characters, only Latin characters are read.
  • For documents that have no information in Latin script but are ICAO-compliant and have an MRZ, template checks and data extraction are still possible; however the number of cross-checks (i.e. matching data on the visual part of the document vs MRZ) will be limited.

While we cannot currently check OCR or cross-check non-Latin characters, we are open to customer feedback on what languages would be most useful. Please share your views with your Sales Manager or e-mail our Product Manager directly.

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

The length of time it takes to perform the check depends on the document submitted. In most 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 working hours (8am-6pm CET, Mo-Fri).

2.3 What does it include?

The specific checks performed depend on the document being checked and the AuthentiScan module the customer has selected. Below is a brief overview of what the Standard and Premium modules can do:

2.4. Integration, Setup and Other Processes

It is possible to set up an integration of the AuthentiScan system within your internal systems. For both AuthentiScan Standard and AuthentiScan Premium Online, it is possible to do so via the REST integration.

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 an identity is verified and the results are returned to a customer, all processed data is deleted from our servers. Customers are able to indicate if and for how long they would like to access PDF reports on the checks through the frontend. Customers who choose to receive the results directly via the integration may opt to keep the data in our system for only a brief period of time (i.e. three days) or not at all.

During the customer setup 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 as well as their choice to use the Keesing Helpdesk and their data storage needs. The customer can also change preferences at any time by informing us of the desired change.