2 November 2026 · 11 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)
Fintech Penetration Testing: What to Test, Which Rules Apply and What Sponsor Banks and Investors Ask For
A fintech moves other people's money through code it ships every week, on rails it does not own, under licences held by partners who can switch it off. That combination makes penetration testing a condition of doing business rather than a compliance line item. This guide maps the attack surface, the regulatory expectations in the United States and the EU, and the evidence sponsor banks, auditors and investors expect to see.
What fintech penetration testing is and why it differs
Fintech penetration testing is a manual, goal-driven security test of a financial technology product and the infrastructure around it: the mobile and web applications, the public and partner APIs, the onboarding and identity verification flows, the payment and card integrations, the ledger, and the cloud environment that hosts them. The goal is not a list of vulnerabilities but an answer to three questions a sponsor bank, a regulator or a customer will eventually ask: can an attacker move money they should not, can they see or change financial data they should not, and can they get past the identity checks that make the product lawful to operate.
Three things make it different from testing a general SaaS product. Money is the target, so business-logic flaws (a transfer limit that can be bypassed, a refund that can be issued twice, a balance that updates before a payment settles) matter more than the classic injection classes. The product depends on regulated partners, so the test must cover the integrations with sponsor banks, card processors, payment networks and data aggregators, and the evidence has to satisfy their due diligence. And releases are frequent, so a single annual test leaves most of the year's code untested unless the programme is tied to the release cycle.
SaaS-specific topics such as multi-tenancy, SOC 2 for software companies and startup security programmes are covered in our SaaS penetration testing guide, linked below. Card-data scoping and Requirement 11.4 are covered in the PCI DSS guide. This page concentrates on what is specific to fintech.
The fintech attack surface
Eight surfaces where a fintech can lose money, data or its licence. Each is described at the level of what the test looks for; the techniques belong in the engagement.
Mobile applications
Tested against OWASP MASVS v2 and MASTG: local data storage, certificate pinning and transport security, authentication and biometric binding, session handling, reverse-engineering resistance for the parts that matter (key material, fraud signals), and above all the API the app talks to, which is where the real functionality lives.
Public and partner integrations
The public and partner APIs, tested against the OWASP API Security Top 10 (2023): object-level and function-level authorisation, excessive data exposure, rate limiting, mass assignment, and the business logic behind every endpoint that creates, moves or approves value. API testing is the core of a fintech engagement and the reason this page routes to our API penetration testing service.
Open banking and data aggregation
Consent flows, token lifecycle and scope enforcement for aggregator and third-party access, FDX-aligned APIs in the US and PSD2 interfaces in the EU, and what a compromised aggregator credential or a leaked long-lived token could pull. The CFPB's Section 1033 Personal Financial Data Rights rule, finalised in October 2024 and reopened for reconsideration in 2025, keeps this surface in focus whatever its final shape.
KYC, onboarding and identity verification
Document upload and liveness checks, the vendor integrations behind them, step-up and re-verification logic, synthetic-identity resistance, and whether onboarding decisions can be replayed, bypassed or manipulated client-side. A KYC bypass is a security finding and a licence risk at once.
Payment rails and money movement
ACH origination through the sponsor bank, card authorisation and settlement, real-time payments over RTP and FedNow, wire and international transfers, limits and velocity controls, idempotency and race conditions on transfers, and the webhooks and callbacks that confirm settlement.
Card programmes and BIN sponsors
Issuer-processor integrations, card provisioning and tokenisation, card-data scope boundaries for the parts of the platform that touch card data, programme-manager controls, and the dispute and chargeback workflows that attackers abuse for fraud at scale.
Ledger integrity
Whether balances, holds and settlements can be made to disagree with the money that actually moved: double-spend through concurrency, rounding and currency conversion abuse, negative-amount and overflow handling, reconciliation gaps between the internal ledger and the sponsor bank's records.
Fraud controls as security controls
Velocity limits, device fingerprinting, transaction monitoring and step-up authentication are security controls when the attacker is a customer. The test checks whether they can be evaded, disabled by a client-side change or starved of the signals they depend on.
The regulatory map for fintech penetration testing
Which regime reaches which kind of fintech, what it expects from testing, and what evidence the partner or supervisor behind it will ask for. US regimes first; PSD2 and DORA for fintechs operating in the Netherlands and the EU.
| Regime | Who it reaches in fintech | Testing expectation | Evidence asked for |
|---|---|---|---|
| PCI DSS v4.0.1 | Any fintech storing, processing or transmitting cardholder data, and card programme managers | Requirement 11.4: internal and external penetration testing annually and after significant change; segmentation testing; Requirement 6.4 for payment pages | Report with CDE scope, segmentation results and retest; Attestation of Compliance |
| SOC 2 (AICPA Trust Services Criteria) | Almost every B2B fintech and most consumer fintechs selling to banks | No named test, but CC4.1 and CC7.1 are routinely evidenced with an annual third-party penetration test and remediation tracking | Type II report with the penetration test referenced in the control evidence |
| NYDFS 23 NYCRR Part 500 | Fintechs licensed by NYDFS: money transmitters, virtual-currency licensees, lenders, insurers | Section 500.5: annual penetration testing from inside and outside by a qualified independent party | Test report plus the CISO's annual certification and risk assessment |
| State money-transmitter laws | Fintechs that hold or transmit customer funds without a bank charter | Most states' rules, increasingly aligned through the model Money Transmission Modernization Act, require an information security programme and examination; examiners ask for independent testing | Current test report and remediation evidence at licensing and examination |
| GLBA Safeguards Rule, 16 CFR Part 314 | Non-bank lenders, loan servicers, brokers and buy-now-pay-later providers | Annual penetration test and six-monthly vulnerability assessments (314.4(d)(2)) unless continuous monitoring is in place | Dated test and scan evidence for the Qualified Individual's board report |
| Sponsor bank due diligence (OCC, FDIC, Federal Reserve expectations) | Every fintech with a banking-as-a-service or sponsor relationship | Interagency third-party guidance of June 2023 makes the bank responsible for assessing the fintech; after the 2024 and 2025 consent orders, banks ask for current tests before and during the relationship | Penetration test report under 12 months old, remediation and retest evidence, SOC 2 Type II |
| PSD2 and DORA (EU, Netherlands) | Payment and e-money institutions, crypto-asset service providers, their critical ICT providers | PSD2 RTS on strong customer authentication and secure communication; DORA Articles 24 and 25 require a risk-based testing programme with annual penetration testing of systems behind critical functions | Testing programme documentation and reports filed in the ICT risk-management framework for DNB and the AFM |
What sponsor banks and partners demand
Sponsor banks are examined on what their fintech partners do. Since the banking agencies' 2023 third-party guidance and the enforcement actions that followed in 2024 and 2025, their due diligence has become specific. Expect these requests at onboarding and at every annual review.
A current, independent penetration test
A report under twelve months old from a firm independent of your engineering team, covering the product and the integration with the bank, not a vulnerability scan and not an internal exercise. Many banks now ask for the scope statement and the testers' qualifications, not only the summary.
Scope that covers the integration itself
The API connection to the bank, the credentials and certificates used, the file transfers and webhooks, the account structures (FBO accounts, virtual accounts, sub-ledgers) and the reconciliation between your ledger and theirs. The bank's examiner will ask what a compromise of your platform could do to the bank's customers.
Remediation evidence and a retest letter
Findings closed within a defined window, with a retest confirming the fix. An open critical finding at the annual review is a contract conversation, not a technical one.
Supporting attestations
SOC 2 Type II, a PCI DSS Attestation of Compliance where cards are involved, and policies that match what the test observed. Banks cross-read these documents; a SOC 2 that claims annual testing must line up with a test report that exists.
A programme, not a point in time
Evidence that testing recurs with releases and that new products or rails are tested before launch. A single test from the funding round two years ago reads as a gap.
Testing cadence per release
Fintechs ship weekly. A testing programme that keeps pace separates the annual full-scope engagement from targeted tests tied to change.
Annual full-scope engagement
Mobile, web, APIs, cloud configuration and the partner integrations, tested together so chained findings surface. This is the report the sponsor bank, the auditor and the investor read.
Pre-launch test for every new product or rail
A new card programme, a new payment rail, an open banking connection or a lending product gets its own scoped test before customers touch it. Partners increasingly require it in the programme agreement.
Targeted retest after material releases
Changes to authentication, authorisation, money movement, KYC or ledger logic trigger a focused test of the changed components within the release cycle, not at the next annual round.
Continuous testing for high-velocity teams
Penetration testing as a service spreads tester time across the year against a living scope, with findings flowing into the engineering backlog. Our guide to penetration testing as a service, linked below, explains when it fits and what it does not replace.
Bug bounty versus penetration test versus automated scanning
Mature fintechs run all three. They answer different questions, and only one of them produces the document a sponsor bank or auditor accepts.
| Aspect | Automated scanning | Penetration test | Bug bounty |
|---|---|---|---|
| What it finds | Known vulnerabilities and misconfigurations | Chained and business-logic flaws, authorisation gaps, ledger and payment abuse | Whatever motivated researchers choose to look at |
| Coverage | Broad, shallow, continuous | Defined scope, deep, time-boxed | Unpredictable; concentrates on public surfaces |
| Who performs it | Software | Named, certified testers under contract and NDA | Anonymous or pseudonymous researchers |
| Evidence value | Supports compliance scanning requirements; not a penetration test | Accepted by sponsor banks, auditors and regulators | Supplementary; rarely accepted as the required test |
| Best for | Hygiene between tests | Assurance, compliance, pre-launch | Ongoing exposure of public apps once the basics are solid |
What investors and acquirers ask for in diligence
Cyber diligence in fintech fundraising and M&A has converged on a short list. Having it ready shortens the process and removes a price-chip argument.
- The most recent full-scope penetration test report, with scope statement, named testers and methodology
- Remediation status for every high and critical finding, with retest evidence
- The testing cadence over the last 24 months, showing tests tied to launches and major releases
- SOC 2 Type II and, where relevant, the PCI DSS Attestation of Compliance
- Sponsor bank and partner due diligence correspondence showing no open security conditions
- Incident history, including anything reported to a regulator or a partner, and what changed afterwards
How HackersHub tests fintechs
We start from the API, because that is where fintech value moves, and test the mobile and web clients as consumers of it. The engagement follows OWASP WSTG, MASVS and MASTG and the OWASP API Security Top 10, with deliberate time reserved for business-logic and ledger testing: transfer limits, idempotency, concurrency, refund and dispute flows, KYC decision paths. Partner integrations are tested from your side with the sponsor bank's rules of engagement respected, and the cloud environment is reviewed for the configuration gaps that turn an application finding into a data breach. Every tester holds OSCP at minimum, with OSWE and CREST-certified testers on the team, and is named in the report.
The report is written for three readers: your engineers, who get reproducible findings and prioritised remediation; your compliance lead, who gets a scope statement mapped to PCI DSS, SOC 2, Part 500 or DORA as applicable; and the sponsor bank or investor, who gets an executive summary and a retest letter. A verification retest of medium and higher findings within 90 days is included. HackersHub is based in Amsterdam, Netherlands and tests US fintechs remotely within agreed windows and US business hours. With 10+ years of offensive security work and a 4.9/5 rating across 127 reviews, we are used to our reports being read by partners who can end a programme.
Frequently asked questions
Related guides
- API penetration testing by HackersHub
- Mobile application penetration testing
- Penetration testing services by HackersHub
- SaaS penetration testing: multi-tenancy, SOC 2 and startups
- PCI DSS penetration testing: Requirement 11.4 explained
- Penetration testing for banks and credit unions
- NYDFS penetration testing: 23 NYCRR 500.5
- GLBA and FFIEC penetration testing for non-bank lenders
- Penetration testing as a service: when continuous testing fits
- SOC 2 penetration testing: what auditors expect
Sponsor bank or investor asking for your penetration test?
We test the API, the apps, the ledger and the integrations, and deliver a report your engineers, your compliance lead and your partners can each use. Talk to an expert.