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.

BaseDrift

payout pout_mule
Inbox · ← All decisions
Held — nothing recorded yet
Nothing 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 RECOMMEND REJECT
Destination belongs to a different supplier
R2c_followup_destination_conflict
This account is already on file for another supplier. One account collecting from several suppliers is how one attacker harvests many.
Request asks for no destination change, but the payout is headed to an account on file for a different vendor: account 589685962440 (payout fund account) is already on file for a different vendor (VEND0000) outside this vendor's declared group — cross-contact reuse

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

Every record below names the person who made it. That is what makes the two-person rule enforceable.
The phone call
Ring the number in our supplier records. Never a number written in the request — a request that can change the account can change the phone number under it.
The rupee
Ask the supplier to send Rs 1 from 926841336891, and no other account. Which account is asked for is the entire control.
Note (optional)
Close the case
Release as Priya Menon: Nothing is verified yet. Record a callback outcome or the rupee arriving before releasing.
Rejecting needs no second person. The two-person rule protects money leaving; refusing to pay releases nothing.

What was checked

Supplier
VEND0110
Destination account
589685962440
Destination came from
The payout itself — the payout's own fund account, never the email [razorpay_fund_account]
Fund account
fa_mule
Amount
Rs 14,670.93
Change request
none on file
Correlated by
No request on file [none_found]
Evidence source
No change request on file [no_document_supplied]
Semantic reading
PAYMENT_FOLLOWUP / NONE / NONE

Accounts on file for this supplier

AccountAddedVerifiedSettled
926841336891
KKBK0406499 · active
At onboarding
2024-12-29
Verified at onboarding (KYC)43
payouts
Primary
This payment is going to 589685962440, 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
Mismatch
Destination account
account_continuity
account 589685962440 (payout fund account) is already on file for a different vendor (VEND0000) outside this vendor's declared group — cross-contact reuse
from Checked across all suppliers

What this maps to at RazorpayX

POST /v1/payouts/pout_mule/reject needs human confirmation
RECOMMENDED — payout stays pending until a human agrees
PATCH /v1/fund_accounts/fa_mule needs human confirmation
RECOMMENDED — destination disabled only on confirmation

Action plans. Nothing in this repository calls Razorpay.