By Abhijeet Batsa, Founder at Vellix.io | Ex Paytm Money, Snapdeal, Rakuten
There's a difference between a fraud detection system and fraud-resilient product logic.
A fraud detection system watches live transactions and flags suspicious patterns. You probably have one, or you use your payment processor's.
Fraud-resilient product logic means your API endpoints, state machines, and business rules are built in a way that doesn't create exploitable gaps — even before a transaction reaches the fraud detection layer.
Most fintech test suites test the former (does fraud detection fire?) and not the latter (are there flows in our product that bypass or exploit our own logic?). The result: fraud vectors that are invisible to detection systems because they don't look like fraud from the outside — they look like legitimate transactions that happen to exploit a product logic gap.
This is the class of vulnerability that Vellix's Fintech Fraud Scan checks for. Here are 23 of the most common vectors we find in real payment and WealthTech codebases.
Section A: Payment Flow Fraud Vectors (9 vectors)
1. Retry Loop Exploitation
What it is: A user initiates a payment, receives an error (network timeout, processing failure), and retries. If your idempotency implementation is incomplete, the retry can process as a new transaction while the original is still in Processing state — resulting in a duplicate charge that looks like two separate legitimate payments.
What to test: Multiple concurrent requests with identical parameters. Requests with the same idempotency key submitted within the deduplication window. Out-of-order webhook delivery after retry.
Why it matters: Legitimate users experiencing network issues will retry. If your retry handling has gaps, this becomes exploitable — intentionally or not.
2. Race Condition in Wallet/Balance Deduction
What it is: A user initiates two transactions simultaneously from the same wallet or account. Both pass the balance check before either deduction is processed. Both succeed. The user has effectively paid with the same balance twice.
What to test: Concurrent transaction initiation for the same user/account. Verify that the balance check and deduction are atomic — or that the second concurrent transaction fails with the correct error after the first deduction.
Why it matters: Not always malicious — happens legitimately with slow network conditions. But it's exploitable once users learn about the gap.
3. Negative Amount Submission
What it is: Submitting a negative transaction amount to trigger a credit rather than a debit. Most payment APIs reject this at input validation, but edge cases exist — especially in refund APIs, partial settlement APIs, and split payment flows where the sign of amounts is computed rather than directly inputted.
What to test: Negative values, zero values, and values that compute to negative through fee subtraction or split calculation. Test at every layer that accepts or computes amounts.
4. Amount Manipulation via Fee Exemption Abuse
What it is: Fee exemption conditions (promotional, tiered, first-transaction) have boundary conditions. If the fee calculation queries the exemption table after the transaction amount is set but before final processing, a race condition can allow a transaction to be processed at a fee tier it shouldn't qualify for.
What to test: Transactions submitted at exact tier boundaries with simultaneous exemption queries. Transaction amount modifications after fee calculation but before settlement.
5. Partial Refund Overflow
What it is: Successive partial refunds that cumulatively exceed the original transaction amount. If the refund system checks each refund against the original amount independently rather than tracking cumulative refunds, this is exploitable.
What to test: Submit 5 partial refunds of 25% each against a single original transaction. Verify that the total refunded amount is capped at 100% of the original.
6. Split Payment Manipulation
What it is: In split payment systems (card + wallet, card + loyalty points), the amounts from each payment source must sum to the transaction total. If they don't, the difference goes somewhere — sometimes into a float that can be exploited.
What to test: Split payments where source amounts sum to less than the transaction total. Split payments where source amounts sum to more. Concurrent modification of split amounts after initiation.
7. Chargeback Abuse via Timing
What it is: A user initiates a refund through your platform while simultaneously initiating a chargeback through their card issuer. If your system processes both, the user receives double the original transaction amount.
What to test: Simultaneous refund API call and chargeback webhook delivery for the same transaction. Verify that your system handles the double-credit scenario correctly — that the refund is reversed when the chargeback is confirmed, or vice versa.
8. Expired Session Token Replay
What it is: A payment session token captured during a legitimate transaction is replayed after its nominal expiry. If token validation uses server time but the token expiry check has a grace period or timezone inconsistency, the window can be extended.
What to test: Session token replay at T+expiry, T+expiry+1s, T+expiry+grace_period, T+expiry+grace_period+1s. Verify that tokens are definitively invalid after the grace period regardless of server time zone.
9. Webhook Endpoint Spoofing
What it is: If your webhook endpoint doesn't validate the source of incoming webhooks (via signature verification), an attacker can send fake settlement webhooks that trigger your system to mark transactions as settled before they actually are.
What to test: Webhooks with invalid signatures, missing signatures, signatures generated with incorrect keys. Webhooks claiming settlement for transaction IDs that don't exist. Webhooks in unexpected sequence order.
10. Risk Profile Manipulation via Re-KYC
What it is: A user with a high-risk profile (restricted investments, lower limits) fails a re-KYC attempt and re-submits. If the re-submission flow resets the risk profile to a default "moderate" before the re-evaluation completes, there's a window where the user has more permissions than their assessed profile allows.
What to test: Re-KYC submission timing — what is the risk profile at T+0 after submission, T+submission processing time, T+approval? Verify no expansion of permissions during the re-evaluation window.
11. Portfolio Calculation Race Condition
What it is: In real-time portfolio valuation, a user initiates a transaction based on a displayed portfolio value. Between the display and the transaction processing, the value changes. If the transaction is processed against the displayed (stale) value rather than the current value, the settlement amount is incorrect.
What to test: Transaction initiation after an artificial delay (simulate network latency) against a volatile asset. Verify that the settlement uses the price at transaction processing time, not at display time.
12. AML Threshold Calculation Gaps
What it is: AML reporting thresholds often apply to cumulative transaction amounts within a period. If the threshold calculation doesn't correctly aggregate across transaction types (purchases, redemptions, SIP instalments) or across accounts linked to the same user, the threshold can be approached without triggering the required reporting.
What to test: A series of transactions that approach the reporting threshold across different transaction types. A transaction that would push a user over the threshold if all transaction types are counted. Verify that the threshold calculation is comprehensive.
13. SIP/Recurring Payment Exploits
What it is: Systematic Investment Plans and recurring payments have specific rules: minimum amount, maximum frequency, mandate limits. If the mandate amount is validated at setup but not at each execution (e.g., post-split, post-fee calculation), individual executions can exceed the mandate limit.
What to test: SIP execution amounts including fees vs. mandate amount. Split SIP scenarios where individual instalments are below the mandate limit but accumulate beyond it within the validation period.
14. Redemption Before Settlement
What it is: A user purchases a mutual fund unit. Before the purchase settles (T+1 or T+2), they initiate a redemption. Depending on your state machine implementation, the redemption might be processed against units that don't yet exist in a settled state.
What to test: Redemption initiated within the T+0 to T+settlement window. Verify that the system correctly blocks, queues, or errors on redemptions against unsettled positions.
15. Tax Calculation at LTCG/STCG Boundary
What it is: Long-term vs short-term capital gains tax applies based on holding period. A transaction that occurs at exactly the holding period boundary (1 year for equity in India) can be misclassified as STCG when it should be LTCG (or vice versa), resulting in incorrect tax calculation.
What to test: Redemption transactions at exactly 365 days, 364 days, and 366 days from purchase date. Verify correct LTCG/STCG classification and tax calculation for each.
16. Nominee Account Routing
What it is: In estate or nomination scenarios, payment routing to nominee accounts has specific rules. If the nomination validation is incomplete — particularly for accounts where nomination was set up before a product update — payments can be routed to incorrect destinations.
What to test: Nomination scenario edge cases: nominee set before product update, incomplete nomination record, simultaneous nomination update and transaction processing.
Section C: API-Level Structural Vectors (7 vectors)
17. Parameter Pollution
What it is: Submitting duplicate parameters in a single API request — particularly in query strings or form data. If your parser takes the first occurrence and your validation takes the last (or vice versa), a gap exists where the validated value differs from the processed value.
What to test: API requests with duplicate parameter keys carrying different values. Verify that the parameter your business logic processes is the same parameter your validation checked.
18. Type Coercion Exploits
What it is: Sending a string where an integer is expected, a float where an integer is expected, or a boolean where a string is expected. Depending on your language and framework, type coercion can produce unexpected comparison outcomes (e.g., "0" == false in PHP-style loose comparison).
What to test: All API parameters with their wrong type. Amounts as strings, strings as integers, null where a value is required. Verify that type validation is strict and that coercion doesn't produce exploitable comparison results.
What it is: In APIs that return paginated transaction lists, the boundary between pages can be inconsistent if a new transaction is added between page 1 and page 2 requests. This is exploitable if the total count or aggregate value is computed from paginated responses rather than from a consistent snapshot.
What to test: Paginated list requests with concurrent transaction insertion between page requests. Verify that aggregates computed from paginated responses are consistent with direct aggregation.
20. JWT/Token Scope Boundary
What it is: A user authenticated for Account A uses their token to access endpoints that should be scoped to their account but has a parameter that accepts Account B's identifier. If the scope check validates the token but not the resource ownership, cross-account access is possible.
What to test: Authenticated requests where the token belongs to User A but the resource ID in the request belongs to User B. Verify that authorisation checks resource ownership, not just authentication.
21. Timestamp Manipulation
What it is: APIs that accept client-supplied timestamps for transaction dating can be exploited if the server doesn't validate that the timestamp is within an acceptable window of the current time. This is particularly relevant for backdating transactions for tax purposes or exploiting time-bound promotions.
What to test: API requests with timestamps in the past (1 hour, 24 hours, 1 week, 1 year). Timestamps in the future. Timestamps at promotion or period boundaries. Verify that server-side timestamp validation rejects out-of-window values.
22. Batch Request Atomicity
What it is: APIs that accept batch requests (process multiple transactions in one call) may not implement atomicity correctly. If 5 of 10 transactions in a batch succeed before one fails, does the system roll back the successful 5? Or are they committed while the remaining 5 are failed?
What to test: Batch requests where one element is intentionally invalid. Verify the atomicity contract — either all succeed, or all fail. Verify the error response correctly identifies which element failed.
What it is: Error responses that include internal state information — account balance in an insufficient funds error, user details in an authentication failure, internal transaction IDs in a processing error — give an attacker information they can use to map your system.
What to test: Deliberate error-triggering requests (wrong credentials, invalid amounts, non-existent IDs). Verify that error responses contain only the information a legitimate user needs to correct their request — not internal system state.
How to Prioritise These 23 Vectors
Not all 23 require immediate attention. Prioritise by:
Transaction volume on the affected flow: A race condition in a flow that handles 10,000 transactions/day is more urgent than one in a flow that handles 10/day.
Financial exposure per incident: Partial refund overflow on a ₹10,000 average transaction is higher priority than parameter pollution on an informational endpoint.
Exploitability: Some of these require sophisticated timing or tooling. Others (negative amounts, parameter pollution) require nothing more than a modified API request.
Current coverage: Run your existing test suite against this list. The vectors you have zero tests for are your priority list.
Running a Fraud Vector Scan
If you want to check your current coverage against these vectors systematically, Vellix's Fintech Fraud Scan validates your API test coverage against the full vector set — including these 23 and the additional vectors we've identified from real fintech codebases.
Free tier at vellix.io includes a Fraud Scan credit. No card required.
Abhijeet Batsa is the founder of Vellix.io — AI test generation and fraud scan for fintech teams — and FuturestaQ, a fintech reliability consulting firm. 16 years at Paytm Money ($4B AUM), Snapdeal, Rakuten Viki Singapore. vellix.io | futurestaq.com
