Home Use Cases Financial Authentication
USE CASES · FINANCE AND FINTECH

Financial Authentication

“The person on the other side of the screen — what exactly makes you certain it is them?”

Remote account opening and transaction approval rest on a submitted image. Deepfakes have made forged documents and replayed video easy, and that procedure is now under strain. UniverseAI installs the authentication engine inside your own servers — spoof detection and matching against your enrolled population finish inside your perimeter.

Send Your Requirements Request a Live Demo

What actually happens at a financial institution

We will not open with market size or growth rates. Here are the three scenes your team lives through every time.

SCENE 1 / REMOTE ONBOARDING
You cannot be sure the ID photo and the face are the same person
An ID document and a selfie arrive through the remote onboarding screen. A reviewer compares them by eye — but an image alone does not reveal whether it was captured from a live person or re-shot from a screen.
Cause: the procedure has no step that judges whether the submitted image came from a living person in front of the camera.
SCENE 2 / AFTER AN INCIDENT
One account takeover, and the mandate arrives outside your plan
A single takeover or identity-theft case triggers an immediate mandate to strengthen authentication. Regardless of the IT budget fixed at the start of the year, it becomes something you must answer within the quarter.
Cause: IDs, passwords and SMS codes pass straight through once stolen. Nothing in the chain verifies the person themselves.
SCENE 3 / SECURITY REVIEW
The technical review passes, then stops at where the data lives
The functional review concludes without issue. Then it emerges that biometric data would travel to a server outside the organisation — and the review halts right there.
Cause: in finance, where the data ends up is judged before what the product does. A design that sends it outside frequently fails internal review.
The three scenes resolve into one line — you have to verify the person (spoof judgement plus a match against the enrolled population), and that verification has to finish inside the organisation (installed on your servers, originals not retained). If the second half does not hold, the first half never even reaches review. That is why we start with where it is installed.

GATE alone covers this use case

We do not stack products here. The requirement in finance converges on a single line: authentication has to finish inside your servers. What satisfies it is one thing — an authentication engine installed on those servers.

A three-stage diagram in which a face image captured by your terminal is passed to GATE inside your own servers, goes through liveness judgement and 1-to-N matching, and only the authentication result returns to your systems The terminals are yours; the authentication runs on your own servers. Grey = what you already own / blue = what is installed inside your servers Already yours Inside your servers Already yours Terminals and apps Mobile app, ATM, branch Capture only No hardware swap GATE Authentication engine installed on your servers 1. Liveness — spoof detection 2. 1:N match — against the enrolled list Your systems Account opening Transaction approval Done by your systems Face image Result only Biometric data does not leave your servers (under an on-premises configuration) Storage is template-only — only the matching features remain; original images are not kept

What we deliver is the engine and the integration specification. ATMs, kiosks, branch terminals and mobile apps stay exactly as they are. Integration work is still required so that your terminals or the systems managing them call our server, and that work is carried out by your team or your SI partner.

ComponentWhat it does
LivenessScreens the common spoof attempts — printed photos, video replayed on a screen, masks. It is RGB passive, so no infrared camera has to be added and the user does not have to blink or turn their head.
1:N matchingFinds who this person is within a large enrolled population. It is harder than a 1:1 check (is this the account owner?) and it is the one financial institutions with large memberships actually need. 99.97% under KISA certification testing, with a response designed for under one second.
Face and palmRelying on the face alone stops dead under masks, backlight or changed appearance. Adding the palm gives a second route where the face is blocked, or a second factor layered on top for high-value transactions.
StorageTemplate-only. Only the feature data required for matching is stored; original photographs are not kept. Combined with on-premises installation, this is what makes it accurate to say biometric data never leaves your perimeter.
Deployment and redundancyInstalls on your own servers (on-premises), in the cloud, or into container environments such as Docker and Kubernetes. Active-active configuration with automatic failover is supported.
IntegrationREST API. We supply the integration specification; development is carried out by your team or your SI partner. We do not supply terminals.
“Why we do not add other products here.”
We also build video search (VCA) and edge compression (AI BOX). But those two solve retracing footage that has already accumulated and keeping footage from being deleted. Neither is the question that brought you to this page — is the person in front of the onboarding screen really them. If you also have a surveillance-video problem, we address that separately.

Adoption takes four steps

From confirming requirements to deployment — here is exactly what is exchanged at each step.

1
Confirm requirements
Population to be authenticated, daily authentication volume, terminal types, and deployment form (on-premises or cloud). With those four we draft a configuration and reply. We recommend running this review together with whichever team owns security — where the data ends up is usually assessed separately from functionality, and involving them early avoids a second lap later.
2
Live demo
We run liveness judgement and 1:N matching live. The fastest way to judge it is to hand us a printed photo and a replayed video on the spot.
3
Verify in your environment
You verify with your real lighting, terminals and enrolment image quality. Figures measured in certification testing do not reproduce as-is in the field, so testing in conditions close to your actual use is the most accurate route. Send us your requirements and we will propose the verification criteria.
4
Integration and rollout
We hand over the REST API integration specification. Development is carried out by your in-house team or your SI partner; we supply the engine, the specification and verification support.
Integration work always exists
No terminal hardware has to be replaced, but integration development is always required so that your terminals or the systems managing them call our server. Deciding early whether your in-house team or an SI partner owns that work is what moves the overall schedule most.

