Questions banks and fintechs ask about DeepID.

DeepID is the anti-fraud stack for India’s banks and fintechs: onboarding, one-tap login and fraud intelligence on one SDK. It verifies the customer at sign-up, signs them in without a code to steal, and checks every new phone, payee and payment against everything before it, then returns one decision with its reasons to the app and the FRM. Built in India, it serves banks and fintechs across India, APAC and the Gulf.

Teams usually start with one journey, sign-up or login, and add the rest of the stack when they are ready. Customers deal only with DeepID, end to end.

With sign-up or login. Onboarding teams start with eKYC, a live face check and the number confirmed by the network; login teams start with one-tap login and SIM binding. Fraud teams start with a free retrospective on their own history.

Whichever comes first, the same SDK binds the person, the phone and the SIM, so every moment added later has more to check against.

No. DeepID’s verification covers eKYC, documents, liveness and face match, video KYC, business verification, AML screening and bank account checks, and a bank can use all of it. A bank that already has a KYC provider can keep it and start with one-tap login or the session.

DeepID sits beside the FRM a bank already runs and feeds it one decision per moment, with its reasons. Nothing has to be ripped out.

The strongest check the phone and network allow runs first, and the next takes over automatically when it can’t. First the network check, where the carrier confirms the number over mobile data, even on Wi-Fi. Then the SIM check, where the phone sends one text to DeepID from its own SIM. Then Aadhaar consent in the Aadhaar app, and a one-time code last. The first that verifies ends it.

A device risk gate sits in front of every route, and the bank’s server redeems a single-use token with DeepID before it signs anyone in. The bank chooses the steps for each attempt, or requires all of them.

Yes. RBI’s Authentication Mechanisms for Digital Payment Transactions Directions, 2025, in force since 1 April 2026, keep two factors as the baseline and keep SMS OTP as a valid factor. Issuers may add risk-based checks beyond it.

One-tap login moves beyond SMS codes where the network or the SIM can confirm the number, and keeps a one-time code as the last fallback. Other markets set their own rules, and DeepID follows each market’s. DeepID supports compliance and never guarantees it.

RBI press release (opens in a new tab)

On its own, no, and DeepID doesn’t treat it as the decision. A network check confirms that the SIM for the number is in the phone making the request. A SIM swapped at a store would pass it.

That is why the same decision also reads the SIM and device binding from sign-up, the device itself and, on a new phone, a face check against the one from sign-up. A one-time code proves only that someone received the code, not who typed it.

Because nobody stays consistent across all of them. The face matched at sign-up is the face checked when the phone changes; the SIM bound at login is the SIM expected at payment; a phone seen at sign-up that later receives money from many unrelated senders is linked back to it.

So each moment is checked against everything bound before it, and the decision says which of them broke: the face, the number and SIM, the phone, the payee or the session.

Yes. Ask to try it on your own number, and we set up a short session in which you sign in on your own phone and see which check confirmed it. Your engineers can have sandbox access before any contract.

Login success, codes sent and cost per login for your customers are measured on your own traffic in a pilot. We publish no figures for them.

Not from one signal. A call during a payment is common. A 41-minute call with an unknown number, a shared screen, a payee saved minutes ago and typing in long pauses, all together, is not.

Your fraud team decides which combinations warn, cool off or hold, and sees what each would have done in the shadow proof before anything acts on a customer.

Some, if the policy is strict, which is why the shadow proof comes first. DeepID reads your live traffic without acting, and you compare its decisions with your own outcomes, including how many genuine payments each policy would have held, before you choose how strict to be.

You do. DeepID returns the action and the words your app shows. Your call-back team, your scripts and your channels stay yours.

Often, by reading the session rather than the credentials. In a coached payment the customer is real and every credential is theirs, but the session breaks: an active call across the payment journey, a shared screen, dictated typing, an unusual amount and a first-time payee linked to mules.

DeepID answers with a graduated decision, from a warning to a cool-off or a hold and call back, and a message written for the customer.

Mule accounts look normal one by one. DeepID links payees, devices and accounts across your book, so a payee that receives from many unrelated senders, or whose phone opened other accounts, is scored before money is sent to it.

It works alongside shared utilities such as RBIH’s MuleHunter.AI and claims no integration with them.

Liveness catches photos, videos, masks, deepfakes and injected camera streams. The customer gets an instant verdict on the phone, and the server gives the final one before the bank acts. When in doubt it fails closed: it denies or sends for review, and never passes.

The device is read at the same time for virtual cameras, emulators and hooking, every face check leaves a signed record that can be replayed, and face search finds one face behind many accounts.

It depends on how often your customers use the app, so it is measured on your own traffic during the shadow proof rather than promised up front.

Try one-tap login on your own number, and give your engineers sandbox access. Then a shadow proof on one journey, sign-up, login or payment: the SDK scores your own traffic without acting, measured against what you see today. Then limited production on that journey, and the next moment after it.

Fraud teams can start with a free retrospective on their own history, which shows the payee and mule links in their transactions. Session signals, such as an active call or a shared screen, only exist once the SDK runs, so they are proved in the shadow proof.

What you agree in writing before it starts. Usually four things: the fraud DeepID caught that your controls missed, the genuine customers it would have stopped, the effect on your review queue, and the time each decision takes. The genuine customers stopped is always one of them.

What your own history holds: the payee and mule links in 30 to 90 days of your transactions, such as accounts that received from many unrelated senders, payees shared across customers, and where the money in your closed cases went next.

It cannot show session signals, because an active call, a shared screen or the device are only read once the SDK runs. Those are proved in a shadow proof. What is shared, how and where it is held are agreed with your security team before anything is sent.

By the journeys you want to protect and the modules they need. DeepID sizes the tier with your team after the free retrospective, so the quote rests on what your own history shows.

The retrospective is free. Terms for the shadow proof are agreed in writing before it starts.

Implementation is scoped and quoted with the subscription.

Yes. Prices are set for each region: India, APAC and the Gulf.

Hosting, data residency and retention are agreed with your security team before the pilot, and sandbox access is available before any contract. The full security pack is shared on request.

DeepID decides inside the bank’s or payment app’s own journey, at login, new payee and payment, before the payment instruction is sent. The same decision works on each market’s real-time rail: UPI, PayNow, DuitNow, InstaPay, PayTo, Aani and sarie.

DeepID is built in India and serves banks and fintechs across India, APAC and the Gulf. Its rule map covers India, Singapore, Malaysia, the Philippines, Australia, the UAE and Saudi Arabia, each with dated rules and public sources. Which capabilities are live in each market is confirmed with you before a pilot.