Fintech Cybersecurity: PCI DSS, Testing and Cyber Essentials for Payments Firms

Fintech cybersecurity is mostly about proving your controls to the people you depend on: acquirers, sponsor banks, card schemes, the FCA, customers and investors. For payment service providers (PSPs), e-money institutions (EMIs), payment facilitators and open banking firms, that proof comes from four places: PCI DSS validation as a service provider, API and app penetration tests, Cyber Essentials for supplier checks, and testing evidence for UK operational resilience rules or DORA. Banks, issuers and acquirers are covered on our cyber security for banks and card issuers page.

What compliance does a fintech need?

It depends on what you do with money and card data. Most firms sit in more than one row.

Regulation 98 of the Payment Services Regulations 2017 requires every payment service provider to manage operational and security risks and to give the FCA an assessment of them at least once a year. Neither that rule nor the FCA’s operational resilience rules names a certificate or a particular type of security test, so partners fill the gap themselves. Payment firms with their own SWIFT connection also attest every year under the SWIFT CSP.

How does PCI DSS apply to payment firms?

If you store, process or transmit cardholder data on behalf of another business, or could affect the security of their card data, PCI DSS treats you as a service provider. Under Visa and Mastercard rules, service providers handling more than 300,000 of that brand’s transactions a year are Level 1 and need an annual Report on Compliance (ROC) from a Qualified Security Assessor; Mastercard treats every Third Party Processor as Level 1. Merchants and partners will ask for the resulting Attestation of Compliance (AOC) for Service Providers.

Service providers also carry extra requirements. Two shape fintech testing plans under PCI DSS v4.0.1:

• Requirement 11.4.6: if you use segmentation to reduce scope, penetration test it at least once every six months and after any change to segmentation controls (merchants test every 12 months).
• Requirement 11.4.7: multi-tenant service providers must support customers who need to run their own external penetration tests (mandatory since 31 March 2025).

Our PCI compliance service provider page covers the rest, including every service-provider-only requirement. If your platform handles PINs, PCI PIN applies as well, and we assess it as a Qualified PIN Assessor (QPA) company. If you also take card payments as a merchant, our free PCI compliance check suggests your likely SAQ.

What are the main cyber threats to fintech firms?

Fintechs are built on APIs, cloud platforms and partners, so most attacks target those rather than an office network:

• API abuse. Broken object-level authorisation, scraping and replayed requests against the APIs behind your apps and partner integrations.
• Account takeover. Credential stuffing, SIM swaps, weak account recovery and attempts to bypass strong customer authentication.
• Third-party and supply chain risk. Banking-as-a-service partners, identity verification providers, SDKs and open-source libraries that expose your customers if they are compromised.
• Cloud misconfiguration. Public storage buckets, over-privileged IAM roles and secrets left in code repositories.
• Fraud through onboarding. Synthetic identities and money mule accounts that exploit fast sign-up flows.

Each one points to a test: API and mobile app testing for the first two, supplier assurance for the third and cloud penetration testing for the fourth. For ransomware, APP fraud and the other risks across the wider sector, see the main cyber threats to financial services firms.

What fintech penetration testing do payment apps need?

Payment apps need manual penetration tests of the API and of the mobile and web clients, at least once a year and after significant changes. For systems in PCI DSS scope, Requirements 11.4.2 and 11.4.3 make that cycle mandatory for internal and external tests, including the application layer; elsewhere, partners and auditors expect it. Scanners find missing patches, but the flaws that cost payment firms money sit in business logic, so fintech penetration testing has to be manual and authenticated:

Our API penetration testing follows the OWASP API Security Top 10, and mobile app penetration testing covers iOS and Android builds against OWASP MASVS. Most payment platforms run in the cloud, so the accounts behind them need testing too; see AWS penetration testing.

How do UK operational resilience rules and DORA affect fintechs?

Both expect you to test the systems behind your important services. In the UK, the FCA’s operational resilience rules in SYSC 15A cover payment and e-money firms: identify important business services, set impact tolerances and test against severe but plausible scenarios. Our operational resilience guide explains the regime, and firms that want an external benchmark for business continuity often add ISO 22301 certification.

In the EU, the Digital Operational Resilience Act covers payment institutions, e-money institutions and account information service providers authorised or registered in a member state. Article 24 requires financial entities, other than microenterprises, to run appropriate tests of all ICT systems and applications supporting critical or important functions at least yearly.

UK fintechs often sit on both sides of DORA. An EU-authorised subsidiary is a financial entity in its own right, while a UK firm supplying software, hosting or API platforms to EU financial entities is managed by them as an ICT third-party provider, with DORA contract terms, audit rights and requests for test results. We provide DORA testing evidence of the kinds Article 25 lists (vulnerability scans, penetration tests, source code review and scenario-based red team exercises). Threat-led penetration testing (TLPT) is a separate scheme with its own tester rules, explained in our guide to TLPT under DORA, and our DORA regulation guide covers the rest.

What do investors, sponsor banks and US customers ask for?

Independent evidence, usually:

• an AOC for Service Providers, if you touch card data;
• an executive summary of your latest penetration test, with retest results;
• a Cyber Essentials or Cyber Essentials Plus certificate;
• an ISO 27001 certificate, or a SOC 2 report for US enterprise buyers.

Investors ask the same questions in technical due diligence, so test before the data room opens. Our ISO 27001 consultancy prepares you for certification, with the audit carried out by our partner certification body, MQA International. Only a licensed CPA firm can issue a SOC 2 report; we provide the SOC 2 penetration testing evidence the auditor reviews. When partners will accept Cyber Essentials and when they want Plus is covered in our guide to cyber security for financial services firms.

Why Sovereign Secure for fintech cybersecurity?

• PCI SSC-approved QSA company, Qualified PIN Assessor (QPA), Card Production Security Assessor (CPSA), P2PE Assessor and 3DS Assessor, and a member of the PCI SSC Global Executive Assessor Roundtable for 2026 to 2028.
• IASME-licensed Cyber Essentials certification body, and ISO 27001 certified ourselves.
• Web, API, mobile, cloud, network and source code testing, plus vulnerability scanning; external ASV scans delivered through our PCI SSC Approved Scanning Vendor partner.
• Payments clients shown on our site include Cashplus, Liquid Pay and Fiserv.

Where should a fintech start?

Tell us your business model, whether card data touches your systems, and what your next partner, regulator or investor has asked for. We will say which assessment or test answers that request first and send a fixed quote. Use the enquiry form on this page, choosing “PCI DSS Assessments” or “Penetration Testing”, or call +44 161 523 5276.