Penetration Testing in Fintech: Securing Open Banking, Digital Wallets, and Financial Infrastructure

TL;DR: Key Takeaways

• The financial sector accounted for 27% of all data breaches in 2023, making it the most targeted industry globally. Average breach costs in financial services reached $6.08 million per incident in 2025.
• Fintech operates under a regulatory framework that makes security testing a compliance obligation, not just a best practice. PSD2, GDPR, DORA, and NIS2 all impose specific technical and reporting requirements that documented penetration testing directly supports.
• Open banking has expanded the attack surface significantly. Every API endpoint exposed to third-party providers is a potential entry point that requires validation under adversarial conditions.
• 41.8% of breaches affecting leading fintech companies originated from third-party vendors in 2025. Supply chain security is now a primary concern, not a secondary one.
• Cyrex has been conducting penetration testing across fintech and banking infrastructure since its founding. It is the vertical the company was built on.

Where Cyrex Started

Most people associate Cyrex with gaming security. What is less widely known is that fintech was where the company began. Before the gaming contracts, before Protoceptor, before the partnerships with major studios and publishers, Cyrex's founders honed their penetration testing practice across banking applications and financial platforms in Belgium. Fintech is not a new vertical for Cyrex. It is the original one.

That history matters because fintech security is not a discipline you learn from a framework. It requires an understanding of how financial systems actually fail under adversarial pressure, how authentication logic breaks in real-world conditions, how API integrations create exposure that documentation does not anticipate, and how regulatory obligations translate into testable security controls. Cyrex has been accumulating that understanding for over a decade.

The Fintech Threat Model: High Value, High Complexity, High Stakes

Why Finance Is the Most Targeted Sector

Financial technology sits at the intersection of two things attackers find irresistible: liquid value and rich identity data. Unlike most industries where a breach produces data that must be monetised indirectly, fintech breaches can produce direct access to funds, payment credentials, and financial accounts. The IMF estimates that nearly one in five reported cyber incidents globally has affected a financial firm. Verizon's 2025 Data Breach Investigations Report found that system intrusion, social engineering, and web application attacks together accounted for 74% of breaches in the financial and insurance sector.

The three most common attack patterns in fintech are not exotic. They are credential abuse, exploitation of public-facing applications, and third-party compromise. Each of these is directly addressable through structured penetration testing. Each of them is also routinely missed by automated scanning tools that produce coverage metrics rather than genuine adversarial validation.

Open Banking Has Fundamentally Changed the Attack Surface

PSD2 mandated open banking across EU member states, requiring financial institutions to expose APIs to regulated third-party providers. This was a deliberate regulatory shift to promote competition and innovation. It also materially expanded the attack surface of every bank and payment institution operating in Europe.

Every open banking API endpoint is a potential entry point. Strong Customer Authentication requirements under PSD2 reduce certain classes of risk, but they do not eliminate the business logic vulnerabilities, parameter tampering opportunities, and authentication bypass routes that adversarial testing is specifically designed to find. A security failure on an open banking API is not just a payments risk. Under GDPR, it immediately becomes a data breach with reporting obligations and financial penalties attached.

DORA, which took full effect in January 2025, adds a further layer. It requires financial entities across the EU to demonstrate digital operational resilience, including ICT risk management, structured incident reporting, and rigorous management of third-party technology risk. Penetration testing is one of the primary mechanisms for generating the evidence DORA's framework requires.

Third-Party Risk Is the Defining Exposure

In 2025, SecurityScorecard found that 41.8% of breaches affecting leading fintech companies originated from third-party vendors. Third-party involvement in breaches doubled year-on-year according to Verizon's 2025 report. The attack surface in fintech is no longer contained within an organisation's own infrastructure. It extends through every integration, every partner API, every shared service provider.

For fintech companies operating open banking platforms, payment infrastructure, or digital wallet services, this means that testing the primary application is necessary but not sufficient. The interfaces between systems, the authentication logic governing third-party access, and the data handling controls across partner integrations all require explicit adversarial validation.

How Cyrex Tests Fintech Environments

Pair Hacking: Coordinated Testing for Complex Systems

