Penetration Testing for Banks, Fintech and Payments in 2026

Fintech penetration testing is an authorized attack on the systems that move money and hold customer financial data. That means banking and payment apps, the APIs behind them, cloud accounts and internal networks.

For a bank, lender or payment company the test has two jobs. It has to find the flaw that lets someone take over an account, read another customer's records or change a payment. It also has to produce evidence that a QSA, a regulator or a bank partner will accept. Teams often learn that second job matters as much as the first when a report comes back for rework.

This guide covers what PCI DSS, the FTC Safeguards Rule, NYDFS and DORA each say about penetration testing, who actually asks a fintech for the report, how to scope the test, and how AI pentest providers compare.

What CodeAnt AI solves here: CodeAnt AI runs penetration tests for banks, fintech lenders, payment companies and the software vendors that sell to them. AI agents attack web apps, APIs, cloud and internal networks, chain what they find into attack paths, and researchers verify findings by hand before the report reaches you.

Short answer: a bank or fintech pentest should test account takeover, cross-customer data access and payment logic across apps, APIs, cloud and internal networks. Run it at least yearly and after significant changes. Make sure the report is written against the rule your assessor checks, usually PCI DSS Requirement 11.4, plus GLBA, NYDFS or DORA where they apply.

What Does a Penetration Test for a Bank or Fintech Cover?

A financial services pentest asks three questions an attacker would ask of any system that moves money. Everything else in the scope exists to answer them.

The second row fails most often. In industry-level scans CodeAnt runs for data intelligence (August 4 to October 30, 2026), broken access control such as IDOR or unauthenticated APIs made up 49.5% of critical findings.

APIs were the exposed asset on 58.6% of compromised domains in the same scans, and financial data was exposed on 31.6% of them. That is why a fintech test should spend most of its hours on API authorization.

The infrastructure layer still matters. External tests cover every server, mail host and VPN with your name on it. Internal tests start from an attacker's foothold and work toward Active Directory, file shares and the cardholder data environment.

Cloud tests follow identities, storage and secrets from one workload to customer data. A test that skips any of these leaves the path from a low-value foothold to the payments database unmeasured.

Which Regulations Require a Penetration Test for Banks and Fintech Companies?

Four rules name penetration testing for financial firms, and a fintech often answers to more than one. Each sets its own minimum, read here from the rule text.

Bank partners, card networks and enterprise customers ask for the same evidence in their own security reviews. One well-scoped test with a clear report often answers several of them at once.

PCI DSS Requirement 11.4

PCI DSS is the most prescriptive of the four. Requirement 11.4.1 asks for a defined methodology covering application-layer and network-layer testing, and 11.4.2 and 11.4.3 set internal and external tests at least once every 12 months and after any significant infrastructure or application change.

The tester can be a qualified internal resource or a qualified external third party with organizational independence. The standard does not require the tester to be a QSA or ASV.

Requirement 11.4.4 asks that exploitable findings are corrected and the corrections verified by retesting. If segmentation keeps the cardholder data environment out of scope, 11.4.5 requires testing it every 12 months, and 11.4.6 tightens that to every six months for service providers, a change the PCI SSC introduced in v3.2.

Our PCI DSS penetration testing requirements guide walks through each sub-requirement and the v3.2.1 to v4.0.1 renumbering.

FTC Safeguards Rule and GLBA

The FTC Safeguards Rule is the GLBA rule for lenders, servicers, money transmitters and other non-bank financial institutions. Section 314.4(d)(2) requires annual penetration testing scoped from your risk assessment and vulnerability assessments at least every six months and after material changes.

The one way out is effective continuous monitoring that detects changes in your systems on an ongoing basis. Institutions holding information on fewer than 5,000 consumers are exempt from this clause under section 314.6. The GLBA penetration testing requirements guide covers the rest of the rule.

NYDFS 23 NYCRR 500.5

Section 500.5(a)(1) requires penetration testing of your information systems from both inside and outside their boundaries, by a qualified internal or external party, at least annually.

An external-only test does not meet that sentence. The same section adds automated scans at a risk-based frequency and after material system changes. Our NYDFS penetration testing requirements guide covers who counts as a covered entity.

DORA and Threat-Led Penetration Testing (TLPT)

DORA applies to EU banks, payment and e-money institutions, investment firms, insurers and their ICT providers. Article 24(6) requires appropriate tests at least yearly on all ICT systems and applications that support critical or important functions, and Article 25 lists penetration testing among those tests.

Article 26 adds threat-led penetration testing at least every 3 years for the entities their competent authority identifies. TLPT runs on live production systems from real threat intelligence, so it sits on top of the yearly testing and does not replace it.

