Security testing for financial applications

What fintech penetration testing covers

A refund call on another merchant's payment, a withdrawal sent twice in the same millisecond, or a processor secret key inside a mobile build moves money directly. We run web, API, and mobile penetration tests for payment acquirers, banking-as-a-service platforms, neobanks, crypto exchanges, business banking, spend management, open banking, KYC and AML providers, and trading platforms. PCI DSS v4.0.1 requirement 11.4.1 requires a methodology that includes application-layer testing to identify, at a minimum, the vulnerabilities listed in requirement 6.2.4. Our test cases follow the OWASP API Security Top 10 2023 (checked 2026-09-16) and the financial failure patterns below.

Payment and transfer business logic

Business logic flaws move money with valid requests and no injection payload. Tests per flow:

• a refund or reversal above the captured amount, in a different currency, or on a payment already refunded;
• negative, zero, and over-precise amounts, such as three decimals on a currency with two minor units, and rounding that credits a fraction on each call;
• a skipped state: capture without authorisation, payout before KYC approval, or transfer from a frozen account, by calling the later endpoint directly;
• a daily transfer limit, card spend control, or withdrawal cap that only the client app enforces;
• an FX quote reused after expiry, or a quote for one amount applied to a larger amount.

OWASP API6:2023, Unrestricted Access to Sensitive Business Flows, covers flows exposed without compensating for how the functionality could harm the business if used excessively in an automated manner. We script that use: referral bonuses and promotional credits claimed from batches of new accounts, and FX quotes requested in bulk so that only the most favourable rate gets executed. Each finding records the ledger effect: which account gained funds and which account or balance sheet lost them.

Authorisation between accounts

Broken Object Level Authorization (API1:2023, CWE-639 Authorization Bypass Through User-Controlled Key) is the defect where customer A reads or acts on customer B's balance, statement, beneficiary, card, or KYC document by changing an ID. We create at least two customers, two tenants, and every documented role, then call each operation with another party's object IDs. Random UUIDs do not fix a missing ownership check, so we collect IDs from responses, webhooks, and exports.

Property and function checks follow. A customer sets limit, fee_rate, or status through a field the API should ignore (API3:2023). A customer token calls a support endpoint for manual balance adjustment or limit override (API5:2023). In multi-user business accounts, a viewer approves a payment, or an approver approves a payment they created. Every result goes into the access control and authorisation test matrix.

Race conditions on money movement

CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization, turns one balance into two withdrawals. We send parallel requests that each spend the full balance, redeem one voucher, or move funds during a concurrent limit change, then count ledger entries and the final balance instead of trusting HTTP responses. Idempotency abuse tests reuse a key from another account and check that the key is bound to the caller. Functional retry behaviour sits in API and webhook testing, and the payment idempotency guide shows the request sequences.

Card and account data exposure

We search API responses, error messages, logs, analytics events, crash reports, and mobile storage for full PANs, card verification codes, and account numbers. Handling of cardholder data and account data in our own test environment follows our security page. A full PAN in a log platform or crash reporting service brings that system into PCI DSS scope; a full PAN in app storage on a customer device is reported as a finding against requirement 3.5.1. Findings cite PCI DSS v4.0.1 requirements 3.3.1, 3.4.1, and 3.5.1, which the PCI DSS page explains. A payment token that charges a card outside the merchant or wallet it was issued for is also a finding.

Step-up authentication on money movement

Adding a beneficiary, raising a transfer limit, and revealing full card details are the actions an account takeover needs. We replay a step-up token from one payment on a second payment, change the amount or beneficiary after the challenge completes, and call the payment endpoint with a session created before a password reset or device removal. Each accepted request is a finding with the amount it could move.

Partner API keys and secrets

Secret keys for processors, partner banks, and KYC vendors leak through mobile bundles, JavaScript, repositories, and CI logs. Tests confirm that a publishable key cannot run a secret-key operation, that a key scoped to one merchant cannot reach another, that production rejects sandbox keys, and that a rotated key stops working. For mobile app penetration testing we test against OWASP MASVS v2.1.0 (18 January 2024), including certificate pinning with the proxy CA trusted on the device, where the app must still refuse the connection.