Every Cyrex engagement runs under its Pair Hacking methodology that pairs senior offensive security engineers with advanced AI-driven agents to conduct deep, multi-vector penetration testing. In fintech environments, this matters because the most significant vulnerabilities rarely live in isolation. They emerge from the interaction between systems: authentication logic that is correctly implemented in one context but exploitable in another, API parameters that behave safely in normal use but expose business logic flaws under manipulation, or access control boundaries that hold under standard conditions but fail under coordinated adversarial pressure.

Two engineers working in tandem, one testing actively while the second validates findings and challenges assumptions, produces the kind of end-to-end exploit chain validation that financial platforms require. It is also how sophisticated financial threat actors operate.

What Gets Tested

Cyrex engagements in fintech environments cover the full stack of exposure relevant to the sector.

API security and open banking interfaces. Authentication and authorisation logic, parameter tampering, business logic flaws, rate limiting controls, and third-party access boundaries across REST and custom API implementations.

Authentication and session management. Token handling, session hijacking vectors, authentication bypass routes, and the integrity of multi-factor authentication implementations under adversarial simulation.

Private key and credential handling. For platforms managing cryptographic keys, wallet infrastructure, or sensitive credentials, white box testing with full source code access allows validation at both architectural and implementation levels, identifying issues that are invisible to black box testing.

Business logic and transaction integrity. The logic governing fund transfers, payment authorisation, account access, and role-based permissions requires contextual, manual testing. Automated scanners cannot assess whether business logic is correctly enforced under adversarial conditions.

Communication layer security. Using Protoceptor, Cyrex validates the security controls protecting data in transit across custom protocol implementations, API middleware, and backend service communication, areas that standard web application testing tools are not designed to inspect.

Cyrex in Fintech: Case Studies

Bank Degroof Petercam: Secure API Sandbox for Open Banking

Bank Degroof Petercam, the largest independent private bank in Belgium operating across multiple European markets, identified the need for a secure API sandbox environment to support its open banking strategy. The objective was to enable partners and developers to test integrations safely without any exposure to production systems.

Cyrex designed and deployed a dedicated sandbox and staging environment, beginning with a rapid proof of concept to validate the architectural approach. The delivered solution included a customised sandbox environment, deployment and integration of a leading API gateway, secure API exposure with mock data, and structured staging capabilities fully separated from live banking operations.

The sandbox was built as a foundational component of the bank's API and digitalisation roadmap, aligned with open banking standards and configured to support the bank's long-term strategic objectives without creating security debt in the process.

BNP Paribas Fortis: PSD2-Compliant Developer Portal

BNP Paribas Fortis, part of the BNP Paribas Group, required a professional Developer Portal to support its open banking initiatives, provide secure API access to partners and developers, and align with PSD2 compliance requirements.

Cyrex architected and implemented a secure Developer Portal providing clear API documentation, structured API product listings, secure authentication and access mechanisms, interactive console capabilities, and dedicated sandbox environments with test data for safe integration validation. A secure API sandbox environment was implemented at the core of the solution, enabling controlled API testing, strict separation from live banking systems, and structured onboarding for third-party developers.

Cyrex also provided knowledge transfer to BNP Paribas Fortis's internal teams, ensuring the platform could be maintained and expanded independently following project closure.

The bank's Epic Owner noted that everything was delivered according to agreed cost, timing, and market standards, with appropriate training provided, and that Cyrex subsequently advised on how best to implement open banking capabilities within their environment.

Curve (Now part of Lloyd Banking Group): Ongoing Security Partnership

Curve, the multi-card financial platform operating across Europe, works with Cyrex as a key partner for security assessment of its product and critical services. Cyrex's own documentation describes the engagement as an ongoing partnership, with Curve's security team relying on Cyrex to assess services and validate security controls on a recurring basis.

Pali Wallet: Private Key Security in a Cross-Chain Browser Extension

Pali Wallet is the official Syscoin browser wallet, supporting Bitcoin-forked networks alongside Ethereum-compatible chains. As a browser-based extension storing private keys locally, the wallet operated within a high-risk threat model encompassing private key storage mechanisms, browser memory handling, DApp interaction logic, and Web3 integrations across multiple chains.

Cyrex conducted white box penetration testing with full source code access, reviewing controller and method logic, performing parameter tampering and input manipulation, identifying injection points, and conducting controlled exploitation to provide proof of concept validation of findings.

