Standards must deliver more benefits to the market they serve than they cost to implement, or risk becoming irrelevant

On the 26th of November 2024 the PCI Security Standards Council (PCI SSC) published Version 1.1 of the PCI Mobile Payments on COTS (MPoC) Standard, designed to support the evolution of mobile payment acceptance solutions. ?It’s worth taking a closer look at the key changes which Version 1.1 delivers because, from Mypinpad’s perspective at least, it represents some but not all of the much needed rolling back of Version 1.0’s standards requirements. More work is required to make the next version of MPoC (V2.0) meet the right balance of cost and benefit commercially competitive for most industry participants.

There are 10 key changes noted in PCI SSC’s accompanying its blog post on the Version 1.1 changes. I’m picking just three of these changes because they illustrate the point I’m trying to make in this, my first blog of 2025:

1.?????? Removal of Secure Software and Kernel functional validation requirements

2.?????? Updates to self-testing requirements for MPoC SDK integration

3.?????? Allowance for FIPS140-2 L2 HSMs (if implemented in controlled environments).

Some changes such as item #1 correct excessive scoping which has become somewhat common.?Kernels are handled by other industry standards. So, inclusion in the MPoC scope was a form of overreach and resulted in dual work by industry participants.

Other changes such as #2 and #3 stem from feedback from industry participants explaining the operational and implementation aspects of the requirements.? So, often standards are written from the point of view of minimising security risk but without considering the operational and implementation costs.?

My view is that as a key point of principle, the cost of every requirement in every standard needs to be measured against the actual benefit.? If costs of implementing any requirements are higher than the benefits they deliver, they should be removed, pure and simple. Simply put, these elements of MPoC added unnecessary compliance requirements and costs to technology providers which only served to stifle innovation. Ultimately, they cost us (and our competitors) far more than the benefits they brought to the market as a whole.

The PCI SSC (and indeed all standards bodies) need to remember that, unlike industry regulators, ?they cannot mandate that their requirements are applied right across the market. If market participants find they are costing more to implement than they deliver in terms of benefits to them and users themselves, the industry will simply navigate around them.

We have seen this over the last 12 years or more with the proliferation of scheme-specific waivers to try to fix problems with excessive standards requirements, especially by PCI. ?Virtually every deployment of SoftPOS was done using scheme waivers rather than under the excessive CPoC standard.? PCI is slowly learning and we hope this learning is not just continuing but accelerating.

Lots of standards body options for software providers

It is also worth remembering we have an array of standards bodies to draw on for software providers which want to ensure their software is bug free, highly secure and yet both highly integrate-able and scalable. A quick Google of standards bodies that govern the quality of software writing and development reveals four bodies immediately. There is ISO (International Organization for Standardization), and the IEEE (Institute of Electrical and Electronics Engineers) which provides standards for software engineering practices. Then there is CISQ (Consortium of IT Quality Software) which provides standards for measuring quality of software.

There are another set of standards bodies dedicated to building software that is highly secure. Again, ISO has standards for that. There is also the IETF (Internet Engineering Taskforce) which develops and promotes voluntary Internet standards, including those related to cyber security.

NIST (National Institute of Standards and Technology) offers guidance on managing and reducing cybersecurity risks; and for tech firms proving in-house IT capabilities a SecurityScorecard ‘A’ rating is highly coveted. It proves to the outside world that they have strong in-house cyber security skills and tight cyber security systems to protect the critical data it holds for its clients.

Benefits of ISO 27001 certification

Mypinpad has elected to put itself through ISO 27001 certification. This standard is recognised around the world - well beyond the payments market. It helps us in several ways:

1. Enhanced Security: ISO 27001 provides a comprehensive framework for managing information security risks, helping software businesses protect sensitive data from cyber threats.
2. Competitive Advantage: Certification demonstrates a commitment to security, which differentiates our software business from competitors and attract security-conscious clients.
3. Regulatory Compliance: It helps ensure compliance with various data protection regulations, reducing the risk of fines and legal issues and speeding up onboarding processes with solution providers.
4. Improved Processes: Implementing ISO 27001 can streamline and improve information security processes, leading to more efficient operations.
5. Customer Trust: It builds trust with customers by showing that the business takes security seriously and has robust measures in place.
6. Market Access: Certification can open up new business opportunities, especially in industries where data security is critical.

We go through standards requirements to show our customers that we make the grade and ISO 27001 certainly helps in this regard. We find it easier to work with larger players as a result of it. Reaching and penetrating new payment market opportunities becomes easier and quicker.

Standards bodies must be fleet of foot

Rounding back to where this piece started, it is good news that PCI SSC has rolled back some of its more onerous MPoC requirements published just over two years ago in Version 1.0. However, it is also clear that with so much innovation in the payments space now, they will need to be more 'fleet of foot' to keep up, and flexible enough to adjust standards requirements when it is clear that technology players are not applying them, or worse,?are looking elsewhere for standards certifications or scheme-specific waivers. All standards bodies must remember all their requirements must deliver more benefit than the cost that they pass onto market participants wishing to be compliant with them.

It is critical for them to listen to the market and have the agility to adjust. Leaving it two years to go to a new version of a key standard does not feel agile enough to me. They need to be constantly reviewing standards take-up. They must listen, then adjust and update their standards requirements and issue new versions much more regularly, much like a software house or SaaS provider does today. Without this iterative approach, it is difficult for them to remain up to date and, ultimately, relevant in a fast paced market like digital payments.