KYC with NFC: Digital to digital (100% ID-auth)

Introduction
NFC availability on documents
   Availability on passports
   Availability on ID-cards and other documents
How does it work business-/process-wise?
How does it work technically? (Integration)

---

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.

Differing from the SCAN-method, where the document is scanned by the camera, the NFC-method is digital-to-digital and includes fully cryptographically verified document authenticity. This is the most secure method of KYC, and it is the only method that can be used for 100% ID-authentication, without worrying about document forgeries.

MachineSense NFC-based KYC is a process where the document is read digitally, by use of NFC technology. Data is verified on several levels (authorization, local hashes and issuing-country certificates), and the results are sent to our customers/partners.

NFC availability on documents

NFC readability is not present 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.

Note: Not all documents are predicted to have NFC implementation in the near future, even in the most advanced countries, like the ones that are already 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.

Availability on passports

At the moment of writing this document, over 160 countries in the World are supporting NFC on their passports, using the ICAO 9303 standard (UN-backed International Civil Aviation Organisation). This means that the MachineSense KYC with NFC is available for all these countries.

These (compatible) passports are including all the major nations, with some exceptions still (India, Pakistan, Egypt, Syria...)

In some regions of the World, this issue is standardized completely. For example - European Union. All the countries in EU must provide ICAO 9303 standard passports, and all of them are NFC-enabled as well as having a machine-readable zone (MRZ), in form of two lines of text at the bottom of the passport's personal data page, conforming to the MRTD (ICAO Machine Readable Travel Documents).

Availability on ID-cards and other documents

Concerning ID-cards, most of the countries supporting NFC-chips for identity-reading are located in Europe. Some of these countries introduced NFC on their ID-cards quite some time ago (like The Netherlands or Sweden), some in the last few years, and some of them are still in the process of doing so. In recently implemented countries it is common that still not entire popularion has the new ID-cards, and that there is a mixed situation.

In addition to this, NFC-enabled chips can be found sometimes on residence-permits, and are in some countries planned to appear also on driver-licenses. In The Netherlands, for example, NFC-chips are already implemented on driver-licenses.

How does it work business-/process-wise?

MachineSense-proposed NFC-based KYC process is consisted of the following

• Acquiring consent, from the end-user about reading the digital data from a document. This is formally achieved by getting three pieces of information from the end-user: Document number, Date of birth and Date of document expiry. This is needed in order to insure privacy protection.
  MachineSense KYC document reader allows your end-users to either type-in this data, or to scan it from the document's MRZ section (for their comfort).
  When scanning, data in regions of interest is automatically recognized and filled-in. Optionally, end-user may be presented with this data and asked to confirm it.

  Note: There are exceptions for consent-related data: On Dutch driver licenses, for example, this data is presented in form of an "NFC-Code", which is a part of single-line MRZ.

• Digitally reading the document. This is achieved by placing the document (passport or other) close to the mobile phone running MachineSense KYC verify app. When proximity and readability are detected (automatic), end-user is presented with reading progress-bar. At this time, end-user's data is read from a NFC-enabled document.
  During this part of the process, blocks of data are read and their hashes verified. This is done in order to insure that the document/chip is not elementary forged.
• Verifying the document authenticity by implementing several fraud-check methods: In addition to above-mentioned elementary forgery checks, when collected data is sent to the MachineSense verification server (with additional, military-grade, custom PKI encryption) the issuing country's certificate is verified, in order to approve veracity of the document, it's validity and if document was registered as lost/missing previously (annulled).
• Decrypting and extracting the data on document-holder, including digitally written 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 MachineSense servers to our parner's servers, where additional verification In this process, caputured data is by default purely transactional from MachineSense point of view (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 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.
• Our partner/customer may choose which face-vector to use for the enrolment purposes of their end-user. They may choose to use the face-vector from the ID-document, or the one from the selfie, or both. Generally, it makes sense to enrol the end-user with all available vectors and later use the latest/freshest one (selfie performed in the previous step), because it will be the most accurate one for further comparisons.
• Our partner/customer may also choose to add during this NFC-based KYC process one more biometric identifier for their users: Voice biometrics. This is internally done by use of our Voice API, and is also optionally available in the NFC app.
  Hence, the end-user may be asked to speak a short phrase, which will be recorded and sent to our Voice API server for vectorizing and sent as a vector to our partner/customer.
  This vector may be, in a similar manner to face-vector, used later for verification of end-user, after supplying the session-based voice sample.

