The entire matching process — capturing your palm, extracting the vein/print pattern, and comparing it
against enrolled users — happens on the device itself. There's no call out to a server or the internet at any
point during a scan. This is a different mode from our connected/cloud deployments, which is why it
behaves differently in a few important ways covered below.

No. Once a device is enrolled with your users, it will keep matching and logging attendance/access events
with zero network dependency. This makes it a strong fit for sites with unreliable connectivity — factory
floors, warehouses, remote branches, basements, construction sites, etc.

Nothing leaves the device automatically. Enrolled palm data and event logs stay local to the hardware
unless you (or your integration layer) deliberately extract them — e.g. for backup, reporting, or syncing
into an HRMS/payroll system. There is no vendor cloud in this mode at all.

This depends on the specific terminal model and how the deployment is architected. We confirm exact
per-device capacity during technical scoping based on your headcount, rather than quoting a single
number that may not hold across different hardware — happy to size this once we know your expected
user count.

This is an important design question to raise with us upfront. In pure local mode, each device matches
only against what's enrolled on it, so multi-terminal deployments need a deliberate plan — either a
centralized enrollment/sync workflow we build into your rollout, or enrolling users at each terminal they'll
use. We scope this explicitly before deployment so it isn't a surprise later; let us know your site layout
(single entry vs. multiple gates/floors) and we'll design around it.

The palm-vein layer's job is identity matching (who scanned, when). Turning that into attendance reports,
payroll exports, or HRMS integration is the application layer built around it — which is exactly what
Gekonova delivers as part of a project (not something that ships "out of the box" from the biometric
hardware alone). We typically build a local reporting/export tool (CSV/Excel export, or a connector into
your existing HRMS/payroll software) as part of the solution.

The underlying capture and matching technology (RGB + infrared vein fusion, liveness detection) is the
same across both modes — accuracy isn't reduced by running locally. What changes is only where the
comparison happens (on-device vs. server), not the recognition algorithm itself.

Our fixed recognition terminals are built for exactly this use case — wall or desk-mounted, with wired
network (RJ45), USB, and serial connectivity, plus native support for door-access relays and Wiegand
card readers. That means it can either run standalone or slot into an access-control setup you already
have (existing card readers, door controllers, turnstiles).

Because enrollment data lives on the device, physical security of the hardware matters in local mode —
mounting it securely and controlling physical access to it is part of a sound deployment. We recommend
planning a backup/re-enrollment process as part of rollout so a hardware failure doesn't mean starting
from zero; we can advise on this during scoping.

Yes, this is a common growth path — e.g. starting with a single-site attendance deployment and later
wanting centralized, multi-site reporting. Because local and connected modes work differently under the
hood, moving to a connected setup later typically means planning re-enrollment (rather than a seamless
one-click migration), so if multi-site growth is even a possibility, it's worth telling us upfront so we can
design the rollout to make that transition as painless as possible.

Local/offline mode does not carry the same licensing model as our large-scale connected deployments
(which are tied to registered-user licensing at scale). Cost structure for a local deployment is scoped per
project — talk to us for specifics based on your device count and site requirements.