Sandbox access
A sandbox comes before any contract. It is where your engineers wire one moment end to end on your own app, see what comes back in the app and as an event, and where the reason codes your FRM rules will use are agreed with your fraud team.
Names and fields are illustrative and agreed in the sandbox before any contract.
On this page
What it includes
- 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.
What to bring
- The journey and the first event
Usually sign-up or login for onboarding and login teams; a new payee or the payment for fraud teams. One moment, wired end to end, is the aim.
- Your platforms
Android, iOS, React Native, Flutter and web, and whether the app is native or a framework.
- Who redeems the token
For login: which of your services signs customers in, since it redeems DeepID’s single-use token server to server.
- Where decisions go
The FRM, case manager or SIEM that should receive the event, and the queue names your team already uses.
- For the retrospective that follows
30 to 90 days of your own history, so DeepID can show what it would have read at the time.
Agreed before a pilot
Sandbox access needs none of this. A pilot does, and all of it is settled in writing with your security team first; the full security pack, with its data-handling detail, is shared on request.
- Hosting
Where DeepID runs for your bank is set with your security team before the pilot starts.
- Data residency
The country your customers’ data is held in is agreed before any of it is sent.
- Retention
How long decision logs and face-check records are kept is settled in writing first.
What the SDK does in your app, and what is agreed first.
From sandbox to production
Proof before you commit. Everything after the sandbox is measured on your own traffic, against criteria agreed in writing before the pilot starts: detection lift, the change in false positives, the effect on the review queue and the decision time in the journey. DeepID publishes no figures for these.
- Try one-tap loginBefore any contract
See the network confirm your own number with nothing to type, and the next check take over when it can’t.
- SandboxBefore any contract
Your engineers wire one moment end to end and see what comes back, in the app and as an event.
- Free retrospectiveFree
DeepID analyses your own history and shows what it would have read at the time.
- Shadow proof6 to 8 weeks
DeepID scores live traffic without acting on it. You compare the results with your own outcomes.
- Limited production8 to 12 weeks
Live decisions on one journey, such as new payee or onboarding, with a rollout plan.
Before you ask
What is in the sandbox?
The SDK for Android, iOS, React Native, Flutter and web, the call at each of the five moments, and the decision with its reasons as your app and your FRM will receive them.
It is where your engineers try the SDK and the decision object on your own app, and where the reason codes your FRM rules will use are agreed with your fraud team.
Do we need a contract first?
No. Sandbox access is available before any contract.
Hosting, data residency and retention are agreed with your security team before a pilot, in writing, and the full security pack is shared on request.
Which moment should we wire first?
Usually 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 often start at the new payee or the payment, where scams and mules show.
Each later moment is one more call from the same SDK, and its reasons join the same decision.
Can we see one-tap login before we wire it?
Yes. Try one-tap login on your own number: the network confirms it with nothing to type, and the next check takes over when it can’t, down to a one-time code.
In the sandbox the same login runs in your app, and your server redeems the single-use token with DeepID before signing anyone in.
What does DeepID publish about decision time, SDK size and uptime?
Nothing on this site. Decision time inside your journey, what the SDK adds to your app’s size and start-up, and availability are measured in the sandbox and the shadow proof on your own traffic.
Any figure DeepID quotes comes with its method, its dataset and its date.
What happens after the sandbox?
A free retrospective on 30 to 90 days of your own history, then a shadow proof of 6 to 8 weeks that scores live traffic without acting on it, then limited production of 8 to 12 weeks on one journey.
Success criteria are agreed in writing before the pilot starts: detection lift, the change in false positives, the effect on the review queue and the decision time in the journey.
Does the sandbox replace our FRM or our KYC provider?
No. DeepID sits beside your FRM, which keeps its own rules, queues and cases; the decision reaches it as an event with its reasons. If you have a KYC provider, the verification modules run where your journey needs them and nothing else changes.
DeepID supports compliance with the rules your market sets. It never claims to guarantee it.
Not sure which team starts where? Which team starts where sets out each team’s first step, and the engineering page what the integration asks of yours.
Request sandbox access.
Tell us the team, the first moment and your platforms. We reply with access for your first moment, and the questions your security team will want settled before a pilot.
Not sure where to start? Which team starts where sets out each team’s first step, or book a demo first.
See DeepID on a real phone.
We show your fraud, security and engineering leads how DeepID would run your sign-up, login or payment journey, then plan a pilot on your own traffic.