DeepID developer documentation
One SDK in your app, one call at each of the five moments, and one decision object for your app and your FRM. Eight pages set out the integration, so your team can judge the work before it starts in the sandbox.
Names and fields are illustrative and agreed in the sandbox before any contract.
How it fits together.
Four steps, whichever moment you start with. The SDK reads the session; your app asks at the moments fraud happens; one decision comes back, and the same decision reaches your FRM.
- 1
Start the SDK once
When the app opens. From then on it reads the session: the network and SIM, the device and its integrity, the owner’s rhythm, an active call, a shared screen. Your app passes none of this. SDKs.
- 2
Call at each moment
Sign-up, login, a new phone or SIM, a new payee and the payment. One call each, before the action takes effect, with your own identifiers and nothing else. Events.
- 3
Branch on the action
One of six comes back: allow, warn, step up, cool off, hold or block, with reason codes and a message written for the customer. Handle all six, so a new rule never falls through. The decision object.
- 4
Receive the same decision as an event
Your FRM, case manager or SIEM gets the decision with the same reasons, and a queue when a person needs to act. Stored once, by its id. Webhooks.
One decision, with its reasons.
Ananya Rao, 41 minutes into a call and sharing her screen, starts a payment of ₹96,000 to a payee added 3 minutes ago, an account 2 days old and linked to 14 others. The payment is held, she reads why, and your FRM receives the same four reasons.
To your app
decision.json
{
"decision_id": "dec_7q2_118",
"event": "payment.initiate",
"session": "ses_8f2c91ab",
"action": "hold",
"reasons": [
{ "code": "ACTIVE_CALL", "module": "scam" },
{ "code": "SCREEN_SHARED", "module": "device" },
{ "code": "DICTATION_PAUSES", "module": "behaviour" },
{ "code": "PAYEE_MULE_LINKED", "module": "graph" }
],
"message": {
"key": "payment_paused_callback",
"text": "Payment paused. Your money hasn’t left your account. We’ll call you on +91 •••• 3210."
},
"queue": "scam-callback",
"policy": { "id": "retail", "version": 14 },
"created_at": "2026-10-22T12:53:34Z"
}Where to go next.
Eight pages, in the order an integration team reads them: from sandbox access to the event in your FRM.
Quickstart
From sandbox access to a decision in your backend.
ReadSDKs
Install, start once and the first call, per platform.
ReadEvents
When to call, what to pass and what comes back, per moment.
ReadThe decision object
Field by field, with who reads each: app, FRM, audit.
ReadReason codes
The catalogue, by module, with what each code means.
ReadPolicies
The policy model, a worked policy and a version diff.
ReadWebhooks
The same decision in your FRM, case manager and SIEM.
ReadSandbox access
What it includes, what to bring, what is agreed first.
Read
What integration teams get.
Everything your engineers need to wire one moment end to end and see what comes back, before anyone signs anything. The full security pack, with its data-handling detail, is shared on request.
- The SDK for your platforms
Android, iOS, React Native, Flutter and web: one SDK, whichever moment you start with.
- The call at each moment
Sign-up, login, a new phone or SIM, a new payee and the payment, with the event names and fields you will build against.
- The decision and its reasons
Allow, warn, step up, cool off, hold or block, with reason codes and the message for the customer, as your app receives them.
- The event your FRM receives
The same decision as an event, for your FRM, case manager or SIEM, so your rules can be written against it before anything is live.
- The reason codes your rules will use
The catalogue, agreed with your fraud team in the sandbox, so the codes in your FRM rules are the ones the decisions carry.
- Before any contract
Sandbox access needs no contract. Hosting, data residency and retention are agreed with your security team before a pilot.
Questions engineers ask.
The two that come first. The rest are on the sandbox page, and in the questions banks and fintechs ask.
Which events should we send?
Sign-up, login, a new phone or SIM, a new payee and the payment are the five. Start with one, usually sign-up or login, and add the rest on the same SDK.
Each call is read against everything earlier in the session, so a payment called after a login and a new payee has more to check against than a payment called alone.
Where is data handling described?
On the security page, and in the security pack shared on request: what the SDK reads in your app, where each check runs (an instant verdict on the phone, the final one from the server), and what is agreed before a pilot.
Hosting, data residency and retention are agreed with your security team before a pilot, in writing.
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.