Penetration testing in fintech: What to test before hackers find it first

A surface-by-surface guide for QA leads, CTOs, and CISOs responsible for the security posture of financial applications.

There is a version of penetration testing that produces a clean report and satisfies a compliance requirement. And there is a version that finds what attackers would actually find. In fintech, only the second version is acceptable, and the gap between them is where breaches happen.

A passing PCI DSS assessment confirms your cardholder data environment meets a defined standard. It does not confirm that your payment API cannot be exploited via a race condition. A green OWASP scan tells you common vulnerability classes aren't present. It says nothing about whether your fraud detection logic can be bypassed by structuring transactions below the alert threshold.

The financial sector pays a steep price for that gap. According to IBM's 2024 Cost of a Data Breach Report, the average breach in financial services costs $6.08 million, 22% above the global average, and that figure doesn't capture the regulatory fines, customer attrition, and operating license risk that follow a serious security failure.

This article is a practical guide to what fintech penetration testing must actually cover: six attack surfaces, the specific vulnerabilities that matter within each, the regulatory baseline you need to satisfy, and a framework for building a testing program that finds real problems rather than generating paper compliance.

Why fintech pen testing is not the same as standard security testing

Standard penetration testing validates that common vulnerability classes, SQL injection, XSS, misconfigured headers, exposed credentials, don't exist in your environment. That's a necessary baseline. In fintech, it is not sufficient.

The attacker profile targeting financial applications is qualitatively different from what most organizations face. Organized cybercrime groups, nation-state APTs, and financially motivated insider threats all operate in this space. They're not running commodity scans. They're building attack chains specific to payment architectures and financial data flows.

The consequence profile is equally different. A successful exploit in a standard SaaS product typically means data exposure or service disruption. A successful exploit in a payment platform can mean direct financial theft, transaction fraud, or regulatory breach, with consequences that compound over time through chargeback liability, customer compensation, and enforcement action.

Three categories of vulnerability recur in fintech pen tests that standard security testing categorically misses:

• Business logic flaws, vulnerabilities that require understanding what the application is financially supposed to do before you can determine how it can be abused. No scanner knows what a valid amortization calculation looks like.

• Race conditions in payment flows, concurrent request attacks against transaction endpoints that exploit the window between a balance check and a database commit. These require manual exploitation, not automated detection.

• Compliance-layer bypasses, authentication and authorization weaknesses in KYC workflows, SCA flows, and regulated reporting paths that automated tools treat as features rather than attack surfaces.

Automated vulnerability scanning is a floor, not a ceiling. The most critical vulnerabilities in fintech environments are found by manual testers who understand financial workflows well enough to abuse them.

The regulatory baseline: What DORA, PCI DSS, and PSD2 actually require

This is not a compliance article. But regulatory requirements define the minimum scope and cadence of pen testing in fintech, and every decision-maker in this space needs to understand what those minimums are before building beyond them.

PCI DSS v4.0

For any fintech product that touches cardholder data, PCI DSS v4.0 mandates annual penetration testing of the cardholder data environment (CDE), covering both external and internal network layers plus the application layer. Testing must also be triggered after any significant change to the CDE, new integrations, architectural changes, major releases. Pen test results must be retained as evidence and remediated before the next assessment.

DORA (EU Digital Operational Resilience Act)

DORA entered full force in January 2025 and represents the most significant shift in security testing requirements for EU financial services in a decade. It mandates an annually executed security testing program covering all critical ICT systems, network tests, web application tests, penetration tests, and social engineering assessments.

Book a strategic QA consultation

Schedule a call

For financial entities performing critical functions, DORA goes further: it requires Threat-Led Penetration Testing (TLPT) at least every three years. TLPT is categorically different from standard pen testing. It is intelligence-driven, runs over multiple months, targets production systems across digital, physical, and human attack surfaces, and uses the real TTPs of actual threat actors. Results are submitted to the relevant competent authority, which issues a compliance attestation. Failure to obtain one can result in fines of up to 2% of total annual turnover.

A practical note on TLPT timing: the first wave of DORA TLPT engagements is expected to begin in late 2026 and 2027. Organizations should be scoping and planning now.

PSD2

