eKYC architecture: identity verification as a reusable capability

Why eKYC has to be a separate architectural capability

Historically eKYC was built for a single task — onboarding the customer at the moment of SIM purchase. Today identity verification is needed in dozens of scenarios:

• Registration in the operator’s app.
• SIM recovery after loss.
• Self-service for tariff change above a threshold.
• Connecting a fintech product through the operator.
• Identity bridge for a partner bank (signed token).
• Compliance check on a suspicious transaction (step-up authentication).

Every scenario uses the same steps: document, biometrics, liveness, registry check. If each team builds its own stack — there are 5 different eKYC flows with different accuracy and compliance.

eKYC as a platform capability: one engine, consumed by many scenarios.

Structural components

Document capture. Capturing the document — passport, ID, driver’s license. With UX guidance (place in the frame, rotate), automatic quality detection.

Document validation. OCR + structural validation (form, holograms, MRZ for passport, watermarks). Fraud detection — identification of forged or edited documents.

Biometric capture. Capturing selfie/face. With ML models optimised for mobile capture conditions (poor light, motion blur).

Face matching. Matching the face from the selfie with the face on the document. Score with threshold.

Liveness detection. Active (asks to turn the head, blink) or passive (texture and depth analysis). Defence against photo / video / mask attacks.

Registry checks. Calls to government registries (passport valid, person exists, not on blacklist). In Uzbekistan — through OMS or the unified identification platform.

Risk scoring. Combined score: document quality + face match + liveness + registry + behavioural signals. Decisioning: pass / step-up / decline.

Audit. Every verification event with full evidence chain (document scan, selfie, scores, registry response, decision, timestamp). For post-fact dispute resolution and regulator queries.

Where it usually breaks

The stack is assembled from several vendors, and each is responsible only for its part. When there is a “why was it rejected” question, there is no single point of accountability.

OCR works on 80% of documents, the remaining 20% go to a manual queue. The queue grows, customer experience deteriorates.

Liveness detection is outdated, fraud cases (deepfake, screen replay) get through. Six months later the team discovers inflated activations.

Registry check is the bottleneck. The government API is unavailable 30% of the time, eKYC stops.

Reuse is not implemented. The customer who passed eKYC at SIM purchase passes it again in the app. UX suffers, customer cost grows.

Identity bridge for partners is built ad-hoc, without a security audit. The bank accepts a signed token in which the signature is not verified.

Identity bridge use case (partner verification)

If the operator has a verified identity, it can issue a signed token to a partner: “this person is verified, passport X, biometric match, last verification 30 days ago”. The partner accepts the token instead of repeating the check.

Architectural requirements:

• Token format: JWT or VC (Verifiable Credentials) signed by the operator.
• Scope claims: what is verified (identity, address, age).
• Freshness claim: how much time has passed since last verification.
• Consent claim: the customer agreed to share with partner X.
• Revocation: a way to revoke the token on consent withdrawal.

This is not “give the data to the partner”. This is “confirm the fact of verification” — the partner gets a claim, not raw data.

Operating model

Owner — Head of Identity / Head of Trust. Not fraud, not IT — a product identity function.

Teams:

• Platform engineering (capture, scoring, integration)
• Identity science (biometric models, fraud patterns)
• Compliance (regulator requirements, KYC level)
• Partnership (identity bridge contracts)

Routine — monthly review of pass/fail/step-up rates, fraud incidents, partner usage.

What is measured

Pass rate — what share of verifications goes through without manual review.

Manual queue size and SLA — how many are in the queue, how long review takes.

Fraud detection rate — what share of fraud attempts are caught.

False reject rate — how many legitimate customers were rejected.

Time to verify — end-to-end latency.

Reuse rate — what share of verifications by new capabilities is satisfied by existing identities (without full re-KYC).

How SamaraliSoft engages

eKYC Blueprint — 8-10 weeks. Inventory of current eKYC fragments by product, target architecture (capture, scoring, registry integration), identity bridge framework for partners, stack choice (build / Onfido / Jumio / local). Pilot — usually one scenario (for example, app onboarding) or one partner identity bridge.

Related

• /en/architecture/telecom-consent-architecture/ — consent for bridge
• /en/architecture/telecom-partner-api-platform/ — partner API
• /en/insights/telecom-trust-platform/ — operator as trust layer
• /en/solutions/telecom-trust-platform-cornerstone/ — trust platform solution