The free retrospective
A free retrospective on 30 to 90 days of your transactions and the fraud cases you closed. DeepID shows what history can hold: the payees and mule accounts linked to those cases, and where the money went next. Data handling is agreed with your security team before anything is shared.
What your history can show
From 30 to 90 days of your data
- 01Payees linked to your closed fraud cases
- 02Accounts that receive from many unrelated senders
- 03Payees shared across many of your customers
- 04Money passed on within minutes of arriving
Session signals, such as a call or a shared screen, are not in history. They are proved in a shadow proof, once the SDK runs.
What history can show, and what it can’t.
Your transactions hold the payee and mule links. Session signals only exist once the SDK runs in your app, so they are proved in a shadow proof, not read from history.
Payee and mule links
In the retrospective, from your history
- Payees linked to your closed fraud cases
- Accounts that receive from many unrelated senders
- Payees shared across many of your customers
- Money passed on within minutes of arriving
Free, on 30 to 90 days of your own data, by the payee and mule graph.
Session signals
In a shadow proof, once the SDK runs
- An active call or a shared screen while money moves
- The phone, its integrity and remote-access tools
- The SIM and number bound at sign-up and login
- Typing, hesitation and dictation
Scored on live traffic for 6 to 8 weeks, without acting on it. Read by scam signals and device intelligence.
Cases this showsMule accounts Digital arrest Investment scams
Your transactions in. The links in them, out.
For every case you closed, the read-out shows the stage at which DeepID would have flagged it, and the payees and accounts still active that share its links.
What you send
Your own transactions.
- 30 to 90 days of transactions, with their payee identifiers
- The fraud cases you closed in that period
- Your outcomes, so the results can be compared with what you already know
What DeepID does
Builds the payee and mule graph.
- Links payees and accounts across your transactions
- Follows where the money in your closed cases went next
- Marks accounts that receive from many unrelated senders and pass money on fast
What you get
A read-out on your own book.
- The mule clusters and payees linked to your closed cases, and the stage at which each closed case would have been flagged
- Payees still active that share those links
- A plan for a shadow proof, for the signals history cannot hold
What it looks at in your industry.
Each industry starts with a first analysis on its own data. These are the analyses DeepID runs, described; what each finds is yours, on your own book.
| Industry | First journey to protect | The first analysis | What it shows |
|---|---|---|---|
| Banks | New payee and high-value transfer, then onboarding | A mule retrospective on 90 days of accounts and transfers | The mule clusters the bank’s controls missed, and the value that passed through them |
| Digital banks | Onboarding and device change | A deepfake and injection test on the onboarding flow | Which injected faces the flow lets through today, and which it would stop |
| Lenders | Application and disbursal | A back test on defaulted loans | The first-payment defaults the application data would have flagged |
| Payments | Wallet onboarding, merchant onboarding and payouts | A mule wallet and merchant ring analysis | The rings found, and the value that passed through them |
| Insurance | Claims intake and self-inspection | A claims evidence test on a sample of past claims | The edited or generated evidence found |
| Capital markets | Account opening and payout | A mule trading account review | The accounts flagged, and the value held in them |
Agreed with your security team before anything is shared.
What is shared, how it is shared, where it is held and for how long are settled first, in writing. Nothing moves until they are. The security page sets out what the SDK reads and how data is handled.
What is shared
You choose which 30 to 90 days of transactions, payee identifiers and closed cases to send.
How it is shared
How the files reach DeepID is set with your security team before any of them move.
Where it is held
The country your data is held in while the read-out is built is agreed first.
For how long
How long DeepID keeps your data after the read-out, and when it is deleted, is written down.
The second of four steps.
Try it, then the retrospective, then a shadow proof, then limited production. Each one is your choice, and none acts on a customer until the last.
- Step 1:
Try it
We set up a short session with you on your own number. You sign in on your own phone, on your own carrier, and see which check confirms it. Your engineers can have sandbox access to wire one moment end to end.
- Step 2:
Retrospective
The payee and mule links your history holds, on your own cases.
- Step 3:
Shadow proof
The SDK runs and scores live sessions without acting, so the call, the screen, the phone and the SIM are measured against your own outcomes.
- Step 4:
Limited production
Live decisions on the first journey, such as sign-up, login or a new payee, with a rollout plan, then the next moment.
Success criteria, agreed in writing before the proof.
Four measures, each taken on your data against what you see today.
- Fraud caught
- How many more of your fraud cases are caught than today.
- False-positive change
- How many genuine customers are stepped up or held, compared with now.
- Review-queue impact
- What happens to the volume your analysts work through.
- Latency
- How long a decision takes in your journey.
Ask for a retrospective.
Tell us which journey worries you and the case that got through. The regional team replies with a data request and the security questions to settle first.
Before you ask
What does a free retrospective show?
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.
How do we prove it works before committing?
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.
Where is our data hosted, and for how long?
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.
Every question, on one page.
Bring us the case that got through.
Tell us the journey and the period, and the regional team sends the data request and the security questions to settle first. Or bring fraud, risk and security to one session.