15 modules on one SDK, from sign-up to every payment.
Four families on one SDK: authentication, verification, intelligence and the decision. What one module binds at sign-up or login is what the next moment checks, so the more of the journey DeepID sees, the more each decision knows.
Decision
payment.initiate · S-0412Hold- Allow · reasons loggedNot seen
- Step up · face checkNot seen
- Hold · call backRisk
Reasons
- ACTIVE_CALL
- SCREEN_SHARED
- PAYEE_MULE_LINKED
Sent to
- Your appPayment paused. Your money hasn’t left your account. We’ll call you on +91 •••• 3210.
- Your FRMHOLD · active call · screen share · mule-linked payee
One SDK, four families, one decision.
DeepID puts 15 modules on one SDK, in four families. Authentication confirms the number with the network and binds the account to the customer’s own phone and SIM. Verification checks the identity against the records that issue it, reads the document, proves a live person is in front of a real camera and screens the lists that matter. Intelligence reads the device, the owner’s own behaviour, the call and the payee in every session. Decision turns every reading into one of six actions, with reason codes, sent to your app and your FRM.
The families are built to be checked against each other. What one module binds at sign-up or login, the face, the number, the SIM and the phone, is what the next moment checks. Each check can be beaten alone. Nobody stays consistent across all of them, so the more of the journey DeepID sees, the more each decision knows.
Your app calls DeepID once at each of five moments: sign-up, login, a new phone or SIM, a new payee and the payment. Each call reads the modules that matter there and returns one decision, from allow to block, with the reasons your rules can use and a message written for the customer. Most customers only ever see the first.
Teams start with one family and keep the KYC provider and the FRM they already run. Onboarding teams start with eKYC, liveness and the number confirmed by the network; login teams with silent network verification and SIM binding; fraud teams with the payee and mule graph, first on their own history. DeepID sits beside the FRM and feeds it.
Five things, bound at sign-up and checked at every later moment.
The face, the number and SIM, the phone, the payee and the session. Each is bound or first read once and checked again at every later moment, by the modules below. A fraudster can beat one check on its own; nobody stays consistent across all five, and the one that breaks says what the fraud is.
| What is held | Bound or first read at | Checked again at | Modules |
|---|---|---|---|
| The faceA live person on a real camera, matched to Aadhaar or the document at sign-up. | Sign-up | New phone or SIM | Liveness and face matchIdentity and eKYCDocument and ID verificationVideo KYC |
| The number and SIMThe number the network confirms, on the SIM bound to the account. | Sign-up | Login, New phone or SIM, New payee, Payment | Silent network verificationSIM and device binding |
| The phoneThe device the account is bound to: intact, and nobody else driving it. | Sign-up | Login, New phone or SIM, New payee, Payment | Device intelligenceSIM and device binding |
| The payeeWhere the money goes, scored against the mule graph before it leaves. | New payee | Payment | Payee and mule graphBank account verification |
| The sessionThe owner acting freely: their own rhythm, no call coaching them, no shared screen. | Login | New payee, Payment | Behavioural biometricsScam signals |
One tap to sign in, and the account stays bound to the phone.
The network confirms the number with nothing to type, then the SIM check, Aadhaar consent or a code when it can’t, and the account stays bound to the customer’s own SIM and phone.
- Silent network verificationOne tap to sign in. The strongest check the phone and network allow runs first, and the next takes over automatically when one can’t.Does the person holding the phone own this number?
- SIM and device bindingEach customer is bound to their own phone and SIM, and checked again whenever either changes.Is this the customer’s own phone?
Know who is opening the account.
Identity, documents, a live face and a clean record, verified at onboarding and whenever it matters again.
Identity
- Identity and eKYCAadhaar, DigiLocker, PAN and other IDs verified against the records that issue them, so every later step relies on one identity.Is this a real identity, and is it theirs?
- Document and ID verificationPassports, national IDs, driving licences and residence permits read and authenticated: the data page, the MRZ and barcodes, the chip and the security features, then matched to the live face.Is the document genuine, and is it theirs?
- Liveness and face matchA live person in front of a real camera, matched to their ID, with an instant answer on the phone and the final one from the server.Is it a live person, and the right one?
- Video KYCAgent-led and self-serve video KYC, with live face and document capture and the same deepfake checks as every selfie.Can we verify them remotely, on a live call?
Business and account
- Business verificationCompanies and merchants checked against GST, company and other registries, with their directors and owners verified like any customer.Is the business real, and who runs it?
- AML screeningSanctions, politically exposed persons and adverse media screened at onboarding, and monitored after it.Is this person on a list we must act on?
- Bank account verificationThe account is confirmed to exist and to belong to the customer before the first payout or mandate.Does the account belong to them?
- Run at onboarding, and again whenever it matters: a payout account is confirmed before the first settlement, and a list match goes to review with its source.
Read the call and the payee, before the money moves.
Session fraud intelligence: the device, the owner’s own behaviour, the call and the payee, read in every session. It is the part onboarding and login vendors leave out, and the reason one decision can cover the whole journey.
- Device intelligenceA device fingerprint that survives reinstalls and resets, and the device checked for tampering in every session.Which device is this, and can it be trusted?
- Behavioural biometricsHow someone types, taps, swipes and moves through the app, compared with how they usually do.Is the owner behaving like themselves?
- Scam signalsA real customer, on their own phone, can still be talked into sending money. DeepID sees the pressure in the session.Is the customer being manipulated?
- Payee and mule graphPayees, devices and accounts are linked, so a mule ring shows up before the payment leaves.Where is the money going?
Also on the same SDK: app hardening, runtime protection that keeps your own app from being hooked, debugged, tampered with or repackaged.
One decision, with its reasons.
Allow, warn, step up, cool off, hold or block, with reason codes, sent to the app and the FRM, and the journeys built around it.
- One decisionEvery signal becomes one decision with its reasons, sent to your app and to your FRM.What should the bank do?
- Journey builderOnboarding, login and payment journeys composed from these modules, with the checks, order and fallbacks your policy sets, per market.Can our teams change a journey without a release?
Also on the same SDK: AI agents, read like any other session and stepped up to the customer’s own phone when a payment is outside her pattern, and the developer tools for each moment.
Six actions, each with its reasons.
Only the risky session slows down. Each action carries a message written for the customer and a record for your FRM.
| Action | When | The customer sees | Your FRM receives |
|---|---|---|---|
| Allow | Everything holds | “Payment sent.” | ALLOW · known device · bound SIM · usual payee |
| Warn | Something is unusual, but the customer is in control | “This payee is new to you. Check the name before you send.” | WARN · first-time payee |
| Step up | Identity is uncertain | “Confirm it’s you with a quick face check.” | STEP_UP · new device · face check requested |
| Cool off | A new device, SIM or payee | “You can send up to the starter limit now. You get the full limit in 12 hours.” | COOL_OFF · new device 4 min · limit applied |
| Hold | Signs of coercion or a mule payee | “Payment paused. Your money hasn’t left your account. We’ll call you on +91 •••• 3210.” | HOLD · active call · screen share · mule-linked payee |
| Block | Clear attack | “We couldn’t verify this session. Your money is safe.” | BLOCK · virtual camera · emulator |
The messages are yours, in your app’s voice. Your fraud team tunes the policy per journey and market.
It feeds the FRM you already run.
Start with sign-up or login and keep your KYC provider, or use DeepID’s verification in full. Either way, DeepID sits beside your FRM and sends it one decision per moment, with its reasons. Nothing is ripped out.
One SDK, one call
Android, iOS, React Native, Flutter and web call DeepID at sign-up, login, a new phone or SIM, a new payee and the payment, from your mobile app, the web, the contact centre, agent and branch systems, and open APIs.
15 modules, one decision
DeepID checks each moment against what was bound before it, the person, the phone, the SIM and the payee, and returns one action with reason codes.
Your app, then everything behind it
Your app shows the customer the right next step. The same decision reaches your FRM, transaction monitoring and AML, case management, core systems, data platform, and SIEM and SOC as an event with its reasons.
Before you choose a family.
Where teams start, what stays, and how the decision reaches the systems you already run.
Where do teams usually start?
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.
Do we have to replace our KYC provider or our FRM?
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.
Is a network check enough to trust a login?
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.
Wire one moment in the sandbox, before any contract.
Sign-up or login end to end, with the decision back in the app and as an event, so your engineers see the shape of it before anyone signs anything.