What we base these claims on

Only what has been measured and what has been deployed — followed by the limits, stated just as plainly.

99.97%
Accuracy under KISA certification testing
Under 1 sec
1:N response target (no millisecond guarantee)
400M+
Face database scale
4
Certifications: KISA, iBeta, GS 1st Grade, ISO
Reference

We hold a reference from operating a large-scale face payment service — an environment where a high daily volume of identity checks genuinely ran. We keep client names off the table outside, and yours is protected by the same rule.

Origin and deployment

A Korea-developed, non-Chinese vendor. Where your internal security policy or procurement specification treats vendor origin as a requirement, it is an eligibility criterion assessed separately from performance. If such a requirement applies, we prepare the supporting documentation.

Stated up front
  • Liveness screens spoof attempts such as printed photos, video replayed on a screen, and masks. Field performance tracks terminal camera quality and lighting, so we tune the decision thresholds to those conditions.
  • The accuracy figure was measured under KISA certification testing and shifts with on-site lighting, angle and enrolment image quality. We recommend verifying in your real environment first.
  • Response time is designed to the under one second mark. The actual figure is set by server specification, database size and the network segment, so send us those three and we will propose a configuration and prepare it so you can measure it in your own environment.
  • Some regulations treat templates as personal data too. We do not give legal interpretations — we state the storage method accurately, and the judgement belongs to your legal and compliance teams.
  • 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.
  • Your existing terminals stay in place. ATMs, kiosks, branch terminals and mobile apps remain the ones you already own — what we supply is the engine and the integration specification.

Frequently asked questions

The nine questions financial teams actually ask first.

Does biometric data leave our premises? We run a segregated network.
An on-premises configuration that installs the authentication engine on your own servers is supported, and in that configuration the data stays inside your environment. Cloud and container deployments (Docker, Kubernetes) are also possible. Once the deployment form is fixed, we document the exact data flow for you.
Do you store the original face photographs?
We do not. Only the feature data (the template) required for matching is stored — a template-only approach. That said, some regulations treat templates as personal data as well, and we do not offer that interpretation. We state the storage method accurately; the judgement is made by your legal and compliance teams.
Can it be defeated by a deepfake or by video replayed on a screen?
Liveness screens the common spoof attempts — printed photos, video replayed on a screen, masks. Field performance tracks terminal camera quality and lighting, so we tune the decision thresholds to those conditions. Trying it yourself in the demo is the most accurate way to judge.
Do we have to replace the terminals we already use?
There is no hardware replacement. Your ATMs, kiosks, branch terminals and mobile apps stay as they are. Integration development is required, however, so that the terminals or the systems managing them call our server, and that work is done by your in-house team or your SI partner. What we supply is the engine and the integration specification.
A 1:1 check seems enough — why would we need 1:N?
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. You need 1:N when identity must be established before an account is specified, or when one person must be prevented from enrolling under multiple accounts. Both modes are supported.
What about users for whom the face does not work well?
Face and palm can be used together. Where the face is blocked — masks, backlight, significantly changed appearance — the palm covers it, and for high-value transactions the two can be layered. Using the palm does require that your terminal camera can capture it properly, so we check capture distance, field of view and lighting first.
Can you confirm that this meets our regulatory requirements?
We do not provide legal interpretations. What we can provide are facts — where it is installed, what is stored and what is not, and how access rights and audit records are kept. Tell us which regulations apply and which internal review items you face, and we will prepare the supporting documentation in that format.
How are server load and redundancy handled?
Active-active configuration with automatic failover is supported. The actual configuration depends on enrolled population, daily authentication volume and concurrency, so send us those three numbers and we will review a configuration and reply. Guaranteed availability levels are set together in the contract.
What does adoption cost?
We respond with a quotation. Three inputs are required: the size of the population to be authenticated, whether you will install on your own servers or in the cloud, and your target deployment date. Send those and we will confirm a reply date immediately.

Related products

The product at the centre of this configuration, and the entry point if you would rather build against the engine itself.

GATE — Biometric authentication on your servers →

The deployment-boundary diagram, the specification table, every strength with its caveat, and where it does and does not fit
GATE API — When you build against the engine directly →

The entry point when you want the recognition engine itself inside your own service, rather than a finished authentication solution.

So verification finishes inside your organisation

Send us four things — population to be authenticated, daily authentication volume, terminal types and deployment form — and we will draft a configuration and respond with a demo schedule.

Send Your Requirements