In November 2022, the PCI Security Standards Council published a new standard, the long-awaited Mobile Payments on COTS Standard or MPoC.
Here is an interview by Alice Malone, Director of Public Relations for the PCI Security Standards Council with Andrew Jamieson, Vice President of Solutions Standards, who will explain what the standard is about and who it will affect.
Alicia Malone: So, before we dive into the details of this new standard, tell us what MPoC is. What is PCI’s Mobile Payments on COTS?
Andrew Jamieson: So, as you said, it’s a new standard we released just last month, November 2022, and it provides the security requirements for implementations which accepts PIN and/or contactless card data on a COTS device. And by COTS device, you can think mobile phone or tablet essentially, although the scope is a little bit broader than that. It’s essentially an evolution of our existing SPoC and CPoC standards, but we’ve built in some extra flexibility into the standard as well, to allow for three different types of listed products, so it provides where SPoC and CPoC really had just the ability to – for SPoC, it’s a PIN, but no cards and in CPoC, cards, but no PIN – we’ve combined that together in MPoC, into a more flexible standard.
Alicia Malone: Tell us a little about the process of how MPoC was developed. How important was it to have industry collaboration on this standard?
Andrew Jamieson: It was vital. Absolutely vital. So, this standard was really developed in direct response to the feedback we heard from the community. As I mentioned, it’s an amalgam of the existing SPoC and CPoC standards and we really heard that people wanted one standard, where they could have the ability to accept card data and PIN on the one COTS device. And they’re also looking for increased flexibility. They were looking for solutions that could fit niche markets, as well as large deployments: 10 merchants, 100 merchants, or 10 million merchants, essentially.
That’s really what we’re trying to do with MPoC and that’s the real difference of this standard. And so, as part of that, as we are working towards it, we had two RFC (Request for Comments) processes on the standard as a new standard. We have RFC processes for each new standard we release and that provided us with over 900 items of individual feedback and that was instrumental in how this standard came together. Really, it would be a different standard without all of that feedback, and I think, personally, a standard not as good. The feedback provided, the input from the community, the information we received on how people wanted this to be structured, how they wanted to use it, really made it the standard it is today.
Alicia Malone: So, how different is PCI MPoC from that of PCI’s other mobile standards, SPoC and CPoC? I know you touched on that briefly, but what is the big difference there?
Andrew Jamieson: I have touched on it. I’ve said they’re an amalgam, but that perhaps does MPoC a bit of an injustice. From a user experience point of view, it’s not that different. As I said, it allows for the PIN and the contactless card to be read on the mobile phone directly. However, when you look under the hood, it’s a standard that was created from whole cloth. It was a brand new standard built on the experiences and the learning that we’ve had with the SPoC and the CPoC standards to allow for those two items of card data to be entered on the single mobile phone, however, also to add flexibility, to add the ability to support software development kits, to add the ability to support the approval of software that is being used in an MPoC solution separately from the overall solution. And in that way, to do that, we really had to look at the requirements in a new light, structure things differently, have essentially technical or development aspects separated from the operational aspects. So notionally, similar, from a user experience point of view, similar, but under the hood, quite different.
Alicia Malone: Let’s talk more about that added flexibility that you mentioned and how the operational aspects have been separated from those development aspects. Can you give an example of how this might be beneficial?
Andrew Jamieson: Yeah. So, a good example, and I mentioned you approve the software separately, or you can approve the software separately. You can still approve the whole solution. That’s fine under MPoC as well, but if you do, when you look at that software aspect, if you do have that approved separately, there are requirements we have around key management, for example. Key management is a good example. Software has to implement and be able to support strong, robust, secure key management and this involves how keys are generated and distributed and stored and used and so forth and so on. However, that’s just how it’s implemented in the software. When you deploy that software, when you use it as part of an MPoC solution, there’s an aspect to how it’s actually used. What’s going on in the backend? How are the keys actually being generated? How are they actually being managed?
There’re operational aspects there as well. And so, this is a good example of where we separate it out and we have actually two key management sections, essentially in MPoC, one of them focused on how does the software aspect actually implement key management? And then how is that operated in the operational aspects in the backends and so forth? And so that’s an example of how it works. For how it’s beneficial, it allows for that separation. It allows you to say, “Okay, we can approve this software separately,” and that adds that flexibility that people were really looking for.
Alicia Malone: What are some of the commercial off-the-shelf devices that this latest standard is targeting?
Andrew Jamieson: Yeah. So, I mentioned I think mobile phones, but it is broader than that. So, you can generally think of mobile phones and tablets, but essentially, what we’re doing is we’re looking at how people are changing the way they interact in a face-to-face commerce sort of way. And so, people want to be able to, in an ad hoc basis, use potentially their mobile phone and maybe they’re in a market or something like this and they want to be able to accept transactions, but there’s also a desire to use different types of devices as well in this context. Maybe it’s commercial devices that have been designed for maybe stock taking and so forth and they want to be able to accept transactions on those sorts of devices as well. We have certain rules around the types of devices that are permitted, but it is certainly broader than your standard mobile phones and tablets, but they’re the primary focus.
Alicia Malone: So, are there specific threats to data security that this MPoC standard is aiming to address?
Andrew Jamieson: Yeah. And essentially, when it comes to data security, it’s really about making sure that the transaction is safe, the transaction that’s being performed, and of course, the data that is involved in that transaction. So being a standard that’s focused on general purpose devices, specifically devices that are not exclusively and specifically designed for the processing of payments, it’s really been a very significant part of the generation of this standard, how we can make sure that operating environment – running a payment application on a general purpose device – how we can ensure that the MPoC application is secured, is able to operate, is able to secure the data that it manages and secures.
So, during the development of the standard, we considered the different threat models, different attack scenarios. We worked through the standard to make sure that the requirements were sufficient to mitigate those types of attacks and protect that sensitive data, so specifically, how do we protect the PIN when it’s entered on these things? How do we protect the card data as it’s entered through the NFC? How do you ensure that a solution is secure if it’s integrating multiple SDKs and we allow, for example, for up to two SDKs to be integrated into a single MPoC application. So, these are just some of the aspects that were part of the consideration when generating the standard.
Alicia Malone: It’s so interesting to me how the payment environment, the payment landscape, the way we make payments, it’s changing so rapidly. Do you think that with the rise and popularity of mobile payments today that payment terminals will become a thing of the past? What do you think the future holds?
Andrew Jamieson: Well, if I had a crystal ball, then I’d have won the lottery by now and I’d be sitting on a beach somewhere. Maybe in sunny Melbourne, the sun is out today, but maybe somewhere that’s a little bit warmer in winter potentially. Unfortunately, I don’t have a crystal ball. I can talk about what we’ve considered and what we’ve seen as prologue to the generation of the MPoC standard. As I mentioned, we’re really seeing people wanting to have more flexibility in how they accept face-to-face payments, using cards in those sorts of environments and using potentially mobile phones and tablets and different types of COTS devices in how that interacts with the terminalized environment. And, of course, our standards that we have like PCI PTS POI, that focus on those terminal environments, I’d probably use an analogy on the issuing side. So, I think everybody’s relatively familiar with having physical payment cards, of course, but also potentially using their phone to perform a payment. Having their card on their phone and tapping their phone potentially on a terminal, rather than their card.
That has not ended up with cards going away. We still have people with cards in their wallet, in their bag, whatever it is, as well as cards on their phone and I think that there is the possibility, the chance, in my opinion, the likelihood that we will see the terminalized environment – things like PCI PTS terminals exist and coexist alongside the MPoC solutions as well. I don’t see MPoC solutions as devouring, if you like, that population of terminals. I see it adding to it and so we will see an increase in the ability of people to accept card-based payments and that increase will be based on the increased population of solutions based on things like MPoC and terminals will still continue to exist.
Alicia Malone: What would you like our listeners, our audience, to know about this new MPoC standard? What do you think is the most important thing?
Andrew Jamieson: You’ve asked for one important thing. I’m going to cheat a little bit and give you two, if that’s all right, and those two things essentially being that MPoC is really focused on flexibility. It is designed to provide people with the opportunity to create those applications for 10 merchants or 10 million merchants, to have their technical aspects listed separately from their operational aspects in these types of solutions.
The second item I would really like people to understand is just how impactful all of the feedback we’ve received during the development process was. I mentioned this right at the start, but I am going to mention it again, because it truly was something that led to a materially improved standard through all of that feedback that we received and I’d like to, first of all, thank everybody who did participate. And if there are people who are listening to this who’ve never participated in an RFC process before, I would strongly like to encourage people to consider participation in the future, because their feedback is so important to us, creating the standards that we do and making sure those standards have fit the purpose and absolutely the best that they can be.
Alicia Malone: Yes. I agree with you, Andrew. I know that this has been a very popular standard. Much anticipated. In fact, when I posted on LinkedIn that the standard had published, I’m always overwhelmed and blown away by the response from the stakeholder community and how many times a post like that gets shared across anyone who handles mobile payments and so I think it’s really a testament to the popularity of this and the need for it in our industry.