Beware: 5 Most Common IDV System Implementation Pitfalls

Implementing an identity verification system is not only an exciting project with many potential upsides, but also a complex undertaking with many potential pitfalls. And while a number of issues can be simply tied to poorly designed technology, they are not the subject of today’s discussion. Today, we’d like to share our personal experience with problems that can arise quite naturally, even if the IDV technology is very reliable. 

From user flow complications to questionable Zero Trust practices, we’re exploring the most common failure points that can hinder your KYC and fraud prevention efforts.

Drawing from many years of experience, we can confidently say that the number one issue can be summed up as deteriorated user experience.  

As the new IDV system is being introduced, users are facing processes that they may not have seen before anywhere else. If these new processes aren’t user friendly, many potential customers may give up before becoming real customers—industry research shows that conversion drop-offs can be as high as 60–70% when the onboarding process is too complex.

Unclear instructions are a major culprit here; if the app doesn’t clearly show how to position an ID for scanning, or fails to explain an active liveness prompt, users are left guessing. Younger users will have little trouble winking at the camera or slowly turning their head, but elderly users or people from less tech-oriented backgrounds may find it confusing. That’s why it’s worth including more passive liveness detection, since it doesn’t require the user to perform extra actions, and is considered more user-friendly.

Another often overlooked factor is language and cultural localization. Our 2023 survey found that 70% of digital nomad users encountered language difficulties during verification, which negatively affected completion rates. 

Lack of accessibility is also worth mentioning, as people with disabilities or even temporary impairments can feel challenged by unaccommodating software. Users with low vision or color blindness often struggle with unclear visual indicators, while those with motor impairments might not be able to simply hold their phone steady.

Ideally, the ID verification process should be as simple as possible: automatically collect only necessary information and use a combination of OCR, MRZ, and barcode reading to auto-fill forms. The solution should also be able to automatically detect the document type for minimal user interference. 

Additionally, NFC verification (for RFID chips) can be performed, which includes passive authentication along with active or chip authentication that is secured with server-side verification of the RFID chip’s data. Also, it should seamlessly check authenticity, as well as if a document is live and not a screen replay by checking hologram OVI, MLI and/or dynaprint.

It’s also important to support the user flow with immediate feedback every step of the way, i.e., telling the user what is happening right now and what exactly went wrong (if it did). This way, users feel they are not left alone in the process and they are actively being helped by the system, as opposed to a frustrating “submit and pray” scenario.

Another major pitfall in ID verification implementation that we see is inadequate testing—especially when handling a wide variety of IDs from all over the world. Some businesses integrate an identity verification solution using just a handful of samples (often whatever team members have on hand, like a few local driver’s licenses or passports).

In production, however, real users will present all sorts of passports, ID cards, visas, and driver’s licenses from different countries and generations. They differ not only in language and format, but in security features, data encoding (MRZ, barcodes, chips), and even certain quirks like naming conventions. So if the system hasn’t been validated against them, there is a high risk of unexpected failures and false rejections once it goes live.

If a company lacks access to such resources, they may consider using a testing toolkit (if provided by their IDV vendor). For instance, Regula provides a unique NFC TestKit that includes a set of test IDs with NFC chips, personalized with the data of fictitious identities or those provided by the customer. These test IDs are simplified images of the required pages of the documents the company intends to verify; however, they are not replicas of real IDs. Additionally, an experienced vendor like Regula will provide expert advice on how to deal with non-trivial situations like a certain country’s IDs not being fully compliant with international standards.  

Facial recognition also falls victim to poor testing, as users will often take selfies in less-than-perfect conditions—and they need to be accounted for. A dimly lit room, harsh backlighting from a window, a cluttered background at home, and many other environments can cause trouble. We’ve seen cases where a strongly patterned wallpaper or a picture frame behind the user caused the software to misidentify facial contours. In one instance, even a square-shaped object right behind the person’s head interfered with the face detection algorithm—an unexpected “false face” pattern that threw off the system.

