By EJN Labs · 9 Sep 2026 · 7 min read
ISO 20022 is a payment-messaging standard, not a security standard, and it does not itself require penetration testing. The pressure on payment firms comes from elsewhere: UK GDPR Article 32(1)(d) requires regularly testing security measures, and correspondent banks, payment scheme members and enterprise customers commonly ask to see evidence of that testing during ISO 20022 migration. A CREST-accredited penetration test is a widely accepted way to provide it.
Why does ISO 20022 penetration testing come up in payment-firm security reviews?
ISO 20022 penetration testing comes up because migrating payment messaging infrastructure widens the attack surface just as procurement teams and correspondent banks are already reviewing the change. New gateways, translation layers and API connections are exactly what a security reviewer asks about before sign-off.
During the migration window, legacy and ISO 20022 messages typically run side by side, translated back and forth by middleware that did not exist a year ago in many payment environments. That new middleware, plus any API built to receive the new message types, tends to be the first place a security review looks.
ISO 20022 messages also carry richer structured personal data than the formats they replace, including full names, addresses and purpose-of-payment fields rather than truncated reference codes. That is one reason UK GDPR obligations sit close behind the security conversation.
Does ISO 20022 actually require penetration testing?
No. ISO 20022 is a messaging format standard for financial transactions; it defines message structure, not security controls, and never mentions penetration testing. Security pressure on payment firms comes from separate instruments, including UK GDPR and FCA operational resilience rules, not this standard.
What is required is broader than the messaging standard itself. UK GDPR Article 32(1)(d) requires a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational security measures, without naming a specific method. For firms whose payment processing counts as an important business service, the FCA’s operational resilience rules under SYSC 15A set an impact tolerance the firm has to stay within, and testing that ability is how a firm demonstrates it, again without the rules prescribing penetration testing as the method.
Neither instrument names ISO 20022, and neither hands a supervisor a fixed checklist to inspect. Regulated payment businesses typically keep recent testing evidence on file anyway, since a supervisor may ask how a service was tested. Commercial pressure is often more immediate: correspondent banks and payment scheme members increasingly build security questionnaires into onboarding, and a CREST-accredited penetration test report is one of the few evidence formats every party in a payment chain recognises without further explanation.
What should ISO 20022 payment security testing actually cover?
ISO 20022 payment security testing should cover the message gateways, translation middleware and APIs handling the new format, not just the core payment application. Testing should include message parsing, counterparty authentication, and whether the payment environment is segmented from the network.
Four areas come up repeatedly once a scope is agreed:
- Message gateway and translation testing. How the gateway parses, validates and rejects malformed or oversized ISO 20022 messages, and whether the logic translating between legacy and new formats introduces flaws of its own.
- API and connection authentication. Mutual TLS configuration, credential handling and session management on the interfaces counterparties use to submit or receive messages, an area our API penetration testing work covers in depth.
- Network segmentation. Whether payment processing systems are properly isolated from the rest of the corporate network, which is exactly the boundary our external infrastructure penetration testing engagements are built to test.
- Business logic. Duplicate payment detection, message replay handling, and whether amount or reference fields can be tampered with between validation and settlement.
Firms that also process card payments should scope card-scheme obligations in alongside the ISO 20022 work rather than as a separate project. PCI DSS Requirement 11.4.2 requires internal penetration testing at least every 12 months, and 11.4.3 requires the same externally, both tied to the cardholder data environment rather than the messaging layer.
How does an ISO 20022 payment security testing engagement unfold?
An ISO 20022 payment security testing engagement typically opens with a scoping call covering message types and environments in scope, moves through testing against the gateways and APIs identified, and closes with a report mapped to the systems an auditor or counterparty will actually ask about.
When EJN Labs scopes this work, the pattern stays consistent even though every payment stack looks different:
- Scoping. We map which message types, gateways and counterparty connections are in scope, and agree whether card-scheme obligations sit alongside.
- Testing. Testers work against the gateway, translation layer and any exposed APIs, combining automated scanning with manual testing of message handling, authentication and segmentation.
- Reporting. Findings are written up against the systems and message flows actually tested, with enough detail for your engineering team to fix and for a counterparty’s security team to review.
- Retest. Once fixes are in place, we retest the specific findings rather than the whole scope again, which keeps the second pass fast and inexpensive.
What does ISO 20022 payment security testing cost in the UK?
ISO 20022 payment security testing typically costs £4,400 to £16,800 in the UK, depending on how many gateways, APIs and environments are in scope. UK day rates for CREST-accredited testing run £1,100 to £1,400, and a focused gateway engagement usually needs 4 to 6 days; a full payment-environment review needs more.
Scope, not the size of the firm, is what moves the price. The table below shows typical UK ranges for the scopes we see most often.
| Scope | Typical effort | Typical UK cost |
|---|---|---|
| Payment message gateway test | 4 to 6 days | £4,400 to £8,400 |
| Gateway plus network segmentation review | 6 to 9 days | £6,600 to £12,600 |
| Full payment environment, including cloud configuration | 8 to 12 days | £8,800 to £16,800 |
| Retest after remediation | 1 to 2 days | £1,100 to £2,800 |
These are typical UK ranges rather than a quote; the exact figure depends on your gateway architecture and comes from scoping. Our guide to penetration testing costs in the UK sets out how scope translates into day count in more detail, and a CREST pentesting quote gets you a fixed price for your own environment.
How EJN Labs approaches ISO 20022 payment security testing
EJN Labs approaches ISO 20022 payment security testing as a scoped engagement built around your message flows, not a generic infrastructure test relabelled for payments. We are a UK CREST-accredited firm, certified to ISO 27001 and Cyber Essentials Plus, with every engagement carried out by UK-based testers.
Every ISO 20022 engagement starts by mapping which message types and counterparty connections actually matter to your business, rather than testing every interface equally. Where a firm also needs card-scheme or operational-resilience evidence from the same engagement, we scope that in from the outset, so one report can answer more than one questionnaire.
Frequently Asked Questions
Does ISO 20022 require a penetration test?
No. ISO 20022 is a messaging format standard for financial transactions and does not require or mention penetration testing. Security testing obligations for payment firms come from separate instruments, including UK GDPR Article 32(1)(d) and FCA operational resilience rules, not the messaging standard itself.
What security evidence do payment firms need to show for ISO 20022 migration?
Payment firms typically need to show a recent penetration test report covering the gateways and APIs introduced by the migration, evidence of ongoing testing under UK GDPR Article 32(1)(d), and, where relevant, records showing the payment service stays within its impact tolerances.
Do correspondent banks ask for penetration test evidence during ISO 20022 onboarding?
Commonly, yes. In our experience, correspondent banks and payment scheme members increasingly build security questionnaires into onboarding and annual review cycles, and a CREST-accredited penetration test report is one of the few evidence formats every party in the payment chain recognises without further explanation.
What does ISO 20022 payment security testing cost?
A payment message gateway test typically takes 4 to 6 days at £1,100 to £1,400 a day, so £4,400 to £8,400. Adding wider network segmentation and API testing takes it to 6 to 9 days, or £6,600 to £12,600. The exact price depends on scope and comes from the quote form.
How often should payment message infrastructure be tested after an ISO 20022 migration?
Annually is the common baseline, tightened around go-live. In our experience, firms test new gateways and APIs before go-live, again shortly after, then fold ISO 20022 components into their normal annual testing cycle rather than treating the migration as a one-off event.
Get ISO 20022 payment security testing evidence in place
If an ISO 20022 migration or a counterparty’s security questionnaire is putting penetration testing on your critical path, we can scope an engagement around the gateways and message flows you actually run. Get a CREST pentesting quote and we will confirm scope and price for your engagement for your payment environment.
Leave a Reply