KYC ID-doc SCAN: Analog to digital

Introduction
Why would you use analog-to-digital scanning if there is a digital option available?
How does it work business-/process-wise?
How does it work technically? (Integration)
KYC elements in details

---

Introduction

KYC (Know Your Customer) process is something that was -traditionally- done manually, person-to-person. One would go to a bank, for example, and had identity document checked and verified by a bank employee. This is still the case in many situations. However, this process is possible to be automatized to the full extent.

MachineSense offers two types of document/person verification (KYC), which both may be executed completely unattended, or -if opted for- partially attended (and depending on the legal regulations on your territory). Those two basic versions of automated KYC are:

• KYC with document scan (analog to digital)
• KYC with NFC-based document read (digital to digital and cryptographically verified

This section describes the first of those two options (Scan, analog to digital).

Why would you use analog-to-digital scanning if there is a digital option available?

Well, it's not really available on all the documents. For example, in many countries, the ID cards are not NFC-enabled. Your ID-card or other document needs needs to have digital storage enabled and NFC (Near-Field Communication) technology to be able to be read digitally. If the document you wish to read does not have NFC, you need to use the analog-to-digital scanning.

Second, not all documents are predicted to have NFC implementation in the near future, even in the most advanced countries, the ones -for example- implementing NFC on IDs. All passports (worldwide) DO implement this technology, and most of the countries have an ambition to implement it on their ID-cards (although many of them have not until now), but driver-licenses, for example, or work permits are still out of the picture. In all these cases, and in order to stay universal, analog-to-digital scanning often appears to be the only option.

How does it work business-/process-wise?

MachineSense-proposed KYC process is consisted of the following

• Scanning of the document, by use of mobile camera or computer webcam
• Verifying the document authenticity by implementing several fraud-check methods
• Extracting the document-holder face-image and providing document-holder's facial biometric enrollment data (in form of non-PII information, i.e. face-representation vector data) for possible later verification
• Transferring captured data from our (web/mobile) client in super-strong (custom PKI) encrypted form to MachineSense servers, where additional verification and optional facial enrollment/verification is performed. This data is purely transactional (none of it is kept on MachineSense servers), and is sent directly to you, our customer. (Optionally we may provide also the safe-storage functionality, if customer requests and is legally allowed to do so).
• (* Optional, but often used) Comparing facial biometric characteristics of the facial information from the ID-document with a (liveness-detection checked) selfie. That is -- verifying that the person presenting the document is the same person using the device to register/perform KYC. This includes both facial comparison and doing liveness detection (anti-spoofing against recorded photo- or video- attacks and faking the document ownership).
• In this process - vectorized biometric information on document owner is also transferred to our clients. This information is not PII (Personal Identifiable Information), and is not usable for any other purpose than performing biometric comparison/verification. It is also not usable for any other purpose than the one it was collected for. This information may be used for enrollment of the end-user to the customer's system and -later- for verification of the account owner by biometric means.

MachineSense created APIs and client-side components (Web-assembly-based) that enable you to perform all the above-mentioned steps in a very simple way.
Our Web-assembly (WASM) components are available for both web/desktop and mobile (Android and iOS) platforms.
If using our client-side components, all client-side API calls are performed automatically.

How does it work technically? (Integration)

Integration process with MachineSense KYC is quite simple. It consists of the following steps (see also the diagram below):

1. Your back-end calls our API server, telling it which method/scenario it wants executed. Optionally, it may send any free-form text that will be returned in the end, together with the results, for your easy reference.
2. Our API accepts the request, and returns a unique session ID (UUID) to your back-end. This session ID is used to identify the session and all the data that is sent to our API server in the following steps.
3. Your back-end sends the session ID to your front-end (web or mobile) client. It may do so however you wish (as a session-ID string, as a URL, etc), and depending on which client-side component option you are using (see further below).
   Your back-end might send the session ID to the client (and your end-users) in the following ways:
   • Passing the session-ID as-is, to be copied or typed into your form
   • Passing the session-ID as a QR-code, to be scanned by your end-user's mobile phone. This is the recommended version, since cameras are far more advanced on mobile phones than on desktops and are guaranteeing better and more accurate results.
   • Additionally, if you want your end-user to finalize the KYC procedure on the mobile phone, while you initiated the process on a desktop/web client, you may want to send an email or SMS to your end-user, containing the session-ID as a URL. This URL will be opened on the mobile phone, and we are connecting the two sessions (desktop and mobile) by use of the session-ID.
   • Passing the session-ID as a URL, to be clicked on by your end-user. This is the recommended version for desktops, since it is the easiest to use.
4. MachineSense front-end Web-assembly (WASM) component is loaded on your client (web or mobile) and is performing tasks of scanning the ID-document (ID-card, passport, etc.), verifying its authenticity, extracting the face-image and sending it to our API server. This data is additionally encrypted by a custom PKI implementation, for both your end-user's, but also your security and as an anti-tempering measure.
   There are three possible ways how you can organize your client-side: