← Back to Synergy
SYNERGY · IDENTITY SDK

Verify a person, anywhere, in under two minutes.

A drop-in identity kit for mobile and web. NFC chip reading, document capture and OCR (Latin, Arabic, Kurdish), passive liveness with face matching — orchestrated, hardened, and ready for production.

Primitives5
Verifies in~90 seconds
Regional OCRar · ku · latin · MRZ
NFC · DG2 face read
OCR · ar / ku / latin
Liveness 0.97
Verified · 1.4s
9:41 ●●●● 5G
Hold ID near the back
Keep the chip steady against the rear of your phone.
NFC
Reading chip · DG1 · DG2 · DG11
Capture the front
Hold the card flat. Edges will lock automatically.
Auto-snapping · perspective corrected
Look straight ahead
Move your head into the oval. Hold steady.
Liveness check · multi-frame
Verified
Completed in 1.4 seconds
NAMELayla A.
CHIP MATCH0.97
LIVENESSPASS
What it is

Five identity primitives, one orchestrator.

Identity verification looks like one product but it's actually five — and the friction users feel is almost always at the seam between two of them. NFC reads, but the OCR can't split a compound name. The document scans, but perspective is off. Face matches, but the liveness was passive and an attacker spoofed it.

Synergy Identity SDK ships those five pieces as a single kit and gives you the orchestrator that sequences them, validates between steps, and recovers when one fails. Every primitive is exposed as its own service. The example flow is real, hardened in a national-bank production deployment.
01

NFC ID Reading

Pull cryptographically-signed personal data straight off the chip.

02

Document Capture

Camera capture with edge detection and perspective correction.

03

OCR

Latin and MRZ on-device. Arabic and Kurdish through a Vision API.

04

Liveness Detection

Active, passive, or hybrid — multi-phase, no third-party redirect.

05

Face Match

Biometric comparison between a fresh selfie and a trusted reference.

The five primitives

Each one stands on its own.

Use the orchestrator and get all five sequenced for you. Or call any single primitive directly and wire it into a flow you already have.
01NFC ID Reading

Pull cryptographically-signed personal data straight off the chip.

A signed personal identity record from the chip itself — full name in Latin and Arabic, date of birth, expiry, issuing authority, gender, nationality. A high-resolution face photo from the secure data group is used as the reference image for face matching. For regionally-issued cards, additional data groups are parsed and exposed.

StandardISO 7816 APDU over NFC
AuthenticationBAC with optional PACE
Read time4–8s, warm-started in ~2s
Failure modesDetected with actionable messaging
CHIP
DG1 · MRZ
DG2 · 132kB face
DG11 · arabic name
DG13 · region data
02Document Capture

Camera capture with edge detection and perspective correction.

Real-time corner tracking auto-snaps when the document is stable. Per-frame de-skew gives you a flat document — not a photo of one. Modes are configurable per flow: single-page for an ID card front, multi-page for passport spreads or two-sided residence cards.

Edge detectionReal-time corners, auto-snap
PerspectiveDe-skewed every frame
OutputCropped JPEG, ready for OCR
ModesSingle, multi, gallery import
03OCR — Dual Engine

Latin and MRZ on-device. Arabic and Kurdish through a Vision API.

The fast on-device engine handles Latin script and MRZ bands offline. The Vision-API engine handles Arabic and Kurdish on the front of the card, where compound names and right-to-left labels need a stronger model. Outputs are cross-validated against the chip data so mismatches surface immediately.

On-device~200–400 ms · Latin · MRZ
Vision API~1.0–1.5 s · ar / ku
Compound namesPreserved end-to-end
Cross-checkOCR ≈ chip · auto-advance
MRZ · Latin · on-device
P<IRQAL-FALEH<<ALI<ABD<AL<RAZAQ
~280 ms
Front · Arabic · Vision API
علي عبد الرزاق فالح
~1.1 s
04Liveness Detection

Active, passive, or hybrid — multi-phase, no third-party redirect.

The user follows on-screen prompts — closer, back, hold steady — and the SDK collects multi-frame depth and position evidence. The check runs entirely from in-app assets in a sandboxed webview; no traffic leaves the device. Languages, thresholds, and phase configuration are all tunable per deployment.

ArchitectureIn-app sandboxed webview
PhasesMulti-phase distance check
NetworkNo traffic leaves the device
LanguagesEnglish, Arabic
↑ closer↓ back
05Face Match

Biometric comparison between a fresh selfie and a trusted reference.

The match runs during the liveness phase — the user does not take a separate selfie. The reference image is whatever you trust most, typically the chip face photo, falling back to the card-front capture if NFC is unavailable. Output is a match score and a pass/fail verdict.

ReferenceChip · card · or your image
ThresholdTunable per deployment
UXSingle pass, no extra selfie
OutputScore 0–1 + verdict
CHIP
LIVE
0.94✓ MATCH
Orchestration

Five primitives don't make an onboarding flow — until something sequences them.

The SDK ships with a step-based orchestrator that turns the primitives into a guided flow. The example we use everywhere — and the one running in production — is 16 steps, with persistent state, cross-step validation, and recovery routing built in.
01
Card front capture
Document
02
MRZ scan (back)
DocumentOCR
03
NFC instruction
04
NFC scan
NFC
05
Name verification
OCR
06
Liveness + face match
LivenessFace Match
07
Review personal info
08
Passport (optional)
Document
09
English transliteration
Tier 1 · Drop-in

Use the orchestrator as-is

The full regional flow, configured for your auth + branding. Fastest path to production.

EFFORT · DAYS
Tier 2 · Customize

Skip, reorder, inject

Drop steps you don't need. Reorder the ones you do. Inject your own (custom KYC fields, internal compliance gates).

EFFORT · A WEEK
Tier 3 · Primitive

Wire your own flow

Skip the orchestrator entirely. Call individual primitives from your own onboarding code. Three lines per primitive.

EFFORT · A SPRINT
Regional fit

The kit was not built in San Francisco.

Most identity SDKs treat Arabic as an afterthought. Synergy Identity SDK was built specifically for the MENA market, by a team in MENA, against MENA documents. If your market is here, you don't have to build any of this. If it isn't, the regional code is opt-in — the international primitives stand on their own.
IQ SA AE EG TR MA
01
Arabic name handling

Compound names like "عبد الرزاق" stay as one part across chip read, OCR, display, and submission.

02
Kurdish field-label fallback

When Arabic OCR confidence is low, Kurdish labels on the same document are used to recover the same field structure.

03
Regional ID data parsing

Region-specific data groups (religion, blood type, registry) are exposed — most kits drop these.

04
Right-to-left UI

Every screen in the example flow is RTL-correct, including capture overlays and the face oval.

Privacy

Identity data should be the most carefully-handled data your app touches.

We treat the verification path as if it were nuclear. On-device first, encrypted at rest, no third-party SDKs in the path, application-level encryption on every API call, and active runtime hardening against rooted or tampered devices.
On-device first

Local where it can be

Chip reading, capture, MRZ extraction, and liveness all run on the device.

Encrypted at rest

Keystore / Keychain

In-flight onboarding state lives in OS secure storage. Never in plain prefs.

No third parties

No telemetry by default

The verification path has no analytics, no third-party SDKs, no redirects.

Hardened

RASP-protected

Root, jailbreak, debugger, and tampering detection refuse to read on a compromised device.

Application-level encryption

Every API call carrying personal data rides an additional AES-CBC envelope on top of TLS — defense in depth against TLS-MITM and against logging at the load balancer.

Pluggable OCR

Only Arabic OCR calls out to a Vision API. You can swap in your own provider if data residency requires it — the SDK is agnostic.

State lifecycle

Onboarding state is cleared automatically on completion or abandonment. Nothing lingers in encrypted storage past its purpose.

Integration

A few lines for a full flow. More lines if you want more control.

The SDK ships in three forms today, with more on the way. Flutter is the reference implementation, used in the running national-bank app this kit was extracted from.
flutter.dart android.kt SOON ios.swift SOON web.ts ROADMAP

Drop-in (full flow)

One call to IdentitySDK.onboard(...) returns a typed result with the ID card, scores, and status. Configurable per deployment with auth token, branding, and skip rules.

Primitive (direct call)

Skip the orchestrator and call any primitive on its own — NFCReaderService, DocumentCapture, OCRService, LivenessService, FaceMatchService. Wire them into a flow you already have.

Who uses it

Anywhere identity has to be verified remotely.

The same primitives compose into very different products. Pick the mix you need.

Bank account opening

NFCDocumentOCR (ar)LivenessFace Match

Fintech onboarding

DocumentOCRLivenessFace Match

Mobile insurance claims

DocumentOCRLiveness

Crypto KYC

NFCDocumentLivenessFace Match

Gig-worker verification

DocumentOCRLiveness

Re-verification kiosks

NFCLivenessFace Match
Real numbers

Numbers from the production deployment.

Tunable to your environment. The defaults below come straight from a national MENA bank running this kit at scale.
~90s
Median onboarding · clean run
88%
NFC success on first attempt
94%
Arabic name auto-match vs. chip
Capability matrix

What runs where.

The SDK is mobile-first. Web support is rolling out — biometric primitives are live there now, with capture and OCR on the roadmap.
Primitive Mobile Tablet Web
NFC ID Reading
Document Capture roadmap
OCR (Latin / MRZ) roadmap
OCR (Arabic / Kurdish) roadmap
Liveness Detection
Face Match
Get started

Verify a real person in your app this week.

Integration-ready today for Flutter. Native Android, iOS, and web are next on the roadmap. Talk to us to scope a pilot, get the docs, and try the example flow against your test environment.