Running an eKYC service: accuracy, data and APIs.

The numbers that describe accuracy

Every eKYC service makes mistakes. Running one well starts with naming them correctly.

For the face match (per comparison):

• False match rate (FMR): how often two images of different people score above the threshold. An impostor is accepted.
• False non-match rate (FNMR): how often two images of the same person score below it. A genuine customer is rejected.

For the whole transaction (per attempt to onboard): the FIDO Alliance, an industry standards body, uses the international vocabulary of ISO/IEC 2382-37:

• False accept rate (FAR) and false reject rate (FRR) describe the final accept or reject decision, which may combine several attempts.
• Failure to acquire (FTA): the system could not get a usable sample, for example because the image was too dark.
• Failure to enrol (FTE): the system could not create a record for an eligible person.

FMR and FNMR describe the algorithm; FAR and FRR describe the system your customers actually experience. They are not interchangeable.

For liveness and presentation attack detection, the test standard ISO/IEC 30107-3, as used in NIST's evaluations, defines:

• APCER: the share of attacks wrongly accepted as genuine, the measure of security;
• BPCER: the share of genuine attempts wrongly flagged as attacks, which NIST calls the rate of inconvenience.

Always ask for the threshold. Each pair of rates trades off against the other as the threshold moves. A vendor who quotes a false non-match rate without the false match rate it was measured at has told you nothing useful. NIST reports face matching as the false non-match rate at a fixed false match rate, and liveness as one error rate at a fixed level of the other.

A real example of targets. NIST's 2025 guidelines for US federal identity services require one-to-one face comparison to achieve a false match rate of 1 in 10,000 or better and a false non-match rate of 1 in 100 or better, and remote presentation attack detection with an impostor attack acceptance rate below 0.07, tested to ISO/IEC 30107-3. They are not rules for Kenya or the EU, but they show what precise requirements look like.

Fairness across groups

A face matcher can work well on average and badly for particular groups. NIST's landmark 2019 study of demographic effects (NIST IR 8280) found:

• False positive differences are much larger than false negative ones. False match rates varied between groups by factors of 10 to more than 100, while false non-match rates usually varied by factors of less than 3.
• False positives were generally higher for women, older people and children.
• The size of the differences depends heavily on the algorithm: some showed much smaller differences than others.

NIST's advice to system owners was to know their algorithm and to test on data that reflects their own operation, because lab results on other images may not match local users, phones and lighting.

Report errors per group at one threshold. Systems normally run with a single fixed threshold. NIST says that to understand fairness you must report both false positive and false negative rates for each demographic group at that threshold. NIST's 2025 identity guidelines add two rules for US federal services: a single fixed threshold for everyone, because adjusting it per group is not feasible, and no group may perform more than 25% worse than the population overall. For example, if the overall false non-match rate is 0.006, no group may exceed 0.0075.

Why it matters. A higher false non-match rate for one group means more of those customers are wrongly rejected and pushed to slower channels or turned away. A higher false match rate for one group means impostors who resemble that group get through more easily. Both are risks, and both are invisible unless you measure by group.

Kenya's Office of the Data Protection Commissioner, in its 2025 guidance on biometric data, says controllers must be satisfied that false positive and false negative rates are within reasonable limits for the size of the population they serve.

Testing and certification

NIST face technology evaluations. NIST runs two continuing programmes: FRTE for face recognition (including one-to-one verification and one-to-many identification) and FATE for face analysis, including presentation attack detection, morph detection and image quality. Developers choose to submit algorithms, NIST runs them on its own large datasets, and the results are published with the developer's name. By October 2026 NIST had evaluated 1,483 algorithms from 455 developers since 2017.

Two cautions:

• A NIST result is a benchmark, not a certificate. NIST requires participants to state that its results do not constitute an endorsement of any system, product or company.
• NIST's presentation attack evaluation (NIST IR 8491, 2023) tested passive, software-only detection on pre-recorded images. It did not test active challenge-response or hardware-based methods, so a good score covers only what was tested.

ISO/IEC 30107-3 sets the principles and methods for testing and reporting presentation attack detection, and classifies attack types. It does not define pass levels. When you see "Level 1" or "Level 2", that comes from a certification scheme built on the standard, not from the standard itself.

