Lincoln Jairran

Context

Frontline teams kept seeing sellers lose funds on peer-to-peer trades, but enforcement was rare: each case looked like an isolated user mistake rather than organized fraud, and the evidence on any single order was thin.

My role

I opened a self-directed investigation to find the pattern buried in the noise, working from raw order and dispute data rather than waiting for a case to be escalated to me.

What I did

• Tracked every confirmed or suspected case in a working file and tagged accounts that recurred across more than one incident.
• Flagged accounts that reused the same destination bank account across multiple, seemingly unrelated orders — including after a prior dispute had already been raised on one of them.
• Cross-referenced shared devices to link accounts that looked unrelated on the surface.
• Partnered with risk leads to validate each finding and get enforcement sign-off before any account action, to avoid penalizing genuine victims caught in the middle.
• Reviewed messaging with a sample of affected sellers to validate the social-engineering script end-to-end — first contact, the pitch, and the justification used for the fraudulent payment details.

Findings

A recurring group of accounts was responsible for a disproportionate share of confirmed cases. Several had already adapted their behavior after a first warning — spacing out their activity and varying their approach specifically to stay under the threshold that would trigger a suspension. I documented the full attacker playbook end-to-end, from first outside contact to the final dispute.

Proposed risk rules

• Restrict accounts from paying into third-party bank accounts flagged mid-trade; repeat offenses trigger a graduated suspension of trading privileges (temporary, escalating to extended).
• Real-time in-chat detection for messages containing long numeric strings that resemble bank account numbers, prompting both parties with a warning and a direct escalation path before payment — rather than letting the trade proceed silently.
• Require accounts to pre-register and verify any third-party account they intend to use, closing the loophole that let the ring rotate through "clean" accounts.

Outcome

Findings and proposed rules were shared with Risk and Product leadership; several accounts were suspended on the strength of the evidence trail, and the in-chat detection proposal directly informed a Risk-team initiative to flag bank-account-like strings during a live trade. I also authored the internal training material later used to onboard teammates on the scheme.

Context

While reviewing unrelated disputes tied to a regional instant bank-transfer payment method, I noticed a recurring anomaly: a single proof of payment appeared to settle several separate trades against the same counterpart — same payment method, same amount, same parties — rather than one payment matching one trade.

My role

I isolated the pattern to confirm it wasn't a one-off input error, built a small evidence set across independent orders to show it was reproducible, and escalated it as a system-level issue rather than logging it as routine disputes.

What I did

• Compared timestamps, amounts and counterparties across the affected orders to rule out coincidence or user error.
• Packaged the evidence — affected order pairs, payment method, and the settlement pattern — for engineering and risk to reproduce independently.
• Argued for classifying the exploiting accounts as confirmed fraud rather than merely "suspicious," since the behavior pattern (repeated exploitation, funds withdrawn to the same destination) met the bar on its merits even though the scenario wasn't explicitly named in the existing playbook.
• Followed up over several weeks with the responsible team until the payment method was temporarily disabled pending a fix.

Outcome

The payment method was suspended for remediation while engineering investigated the root cause, the exploiting accounts were escalated for enforcement, and the case fed into a broader conversation about judging edge-case fraud on behavior rather than strict precedent.

Context

Alongside individual casework, I tracked friction that cost time or created inconsistent outcomes without adding any real safety — and wrote each one up as a specific, actionable request rather than a general complaint.

My role

Self-initiated reporting, usually raised directly with team leads and, where relevant, escalated to Product/Engineering.

What I did

• Payment-method configuration gap: flagged that a widely-used instant payment method was being set up under the wrong transfer type by users, creating confusion and false dispute flags — proposed either listing it as its own method or issuing clear setup guidance.
• Bulk-action bug: reported that a bulk "close all listings" action silently failed to close every listing, forcing manual, repeated clean-up — requested a reliable bulk action and a fix for the underlying failure.
• Support tooling gap: proposed a way to re-enable a single restricted function (e.g. chat access) for an account without lifting every other restriction, so agents aren't forced to choose between a full unblock and no fix at all.
• Completion-rate transparency: when traders disputed a drop in their trade completion rate, agents had no way to trace which specific past order caused it — proposed a lookup tool to identify the order and give the trader a direct path to appeal it.

Outcome

Several of these were validated and escalated by team leads, and some were later incorporated into tooling updates; others are still pending prioritization. Not every idea has shipped — but surfacing friction as a specific, scoped fix rather than absorbing it quietly is a habit I've kept consistently.