Under PSD2's Strong Customer Authentication (SCA) requirements, authentication flows for payment initiation and account access must meet specific technical standards. From a pen testing perspective, this means SCA implementations, including biometric flows, hardware tokens, and out-of-band authentication, must be tested for bypass vulnerabilities, not just functional correctness.

Meeting regulatory requirements is the minimum, not the objective. A DORA-compliant testing program designed only to satisfy the regulation leaves a security gap that the regulation itself acknowledges by mandating TLPT, which goes beyond what standard compliance testing addresses.

Attack surface #1: APIs, the highest-risk target in fintech

APIs are the architectural spine of modern fintech. They power payment flows, connect banking rails, expose customer data to third-party services, and enable the open banking ecosystem. They're also, consistently, the most actively exploited attack surface in the sector.

Akamai's 2024 API Security Impact Study identified financial services as the most targeted sector for API attacks, not because financial APIs are inherently less secure, but because the payoff for a successful exploit is direct and immediate. An authorization bypass on a payment endpoint doesn't just expose data. It enables fund extraction.

What to test and what attackers look for

• Broken Object Level Authorization (BOLA / IDOR), the most common critical finding in fintech API assessments. Can User A access User B's transaction history, account balance, or KYC documents by manipulating an object ID in the request? Automated scanners cannot detect this because they don't know which IDs belong to which users. Grey-box manual testing with multiple test accounts is the only reliable detection method.

• Broken Function Level Authorization (BFLA), can a standard user call admin-level endpoints? In a payment platform, this might mean triggering refunds, adjusting transaction limits, or accessing batch settlement records by directly hitting an undocumented endpoint the UI never exposes.

• Race conditions and double-spending, what happens when two simultaneous POST requests hit the same transfer endpoint before the database has committed the balance deduction? A properly constructed concurrent request attack can withdraw funds multiple times from a single balance. This requires manual exploitation with precise timing, not automated scanning.

• Rate limiting and brute-force exposure, authentication endpoints, PIN confirmation flows, and payment confirmation steps must all be tested for rate limiting. An unprotected login endpoint in a mobile banking app is a direct path to credential stuffing at scale.

• Undocumented and shadow endpoints, legacy API versions left running in production, internal endpoints accidentally exposed through misconfigured routing, and deprecated authentication paths are all active attack surfaces. Enumeration and discovery are a core part of API pen testing scope.

• Error handling and information leakage, do error responses reveal stack traces, database query structures, or internal service architecture? In a payment context, verbose error messages from a failed transaction can reveal the internal state machine to an attacker designing a more targeted exploit.

Learn how we turned a broken QA process into a scalable testing system

Learn more

Attack surface #2: Business logic, what automated tools cannot find

Business logic vulnerabilities are the category that most sharply distinguishes fintech pen testing from standard security assessment. They require a tester who understands what the application is supposed to do financially, and can then determine whether that logic can be gamed.

No CVE scanner knows what a valid loan amortization output looks like. No DAST tool knows that a transfer should be blocked if it exceeds a daily limit, or that a KYC check must complete before a withdrawal is authorized. These are domain-knowledge requirements, and they cannot be automated.

What to test

• Transaction flow manipulation, can a payment be forced through without completing all required authorization steps? Can an authorization token be reused after a transaction fails? Can a user initiate a withdrawal that bypasses the settlement hold period by exploiting a timing gap in the workflow?

• Fee and calculation abuse, can a user structure transactions to avoid fee triggers? A common exploit pattern: sending thousands of micro-transactions below the fee threshold to move large amounts without incurring processing fees. Rounding errors in currency conversion, if exploitable at scale, can also represent material financial loss.

• Fraud detection evasion, this is specifically the logic that fintech teams are most reluctant to test aggressively, but it is also the logic that sophisticated attackers spend the most time probing. Can funds be moved in increments below the fraud alert threshold? Can transaction timing be structured to avoid velocity rules? Testing fraud engine behavior requires using realistic transaction patterns, not just triggering obvious fraud signals.

• Workflow sequence violations, can a user skip steps in a KYC flow and access account features before identity verification is complete? Can a user change their registered bank account and immediately initiate a large withdrawal before the cooling-off period expires?

• Balance and credit limit manipulation, are there concurrency scenarios where a balance check passes for two simultaneous requests, allowing both to proceed against the same balance? Can a credit limit be exceeded by splitting a transaction across multiple simultaneous requests?