The engagement uncovered significant vulnerabilities including exposure of private wallet keys to websites, private keys stored in plaintext on the system, and wallet passwords stored in browser memory in plaintext. Following remediation, Cyrex conducted structured regression testing to confirm all vulnerabilities were fully resolved and that no new weaknesses had been introduced. The final assessment confirmed significantly strengthened security maturity post-remediation.

Regulatory Compliance: What Fintech Organisations Need to Demonstrate

DORA

The Digital Operational Resilience Act, fully effective from January 2025, requires financial entities to demonstrate ICT risk management, structured incident reporting, and third-party technology risk governance. Penetration testing generates the documented evidence of adversarial validation that DORA's framework expects, particularly around application security and third-party interface testing.

PSD2 and Open Banking Security

PSD2 requires Strong Customer Authentication and mandates that open banking API interfaces are securely implemented. Penetration testing of API authentication logic, session handling, and third-party access controls provides direct validation of PSD2 technical compliance requirements.

GDPR

Financial platforms handle personal and financial data subject to GDPR's Article 32 requirement for appropriate technical and organisational security measures. Documented penetration testing, with findings, remediation evidence, and regression validation, demonstrates that the organisation has taken concrete steps to validate its controls rather than simply asserting compliance.

ISO 27001

For fintech organisations pursuing or maintaining ISO 27001 certification, structured penetration testing with CVSS-aligned severity scoring and reproducible findings provides the documented security assessment evidence that the standard requires.

Conclusion

Fintech security is an adversarial problem operating inside a regulatory framework. Generic scanning tools satisfy neither the adversarial dimension nor the compliance dimension. What financial platforms require is structured, expert-led testing that validates security controls under real-world attack conditions and produces documentation that regulators and auditors can assess.

Cyrex brings a decade of fintech security experience, genuine technical depth across API security, private key handling, open banking infrastructure, and Web3 wallet security, and a methodology built around the same coordinated approach that sophisticated financial threat actors use. The financial sector was where Cyrex started. It remains one of the verticals the company knows best.

Frequently Asked Questions

What is penetration testing in a fintech context? Penetration testing in fintech is the authorised simulation of cyberattacks against financial technology platforms, including web and mobile applications, open banking APIs, payment infrastructure, digital wallets, and the authentication and session management systems that govern access to financial accounts and data. The goal is to identify exploitable vulnerabilities before attackers do, with findings documented in a format that supports both remediation and regulatory compliance evidence.

Why is the financial sector so heavily targeted by cyberattacks? Financial platforms combine two factors that make them disproportionately attractive to attackers: direct access to liquid value through payment systems and fund transfers, and rich identity data that enables fraud, account takeover, and extortion. The financial sector accounted for 27% of all breaches handled by Kroll's incident response team in 2023, and average breach costs reached $6.08 million per incident in 2025.

How does penetration testing support PSD2 and DORA compliance? PSD2 requires that open banking API interfaces implement Strong Customer Authentication and are securely exposed to third-party providers. DORA requires financial entities to demonstrate ICT risk management and third-party technology risk governance. Penetration testing provides direct adversarial validation of the technical controls both frameworks require, and Cyrex's structured reporting generates the documented evidence that regulatory and audit processes expect.

What is the risk of open banking APIs specifically? Open banking APIs create mandatory external access points that third-party providers use to integrate with financial platforms. Each endpoint requires validation of authentication logic, access control boundaries, parameter handling, and business logic integrity under adversarial conditions. A security failure on an open banking API simultaneously creates a payments risk and a GDPR data breach, with both sets of regulatory consequences attached.

Why does third-party risk matter so much in fintech? 41.8% of breaches affecting leading fintech companies in 2025 originated from third-party vendors. Financial platforms that rely on external API integrations, shared infrastructure, or partner-provided services inherit the security posture of those providers. Testing programmes that do not explicitly cover third-party interfaces and integration points leave a significant portion of the actual attack surface unassessed.

What makes white box testing particularly valuable for financial platforms? White box testing provides full visibility into source code and architecture, enabling identification of vulnerabilities at the implementation level that are invisible to black box testing. For financial platforms handling cryptographic keys, private credentials, payment logic, or complex access control systems, white box testing is often the only approach that produces genuine assurance rather than surface-level coverage.