One SDK for Android, iOS and web
Payee and mule graph Know where the money goes, before it goes.
Payees, devices and accounts linked across your book, so a mule shows when the payee is added, while the payment can still be stopped.
Why it matters.
Every mule is somebody’s payee first. Score it then, and the money never has to be chased.
Linked across your book
Payees, accounts, devices and SIMs, linked as they appear at sign-up, a new payee and the payment.
Scored before it’s saved
How old the payee’s account is, what it’s linked to, and who else is paying it.
Scored again at the payment
A payee that started receiving from strangers since it was added is caught before money leaves.
Proven on your history
A free retrospective reads the same links from 30 to 90 days of your own data.
Four layers of the payee and mule graph.
Read when a payee is added and again at the payment, across your whole book.
Each new payee scored before it is saved: how old the account is, what it is linked to and whether it receives from many unrelated senders.
An account receiving from many unrelated senders, the clearest sign of a mule, read before anything is sent to it.
A phone or a SIM seen behind other accounts links them, so one person running many accounts shows at sign-up.
Device intelligencePayees shared across customers, and where the money in closed cases went next, link accounts into the ring behind them.
Mule accounts, step by step
The graph adapts to every mule, wherever your customers are.
Mule accounts
Catch the account the money is going to, not just the one it leaves.
payee.addYour console
- Signal
- Account new, linked
- Decision
- Cool off
- Reasons
PAYEE_ACCOUNT_NEW PAYEE_MULE_LINKED
A payee two days old: the customer sees “Limit for now. You can send up to ₹10,000 to this payee now. You get the full limit in 12 hours.” Your console records Cool off, for Account new, linked, with PAYEE_ACCOUNT_NEW and PAYEE_MULE_LINKED.
payment.initiateYour console
- Signal
- Many unrelated senders
- Decision
- Hold
- Reasons
FAN_IN_UNRELATED
Many strangers paying one account: the customer sees “Payment paused. Payment paused. Your money hasn’t left your account. We’ll call you on +91 •••• 3210.” Your console records Hold, for Many unrelated senders, with FAN_IN_UNRELATED.
payment.initiateYour console
- Signal
- Rapid pass-through
- Decision
- Hold
- Reasons
RAPID_PASS_THROUGH
Money straight back out: the customer sees “Payment paused. Payment paused. Your money hasn’t left your account. We’ll call you on +91 •••• 3210.” Your console records Hold, for Rapid pass-through, with RAPID_PASS_THROUGH.
Mule rings
Follow phones and payees across accounts to the people running them.
signup.startYour console
- Signal
- Phone shared across accounts
- Decision
- Step up
- Reasons
SHARED_DEVICE
Many accounts on one phone: the customer sees “Confirm it’s you. Confirm it’s you with a quick face check.” Your console records Step up, for Phone shared across accounts, with SHARED_DEVICE.
payee.addYour console
- Signal
- Payee shared
- Decision
- Hold
- Reasons
ACCOUNT_SHARED PAYEE_MULE_LINKED
A payee shared across customers: the customer sees “Payment paused. Payee not added yet. We’ll call you on +91 •••• 3210 before anything changes.” Your console records Hold, for Payee shared, with ACCOUNT_SHARED and PAYEE_MULE_LINKED.
signup.startYour console
- Signal
- Face reused
- Decision
- Block
- Reasons
FACE_REUSED
One face, many accounts: the customer sees “Can’t continue. We couldn’t verify this session. Your money is safe.” Your console records Block, for Face reused, with FACE_REUSED.
Scam payees
Stop the payment to a payee others have already reported.
payee.addYour console
- Signal
- Payee reported
- Decision
- Hold
- Reasons
PAYEE_SCAM_REPORTED
A payee in reported cases: the customer sees “Payment paused. Payee not added yet. We’ll call you on +91 •••• 3210 before anything changes.” Your console records Hold, for Payee reported, with PAYEE_SCAM_REPORTED.
payment.initiateYour console
- Signal
- Mule-linked payee, call active
- Decision
- Hold
- Reasons
PAYEE_MULE_LINKED ACTIVE_CALL
A risky payee, on a call: the customer sees “Payment paused. Payment paused. Your money hasn’t left your account. We’ll call you on +91 •••• 3210.” Your console records Hold, for Mule-linked payee, call active, with PAYEE_MULE_LINKED and ACTIVE_CALL.
payment.initiateYour console
- Signal
- Usual payee
- Decision
- Allow
- Reasons
USUAL_PAYEE
A payee known for years: the customer sees “You’re in. Payment sent.” Your console records Allow, for Usual payee, with USUAL_PAYEE.
One SDK, every module.
The graph is weighed with everything else DeepID reads.
Scam signals
The call and the shared screen, while money moves.
Behavioural biometrics
How the owner types, taps and swipes, against this session.
Device intelligence
A fingerprint that survives resets, and tampering read every session.
SIM and device binding
The account bound to the customer’s own phone and SIM.
AML screening
Sanctions, PEP and adverse media, monitored.
One decision, with reasons
Allow to block, sent to the app and the FRM.
Read next.
Scam interventions
What to do when the customer is the one being played.
SIM and device binding
What each one ties down, and why banks use both.
Injection attacks
How a fake camera feed reaches a selfie check, and how the device gives it away.
Questions banks ask.
What does the graph link?
Payees, accounts, devices and SIMs across your book, as DeepID sees them at sign-up, at a new payee and at the payment. Adding accounts and payees from your own data widens the view, and the retrospective shows what each source adds.
Can we see this on our own data before a pilot?
Yes. A free retrospective reads 30 to 90 days of your transactions and closed cases and shows the payee and mule links in them: accounts that received from many unrelated senders, payees shared across customers, and where the money in closed cases went next.
Does it work with MuleHunter.AI?
It works alongside shared utilities such as RBIH’s MuleHunter.AI and claims no integration with them. The graph reads your own book, and the decision it feeds is yours.
Does the graph replace transaction monitoring?
No. Your transaction monitoring and FRM stay. The graph adds recipient and network risk as an input to them, before the payment is sent rather than after.
Try one-tap login on your own number.
See the network confirm your number with nothing to type, and the next check take over when it can’t. Then plan a shadow proof on one journey, measured on your own traffic.