Wherever authentication is needed, the same GATE stands.
Face and palm engines run inside; the field sees one REST API. Surveillance, attendance, payment and access all call the same server.
Request a Demo Request an Integration Scope ReviewAuthentication sits immediately before the transaction. Nothing is paid, no door opens and no attendance is recorded until it is passed. That makes authentication not one feature among many, but the door a service starts behind.
Payments, finance and access control are places where the budget does not disappear. When authentication stops, the transaction stops — so it is treated as something to keep running rather than something to cut.
Demand moves from face to palm, then to fingerprint and iris. None of them fully replaces another; which method is used comes down to the conditions on site.
In most setups, changing one method means rebuilding the integration. So authentication becomes a question of whether the engine can be swapped, before it is a question of how good the engine is. That is the job a platform takes on.
Not laboratory figures — deployments in operation and accredited test results.
A strength stated without its caveat becomes an overstatement, and overstatements come back as claims after deployment. So we print the caveats in the same place.
A 1:N search finds who this person is within an enrolled population; a 1:1 check confirms that this person owns this account. Both run inside the same GATE, so a control room that must first work out who someone is and a payment counter that only needs to confirm it is them are covered by one server.
Caveat — the two modes demand different server resources. Tell us which one you will mainly use and your daily volume, and we will draft the configuration accordingly.
A 1:1 check confirms that this person owns this account. A 1:N search finds who this person is within a large enrolled population. The second is far harder, and it is what payment, transit, and public-sector operators with large membership bases actually need.
Caveat — the real configuration depends on enrolled population, daily authentication volume, and concurrency. Give us the numbers and we review and reply; we do not confirm on the spot.
RGB means it runs on ordinary colour cameras. No infrared or other special hardware has to be added. Passive means the user does not have to blink or turn their head. It screens the common spoof attempts: printed photos, video replayed on a screen, and masks.
Caveat — field performance tracks camera quality and lighting. We review the installation environment, tune the decision thresholds to that site, and prepare it so you can verify in your own environment.
A site that relies on the face alone stops dead whenever the face does not work: masks and hats, backlight, growing children, users whose appearance has changed. A palm gives you a second route where the face is blocked, or a second factor layered on top for high-value transactions.
Caveat — using the palm requires that your terminal camera can actually capture it. We check capture distance, field of view, and lighting first, then give you a definite answer.
Whatever engine runs inside, what your site systems call is a single documented REST API. Your development team or SI partner can build from the documentation alone, and an issued key lets you call it in a test environment first.
Caveat — the integration work itself is carried out by your team or your SI partner. We supply the specification and the test environment, and map the integration scope with you.
In one line: the terminals are yours, and the authentication is done by GATE running inside your servers. Drawing this line first is what prevents the "this is not what we were told" moment later in the project.
We do not sell terminals. ATMs, kiosks, POS devices, and mobile apps remain the ones you already own. What we deliver is the software engine that performs the matching behind them, together with the integration specification. There is no terminal hardware replacement, but there is integration work, carried out by your own team or your SI partner.
The integration specification is published as a documented commercial REST API. 1:1 verification, face enrolment and match-history lookup are provided under the same specification.
Open the Developer Docs →# 1:N face match — request example (multipart) POST /api/v1/feature/face/identify Authorization: Bearer <accessToken> X-Api-Key: <project API key> Content-Type: multipart/form-data # matchingFeatureImage=<face image> # Response { "success": true, "data": { "matchType": "IDENTIFY", "featureId": "abc123-def456", "similarity": 97.00, "checkLiveness": true, "transactionUuid": "550e8400-..." } }
The deployment shape depends on your environment. Send us the environment and we will draft a configuration and reply.
| Item | Specification |
|---|---|
| Deployment | On-premises on your servers, cloud, or container environments |
| Authentication Modes | 1:N large-scale search and 1:1 precise matching |
| Biometric Modalities | Face and palm (separately or combined) |
| Spoof Detection | Liveness (RGB passive; no separate IR camera required) |
| 1:N Response | Designed for under one second (the actual figure is measured against server specification and database size) |
| Face DB Scale | 400M+ face database |
| Accuracy | 99.97% under KISA certification testing |
| Certifications | KISA, iBeta, GS 1st Grade, ISO |
| Storage Method | Template-only. Feature data for matching is stored; original images are not |
| Redundancy | Active-active with automatic failover (guaranteed availability levels are a contractual matter) |
| Integration | REST API (specification supplied; development by your team or SI) |
| Terminals | Your existing devices are used (we do not supply terminals) |
| Data Location | Held within your own environment under an on-premises configuration |
The screens differ and the names differ from site to site, but at the moment identity is confirmed, the same GATE is running.
Behind the control-room screen, GATE is what pins down who the person is.
It runs a 1:N match against the enrolled list and returns only the result to the control system. Your cameras and control screens stay as they are; only the matching engine moves into the server. If you also need condition-based video search, VCA is worth evaluating alongside it.
GATE is the authentication server that face-recognition attendance terminals call.
A student stands in front of the terminal, GATE matches against the enrolled list and returns whether it is them; the attendance record and the notification are handled by the school system. Feature data for matching is kept in place of the original photograph. With growing children the gap from the enrolment photo widens, so we set a re-enrolment cycle with you.
Behind stored-value face payment and the POS, GATE is what confirms identity.
After a one-time enrolment, a face carries the customer through to payment with no card and no phone. GATE's part ends at confirming identity; deducting the balance and approving the payment are picked up by the payment system. In this area we hold a reference from the country's largest face payment service.
It confirms that the person in the entry log was actually them.
It narrows the borrowed-card and stand-in problem that card and fingerprint terminals carry. Opening the door and writing the attendance record are done by your systems; GATE returns only the identity result. The more sites you run and the larger the enrolled population, the more 1:N is worth.
GATE is where authentication engines come to stand. Standing there now are our own face and palm engines and liveness; other methods will come into the same place.
Fingerprint, iris and third-party liveness are being prepared for the platform. Release dates and specifications are not settled, so we do not print them. When they are, they will appear here.
Once cloud-only authentication services and vendors blocked by origin requirements are taken out, what remains is narrow. That is where we stand.
In finance and the public sector, a design that sends biometric data outside the organisation often fails internal review, and cloud-only authentication services stop there. GATE can be installed on your own servers, and it also runs in cloud and container environments.
Caveat — whether a given regulation applies is a judgement for your compliance team, not ours. We prepare the material they need for that review.
We do not stockpile face or palm photographs. Only the feature data (the template) needed for matching is stored; the original image is not kept. Combined with on-premises installation, this is what makes the statement accurate: biometric data never leaves your perimeter.
Caveat — some regulations treat templates as personal data too. We do not give legal interpretations. We state the storage method accurately; the judgement belongs to your legal and compliance teams.
Some procurement specifications and internal security policies treat vendor origin as an eligibility requirement. In those situations, being Korea-developed is not a performance advantage. It is eligibility to bid at all.
Caveat — vendor origin is an eligibility requirement, assessed separately from performance criteria. If such a requirement exists, we prepare the supporting documentation.
If any one of the following applies to you, this is the right fit.
Sites where the face alone is not enough — dual-modal face and palm means the palm covers the situations where the face is blocked.
Procurement with a vendor-origin exclusion — we are a non-Chinese vendor.
Environments where biometric data cannot leave the organisation — an on-premises installation on your own servers, storing feature data for matching rather than original images.
1:N sites with a large enrolled population — 99.97% under KISA certification testing, a 400M+ face database, a 1:N response designed for under one second, and a reference from operating a large-scale face payment service.
Tell us which requirement matters most and we will propose how to verify that one.
Three things make a site eligible: (1) a data centre or cloud environment to host the authentication server, (2) terminals or apps that capture face or palm images, and (3) an in-house development team or SI partner to do the integration.
In practice, these are where it usually lands.
Finance and fintech — remote identity verification and account-takeover defence. The security team is the gate, and on-premises deployment plus template-only storage is the answer to their first question.
Retail and payments — identity checks handled on the servers of the company operating the payment platform.
Transit — matching images sent by gate and boarding terminals, where the enrolled population is large enough that 1:N scale is itself the requirement.
Access control and public ID — multi-site consolidation or identity verification with large enrolled populations.
Theme parks, hotels, airports — the more repeat visitors, the more 1:N is worth.
An organisation with an app but no servers — GATE installs onto servers, so without infrastructure to host the engine our solution alone does not complete the picture.
A single retail outlet — in face payment our customer is the company operating the payment platform, not one store. Store-level enquiries are documented and passed to the right person.
One office building with a handful of doors — there is usually little reason to stand up a server solution.
No party to do the integration — without a team to make the terminals or management system call our server, the deployment does not complete.
That said, we do not cut the decision off ourselves. We record the environment, scale, and requirements as stated, and reply after review.
Running it under the conditions you will actually use is more accurate than reading a document. We start by setting the verification criteria with you.
Face and palm authentication, spoof screening, 1:N matching against a large enrolled population, template-only storage that keeps no original biometric images, on-premises installation on your servers, and the REST API integration specification — all of it can be documented for you, and all of it can be confirmed by result in an environment close to your actual conditions. Send us your requirements and we will propose the verification criteria and reply; where a deeper technical review is needed, we arrange a dedicated session.
The entry point when you want the recognition engine itself to build against, rather than a finished authentication solution.
If you need the device itself, that is a separate product track. GATE is the authentication server solution; look here for terminals.
The eight questions we receive most often during evaluation.
Products commonly evaluated alongside this one.
After a one-time enrolment, the payment flow needs only your presence
Condition-combination search on face, body, colour and carried items, plus companions and routes
1:N authentication, liveness and face indexing, delivered as an API
Send four things — terminal types, the size of the population to be authenticated, the installation environment (your own servers or cloud), and your target deployment date — and we will reply with whether the configuration works, what the integration covers, and a quotation.
Send Integration Requirements