A real-world example that illustrates the category: a digital banking app allowed fund transfers to initiate before full identity verification was completed on the receiving account. The check existed in the UI flow but was not enforced at the API layer. Attackers moved money in small increments, each individually below fraud detection thresholds, systematically exploiting both flaws in combination.

Business logic testing requires test cases co-authored with someone who understands the financial product, a compliance officer, product manager, or domain expert. Security expertise alone is not sufficient to design these tests.

Attack surface #3: Mobile applications

Mobile is where the majority of fintech users interact with the product daily. It is also where many security teams have the thinnest pen testing coverage, because mobile security requires a different methodology, different tooling, and a broader understanding of the device ecosystem than web application testing.

What to test, static and dynamic analysis combined

• Insecure local data storage, are session tokens, authentication credentials, API keys, or financial data stored in plaintext in local storage, SharedPreferences, SQLite databases, or application logs on the device? On a rooted or jailbroken device, this data is directly accessible without authentication. A European digital bank discovered this exact flaw: session tokens and account IDs stored in unencrypted local storage, extractable from any rooted device.

• Certificate pinning and transport security, can an attacker intercept application traffic using a proxy on a standard (non-jailbroken) device by installing a custom root certificate? Is TLS enforced across all API calls, including less-trafficked internal endpoints? Missing certificate pinning on payment API calls is a direct interception risk.

• Biometric authentication bypass, does the application correctly validate biometric authentication results on the server side, or does it trust a local flag that can be manipulated on a compromised device? Biometric confirmation that only exists client-side is bypassable with standard hooking tools like Frida.

• Deep link and intent handling, can a malicious application on the same device trigger sensitive actions in the fintech app through deep links, URL scheme handling, or Android Intent interception? This is a common attack vector for payment authorization hijacking.

• Third-party SDK risk, analytics SDKs, marketing attribution tools, and customer support integrations embedded in mobile apps often have access to more data and permissions than their function requires. An SDK with access to network traffic or local storage is a supply chain risk inside your own application.

• Session management on device, are sessions properly invalidated when the user logs out? Can a session token extracted from a device backup or memory dump be replayed to authenticate against the API? For a financial application, session reuse attacks can enable transactions under a stolen identity.

Effective mobile pen testing requires both static analysis, reverse engineering the application binary to examine code, hardcoded values, and embedded credentials, and dynamic analysis, runtime behavior testing under normal and adversarial conditions, including on jailbroken and rooted devices.

Attack surface #4: Cloud infrastructure and configuration

Most modern fintech products run on cloud infrastructure. The shift from traditional data centers to AWS, Azure, or GCP has moved the attack surface from network perimeters to identity, configuration, and access control. Cloud misconfigurations are one of the most common root causes of financial data exposure, and they are almost never caught by application-layer pen tests.

The blast radius of a cloud-layer compromise in fintech is severe: a misconfigured IAM role can expose an entire production environment. An unencrypted database backup in a public S3 bucket can expose millions of customer records. A compromised developer credential with production access can enable direct interaction with payment systems.

What to test

• IAM and privilege escalation, can a compromised service account, developer credential, or CI/CD pipeline token be used to escalate privileges to production systems? In AWS, IAM privilege escalation paths are well-documented by attackers and frequently overlooked by defenders. The specific question: what can the most over-permissioned non-admin role in your environment actually access?

