Internal fraud in P2P: when people and payments contradict the ledger

A hypothetical P2P team discovers three facts. One bank transfer is linked to two successful orders. A withdrawal recipient changed after approval. The same pair of employees repeatedly closes one counterparty's exceptions. None alone proves fraud. Together, they justify restricting the relevant actions and examining evidence while the money and history remain available.

This is a composite defensive scenario, not an allegation about a particular processor. Internal fraud means deliberate abuse of employee access or authority, including collusion. Mistakes, poor interfaces and overloaded shifts can produce similar signals. Controls should detect contradictions; an investigation should establish their cause rather than assume guilt.

First episode: convincing evidence, insufficient money

A forged receipt threatens more than inexperienced traders. Inside a team, it can justify a manual decision if the reviewer sees only the document uploaded by the operator. Two people formally approve, but both rely on the same unreliable source. A two-person rule does not create independence by itself.

Confirm receipt through an authorised source of actual funds movement independent of the counterparty's screenshot: a bank record or appropriate payment-provider confirmation. A customer's document can help locate a transaction; it should not automatically create money in the ledger. If the source is temporarily unavailable, retain a pending-verification state rather than declaring success at a manager's request.

Matching also requires uniqueness. Amount, date and name may coincide across different transactions. Link a stable bank-movement identifier to the accounting entry and prevent silent reuse. If a reference is not unique or is unavailable, use another matching method and an explicit uncertainty state. A populated UTR field does not by itself establish an adequate control.

Second episode: approving one payment, sending another

Recipient substitution is especially dangerous when review and execution use different versions of the instructions. A reviewer approves payment to a customer, an employee then edits the account and the system retains the previous approval. The log contains two signatures, but neither relates to the details actually executed.

OWASP's transaction-authorisation guidance stresses binding confirmation to significant transaction data. Applied to a P2P operating design, approval belongs to a specific amount, currency, recipient and instruction version. Material changes require a fresh decision. This is a proposed application of a general principle, not a claim that every panel already implements it.

Separate permission to edit recipients, approve exceptions and execute payouts. Managers should not have unlimited authority to rewrite logs retrospectively either. Emergency access needs a bounded purpose, reason, expiry and independent retrospective review. Otherwise, the emergency control becomes the normal way to bypass scrutiny.

Third episode: two people can collude

If one trader repeatedly confirms a counterparty's disputed operations and one reviewer repeatedly approves the exceptions, independent sampling is appropriate. Similar concentration can also arise from shift patterns, language specialisation or assigned portfolios. Compare the activity with actual assignments and the available sample.

Useful defensive signals concern combinations: unusually frequent manual corrections, repeated operator–reviewer–recipient relationships, refunds following changed details, missing primary evidence and materially different outcomes after reconciliation. Publishing evasion thresholds is unnecessary. Staff need to understand which actions require explanation and that logs cannot be altered invisibly.

Rotating reviewers periodically and sampling completed operations reduce dependence on one pair of employees. A small team does not necessarily need a large security department. An independent controller reviewing the riskiest changes daily may help more than another formal sign-off by the same person.

Triangulation breaks the assumed customer relationship

Where triangulation is suspected, the money, order and apparent buyer may relate to different people. The defensive task is to detect disconnected identities and purposes, not reconstruct an entire scheme from chat messages. Matching the amount and confirming receipt do not establish a relationship between the payer and the person receiving an asset or gaming-account credit.

Assess the payer name, verified user, payout recipient, supported purpose and change history against the rules of the actual payment route. Do not collect unnecessary information or circulate third parties' documents in a general chat. If the relationship remains unexplained, pause the relevant execution within the team's authority and refer it to the authorised decision-maker.

Refunds can also carry risk. A request to return an accidental payment to a new account should not be executed merely because the requester knows the amount. Verify the claimant, original movement, authority over the money and permitted refund route. Where a bank restriction or dispute exists, use the bank and prescribed process rather than creating a new transfer chain.

Investigate without a witch hunt

First preserve records and restrict the specific risky permissions. An independent reviewer then reconstructs events: who saw which data, what changed, what evidence was available and what actually executed. Someone whose conduct is under review should not have sole control over evidence exports. Access to investigation materials should also be limited for everyone else.

Separate management action from legal conclusions. Manual-confirmation rights can be suspended temporarily without declaring an employee a criminal. Fix a discovered interface defect even if intent cannot be proven. Calculate loss using confirmed movements and obligations, avoiding counting the same event twice as both a refund and a duplicate payout.

After the review, change the actual failing control: approval-version binding, independent confirmation, editing rights or duplicate-movement detection. A mass password reset will not remove a logical ability to approve one payout and execute another. Good protection makes legitimate work clearer and leaves fewer places where someone can silently replace evidence with a convenient story.