Pentest, PTaaS, bug bounty or AI agent: what each one shows a bank
An EU fintech can buy security testing in four shapes in 2026. They differ less in what they find than in what you can show afterwards.
Security testing for a fintech was usually bought one way: a consultancy, a fixed scope, a report once a year. In 2026 it comes in four shapes. You can hire a pentest firm, subscribe to a testing platform, pay outside researchers per bug, or run an AI agent. When a bank’s vendor-risk team asks what you have, and the four answers look very different on paper.
This note compares them on what they leave you holding: who tested, how often, whether fixes were re-tested, and what you can put in front of a reviewer.
The yardstick the bank uses
For financial entities other than microenterprises, DORA sets the baseline: a testing programme (Art. 24(1)), independent testers, internal or external (Art. 24(4)), appropriate tests at least yearly on all systems supporting critical or important functions (Art. 24(6)), and a menu in Art. 25(1) that runs from scans and source code reviews to penetration testing. Art. 24(5) adds methods to validate that identified weaknesses are fully addressed. Entities selected by their authority also undergo threat-led penetration testing at least every three years (Art. 26). The ECB updated its TIBER-EU framework on 11 February 2025 to align with DORA’s rules for that kind of test. Suppliers feel the baseline through their contracts, as our note on DORA vendor-risk questions explains.
The UK National Cyber Security Centre names the limit every option has to answer. A penetration test can only show that systems are not vulnerable to known issues “on the day of the test”, and “it’s not uncommon for a year or more to elapse between penetration tests” (NCSC).
1. The pentest firm
Named consultants, an agreed scope and a signed report remain the format vendor-risk teams know best. There are quality signals: CREST, a UK not-for-profit, says it “accredits, certifies and quality assures 300 member companies worldwide”, and lists TIBER-EU and the Bank of England’s CBEST among the regulator programmes on its site. The weakness is the snapshot. Checking a fix often means booking a second engagement.
2. Penetration testing as a service
PTaaS moves the engagement onto a platform. HackerOne describes findings “delivered live through the HackerOne platform” and “retesting to confirm that the fixes have been correctly implemented”. Cobalt quotes its standard tiers on request but lists a promotional US$3,500 per test for its autonomous pentest, for tests completed by the end of 2026. The line between PTaaS and AI agents is already blurring. Scope, though, is still what you book.
3. Bug bounty
A bounty pays outside researchers for each valid finding. HackerOne’s 2026 Security Research Report counts US$89.1 million in bounties paid through its platform between July 2025 and June 2026. European platforms compete on location: Intigriti, based in Belgium, says its data is hosted exclusively in Europe, and the French platform YesWeHack won a European Commission bug bounty framework worth up to €7.68 million in October 2025. Both mention DORA on their own sites. That is their claim, not a regulator’s.
A bounty can surface findings outside any scheduled test, within the scope the programme sets. It is weak evidence of absence: a quiet month says nothing about what nobody looked at.
4. AI agents
AI-assisted testing now has public examples. Google’s Big Sleep agent found its first real-world vulnerability, in SQLite, in late 2024. In June 2025 XBOW reported that its autonomous tester had reached the top of HackerOne’s US leaderboard. In August 2025 the finalists of DARPA’s AI Cyber Challenge found 54 unique synthetic vulnerabilities across 63 challenges and patched 43.
Read that funnel carefully. Those were the programmes’ statuses at the time of publication, and they do not measure autonomous validation or remediation. The NCSC judged in May 2025 that fully automated, end-to-end advanced cyber attacks are unlikely before 2027, and that the most significant change will “highly likely” come from AI-assisted vulnerability research (NCSC). For a buyer the open question is the record: does the tool keep what it tested, on which revision, and what it could not check?
What a vendor-risk team can actually assess
DORA does not approve testing by product label, and we found no supervisor statement that accepts PTaaS, bug bounty or AI-agent output as such. Statements of acceptance on vendors’ pages are the vendors’ own. What a reviewer can assess is the record: scope, date, method, who tested, which revision, the result, and a re-test of each fix. Any of the four can produce that record, and any of them can fail to.
Our recommendation, not a legal duty: agree a testing cadence with each regulated customer. A sensible default is a scoped, dated test of the functions they rely on, at least yearly and after material changes; cheaper continuous checks in between; and a re-test tied to every fix. Before you buy any of the four, ask:
- Who authorises the testing, and who can stop it?
- Which assets and which revisions are in scope, and what may testers access?
- Who handles sensitive findings, and where are they stored?
- Do you receive a portable report and a record of each fix being validated, or only a dashboard login?
One check this week
Open your last test report. Does it name the revision that was tested and the date of each re-test? If not, expect it to be a vendor-risk reviewer’s first follow-up question. Our note A finding is not a fix lists what such a record needs.
Bracemont is in development: security testing for regulated software, with a human approving scope and every merged fix. Join the waitlist to hear when it opens.