• Network segmentation between environments, is your payment processing environment properly isolated from development and staging workloads? Can a compromise in a lower-security environment (a developer's workstation, a staging server, a monitoring tool) pivot to production payment infrastructure through shared credentials or network paths?

• Storage and database exposure, are any S3 buckets, Azure Blob containers, or GCS buckets publicly accessible or accessible without authentication? Are database backups encrypted, access-controlled, and inventoried? Backup infrastructure is frequently overlooked in security assessments and is a high-value target for data exfiltration.

• Secrets sprawl, are API keys, database credentials, payment gateway tokens, and cryptographic signing keys stored in environment variables, committed to code repositories, present in application logs, or embedded in container images? Secrets management failures are the most common cause of third-party service credential compromise.

• Container and serverless permission boundaries, do containerized workloads and serverless functions operate with the minimum permissions required? An over-permissioned Lambda function or a container running as root in a misconfigured cluster can serve as a pivot point to other services.

• Detection and response coverage, would a cloud-layer compromise be detected by your current logging and alerting setup? Testing the detection capability is as important as testing the controls. A pen test that successfully compromises a cloud environment and generates no alerts has identified a detection gap as significant as the initial vulnerability.

Cloud pen testing requires explicit written authorization and advance coordination with your cloud provider. AWS, GCP, and Azure all have penetration testing policies. Testing without following them can result in account suspension and legal exposure, coordinate before you engage.

Attack surface #5: Third-party integrations and the supply chain

According to SecurityScorecard's 2025 analysis, 41.8% of fintech breaches trace directly to third-party vendors. That figure alone makes third-party attack surfaces the most statistically significant risk category in the sector. Yet most pen testing programs treat third-party integrations as an afterthought, testing the application layer while leaving the integration layer effectively unexamined.

In fintech, third-party dependencies are not peripheral features, payment gateways, banking rails, identity verification providers, credit bureaus, and fraud platforms are structural components of the product. If any of them is compromised, or if your integration with them is insecure, the impact flows directly through to your customers and your regulatory standing.

What to test

• Integration authentication and authorization, are API keys and OAuth tokens for third-party services properly scoped, rotated, and stored? Can they be extracted from client-side code, intercepted in transit, or found in application logs? An API key for a payment gateway embedded in a mobile application binary is a direct path to unauthorized transaction initiation.

• Data validation of third-party inputs, does your application validate and sanitize data received from third-party APIs before processing it? An injection attack doesn't have to originate from a user, it can arrive through a compromised or manipulated upstream integration.

• Failure and error response handling, what does your application do when a credit bureau API returns a 503? When a fraud platform times out? When an identity verification service returns a malformed response? Insecure failure handling, including silent fails that bypass required checks, is a business logic vulnerability that originates in the integration layer.

• OAuth token scope and PSD2 compliance, for open banking integrations under PSD2, are OAuth tokens correctly scoped to the permissions the user granted? Can a token issued for read-only account access be used to initiate a payment? Token scope validation failures are a direct path to unauthorized transaction execution.

• Third-party library and SDK CVEs, are embedded open-source libraries and third-party SDKs current? Known vulnerabilities in popular payment libraries, cryptographic implementations, and authentication frameworks are actively exploited. Dependency scanning should be automated in CI/CD, but a pen test engagement should also verify that scan results are being acted on.

A practical constraint: testing third-party integrations against live production external systems requires coordination and carries operational risk. Service virtualization, contract testing, and third-party sandbox environments should be used to test integration security without creating live transaction risk or violating third-party terms of service.

Attack surface #6: The human layer, social engineering

Technical controls protect systems. They do not protect people with access to systems. In fintech, where employees routinely handle payment authorizations, customer data, and internal system access, the human layer is a genuine attack surface with direct financial consequences when compromised.

Social engineering is explicitly included in DORA's TLPT scope because regulators understand what security teams sometimes resist acknowledging: the most sophisticated technical controls can be bypassed by a convincing phone call to the right person at the right time.

What to test

• Phishing simulations targeting high-access roles, customer support staff, operations teams, and anyone with access to payment systems or customer financial data represent the highest-value targets for credential theft. Spear-phishing simulations should be tailored to the specific roles and the systems they access, not generic email awareness tests.

• Vishing (voice phishing) against operations and IT, can a caller impersonating a vendor, regulator, or senior internal figure extract credentials, system access, or sensitive operational information from support or IT staff? In financial services, this is a live attack vector used by organized fraud groups targeting real-time payment systems.

• Pretexting and internal social engineering, can a tester with low-level internal access social-engineer their way to elevated system permissions through legitimate-looking internal requests? Scenarios include: impersonating a new employee needing system access, impersonating an auditor requesting data exports, or impersonating a vendor needing credentials for a 'maintenance window.'

• Physical security testing, for organizations where financial operations occur in office environments, can an unauthorized individual gain physical access to terminals, servers, or workstations? Tailgating, impersonation, and physical credential cloning are all in scope for a comprehensive TLPT-aligned assessment.

Social engineering tests must operate under strict ethical and legal controls: defined scope approved by senior management, clear rules of engagement, documented authorization, and a process for staff to report suspected tests without penalty. The goal is to identify process failures and training gaps, not to create adversarial relationships with employees.

How to structure a fintech pen testing program

A pen testing program that addresses all six attack surfaces above requires deliberate structure. The following framework gives engineering and security leaders a practical basis for scoping, scheduling, and governing fintech security testing.

Scope from risk, not compliance minimums

Map your highest-value assets first: payment processing core, customer PII stores, authentication systems, financial calculation engines. Make these the center of scope and expand outward. Compliance requirements define what must be tested, your threat model defines what needs to be tested.

Attack surface priority by impact

Testing cadence

What a good engagement must produce

A pen test report that lists CVE numbers and CVSS scores without financial impact context is not useful to a fintech decision-maker. Require the following from any engagement:

• Proof-of-concept demonstrations for every critical and high finding, not just a description of the vulnerability, but evidence that it was exploited

• Business impact assessment per finding, what is the financial and regulatory consequence if this vulnerability is exploited by an attacker?

• Remediation guidance that developers can act on, not 'update your authentication mechanism' but specific code-level or configuration-level changes

• Re-testing commitment, verification that fixes are effective before the engagement is closed

• Audit-ready documentation, for PCI DSS, DORA, and any regulatory review, the engagement record must show what was tested, when, by whom, with what methodology, and what the results were

Choosing and evaluating a fintech pen test partner

Fintech pen testing requires a partner with financial domain knowledge, not just security expertise. A firm that is excellent at web application pen testing for SaaS products is not automatically equipped to find business logic vulnerabilities in a payment platform or race conditions in a settlement engine.

Non-negotiable qualifications

• CREST accreditation, required for DORA TLPT engagements; also a meaningful signal of methodology and quality standards for standard pen test engagements

• Individual tester certifications, OSCP (Offensive Security Certified Professional) and OSWE (Offensive Security Web Expert) at minimum; these certifications require demonstrated exploitation skill, not just theoretical knowledge

• Documented fintech case studies, not financial sector in general, but specifically payment systems, open banking APIs, digital banking, or lending platform testing

• PCI DSS, DORA, and GDPR compliance mapping built into report format, so findings can be directly referenced in audit and regulatory evidence

What separates real fintech pen testers from checkbox vendors

• They test business logic, not just OWASP Top 10, and can explain how they approach it

• Their reports show what an attacker could do with a vulnerability, not just that the vulnerability exists

• They have found vulnerabilities that previous vendors missed, ask for specific examples

• They engage with your domain context: payment architecture, regulatory obligations, integration dependencies

Key questions to ask before engaging

• Walk me through how you approach business logic testing for a payment platform. What does that look like in practice?

• How do you handle third-party integration testing when we don't have unrestricted access to the external sandbox?

• What is your methodology for API testing beyond the OWASP API Top 10?

• How do you verify remediations, and what does your re-testing process look like?

• If you are conducting TLPT under DORA, what threat intelligence sources do you use, and how is the scope defined?

Red flags

• The vendor leads the conversation with tool names and automation percentages rather than methodology and past findings

• No fintech-specific case studies, only general web application or network security references

• Reports from previous clients list vulnerability names without proof-of-concept or business impact

• No clear re-testing process or remediation verification commitment

Conclusion

A pen testing program that satisfies compliance and a pen testing program that genuinely reduces your attack surface are not the same thing. The difference lies in scope, methodology, and the willingness to test what matters, not just what regulators can verify.

The six attack surfaces covered in this article represent the real threat landscape of a fintech product. APIs that handle real money. Business logic that governs financial calculations. Mobile applications that hold session credentials. Cloud infrastructure that hosts payment data. Third-party integrations that process 41.8% of all fintech breaches. And employees with system access who can be socially engineered.

Any pen testing program that leaves one of these surfaces unexamined has a gap that a determined attacker may already know about. The question is whether you find it first.

Looking to scope a fintech penetration test or build a continuous security testing program? DeviQA's security testing practice works with fintech teams across payment platforms, digital banking, and lending, from targeted API assessments to DORA-aligned testing programs. Get in touch to discuss your specific environment.

Your dev team need a solid QA partner

Schedule a call

About the author

Ievgen Ievdokymov

Senior AQA engineer

Ievgen Ievdokymov is a Senior AQA Engineer at DeviQA, focused on building efficient, scalable testing processes for modern software products.