Who Is Asking Your Fintech for a Pentest, and What Do They Want to See?

The regulation is rarely the first to ask. On our calls with banks, lenders and payment companies between July and November 2026, the request came from three places, and each one wants a slightly different report.

A lender's CTO put the bank partner case plainly. The bank that funds them requires an external and internal pentest every year, and their SOC 2 auditor asks separately.

The bank-as-customer case is the one vendors underestimate. Banks push their own compliance obligations onto the vendors that touch their data, then ask for evidence on their schedule, which is rarely the vendor's audit calendar.

The practical move is to collect every request you owe in one list before scoping. A single test with one report built for the strictest reader usually satisfies the others.

How Should You Scope a Financial Services Pentest?

Scope from what you expose and what you hold, then pick how much the tester knows going in. The three standard depths answer different questions.

For a fintech, grey box is the floor. The three risks that matter most (takeover, cross-customer access, payment manipulation) only show up once the tester is logged in as a real customer. See black box vs white box vs gray box penetration testing for the tradeoffs in detail.

Scope from domains, apps and accounts

Cloud-native teams are often asked first how many IP addresses, endpoints and servers they have. On a stack built from managed services, serverless functions and shared CDN addresses, that count says almost nothing about the attack surface.

Scope from your domains, applications, APIs, cloud accounts and user roles instead. A lender on one of our calls said exactly this about IP-based quotes, and the same complaint keeps coming up on our calls.

Agree the boundaries with your assessor first

For PCI DSS, agree the cardholder data environment and the segmentation boundary with your QSA before testing starts. A test against the wrong boundary produces a clean report your assessor cannot use.

Decide production versus staging the same way. Testing staging is safer, but the assessor needs to know the staging build matches production for the evidence to count.

What Should a Pentest of a Fintech Web App That Handles Payments and PII Cover?

Use this list to check a proposal or a finished report. If a line has no matching test case, ask why before you sign.

Identity and sessions

• Login and MFA: credential stuffing limits, MFA bypass and MFA enrollment by an attacker.

• Recovery: password reset tokens, email and phone change flows, support-assisted recovery.

• Sessions: token lifetime, logout, reuse of tokens across devices and roles.

Customer data and PII

• Object access: swap account, statement, card and KYC document IDs across two test customers.

• Bulk exposure: export endpoints, search, admin APIs reachable with a customer token.

• Stored documents: signed URL lifetime and guessable paths for uploaded ID files.

Payments and business logic

• Amounts: negative values, rounding, currency switches and changes after approval.

• Recipients: swapping the payee between quote and confirm.

• Refunds and reversals: issuing twice, refunding more than was paid, racing two requests.

• Approvals: skipping a maker-checker step or approving your own request.

APIs, cloud and the path to data

• API surface: undocumented versions, partner and webhook endpoints, unauthenticated routes.

• Cloud: over-permissive roles, public storage, secrets in build logs and environment files.

• Internal path: from one compromised workload to the database that holds customer records.

A grey box test with one ordinary account per role covers the first three groups. A white box test adds code and cloud configuration, which is where you learn whether a fixed IDOR exists in twelve other handlers.

The payments group is where a refund issued twice turns into a finance team's very long afternoon. CodeAnt's research team found a version of it in open source. CVE-2026-71506 let a Dolibarr user with only invoice-deletion rights delete recorded customer payments through the API.

Will an AI Pentest Hold Up With Your Assessor, Bank Partner and Board?

Four questions stall finance deals on our calls. Each has a direct answer you can check against the rule text.

How much is AI, and where does a person come in?

AI agents do the mapping, the attack attempts and the chaining, for hours and across every reachable asset. Researchers then verify findings by hand before the report goes out, so the output is a short list of proven issues with reproduction steps.

Ask any provider the same question and get the split in writing. A report nobody reviewed is a scanner export with a cover page.

Will our assessor accept a report from an AI pentest?

PCI DSS does not ask whether the tester used AI. It asks for a defined method, a qualified tester with organizational independence, internal and external results, and proof that exploitable findings were fixed and retested.

Bring that evidence and your QSA assesses it like any other report. The QSA makes the final call, so share a sample report with them before you buy. Our guide to AI pentesting for audit-grade compliance evidence covers the 11.4.1 manual-testing question in detail.

Can AI find payment and business logic flaws?

Business logic is where finance breaks. A refund issued twice, an amount changed after approval and a recipient swapped mid-transfer all return a normal 200 response.

Finding them takes real roles and a model of what should happen. That is why a grey box test runs as actual customers and checks amounts, recipients, refunds and approvals, and why a person reviews what the agents report.

We already have a pentest vendor on contract