Certification schemes. The FIDO Alliance, an industry body, runs a face verification certification in which accredited laboratories test matching a selfie against an identity document photo and presentation attack detection, against published thresholds. Its requirements also cover deepfakes and injection attacks. Read the scope of any certificate carefully: document authenticity, for example, is a separate certification.

Injection attacks have their own European standard, CEN/TS 18099 (2024), which addresses detecting images or video fed into the system without going through the camera, and leaves presentation attack testing to ISO/IEC 30107.

Test it yourself, too. Every source points the same way: independent results tell you an algorithm can work; only testing on your own customers, devices and conditions tells you it does.

Protecting biometric data

Face images and templates are among the most sensitive data an organisation can hold. A stolen password can be changed; a stolen face cannot.

Treat it as sensitive. NIST's 2025 guidelines say biometric data must be "treated and secured as sensitive personal information". Kenya's Data Protection Act, 2019 lists biometric data as sensitive personal data.

Keep less. Kenya's 2025 guidance on biometric data explains that risk rises with the number of biometric features extracted, and gives the example of storing non-reversible templates rather than full images, encrypted. Ask whether you need to keep the original image at all once the check is done.

Protect what you keep. The guidance and the UK Information Commissioner's biometric guidance point to the same controls:

• encryption in transit and at rest, with secure key management;
• strict access controls and regular security audits;
• clear retention periods, with prompt deletion or anonymisation at the end;
• comparison methods that do not use unprotected biometric data directly.

Template protection. The international standard ISO/IEC 24745 covers protecting biometric information in storage and transfer. The UK regulator describes the properties to aim for: templates that cannot be reversed into the original image, cannot be linked across systems, and can be revoked and replaced. NIST notes that solutions offering all of this are still limited, so the other controls remain essential.

Consent and alternatives. Where processing relies on consent, Kenya's guidance says it must be verifiable and withdrawable, and people must have an alternative way to access the service.

In Kenya: under the Data Protection Act, 2019 and the Data Protection (General) Regulations, 2021, processing biometric data is treated as high risk, so a data protection impact assessment is required; the Act says the assessment report must be submitted 60 days before processing begins. A personal data breach must be notified to the Data Protection Commissioner within 72 hours. Check the current requirements, including any rules on where data must be stored.

APIs, verified claims and the audit trail

An eKYC result has to reach other systems: the onboarding app, the core banking system, a partner. How it travels matters for privacy and for audit.

Verified claims. The OpenID Foundation's OpenID Connect for Identity Assurance specification, final since October 2024, defines a standard way to send identity data together with how it was verified. A verified_claims element contains two parts:

• claims: the verified data itself, such as name and date of birth;
• verification: how it was verified, including the trust framework it was verified under (required), and optionally the assurance level, the time the verification was completed, a unique verification process reference for disputes or audits, and the evidence used, such as a document, an electronic record or a vouch, with details of the checks performed.

The specification keeps verified and unverified data apart, so a receiving system cannot mix them up, and lets the receiver ask only for the claims it needs, which supports data minimisation.

Federation. NIST's SP 800-63C-4 describes how one identity provider can send verified identity assertions to many services, with its own assurance levels for the strength of that exchange.

The audit trail. The EBA's remote onboarding guidelines ask for images, video, sound and data to be time-stamped, stored securely and kept readable for later checks. A good record answers, for every decision:

• which checks ran, in which version, with which thresholds;
• what each check returned;
• who reviewed the case, if anyone, and why the final decision was made;
• a reference that links the result sent to other systems back to this record.

In Kenya, the Central Bank of Kenya's 2025 guidance on customer due diligence gives examples of verification that an eKYC service may need to support: cross-checking national identity number, serial number and name against the population register (IPRS), checking a KRA PIN, selfie-based facial recognition for digital lenders and mobile money providers, and video calls to confirm presence. They are examples rather than a fixed list, so design the service to record which method was used for each customer.

Your certificate of completion

Enter your name as you want it to appear, then save the certificate as a PDF. In the print window, choose Save as PDF. A certificate is issued once per completion of the course.

Saolix does not record who takes this course, so it cannot verify these certificates. The certificate confirms completion of a free self-paced course and is not an accredited qualification.