Start Here
I have always tried to understand the way things are. I often use the term “be the transaction” as I try to place myself in the situation, making decisions based only on the logic and the data available to the transaction at the time.
I start at the beginning with card design, card personalisation and card issuing. I consider the card authorisation platform, and the nature of the product offered to the cardholder, which is linked back to the personalisation profile. I think about the POS device, and its relationship with the retail checkout and of course, the PCI-DSS (of which I am NO fan). I then consider the interface to the card schemes, their evolving rules of engagement, and the impact of the rules on the relationship to the transaction. After the card scheme has had its say, I put myself in the position of the issuer, receiving the incoming message, authenticating the incoming POS request and applying local authorisation rules to the cardholder’s account. I think about building the response message and then handing it back to the scheme for onward transmission to the POS. Finally, I think about how the POS will authenticate the response, before completing the transaction. After the event, we can all think about the settlement processes, and the back-end interfaces to the customer, including app updates and statement wording.
I can do all this because I have done all this.
Early Years and Training
I have been happily involved in the Card Payments game since the mid to late 1980s. I began my career in the local branch of HFC Trust and Savings (Doncaster 076) and after 18 months of learning stuff about face to face banking, was transferred to Head Office in Bracknell. Following four weeks of a Business Systems Analysis training course – two weeks before and two weeks after Christmas – that was presented by Hoskyns at the 5-star, Highcliffe Hotel in Bournemouth, I was let loose on the new fangled ATM thing. My bit was designing a new process for to allow staff to order customer cards in branch.
I have to say that the training course was brilliant and what I learned has stayed with me to this day. My thanks go to Richard, the Hoskyns consultant, although he did tell us that he called himself Dick as he thought he looked more like a Dick than a Richard.
Click the button and I’ll tell you about the training.
Monkey Around: Resumé Highlights
Before going any further, you might want to take a look at my experience across the card ecosystem, including: issuing, acquiring, transaction processing, ATMs, POS, mobile, retail, hospitality, magstripe, EMV, x-pay, Open Banking, and alternative payment services … and more!
One thing that I am asked a lot: what particular payments area do you specialise in?
The Payment Monkey and the PAN
The Payment Monkey was a construct of my time at Tesco – retail, not bank – when, around 2010, we were exploring practicalities and considerations relating to the implementation of a New Payment Platform across all retail payment operations. The analysis involved a significant chunk of the PCI-DSS, and I was involved in the pragmatic assessment of the mechanisms available to address the “need” to protect the PAN. As I delved into the analysis, I came across the website of the “PCI Guru”, an expert based in the US with a financial interest in magstripe security and a minimal grasp of EMV.
At Tesco, I very quickly became known as The Payment Monkey; the name lives on. The Payment Monkey fully supports the need for proper security in all business systems, but has little time for the gaslighted nonsense that is the PCI-DSS!
The Payment Monkey c. 2010
Principles of Proper Payments
If you were to design a global retail payment service, how would you go about it, what components would you need, and what features would you be looking to deliver?
- I would argue – some might not – that it would need to be accessible to all.
- Access to generic payment services should be inexpensive.
- Payment processing for the individual should be simple and straightforward.
- Payment processing for merchants should be simple, straightforward and inexpensive.
- Data associated with payment processing should carry no intrinsic value.
The solution, if I were to start from scratch today, would look something like the existing four-party model. This model represents the best way of connecting multiple parties without requiring multiple bilateral relationships.
Why PCI?
I have been designing, developing and implementing card payment solutions and systems for most of my working life.
I began in the days of magstripe, before the development of the high-coercivity card and I also remember the introduction of the CVV and its location on the stripe: the first three digits in the discretionary data field.
I introduced the Halifax to EMV in 2002 and helped design the systems issuing the first 12.5 million chip cards in the UK. The Halifax systems did just about everything you could do with a chip card, and all the systems were built in-house.
I watched in slow motion as the Japanese Knotweed of the PCI-DSS took hold, consuming all logic and reason in its path. I followed the story as industry experts were consumed, and dissention became the act of a heretic.
Click on the button that says READ MORE! to retrace the history and to draw your own conclusion.
Explore the Future of Payments
The global payment ecosystems continues to evolve with technologies like AI, tokenisation, and real-time payments.
Stay ahead of the game by diving deeper into the world of payment processing.
Have questions or need expert insights? Contact us.
