Static snapshot. A frozen copy of the operator dashboard, safe to open anywhere. The buttons below are drawn but inert — recording a verification and being refused the release is a state change, so it runs on the live app: python src/demo.py --serve.
Held — nothing recorded yetNothing has been recorded. Call the supplier on the number in our records — never a number in the request — or ask for the rupee.
On hold
Identity checks could not be completedR5_tier1_inconclusive
Not evidence of fraud — evidence we could not confirm identity. Verify through a channel the requester does not control.
Identity evidence inconclusive: GST registration — 36XZNBL2444U1Z8 matches but the claim was hedged; Destination account — new account 950064355944 (payout fund account) — known: ['926841336891']
Verification — what would release this
Ask the supplier to send Rs 1 from this account, and no other:
926841336891
chosen because 926841336891: 43 settled payout(s), added 2024-12-29 via onboarding, verified by onboarding_kyc
- Outcome
- Could not reach the supplier
UNREACHABLE
- Callback to
- 9053169723
- Number came from
- vendor_master — never a number in the request
- Attempts
- 2
- Escalated
- True
2 callback attempts to 9053169723 (from vendor master) went unanswered. Payout remains held and is escalated for human review. Never auto-released.
Two people, not one. Whoever records the verification outcome must not be whoever releases the payment. A compromised or complicit AP clerk who can do both approves their own request, and the control is theatre. This is enforced when the button is pressed, not only drawn on the screen.
Record what you did
What was checked
- Supplier
- VEND0110
- Destination account
- 950064355944
- Destination came from
- The payout itself — the payout's own fund account, never the email [razorpay_fund_account]
- Fund account
- fa_new
- Amount
- Rs 140,752.20
- Change request
- doc_835db9df8abecf79
- Correlated by
- Named on the payout [explicit_note]
- Evidence source
- Read from the message [llm_extraction]
- Semantic reading
- BENEFICIARY_CHANGE / REPLACE_PAYOUT_DESTINATION / OUTSTANDING_AND_FUTURE
Accounts on file for this supplier
| Account | Added | Verified | Settled | |
|---|
| 926841336891 KKBK0406499 · active | At onboarding 2024-12-29 | Verified at onboarding (KYC) | 43 payouts | Primary |
This payment is going to 950064355944, which is not one of the accounts above. That is what the destination check reports, and why the payment is held.
Identity checks — against your supplier records
result
check
finding
OK
Account holder's name name_match
score 92 >= 85
from Bank account verification
OK
Account can receive money account_status
account is active
from Bank account verification
Unverified
36XZNBL2444U1Z8 matches but the claim was hedged
from The email, against our records
Concern
Destination account account_continuity
new account 950064355944 (payout fund account) — known: ['926841336891']
from Payout, against our records
Circumstances — never decisive on their own
result
check
finding
Unverified
Sender's email domain sender_domain
sender domain not found
from The email header
Concern
Pressure to act quickly urgency
urgency: last item before our books close for the year
from Read from the message
Concern
Asked to be contacted differently channel_manipulation
redirecting communication: No need to copy the group on this one — just me is fine
from Read from the message
OK
Amount against this supplier's usual payment_pattern
Rs 140,752 within 15% of avg
from The email, against our records
Concern
First email ever from this sender inbox_first_contact
no earlier message from this sender is in the mailbox — a first contact asking about a payment destination
from Mailbox history
What this maps to at RazorpayX
no API call — payout stays pending while verification runs
Action plans. Nothing in this repository calls Razorpay.