Keep your annual test and add coverage where it is thin, often APIs and code. After the next cycle, compare the two reports side by side on verified findings and the time each took to confirm.

How Do AI Pentest Providers for Financial Services Compare?

Compare providers on what they test, how fast the report arrives, how you pay and whether the report is built for an assessor. Vendor facts below were read on each vendor's own pages on November 9, 2026.

The split that matters for a regulated buyer is the report. A fast AI test that your assessor will not read as compliance evidence still leaves you buying a second test.

For deeper vendor detail, see our breakdowns of Synack pricing, Cobalt pricing, Intruder pricing and Aikido pricing.

How Do You Choose a Penetration Testing Provider for a Fintech?

Pick the provider whose report your strictest reader accepts, then check it finds what matters on your own stack. A short pilot settles both.

1. List every reader. QSA, sponsor bank, card network, regulator, enterprise customers. Note the format and cadence each one asks for.

2. Send the evidence list to the vendor. For PCI DSS that means method, tester qualifications, independence statement, dated internal and external reports, retest proof and segmentation results.

3. Write the answer key first. Before the pilot, record the authorization rules you expect to hold, such as which roles may approve a transfer.

4. Test one app with two customer accounts. Count verified high and critical findings with reproduction steps, and time how long each takes your engineers to confirm.

5. Price a full year. Include tests after significant changes, segmentation tests and retests, since that is where per-engagement pricing grows.

6. Show a sample report to your assessor. Ten minutes of QSA feedback before signing beats a rejected report after.

Our AI pentesting provider evaluation framework turns this into a scorecard you can share with procurement.

How Does CodeAnt AI Run a Financial Services Pentest?

CodeAnt AI has run 12,000 pentests and is trusted by more than 1,000 companies, including Fortune 500 companies like NRG, cybersecurity leaders like Commvault, and fast-growing companies like 11x and Sanas. A financial services engagement runs in five steps.

1. Scope from what you expose. A black box test starts from your name alone, and AI agents map domains, subdomains, exposed services and APIs the way an outsider would. You choose what is in scope, and for PCI DSS you agree the cardholder data environment with your assessor first.

2. Test as a customer and as an insider. A grey box test uses one ordinary account per role to check login, recovery and sessions, cross-customer access to statements, KYC files and records, and amounts, recipients, refunds and approvals. A white box test adds code, configuration and architecture.

3. Prove it, then verify it by hand. Agents chain findings into attack paths and keep only what they can prove. Researchers verify findings by hand before anything reaches you.

4. Report for each reader. Engineers get reproduction steps and fixes, the board gets a one-page summary, and you get an attestation letter for partners and customers. For PCI DSS, the report is written against Requirements 11.4.1 to 11.4.7, with the method, tester qualifications and independence statement your assessor reviews.

5. Retest after fixes. CodeAnt runs the same attack again on each fixed finding and records the result, which is the proof of correction PCI DSS Requirement 11.4.4 asks for.

Timing: the AI pentest report arrives within 48 hours. A PCI DSS engagement takes about three weeks from scope to report, and an annual program runs four tests a year including the six-month segmentation test.

Pricing: CodeAnt prices each pentest on the attack surface you have, and gives very generous pricing to fast-growing companies.

Proof: CodeAnt is SOC 2 Type II, a Gartner Cool Vendor 2026 and CERT-In empanelled. It is a VulnCheck CNA partner, and its security research team has published more than 200 CVEs, including CVE-2026-29000 in pac4j-jwt (CVSS 10.0) and CVE-2026-28292 in simple-git (CVSS 9.8).

Phunware called CodeAnt "the most advanced and thorough penetration test we've run to date."

Scope your financial services pentest or see how the PCI DSS engagement maps to Requirement 11.4.

Where This Leaves You

Start from the list of people who will read your report, then scope the test around the three risks that cost a fintech money: account takeover, cross-customer data access and payment logic.

Buy the depth that reaches those risks, usually grey box or white box, and confirm with your assessor that the report format works before the test starts. For the wider compliance picture, read our compliance penetration testing guide, or go straight to financial services penetration testing with CodeAnt AI.

Sources

Rule text and vendor facts were checked on November 9, 2026.

• PCI SSC Document Library, PCI DSS v4.0.1 Requirement 11.4

• PCI SSC FAQ on Requirement 11.3.4.1 and service provider segmentation testing

• FTC Safeguards Rule, 16 CFR 314.4 (govinfo)

• NYDFS 23 NYCRR 500.5, Vulnerability management (Cornell LII)

• DORA, Regulation (EU) 2022/2554, Article 26

• CodeAnt AI PCI DSS pentesting

• CodeAnt AI security research, CVE-2026-71506