Similarly to the process of analog-to-digital, MachineSense is, by default, NOT RETAINING THE DATA. All the data is sent to our partner/customer, and is not kept on our servers. It is only a pass-through real-time transactional service.
Optionally, if customer wants it and is legally allowed, MachineSense may offer secure enrollment data storage, but this is not the default option, and is usually not something our customers wish or are allowed to do by law.

How does it work technically? (Integration)

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

1. You (partner/customer) ask your user to download the authentication app from MachineSense. This mail be a generic MachineSense app, or white-labeled app with your branding. Additionally, you may embed the MachineSense code in your own app and we'll give you the technical support to achieve that.
2. Once your end-user has downloaded the app, it is ready to be used for authentication.
3. Your back-end calls our API server, telling it (optionally) the details of the scenario it wants executed. Additionally, it may send any free-form text that will be returned in the end, together with the results, for your easy reference.
   Scenario options include:
   • Receive also the face-image(s). If yes, those are encoded as b64 jpegs.
   • Receive also the voice-vector(s) / include voice registration in the process.
   • Receive also the document-image(s). If yes, those are encoded as b64 jpegs.
4. Our API accepts the request, and returns a unique session ID (USID) 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.
   You ask your end-user to start the app and initiate the authentication process with the Session-ID code that you provide on your portal/web-site.
5. Your end-user starts the app and enters the session ID code. The app is now ready and leads the user through the authentication process.
   User will see the following authentication screens:
   • Provide consent by scanning the MRZ from the document (ID-card or passport, both have MRZ section). This is assuming to be the agreement of proceeding with the NFC scan, as specified by ICAO 9303 standard. Optionally, you may ask the end-user to type in the three key pieces of data used for consent: Document number, Date of birth and Date of document expiry. However, it is assumed that it's much more user-friendly to let user scan the MRZ.
   • User is now asked to place the document close to the mobile phone, and to wait until it is read. Progress is being displayed.
   • User is asked to take a selfie, which is used for liveness detection and for biometric comparison with the document image.
   • If opted for during the session-intialization (by you): User is asked to speak a short phrase, which is used for voice biometric enrollment (and later in the process of voice authentication). for details on voice-enrolment and authentication, please see the Guide on speaker recognition.
6. All the data from our app (or lib) is sent extra-encrypted (custom PKI), on top of the standard HTTPS encryption, to our API-server which decrypts it and verifies it through a set of complex procedures. Those include internal cryptographic procedures, checking of the country-certificates for particular document(s) and checking the lists of lost/missing documents.
   After processing the document data, our server takes biometrics objects collected (facial and/or voice information) and transforms it into biometrically enrollable data (face-vectors and/or voice-vectors). This data is sent back to you together with the document data.
   As mentioned, you may opt to also receive the document-image(s) and/or face-image(s).
   Two facial images (document-image and selfie) are compared and liveness detection is performed. You receive the so-called "distance" between the two images, which is a measure of similarity. You may choose to use this distance as a threshold for your verification process.
   Vectorised (non-PII) data may be used by you to enroll (add to the user authentication data) your end-user,
7. After receiving all the data correctly and successfully, you may choose to store it in your own database, or to process it otherwise. You would send an "OK" message to our API server, which will then send a confirmation to the app, and the app will display the ending message to the end-user.