hunt-fintech-graphql

Replay the identical mutation with the same idempotencyKey twice and check whether two distinct transactionIds result. Then use alias batching to send the same redeem or transfer operation multiple times in one request, escalating to parallel HTTP requests to confirm a real race condition.

Fintech-specific issues include idempotency-key replay enabling double-spend, decimal-precision and rounding abuse on Money scalars, source-account authorization gaps in transfers, non-atomic multi-entry ledger writes, and KYC/PII field-level authorization gaps on nested types.

Generic GraphQL testing covers introspection, IDOR, and batching mechanics, while fintech testing adds the money-movement delta: ledger write atomicity, currency-consistency checks, decimal parsing edge cases, and asymmetric debit-vs-credit authorization that only matter when a resolver bug moves real funds.

Custom Money or Decimal scalars sometimes fall back to native float parsing under edge-case input like scientific notation or oversized strings, reintroducing floating-point error. Repeated sub-cent transactions can also accumulate rounding drift when server-side and client-side rounding differ.

You must demonstrate an actual ledger state change, such as querying the account balance before and after the attack. Race-condition findings should be reproduced twice from a clean state, and error-message-only findings without financial impact do not meet the validation bar.