Fintech penetration testing for payments and banking apps

On this page

• Attack surfaces and risks
• Payments
• Lending and banking apps
• Insurtech
• Regulation
• How a test runs
• Report and retest
• Experience and method
• Questions

Attack surfaces and risks

Scope penetration testing for fintech around the applications, interfaces and money-movement flows you need tested.

We test how your system uses its integrations — KYC, payment, bank and eID services.

Payments

A fintech pentest can cover payment flows, payment-provider integrations and payouts. We test whether duplicated or replayed requests or webhooks can move money twice, and whether rate limits hold when requests are repeated quickly.

We test authorisation: whether a user can start, change or approve a payment, refund or payout they are not entitled to. We examine refund, promotion and chargeback abuse as logic flaws.

For payment-provider integrations, we test how your system handles responses and callbacks. For checkout, see e-commerce penetration testing.

Lending and banking apps

Lending and banking scope can include the online banking web application, the mobile banking app and the customer web app where applicants apply. We test the APIs behind these applications, including onboarding and KYC calls and the endpoints serving account and repayment views.

We test authentication and two-factor flows, and whether a customer can access another customer’s data without authorisation. We also test rate limits on login and onboarding, and logic flaws in money movement.

Both a mobile app and its APIs can be included in the scope. For payment services, see the PSD2 section.

Insurtech

Insurtech testing can cover customer portals where policyholders view policies and submit claims, iOS and Android mobile apps, and partner or broker APIs.

In those portals, apps and APIs, we test authentication and authorisation, input validation, encryption and data integrity, rate limiting, and error handling.

Report and retest

Every report lists the vulnerabilities found, rates each by risk, and gives remediation steps. A penetration test report also sets out the exploitation methods demonstrated during testing, and a priority-based action plan.

Our reports include an executive summary, the scope of work, the test type and methods, the methodology, how risk is calculated, a summary of findings, detailed results for each finding, and a conclusion.

In the report for your payment or banking application, each finding is rated by severity.

Reports run to 20–100+ pages.

After you fix the findings, we re-test them.

A retest covers the findings only, not the full application. It is usually quoted in the same offer as the test. The retest window is about 4 weeks, or sooner if you have fixed the findings earlier and our schedule has an opening.

You can request our sample web application penetration test report through the contact form or by email.

Experience and method

With over 7 years of experience in testing, we have built extensive expertise in web applications and websites, e-commerce platforms, mobile applications, APIs and SaaS solutions.

Our penetration tests can follow OWASP, ISSAF, PTES or OSSTMM at your request or on our recommendation. What we follow and how much of it we cover are agreed at scoping.

Testing uses Burp Suite, manual testing and our own tools.

Our pentesters hold certificates including PNPT, eCPPTv2, CAP, CompTIA PenTest+ and CompTIA Security+, and their published research includes five CVEs.

Questions

Does DORA require penetration testing, and what is TLPT?

Under DORA, EU financial entities other than microenterprises must run a digital operational resilience testing programme and, at least yearly, test the ICT systems and applications that support critical or important functions (Article 24). Penetration testing is one of the tests Article 25 lists for that programme. Our penetration tests of web applications, mobile apps and APIs can form part of it.

We do not perform threat-led penetration testing (TLPT) under DORA Article 26.

What does PCI DSS require, and how often?

PCI DSS v4.0.1 Requirement 11.4 requires internal and external penetration testing at least once every 12 months and after significant changes, including network-layer testing and, where segmentation is used, segmentation testing. We test the web applications, APIs and mobile apps in your PCI DSS scope. We do not perform network-layer or segmentation testing, so our test covers part of Requirement 11.4. We are not a QSA and do not certify PCI DSS compliance.

How do you test transaction logic, refunds, promotions, chargebacks and rate limits?

We test transaction logic by checking how money-movement and refund flows respond to repeated requests and actions outside a user’s permissions. The checks cover refund, promotion and chargeback abuse, rate limits, authentication and two-factor flows, webhook handling and idempotency.

Do you test the mobile app and its APIs together?

Yes, a mobile app and the APIs behind it can be tested in the same engagement.

We scope each test with you, either through our scoping questionnaire or in a scoping meeting where we ask the same questions.

How do you test integrations with KYC services, payment providers and bank APIs?

We test how your system uses its integrations — KYC, payment, bank and eID services.

Will testing disrupt our live financial services?

Testing is conducted under controlled conditions with agreed rules of engagement. We schedule around your business needs.

A bank partner asked for our penetration test report. What does it give them?

The report is evidence you can give your auditors, supervisors and customers. What they accept is their decision.

Every report lists the vulnerabilities found, rates each by risk, and gives remediation steps. A penetration test report also sets out the exploitation methods demonstrated during testing, and a priority-based action plan.

How do retests work?

After you fix the findings, we re-test them.

A retest covers the findings only, not the full application. It is usually quoted in the same offer as the test. The retest window is about 4 weeks, or sooner if you have fixed the findings earlier and our schedule has an opening.

What does a fintech penetration test cost?

The cost of a fintech penetration test depends on the number of systems or applications in scope, the testing type, the complexity of the environment and the timeline.

See common questions on penetration testing cost, duration and frequency.

What is the difference between a penetration test and a vulnerability assessment?

A vulnerability assessment scans your systems with Burp Suite, and an expert verifies and prioritises what the scan finds. A penetration test goes further: testers try to exploit what they find and show you the impact.

For the service details, see penetration testing and vulnerability assessment.

Related services

• Web application security testing
• Mobile application security testing
• API security testing
• Penetration testing
• Vulnerability assessment