Prove a transfer can't move someone else's money

Trident replays the request that moves money between accounts and proves whether ownership is ever checked.

criticalCWE-639

Transfers check the caller, never the account

EntryMerchant sessionImpactMove any balance

Reproduced with a second merchant account

The path behind a transfer

Authenticated merchant
Transfer request names an account
Choke point
Payments service funds it
Cardholder data environment
The session is valid. The account it names is never checked.

Two checks, one of them missing

Is the caller signed in?
Does the caller own this account?
Transfer released
A valid session submits an account it does not own.

The engagement, step by step

01

Recon

Read-only credentials map transfer, payout, and refund endpoints.

02

Path mapping

Authorization edges resolve into paths ending at funding accounts.

03

Exploit validation

Each abuse case is replayed until proven or dismissed.

04

Draft PR + report

The ownership guard lands as a draft pull request.

What your team receives

The finding above, packaged as the report your teams receive.

  • Read-only API credentials, scoped and expiring
  • Captured requests are sanitized — no live card data stored
  • Every finding ships with its reproduction and its fix
  • Retest evidence attached once the guard lands

Where money and account data can go wrong

Payment flows fail through logic far more often than through the cryptography protecting them.

Payment risk

In fintech the defining risk is rarely a memory-corruption bug. It is an authorization or logic flaw that lets money move in a way the product never intended. The flaw on this page is the canonical one: a transfer endpoint that checks who is calling, then takes the funding account straight from the request body.

Transfer authorization
Whether an authenticated caller can move funds involving an account they do not own, including through identifiers the interface never exposes.
Amount and currency handling
Negative amounts, rounding and precision boundaries, currency substitution, and fee or limit calculations that can be driven outside their intended range.
Idempotency and replay
Whether a captured request can be replayed for a second effect, and whether idempotency keys are enforced server-side rather than logged.
Ledger and reconciliation state
Sequences leaving balances, holds or reversals in states reconciliation cannot resolve, including refunds exceeding the original charge.
Cardholder data reachability
Which identities and services reach stores holding account or cardholder data, including the analytics and backup copies that inherit access quietly.

Questions about testing payment systems

That is the centre of the work here. The intended authorization and transaction model is requested at scoping, because without it a tester cannot separate a deliberate product decision from a defect.

Know a transfer only moves its owner's money.

See the same check run against your own payment flows.

Every finding is reproduced before it is reported.