Tuning an identity verification system is a balancing act between security and usability, among other things. While it’s important to reduce the risk of letting a fraudulent user through, dialing the system to ultra-conservative settings can backfire. It may start rejecting a large number of legitimate users, which, naturally, hurts the business by turning away real clients.

This problem is most clearly seen in facial biometric matching—if the match score threshold is very high, even the same person’s photo and selfie might score below that threshold. Overly aggressive document authenticity checks are another case: if you configure the system to flag the slightest discrepancy as “fraud,” you’ll end up failing authentic IDs that may have minor wear and tear or uncommon layouts. 

How to avoid this? It’s recommended to use a risk-based approach where only certain signals are high risk like a mismatch in personal information or a device with a fraud history. Only in such cases should the system escalate to more checks; otherwise, keep it smooth. Additionally, important metrics like false rejection rates should be monitored at all times: if, say, 5% of all applicants are failing document verification but manual review finds most of them were legitimate, that’s a sign that the settings are too rigid.

In remote ID verification, zero trust to mobile means the backend does all the heavy lifting (e.g., image analysis, data extraction, liveness checks), since the user’s device cannot be trusted with these operations. This is overall a great idea, and we advocate for it ourselves, but only if it’s approached with nuance. 

Just as Zero Trust reduces the chance of client-side tampering, it can also lead to major backend overload and latency. If every single operation is done on the server, the user’s device becomes just a dumb camera and input collector. The client app might capture a photo and immediately send it to the server with no pre-processing—and the server then has to do all image cropping, quality checking, text recognition, and so on. 

For one, it increases the round-trip times—users may have to wait several seconds to find out if their ID image was acceptable or if their selfie passed the liveness check. Secondly, if your user base scales, your servers must handle a huge volume of raw image processing. High-resolution photos or multiple retry attempts can chew up CPU/GPU time on the backend, and an influx of verification requests could slow the entire system or drive up costs significantly.

On the flip side, a zero-trust security model can still be maintained while also using client devices for pre-processing and data collection efficiency. All data in transit can be encrypted, and the system can still use the client’s CPU to perform face detection on the live camera feed. The server can then “not trust” the result until it verifies it, but if the client didn’t even detect a face, you’ve saved the server from doing pointless work on a blank image. This way, RFID chip reading is performed on a mobile app and the signed data is sent to the server for validation, which takes seconds.

Some businesses only offer web products to their users—not a problem in itself, but the expectations from an IDV system should then be curbed. A web-only approach severely limits what identity verification methods you can use, as certain advanced features just won’t work in a browser or will perform poorly compared to a mobile SDK.

In the case of ePassport processing, mobile web browsers have little to no support for NFC interactions for security reasons. And even for more conventional features, mobile web has constraints. The browser camera settings can’t be tuned as finely as in a native app, and some older devices or browsers might not support real-time video processing. 

If an app is absolutely out of the question, there are workarounds, but they are far from perfect. A “web-to-mobile handover” can be implemented, where the user in a desktop or mobile browser is prompted to use their phone camera via a link or QR code. This at least gets a mobile device into the loop for image capture, but it is still clunky.

Regula boasts over 30 years of experience in the IDV industry, and we know that almost no implementation goes without hiccups. When integrating our solutions, we already know what to expect, and we make sure any customer issues are resolved as quickly as possible.

As for solutions themselves, we offer powerful IDV products for all organizations, combining document forensics and face recognition.

Regula Document Reader SDK is a highly customizable cross-platform solution that processes images of documents and verifies their real presence (liveness) and authenticity. The software identifies the document type, extracts all the necessary information, and confirms whether the document is genuine. On top of that, the SDK leverages mobile NFC verification and complete server-side verification to confirm the genuineness of the RFID chip.

At the same time, Regula Face SDK conducts instant facial recognition and prevents fraudulent presentation attacks such as the use of static face images, printed photos, video replays, video injections, or masks.

Regula offers a database with 15,000+ identity documents from 251 countries and territories, and a unique NFC TestKit service, providing you with ID samples with NFC chips for more efficient testing and shorter time to market.

Let’s drive the future—together. Book a call to learn more about our solutions!