Reason codes
59 codes, grouped by the module that reads them: 44 that say why a session looks unsafe and 15 that say what held. Every decision lists its codes, risk first, and the same codes reach your app, your FRM and the decision log.
Names and fields are illustrative and agreed in the sandbox before any contract.
On this page
Reading codes
- Risk codes say why a session looks unsafe.
ACTIVE_CALL, SCREEN_SHARED, PAYEE_MULE_LINKED. A decision lists them first. Trust codes say what held, such as NUMBER_VERIFIED when the network confirmed the number, so an allow is as explained as a hold.
- Codes are inputs to your policy, not a score.
A rule fires on a condition that names a signal, and the signal is recorded as its code, so the rule that fired and the reason it fired are the same record. Your FRM rules can be written against the codes directly.
- Each code names the module that read it.
In the decision object,
reasons[].modulecarries it; on this page, the codes are grouped by module, in the platform’s order. “Seen in” links the use cases whose reasons carry the code; a code with none is read in every clean session, or is not tied to one use case.
Silent network verification
Authentication. One-tap login: the mobile network confirms the number silently, then the SIM, Aadhaar or a code. About silent network verification.
| Code | Kind | Meaning | Seen in |
|---|---|---|---|
| NUMBER_VERIFIED | Held | The mobile network confirmed that the number belongs to the SIM in this phone, over mobile data. No code was sent. | Any clean decision |
| NUMBER_UNVERIFIED | Risk | The network could not confirm the number on this SIM, so the next route took over: the SIM check, Aadhaar consent or a one-time code. | Not tied to one use case |
| CODE_FALLBACK | Risk | The number was verified by a one-time code, the last fallback, rather than by the network or the SIM. | Not tied to one use case |
| SIM_SWAP_RECENT | Risk | The SIM for this number changed shortly before this event. The window is set in your policy. | Account takeover |
SIM and device binding
Authentication. The account bound to the customer’s own phone and SIM. About SIM and device binding.
| Code | Kind | Meaning | Seen in |
|---|---|---|---|
| SIM_BOUND | Held | The SIM in this phone is the one bound to the account at sign-up, or re-bound after the customer proved it was them. | Any clean decision |
| KNOWN_DEVICE | Held | The device bound to this account, by an id that survives reinstalls and resets. | Any clean decision |
| NEW_DEVICE | Risk | The first session on a phone that is not bound to this customer. In the story, 4 minutes old. | Account takeover, Insider fraud |
| SIM_MOVED | Risk | The bound SIM is now in a different phone, or a different SIM is in the bound phone. | Insider fraud |
Identity and eKYC
Verification. Aadhaar, DigiLocker and PAN, verified at the source. About identity and eKYC.
| Code | Kind | Meaning | Seen in |
|---|---|---|---|
| EKYC_VERIFIED | Held | The identity was verified against the records that issue it: Aadhaar through DigiLocker or offline KYC, PAN and the other ids your journey names. | Any clean decision |
| ID_MISMATCH | Risk | The details given do not match the issuing record, or the record could not be reached. | Not tied to one use case |
Document and ID verification
Verification. Passports and IDs read, authenticated and matched. About document and ID verification.
| Code | Kind | Meaning | Seen in |
|---|---|---|---|
| DOC_AUTHENTIC | Held | The document’s security features, fonts and fields check out, and its data matches the record. | Any clean decision |
| DOC_TAMPERED | Risk | The document shows signs of editing, substitution or a template. | Claims deepfakes |
| GENERATED_MEDIA | Risk | A submitted photo or document shows signs of generation or editing. | Not tied to one use case |
Liveness and face match
Verification. A live person, a real camera, the right face. About liveness and face match.
| Code | Kind | Meaning | Seen in |
|---|---|---|---|
| LIVE_PERSON | Held | A live person in front of a real camera, with the server’s final verdict agreeing with the phone’s. | Any clean decision |
| FACE_MATCHED | Held | The live face matches the portrait on Aadhaar or the document, or the face matched at sign-up. | Any clean decision |
| FACE_MISMATCH | Risk | The live face does not match the face from sign-up or the document’s portrait. | Remittance mules |
| PRESENTATION_ATTACK | Risk | A photo, a mask or a video on a second screen is held up to the camera instead of a live face. | Not tied to one use case |
| VIRTUAL_CAMERA | Risk | A virtual or emulated camera is feeding the face check instead of the phone’s own camera. | Video KYC deepfakes |
| INJECTED_STREAM | Risk | The video reaching the face check shows signs of being injected rather than captured. | Not tied to one use case |
| DEEPFAKE_SIGNS | Risk | Face-swap or generation artefacts on a live face, a video call or a recorded sign-off. | Not tied to one use case |
| FACE_REUSED | Risk | The same face has been seen on other applications or accounts, under different names. | Mule accounts, Merchant laundering, Crypto off-ramps, Video KYC deepfakes, Loan stacking |
| ID_MULTIPLE_FACES | Risk | One identity document has been presented by several different faces. | Not tied to one use case |
| STEP_UP_NOT_COMPLETED | Risk | A face check or live approval was requested and not completed. | Insider fraud |
Video KYC
Verification. Agent-led or self-serve, with deepfake checks. About video KYC.
| Code | Kind | Meaning | Seen in |
|---|---|---|---|
| VKYC_COMPLETE | Held | The video KYC session completed with a live person on a real camera, and its signed record is kept for audit. | Any clean decision |
Business verification
Verification. GST and registry checks, directors verified. About business verification.
| Code | Kind | Meaning | Seen in |
|---|---|---|---|
| KYB_VERIFIED | Held | The business, its registration and its directors were verified against the registries your journey names. | Any clean decision |
AML screening
Verification. Sanctions, PEP and adverse media, monitored. About AML screening.
| Code | Kind | Meaning | Seen in |
|---|---|---|---|
| AML_CLEAR | Held | No match on the sanctions, PEP and adverse-media lists your policy names. | Any clean decision |
| AML_HIT | Risk | A possible match on a sanctions, PEP or adverse-media list, sent for review. | Not tied to one use case |
Bank account verification
Verification. The account exists, and it is theirs. About bank account verification.
| Code | Kind | Meaning | Seen in |
|---|---|---|---|
| ACCOUNT_NAME_MATCH | Held | The account exists and its holder’s name matches the customer’s. | Any clean decision |
| ACCOUNT_NAME_MISMATCH | Risk | The account’s holder is not the customer, or the account could not be confirmed. | Not tied to one use case |
| ACCOUNT_SHARED | Risk | A payout or disbursement account is shared with unrelated applicants or claims. | Merchant laundering, Loan stacking, Claims deepfakes |
Device intelligence
Intelligence. A fingerprint that survives resets, and tampering read every session. About device intelligence.
| Code | Kind | Meaning | Seen in |
|---|---|---|---|
| EMULATOR | Risk | The app is running in an emulator, not on a physical phone. | Video KYC deepfakes, Loan stacking |
| DEVICE_TAMPERED | Risk | The phone is rooted or jailbroken, the app is hooked or cloned, or malware or an overlay is present. | Not tied to one use case |
| SCREEN_SHARED | Risk | The screen is being shared or mirrored while the customer acts. | Digital arrest, Investment scams |
| REMOTE_ACCESS | Risk | A remote-access or remote-control app is running while money moves. | Vulnerable customers |
| SHARED_DEVICE | Risk | This device is linked to several unrelated accounts or profiles. | Mule accounts, Merchant laundering, Crypto off-ramps, Remittance mules, Claims deepfakes |
| AGENT_OFF_OUTLET | Risk | An assisted-channel agent’s device is transacting away from its registered outlet. | Not tied to one use case |
| ASSISTED_ACTION | Risk | A high-risk action was started on an assisted-channel agent’s device rather than on the customer’s own phone. | Assisted channels |
Behavioural biometrics
Intelligence. How the owner types, taps and swipes, against this session. About behavioural biometrics.
| Code | Kind | Meaning | Seen in |
|---|---|---|---|
| RHYTHM_MATCHES_OWNER | Held | Typing, touch and navigation rhythm match the account owner’s usual session. | Any clean decision |
| BEHAVIOUR_DRIFT | Risk | Typing, touch and navigation rhythm unlike the account owner’s usual session. | Executive deepfakes, Account takeover |
| DICTATION_PAUSES | Risk | Typing in long pauses: digits entered in groups and repeated cancels, as when details are read out over a call. | Digital arrest, Vulnerable customers |
| DETAILS_PASTED | Risk | Personal or payee details were pasted rather than typed. | Investment scams, Video KYC deepfakes |
| HANDOVER | Risk | Behaviour changed after the account was opened, as if someone else now runs it. | Mule accounts |
| SCRIPTED_TIMING | Risk | Uniform, machine-like timing across fields or across many transactions. | Crypto off-ramps, Loan stacking |
| AUTOMATION_UNDECLARED | Risk | A bot, script or automated browser drove the session and no agent was declared. | AI agents |
Scam signals
Intelligence. The call and the shared screen, while money moves. About scam signals.
| Code | Kind | Meaning | Seen in |
|---|---|---|---|
| ACTIVE_CALL | Risk | The customer is on a phone or video call during this event. In the story, 41 minutes in. | Digital arrest, Vulnerable customers |
| AMOUNT_UNUSUAL | Risk | The amount is far above what this customer usually sends. | Investment scams, Vulnerable customers, Executive deepfakes, AI agents |
| URGENCY_SIGNS | Risk | The session shows pressure: a rushed journey to the payment, with the payee pasted or dictated and the amount unusual. | Not tied to one use case |
| APPROVAL_OUT_OF_PATTERN | Risk | A corporate approval chain completed far faster, or in a different order, than usual for this client. | Not tied to one use case |
Payee and mule graph
Intelligence. Where the money is going, before it goes. About payee and mule graph.
| Code | Kind | Meaning | Seen in |
|---|---|---|---|
| USUAL_PAYEE | Held | A payee this customer has paid before, with no links to accounts that behave like mules. | Any clean decision |
| FIRST_TIME_PAYEE | Risk | The first payment to this payee from this customer. In the story, added 3 minutes before the payment. | Investment scams, Vulnerable customers, Executive deepfakes, AI agents, Insider fraud |
| PAYEE_ACCOUNT_NEW | Risk | The payee’s account was opened recently. In the story, 2 days ago. | Not tied to one use case |
| PAYEE_MULE_LINKED | Risk | The payee is linked, through devices, SIMs, faces or money flows, to accounts that behave like mules. In the story, 14 of them. | Digital arrest, Merchant laundering, Remittance mules |
| PAYEE_SCAM_REPORTED | Risk | The payee is linked to payees in earlier confirmed scam cases on your book. | Not tied to one use case |
| FAN_IN_UNRELATED | Risk | The account receives money from many senders with no link to each other. | Mule accounts, Crypto off-ramps, Remittance mules |
| RAPID_PASS_THROUGH | Risk | Money leaves within minutes of arriving, often split across many payees. | Not tied to one use case |
| RECOVERY_CONTACT_LINKED | Risk | The email or number used to recover the account is linked to earlier confirmed takeovers. | Not tied to one use case |
| AGENT_LINKED_MULES | Risk | Accounts opened by this assisted-channel agent later acted as mules. | Not tied to one use case |
One decision, with reasons
Decision. Allow to block, sent to the app and the FRM. About one decision, with reasons.
| Code | Kind | Meaning | Seen in |
|---|---|---|---|
| STEP_UP_FACE | Held | A face check was requested at this decision, and the next decision in the session says whether it passed. | Executive deepfakes, Account takeover, Assisted channels, AI agents |
| COOL_OFF | Held | A lower limit was applied for the hours the policy sets. In the story, ₹10,000 for 12 hours. | Any clean decision |
The decision and the journey builder add no codes of their own: the action, the queue and the policy version are fields of the decision object, and the two codes under One decision record what the decision applied.
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.