Digital onboarding is often described as a quick selfie. For a bank, fintech platform, telecom service or marketplace, however, a selfie is only one piece of an identity decision. A person needs to be connected to a claimed identity; the captured image must be usable; and the service needs a policy for what happens when the evidence is uncertain.
Face verification is a component of that journey—not the entire eKYC system. AttFace Core can contribute face detection, image quality checks, liveness capabilities and 1:1 comparison. Document capture, document authenticity, sanctions screening, account risk and legal KYC obligations belong to other components or to the integrating partner's process.
Concept illustration; not a real AttFace UI, verified identification result or customer deployment.
A simple onboarding moment
Imagine a customer opening an account from home. They first enter their details and capture an identity document with the host application. The app then asks for a live face capture. A good experience explains why the camera is requested, provides immediate framing feedback and avoids repeatedly uploading blurry attempts.
If the flow is document-to-selfie comparison, the application must extract a reliable portrait from the document using a separate document-processing component. The face engine compares that portrait to the live capture under an agreed threshold. Where a liveness step is required, it should be evaluated as a distinct signal, not hidden inside a single unexplained match score.
Design the pipeline as separate decisions
The important engineering choice is to preserve the meaning of each result. Detection answers whether a face was found. Quality checks whether the image is fit for the next stage. Liveness or presentation attack detection evaluates the risk of spoofed capture. A face match reports similarity to an enrolled reference; it does not authenticate the document itself.
Reference integration workflow; not a screenshot of a deployed customer implementation.
If the selfie is too dark, prompt for better lighting instead of asking a customer to repeat document upload. If the result is borderline, send the case to a documented retry, additional factor or review path. Only the application owner should convert the combined evidence into an onboarding outcome.
SDK on device, API on server, or both?
Mobile SDKs are useful close to the camera, where capture quality and user feedback affect completion rates. An API or on-premise service may be appropriate when business logic, audit trails and policy enforcement are centralized. The best partition depends on device trust, latency, network conditions and data residency requirements.
For an on-device path, protect locally stored templates and use scoped, short-lived access to verification events. For a server path, authenticate the calling application, encrypt the transport, set retention rules and avoid exposing biometric templates to unrelated systems. Neither architecture removes the need to test spoofing and injection threats relevant to the deployment.
The questions a product team should answer first
- Is verification against a document portrait, an existing account enrollment, or both?
- Will the flow fail closed, request another factor, or enter manual review when uncertain?
- What documents, age groups, devices and lighting conditions are in scope?
- Which party is the controller for biometric data, and how can a user request deletion?
- How will thresholds, retry limits and demographic performance be validated on representative data?
These are product requirements before they become camera requirements. A polished selfie interface cannot compensate for an undefined decision policy.
Where AttFace Core fits
AttFace Core is relevant when a partner already owns onboarding, identity orchestration or account creation and needs a face-AI building block. Its face pipeline can be integrated into a mobile application or a private service according to the chosen deployment. The partner retains control over legal compliance, document verification and the final acceptance decision.
A useful pilot measures both security and customer experience: incomplete captures, retries, false matches, false non-matches, escalation volume and time to completion. Report those metrics from a properly scoped evaluation rather than borrowing generic accuracy claims.
Fraud controls beyond face matching
An identity platform needs to define its attack surface: stolen documents, manipulated images, scripted clients, enrollment substitution and account takeover can occur at different points. Face liveness controls address some presentation attacks, but they do not verify that a document was genuinely issued or that the account request has a trustworthy origin. Device integrity, network controls, document checks and review queues should be part of the broader design.
For a pilot, map each control to a specific risk and owner. This reduces the temptation to market a single face-verification API as a complete anti-fraud product. Establish a process for testing replay or injection attempts, investigate patterns of repeated failures and document when additional evidence is appropriate.
An integration contract teams can maintain
A clean integration should return a reference to the verification attempt, stage-specific status, decision metadata allowed by policy and an auditable transaction ID. Keep the actual SDK method names in implementation documentation rather than publishing illustrative return fields as a production contract. Define expiry, idempotency and secure retry behavior with the identity-platform team. A predictable API boundary makes the onboarding flow easier to maintain even when models or capture methods evolve.
Build verification into your own onboarding product
If your product already manages onboarding and you want face verification without rebuilding the inference engine, explore AttFace Core. AIPractix can discuss a pilot architecture, deployment options and the boundaries between your identity platform and the face SDK.
