Most KYC vendor evaluations collapse two very different questions into a single demo call. The first: can this platform connect to our stack? The second: does it hold the certifications our regulators and auditors will accept?
Treating these as one question is how teams end up halfway through an integration, only to discover that the sandbox environment doesn’t reflect production, the mobile SDK no longer supports iOS, or the vendor doesn’t hold the necessary certifications.
This checklist separates the two tracks. Work through both before you sign anything.
Why You Need Both Tracks
A platform that integrates cleanly but fails a regulatory audit creates legal exposure. A platform that holds every certification but cannot connect to your mobile app creates a failed launch.
The questions below are written for two audiences working in parallel: the engineering team evaluating integration depth, and the compliance or legal team evaluating certification coverage.
Track 1: Technical Integration
API Architecture
Start by understanding how the KYC platform communicates with your existing systems.
A well-documented API can make it easier for development teams to integrate identity verification into existing onboarding, authentication, or account-opening workflows.
Questions to ask the vendor:
- Is there a documented API for integrating verification into our backend?
- How are verification results returned to our systems?
- Does the platform support asynchronous verification results or webhook notifications?
- How are API versions and changes managed?
- What authentication and security mechanisms are used for API access?
- Are API documentation and testing environments available before implementation?
Web and Mobile Integration
The integration method should match how your customers interact with your product.
For businesses with mobile applications, native SDKs can provide a more integrated verification experience. Web-based flows can be useful when customers need to complete verification across different devices or when a business wants to avoid maintaining separate native implementations.
Questions to ask the vendor:
- Are native SDKs available for iOS and Android?
- Is there a web-based integration option?
- Can users start verification on one device and continue on another?
- How are camera permissions and device capabilities handled?
- How are SDK updates and compatibility changes communicated?
- Does the integration support the user journey and platforms used by your business?
Sandbox and Testing
Testing the integration before production is an important part of technical due diligence.
A suitable testing environment allows engineering teams to understand the API, simulate verification scenarios, and identify implementation issues before customers encounter them.
Questions to ask the vendor:
- Is a testing or sandbox environment available during the evaluation process?
- Can common verification scenarios be tested before production deployment?
- Are test credentials and documentation provided?
- Can developers test different verification outcomes?
- Is there a separate environment or process for pre-production testing?
Workflow Configuration
KYC requirements are rarely identical across every market, customer segment, or risk profile.
A flexible platform should allow businesses to configure verification journeys around their own requirements rather than requiring a completely new integration whenever a workflow needs to change.
Questions to ask the vendor:
- Can verification workflows be configured without extensive development work?
- Can different verification steps be combined into a single workflow?
- Can workflows be adapted for different markets or customer segments?
- Can additional verification steps be introduced when required?
- Can the user experience be customized or white-labelled?
- Can workflow changes be made without rebuilding the entire integration?
This is particularly relevant when businesses need to combine capabilities such as ID verification, liveness detection, face matching, AML screening, questionnaires, or Video KYC within a single onboarding journey.
Deployment and Infrastructure
Deployment requirements vary significantly between organizations.
Some businesses may use a standard cloud deployment, while others may have specific infrastructure, data residency, security, or operational requirements.
Questions to ask the vendor:
- What deployment models are available?
- Where is customer data processed and stored?
- Can deployment be adapted to specific infrastructure requirements?
- What documentation is available for security and infrastructure reviews?
Avoid treating one deployment model as universally necessary. The appropriate setup depends on the organization’s regulatory obligations, architecture, risk profile, and internal infrastructure.
Integration With Existing Systems
KYC verification rarely operates in isolation.
Verification results may need to feed into onboarding systems, CRM platforms, case management tools, fraud systems, or internal compliance processes.
Questions to ask the vendor:
- How can verification results be integrated with existing systems?
- What data is returned after a verification?
- Can verification results trigger downstream workflows?
- What integration support is available during implementation?
The goal is to understand not only whether the KYC platform can perform verification, but also how easily its results can become part of the organization’s broader operational workflow.
Document Coverage and Verification
Document coverage is an important consideration for organizations operating across multiple markets.
A platform should be evaluated based on the countries and document types relevant to the organization’s actual customer base rather than simply relying on a headline coverage number.
Questions to ask the vendor:
- Which countries and document types are supported?
- How frequently is document coverage updated?
- Does the platform support passports, identity cards, driving licences, and other relevant documents?
- Is NFC verification available for supported documents?
- How are unsupported or difficult-to-read documents handled?
Track 2: Compliance Certifications
SOC 2 Type II
SOC 2 Type II certification involves an independent audit of internal control policies and practices over a defined time frame, typically six months to a year. It covers five trust service criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy.
The distinction between report types matters. A Type I report describes a vendor's systems and whether their design is suitable to meet relevant trust principles. A Type II report details the operational effectiveness of those systems. Design suitability and operational effectiveness are not the same thing.
GDPR Compliance
GDPR Article 25 requires data privacy by design and by default, embedding appropriate technical and organisational measures into the complete lifecycle of products and services. Article 25 also specifies that an approved certification under Article 42 may be used to demonstrate compliance with privacy by design and privacy by default requirements.
The assessment should cover how personal data and biometric information are collected, processed, stored, retained, and deleted.
Questions to ask the vendor:
- Will the vendor enter into a Data Processing Agreement where required?
- Where is personal data processed and stored?
- What data retention and deletion controls are available?
- How is biometric data handled?
- What technical and organizational measures are in place to protect personal data?
- Can the vendor provide documentation needed for the organization’s privacy and security assessment?
The appropriate legal basis and privacy requirements depend on the organization’s role, jurisdiction, processing activities, and applicable regulations. These should be assessed with appropriate legal or compliance expertise rather than assumed to be identical for every KYC deployment.
eIDAS Compliance (EU Operations)
The eIDAS Regulation establishes the EU framework for electronic identification and trust services for electronic transactions in the internal market. Regulation (EU) 2024/1183, which amended the original eIDAS framework, was signed on 11 April 2024, published on 30 April 2024, and entered into force on 20 May 2024.
The updated framework introduces the European Digital Identity Wallet (EUDI Wallet), expands the use of electronic identification across public and private services, and introduces additional rules for trust services and digital identity. Each EU Member State is expected to make at least one EUDI Wallet available by the end of 2026.
Certain private-sector service providers that are required to use strong user authentication for online identification will also be required to accept EUDI Wallets under the conditions set out in the regulation. The framework covers areas including banking, financial services, telecommunications, healthcare, education, and other services.
For organisations operating in affected sectors or markets, EUDI Wallet support and a vendor’s roadmap for integrating with the European digital identity ecosystem may therefore be an important consideration when evaluating KYC and identity verification providers.
Ask the vendor:
- Does the platform support relevant eIDAS requirements for your use case?
- Does the vendor have a roadmap for EUDI Wallet integration?
- Can the platform support additional digital identity methods as the European framework develops?
Liveness Detection: iBeta Level 2 (ISO 30107-3)
iBeta certification is an independent biometric testing programme that certifies Presentation Attack Detection systems against ISO/IEC 30107-3, the international standard for biometric anti-spoofing.
iBeta Level 2 certification tests resistance to more sophisticated or varied presentation attack instruments and less predictable capture conditions. Specifically, it tests 3D mask attacks including silicone, latex, wrapped 3D paper, and cloth 3D masks. Level 1 covers only 2D attacks such as printed photos and screen replays. For any deployment where fraud risk is elevated, Level 2 is the meaningful bar.
iBeta certification is required by major biometric buyers including banks, fintech companies, and governments.
Ask the vendor:
- Has liveness detection been independently tested by iBeta against ISO/IEC 30107-3?
- At which level was certification achieved?
Pre-Contract Sign-Off Table
Every item below should have a documented answer before contract execution.
How Identomat Addresses These Requirements
Identomat provides a modular identity verification and KYC platform designed to integrate into existing digital onboarding journeys.
From an integration perspective, Identomat provides APIs, web integration options, and native mobile SDKs, allowing businesses to embed identity verification into their existing applications and user journeys.
The platform also provides configurable verification workflows, allowing businesses to combine different verification capabilities according to their requirements. These can include ID Verification, Liveness Check, Face Match, KYC Questionnaires, Video KYC, AML Screening, KYB, and other identity and compliance capabilities.
For organizations operating across multiple markets, Identomat supports verification across 193+ countries and thousands of identity documents. NFC verification is also available for supported documents.
Deployment options can be adapted to different infrastructure requirements, including cloud, private cloud, hybrid, and on-premises environments.
On the security and biometric assurance side, Identomat has SOC 2 Type II certification, while Identomat’s Liveness Check has achieved iBeta Level 2 testing under ISO/IEC 30107-3. Identomat also supports organizations with GDPR and eIDAS-related compliance requirements.
Identomat serves 150+ enterprises and government organizations across 22+ countries, including TBC Bank, Bank of Georgia, Paysera, and Credit Agricole.
This combination allows businesses to build identity verification and KYC workflows around their own technical architecture and operational requirements, rather than relying on a single fixed onboarding model.
If you are working through the checklist above and want to see how Identomat answers each item, request a meeting with our team.
Ready to get started?
Empower your platform with Identomat's cutting-edge KYC and AML ID verification.
Book a demo
Frequently asked questions
What is the difference between SOC 2 Type I and SOC 2 Type II?
A Type I report describes a vendor's systems and whether their design is suitable to meet relevant trust principles at a single point in time. A Type II report details the operational effectiveness of those systems across a defined window, typically six months to a year. For vendor due diligence, Type II is the meaningful standard. It demonstrates sustained control operation, not a point-in-time design review.
What does iBeta Level 2 actually test?
Level 2 tests 3D mask attacks including silicone, latex, wrapped 3D paper, and cloth 3D masks. This is a significant step up from Level 1, which tests only 2D attacks such as printed photos and screen replays. For any deployment where fraudsters may attempt physical spoofing, Level 2 is the certification to request.
Should I choose a KYC platform based only on certifications?
No. Certifications and independent assessments are useful evidence, but they should be evaluated alongside technical integration, workflow flexibility, document coverage, deployment requirements, data protection, operational support, and the specific needs of your business.
