By EJN Labs · 18 Aug 2026 · 8 min read
FPS security penetration testing is expected of every Faster Payments participant. Pay.UK, which operates the scheme, requires direct participants to comply with the FPS Rules and with its assurance and attestation requirements, set out in the Faster Payments System Principles, while indirect PSPs inherit equivalent obligations through their sponsor, and in our experience independent technical testing is what participants use to evidence the security of the payment estate. Most participant engagements take 4 to 9 days with a CREST-accredited firm, typically £4,400 to £12,600 at UK day rates of £1,100 to £1,400.
Why FPS security penetration testing matters for participants
The Faster Payments System moves money between UK accounts in seconds. That speed is the product, and it is also the risk. A compromised participant is not just a data breach: it is a live channel for irrevocable fraudulent payments, and a stability risk to the scheme itself.
That is why Pay.UK, the operator of Faster Payments, places security and resilience obligations on participants as a condition of taking part. Direct participants connect their own infrastructure to the central system; indirect participants and fintechs reaching the scheme through aggregators and sponsor banks inherit obligations through their access arrangements. Either way, the organisation connecting to the payment flow has to demonstrate that its estate will not become the weak link.
Penetration testing sits at the centre of that demonstration. Policies describe how your controls should work; a penetration test shows how they hold up when a skilled attacker tries to reach the systems that create, sign and submit payment instructions.
What the Faster Payments participant requirements actually ask for
Role-based requirements covering security, resilience and conformance, set by Pay.UK and scaled to how you connect to the scheme. There is no single published checklist: a direct settling participant running its own gateway carries heavier obligations than a fintech connecting through a sponsor bank.
Neither role is exempt.
In practice, participants are expected to evidence three things:
- Conformance: your connection, messaging and payment processing behave as the scheme rules require, including under failure conditions; the Faster Payments System Principles set out functional, non-functional and failure-scenario certification testing that Pay.UK reviews and signs off before a direct participant goes live.
- Resilience: you can withstand and recover from disruption, which for regulated firms dovetails with FCA and PRA operational resilience expectations around important business services and impact tolerances.
- Security testing: the systems in the payment path have been independently tested against realistic attack techniques, and findings are being remediated.
Faster Payments participation does not prescribe a single named test standard the way PCI DSS does for card data. It puts the burden of proof on you. When Pay.UK, your sponsor bank or your regulator asks how you know your payment estate is secure, “we ran a vulnerability scan” does not survive scrutiny. An independent penetration test from a CREST-accredited firm, scoped around the payment path, does.
The same test also serves FCA operational resilience evidence, sponsor bank due diligence and board reporting. We cover the wider picture in our guide to cyber security for financial services.
What to test in a Faster Payments estate
Scope should follow the payment, from the moment an instruction is created to the moment it leaves for the scheme. When we scope these engagements, we map the payment path first and let the asset list fall out of it.
Payment initiation channels and APIs
Web banking, mobile apps and the APIs behind them are where payment instructions are born, and where most real-world payment fraud starts. Testing focuses on authentication and step-up controls, authorisation logic, beneficiary and amount tampering, and business logic flaws such as replaying or racing payment requests. Dedicated API penetration testing matters here because payment APIs often trust internal callers more than they should.
The gateway and scheme connectivity
For direct participants, the systems that build, sign and submit scheme messages are the crown jewels. Testing examines segregation between the corporate network and the payment zone, controls around message signing keys, and whether an attacker on a standard workstation can reach payment infrastructure at all.
External perimeter and remote access
Internet-facing services, VPNs and third-party connections are the routes in. An external infrastructure penetration test establishes what an unauthenticated attacker can exploit before any credentials are involved.
Cloud platforms and supporting services
Newer participants commonly run payment workloads in AWS or Azure. Misconfigured identity roles, over-permissive service accounts and exposed storage give attackers a path around solid application controls, so cloud configuration review belongs in scope.
How an engagement runs
A typical participant engagement follows five stages:
- Scoping. A short call to map the payment path and agree targets, environments and test windows. Payment systems are usually tested in a production-like environment.
- Rules of engagement. Written authorisation, emergency contacts, and explicit exclusions such as live settlement windows. This matters more in payments than in almost any other sector.
- Testing. UK-based testers work through the agreed scope, combining infrastructure, application and API techniques, with daily contact and immediate escalation of any critical finding.
- Reporting. An executive summary for board and regulator conversations, plus technical reproduction steps for engineers, each finding risk-rated in the context of the payment flow.
- Retesting. Verification that remediated issues are closed, giving you a clean evidence trail for Pay.UK, sponsor banks and auditors.
If you are preparing internally first, our penetration testing checklist walks through what to have ready before testers arrive.
What it costs and how scope drives the price
Penetration testing is priced on effort. UK day rates at CREST-accredited firms typically run £1,100 to £1,400, and days are driven by how much of the payment path is in scope. Typical ranges:
| Scope | Typical effort | Typical cost |
|---|---|---|
| External perimeter and scheme-facing connectivity | 3 to 5 days | £3,300 to £7,000 |
| Payment application and API testing | 4 to 6 days | £4,400 to £8,400 |
| Full participant estate: perimeter, applications, APIs and cloud | 6 to 9 days | £6,600 to £12,600 |
Across those scopes, most participant engagements land between £4,400 and £12,600. Aggregator-connected fintechs with a single application sit at the lower end; direct participants with their own gateway sit at the upper end. These are typical UK ranges rather than a quote; our UK penetration testing cost guide breaks down the drivers, and a scoping call gets you an exact figure.
How EJN Labs approaches Faster Payments participant testing
EJN Labs is a UK-based, CREST-accredited penetration testing firm, certified to ISO 27001 and Cyber Essentials Plus. All testing is delivered by UK-based testers, which matters where contracts and regulators restrict where payment data and system access can go.
For payment estates we scope around the transaction, not the network diagram. We ask early where payment instructions are created, where they are signed, and what sits between a standard corporate user and those systems, then run the test cases a payment-focused attacker would: beneficiary manipulation, authorisation bypass between accounts, and lateral movement from the corporate estate into the payment zone. Findings are risk-rated against payment impact, not just generic CVSS scores.
Reports serve double duty: technical teams get reproduction steps and fixes, while risk and compliance teams get language they can put in front of Pay.UK, a sponsor bank or the FCA without translation. Retesting is planned from the start, because for scheme participants the evidence that issues were closed matters as much as the finding itself. See our CREST penetration testing service for the full methodology.
Frequently Asked Questions
Is penetration testing mandatory for Faster Payments participants?
Effectively yes. No single published clause names penetration testing for every role, but Pay.UK requires participants to meet security, resilience and conformance requirements scaled to their scheme role, and independent security testing is the accepted way to evidence those requirements.
The participation obligations themselves are mandatory, and in our experience participants, sponsor banks and regulators all look for independent technical testing of the payment estate.
What does FPS security penetration testing cost?
Typically £4,400 to £12,600 over 4 to 9 days, at UK day rates of £1,100 to £1,400. A perimeter-only test runs £3,300 to £7,000 over 3 to 5 days, while a full estate covering perimeter, applications, APIs and cloud runs £6,600 to £12,600 over 6 to 9 days.
Most Faster Payments participant engagements fall inside those brackets. Exact pricing depends on scope, so request a quote for a firm figure.
Do indirect participants and aggregator-connected fintechs need testing?
Yes. If your systems create or transmit Faster Payments instructions, your sponsor bank or aggregator will pass security obligations to you contractually, and your FCA authorisation carries its own operational resilience expectations. Independent testing of those systems is still the expected evidence.
The scope is usually smaller than for a direct participant, often a single payment application and its APIs.
How often should a Faster Payments participant test?
Test at least annually, and after any significant change to the payment path: a new initiation channel, a gateway migration, a move to a new cloud platform or a change of aggregator. Many participants also run more frequent focused testing on their payment APIs between annual full-scope engagements.
Payment estates change quickly and attackers target them constantly, which is why annual testing is a minimum rather than a target.
Can testing be done without risking live payments?
Yes, with the right controls in place. Most testing runs in a production-like environment that mirrors the payment path. Where production testing is needed, it is governed by written rules of engagement that exclude live settlement activity, define safe test accounts and set escalation contacts.
An experienced payments tester plans around scheme availability rather than putting it at risk.
Get your payment estate tested before someone else does
Whether you connect to Faster Payments directly or through a sponsor bank, the obligation to prove your estate is secure sits with you. EJN Labs scopes engagements around your payment path and delivers evidence you can put in front of Pay.UK, your sponsor and your regulator. Get a CREST penetration testing quote and we will come back with a scoped proposal, usually within one working day.
Leave a Reply