What happens if they show a photo or a video from a screen?

Liveness treats a photo, a replayed video, a mask and a deepfake as a spoof of a live person.

Will a client manage on a weak phone and poor light?

Yes. The client takes one selfie on a regular smartphone, with no head turns. Hints help fix the frame before submit.

Can the system run in our own perimeter?

Yes. On-premise deployment is available so data is processed inside the lender’s perimeter.

Do we need a separate provider for list screening?

Sanctions, watchlists and PEPs can be checked in the same request. Results arrive with the session data.

Will we have to change scoring or CRM?

No. The check returns a verdict via SDK or API. Approve, decline and manual-review rules stay in the lender’s systems.

Biometrics for MFIs

The loan goes to the person named on it

Passport data can be genuine while the person behind the screen is not. In one session Biometric.Vision checks the document, that a live person is in front of the camera, and that their face matches the photo. The client only needs a smartphone to complete the full check in seconds.

Before disbursement, the risk team sees whether the applicant on camera matches the document owner.

Start free Request a demo

Session · loan_applicationPassed

matchface ↔ document

Document readpassport

Liveness confirmedlive person

Face matches passportmatch

AML screeningno risks found

Issue loanAll checks passed · before disbursement

A familiar story?

The data is real. The borrower is not

The application looks clean. The passport passes checks, scoring sees no reason to decline, the money is sent. Later the document owner calls and says they never applied.

Field validation will not stop that application: the fraudster used real data. What was missing is proof that the passport owner was the person in front of the camera.

An unsecured loan has no collateral to recover losses. On top of the payout come dispute handling, manual history review, and questions about how identity was established.

Passport dataScoring green · data valid

DATA VALID

↓ but on screen — not the owner

Took out the loanFraudster · someone else’s passport

NOT THE OWNER

The data is genuine. The borrower is not.

What changes in lending

A real client gets through. Stolen data does not help

A document and one selfie in the application flow: an honest client passes from a smartphone, while a loan on a leaked passport or a face spoof cannot be issued.

The client fixes the frame before submit

Hints help capture the document and selfie, and image quality is checked immediately. If glare or blur gets in the way, the client retakes the shot themselves — with no office visit.

A clear path with no branch visitConsistent rules across all channelsA scenario tuned to your risk profile

PASSPORT · ID

SurnameMORGAN

NameALEX

NumberAN 1234567

P<MORGANMORGAN<<ALEX<<<<<<<<<<<<<AN12345670UTO9406129M3001018<<

Hold it straight

Done

DocumentSelfieDone

A live document owner in front of the camera

Passport data alone is not enough. The client takes one selfie — no head turns or complex prompts. Passive liveness blocks photos, screen replay, masks and deepfakes; the face is matched to the document. Even with a victim’s full data, a fraudster will not pass.

One selfie on a regular smartphoneA different face and spoofs will not match the passportVerdict immediately in the API and dashboard

Anti-spoofloan_flow

Photo

Video

Masks

Deepfakes

Rejectednot a live owner

One face in your database

One face — one borrower

Someone changes the name on the form, substitutes another document, or comes back after a decline. To a regular check these look like new applications. Face search shows the applicant has already appeared.

Duplicates and repeat applications

The system matches the face against your application base. The risk team can spot duplicates, a series of applications under different data, or a new attempt by a previously declined client — before disbursement. Similarity threshold and manual-review rules are set by the lender.

Face search across your applicationsDevice and network signals for context

Applicant found in the database3 applications · 2 documents · 1 decline

Application 4201 · passport A

Application 4318 · passport B

Current · passport A

Repeat lending — shorter

A returning client does not have to repeat the full first-time path. On the next application their face is matched to the stored template — the path to a repeat loan is shorter, and identity control stays.

Session · repeat_loanFace Match

97%

Client confirmed

A trail for every disbursement

How identity was proven is in the audit log

Every check is recorded: which document was reviewed, how liveness and face match went, when the result arrived, and how the session ended. If a disbursement is questioned, the risk team answers from the record, not from an employee’s memory.

Sanctions lists, watchlists and PEPs can be checked in the same request — no separate integration path.

AML screeningin the same request

Sanctions lists

PEP · politically exposed persons

Wanted lists and watchlists

AML — clear

For developers

Classic integration for developers

If your team is used to assembling the architecture by hand — use our ready SDKs and API.

JS · Webview

Web SDK / Flow Widget

A ready JS camera widget for your site or embedded mobile browser (WebView). Fully themeable to your brand.

JavaScriptCustom designWebview

iOS · Android

Mobile SDK

Native libraries for mobile apps. Deep camera access and biometric micropackets even on weak 3G.

SwiftKotlinOffline-ready

Backend

REST API

Direct access to protected verification endpoints for your own server logic. Auth via private X-API-KEY.

RESTX-API-KEYServer-side

AI · Agents

MCP server for AI agents

AI agents connect to verification directly — without writing glue code. Works with Claude, GPT and any MCP client.

MCPClaudeAI-agents

loan_application — REST API

# Create an identity-check session before scoring the application

POST /v1/sessions

Host: api.biometric.vision

X-API-KEY: sk_live_••••••••••••••

Content-Type: application/json

{ "scenario": "loan_application", "checks": ["document", "liveness", "face_match"] }

# → 200 OK

{ "session_id": "sess_9f2a…", "status": "created", "url": "https://flow.biometric.vision/s/sess_9f2a…" }

Questions and answers

What risk teams usually ask

Document data alone is not enough. The applicant passes passive liveness, and their face is matched to the owner’s photo in the document.

500 checks a month — free

Lend to real borrowers

Run the check on real scenarios: someone else’s document, poor light, a repeat application, a face spoof. See how the result plugs into your scoring and what stays in the log.