Monzo Staff Weekly Q&A - Richard Dingwall (Payments Engineer)

Note : All Monzo Q&As to date can be found here :grinning:


Gather round, folks. It’s time. Time for the inquisitive and curious. Time for all who seek knowledge to come forth with questions, in the hope of gaining answers.

Yes. Yes, indeed. You know it. You don’t need to check your watch.

It’s the MONZO WEEKLY Q&A!!!


First, however, better get up to speed.


Catch up with all previous Q&A’s below!

Week 1 : Chris MacLean, Customer Operations & Vulnerable Customers :santa:t2:
Week 2 : James Nicholson, iOS Engineer :green_apple:
Week 3 : Tara Mansfield, People Operations Manager :woman_technologist:t5::man_technologist:t3:
Week 4 : James Routley, Backend Engineer :hammer_and_wrench:
Week 5 : Hugh Wells, Customer Operations :policeman:t3:‍♂
Week 6 : Naz Malik, Technical Specialist :computer:
Week 7 : Fred Morgan, COps Squad Captain (Calls & Social Media) :telephone_receiver:
Week 8 : Emma Northcott, COps Scaling Team :balance_scale:
Week 9 : Jarno Wolf, COps Financial Crime Specialist & Squad Captain :wolf:
Week 10 : Maria Campbell, Head of People :woman_office_worker:t2::man_office_worker:t4:
Week 11 : Jim Amey, Night COps Captain :bat: :crescent_moon:
Week 12 : Richard Cook, Online Community Manager :man_cook:
Week 13 : Beatrice Borbon, Content & Press Manager :newspaper:
Week 14 : Tom Blomfield, CEO :crown:
Week 15 : Ella Johanny, COps/Hiring :handshake:
Week 16 : Harry Ashbridge, Writer :writing_hand:t3:
Week 17 : Beth Scott, Overnight COps :cat2:
Week 18 : Georgie Parmenter, Executive Assistant to the Founders :blonde_woman:
Week 19 : Vulnerable Customers Team :sunflower:
Week 20 : Leah Templeman, Interim VP People :sun_with_face:
Week 21 : Daniel Chatfield, Backend Engineer, Fincrime & Security :closed_lock_with_key:
Week 22 : Valerio Magliulo, Product Manager - Revenue Team :money_with_wings:
Week 23 : Sam Watkin, Operations Analyst :thinking:
Week 24 : Kieran McHugh, Backend Engineer :desktop_computer:
Week 25 : Jonas Huckestein, Co-Founder and Chief Technical Officer :computer_mouse:
Week 26 : Annual Report Edition with Tristan Thomas and Julie Oey :calendar:
Week 27 : Zander Brade, Lead Product Designer :pencil2:

This week in the Hot Coral Hot Seat™️ we’ve got Richard Dingwall, Payments Engineer!!!


Richard has been here at Monzo since February 2016 and his job is writing the code that powers your Monzo card! :muscle:

Fun Fact About Richard:
"I added EBCDIC to the Go programming language :nerd_face:"

His favourite thing about working for Monzo?
“Really understanding what’s possible with our technology to find ways to delight our customers.”

Alright y’all, you know where it goes from here!
Get your questions in,Richard will be here later in the week to answer them!


Greetings Richard!

Do you think the contactless potential of a card has reached it’s limit with this generation of cards, or is there more to see?

If you could create a debit/credit card, what features would you build if you had the power?

1 Like

What are you working on currently?
What has been your favorite project so far and why?
What feature from the roadmap are you most excited to work on and why?


Given the storage capacity of the card, what could you think of using it for in future? Do you think we could upload travelcards and/or loyalty cards to save swiping them separately?


Usual suspects: Pineapple on Pizza? Cats? Other fetishes?

1 Like

Are the recent outages with Visa, Mastercard, Faster Payments and Barclays and Natwest tonight a sign that something is fundamentally broken with the payments system? Is it failing under pressure from too many transactions, bad design or cyber attack? How can Monzo be any more reliable than any other bank with so many things out of your control?


Do you foresee Mastercard and other schemes making adjustments to contactless to allow PSD2 SCA compliance to be less painful than a simple reversion to the old way of force-insert (e.g. perhaps by creating a ‘resubmit with online PIN’ authorisation response)?

Is long PIN support on the internal product roadmap at all?

What future changes do you expect to see in retail POS systems?

Thanks for doing this!


Great question :+1:


Current payment networks seem so antiquated in terms of their architecture: authorisations, batch presentments, refunds taking seven days. They also seem like a middleman that was once necessary, but no longer are from a technical standpoint. Do you think it’s realistic that in the next 10 years we will see a modern payment network that is based more on direct connections between accounts? Something more efficient and responsive than the current architectures? If so, how would you see it working?


When you came into the banking industry, what’s one thing that you were most surprised by?

Contactless potential: Sometimes we get pitched cards from manufacturers with extra security features like fingerprint sensors. These are very cool, but the per-unit cost of these cards is currently very high. Also some of these new features might not work with every terminal around the world.

However all Monzo customers already carry a device which has all these security features and more - their Apple or Android smartphone. So I think any future contactless innovation will probably be in the likes of Apple Pay and Android Pay.

If I could create a debit/credit card: I would remove the PAN (the long card number). Every time you tap your card, the card would generate a single-use cryptographic token which the merchant could use to redeem funds from the bank. This is how chip and contactless cards work currently, but I would introduce a new element to identify the card that would not be a secret, and could not be used to make payments by itself.

My favourite project at Monzo: I had the privilege of being the lead engineer on our in-house Mastercard processor. We started working on it in September of 2016, and launched for internal staff testing by January. Today we have over 800,000 customers depending on it every day to travel to work and buy their lunch and groceries - it’s pretty humbling.

Right now I’m focused on helping other engineers at Monzo learn the ins-and-outs of payments, and on ensuring our payments work reliably all the time. This involves a combination of ensuring our internal platform is resilient against internal failure, and also, being resilient against when other parties send us transaction messages which contain invalid data.

Quite soon I’ll be moving into the finance team to look at how we automate reconciliation across all of our payment networks and marketplace partnerships. We are approaching this problem as a systems design exercise and I’m very excited about this.

From our product roadmap, in the short term I’m particularly excited about two features:

  • Joint accounts - because I have been waiting for this
  • 3D Secure - I’ve been somewhat involved in the development of this and I think our implementation is going to be very cool

In the longer term I’m excited about our API and making Monzo the best programmable bank account in the world. :slight_smile:

Yes these are both totally possible! We haven’t spent too much time on this but all our cards support it. Watch this space for downloadable code samples how to write data to your Monzo card using a computer and a smart card reader! :man_technologist:

Cats: equal love for cats and dogs :cat::dog:
Pineapple on pizza: I’m a believer :pineapple::pizza:
Other fetishes: none that I discovered yet…

I am not aware that any of the large recent outages in the media have been caused by unusual transaction volume or cyber attack.

But payment systems tend to be quite complicated. I would like to answer this question in two parts.

How do you make a reliable payment network?
Payment networks like Mastercard and Visa provide the standardisation and rules that allows customers, merchants and card issuers around the world to accept and clear payments and resolve disputes.

Whether or not it is necessary for every individual transaction packet (at authorisation time) to always be routed through centralised servers to achieve this is an interesting technical question. If the merchant’s systems and the card issuer’s systems are online, it would be very interesting to see if payments could be automatically routed around unavailable network nodes, similar to how internet traffic works.

How do you make a reliable bank?
Historically, banks have achieved reliability by making individual machines really really robust (it’s not unheard of to hear about mainframes with 10+ years uptime), and to minimise the frequency of software changes that could introduce bugs. However this can increase the risk as the size of each deployment increases.

At Monzo we try to follow the lessons from companies like Google and Netflix: we run our systems on commodity x86 hardware in the cloud which we expect to be unreliable. Individual machines fail frequently, but we run a large number of them, so collectively the overall system is very reliable. You can read a bit more about how we do this in this blog post.

In addition, we try to break down large software changes into lots of very small deployments, which individually have very low risk, and are easy to roll back. We also avoid ‘big bang’ releases that affect all our customers at once. New features are rolled out incrementally and slowly across our customer base.

There are certainly many aspects of payment networks which I would love to see modernised. A lot of the message formats date back to the 1980s, and their design is heavily influenced by early computers, and rely on implicit trust between participants, instead of modern security and cryptography.

One particularly painful example is dual-message card transactions (authorisations and presentments) which are sometimes not properly linked together by the merchant or acquirer. These cause us an enormous amount of headaches, and could easily be designed out with protocol improvements.

So it may be possible to improve the reliability of sending payment messages with better protocols and networks. But there are also other non-technical aspects of payments to consider, like settling customer payments between different banks, and risk. Central clearing houses increase the amount of time a payment takes to process, but also act as a firewall to help prevent cascading liquidity problems if one bank fails. These processes should be optimised but should not be eliminated because of the benefit they provide to the system as a whole.

I’ve worked as a software engineer in banks for a few years now. Previous banks I’ve worked at had a surprising amount of software complexity due to the structure of the organisation (Conway’s law). But even having the opportunity to start from scratch, there is a surprising amount of complexity necessary just to deal with regular day-to-day payments!


There we have it folks - an amazing and super interesting Q&A from @rdingwall - incredibly informative!

We will be back next week with another Q&A :slightly_smiling_face:


PSD2 SCA: I don’t have an answer for this question yet. Watch this space.

Long PINs: We would love to support longer PINs! Our cards actually support 12 digit PINs. But unfortunately a large percentage of terminals still only support 4 digit PINs.

Retail POS systems: Chip acceptance in Europe is generally very good but I would like to see an improvement in chip acceptance rates around the world so we can finally ditch magnetic stripes (which are incredibly easy to clone). I would also like to see more terminals take advantage of offline chip support - the impact of recent card network outages could have been reduced if more chip terminals automatically switch to offline-only mode when their connection drops (with appropriate risk controls though). In the longer term I would also love to see automated loyalty rewards, and automated high-fidelity receipt data!


Love these Qs&As!

Thinking about message formats, protocols, etc.: is there much improvement and development of the existing ones, or is it more a case of layering the new on the old?

And if this were to change, who are the parties that are in a position to make it happen (if they desired)?

1 Like

Really interesting answers, thanks @rdingwall :slight_smile:


Awesome, thanks Richard. Your cards support long PINs, yes, but your app doesn’t. If you set a long PIN, you can’t transfer money, etc.

Are there really that many terminals that don’t? AFAIK, support is required as part of the EMV standard. I have a long PIN set on my Barclaycard Visa and haven’t had any issues the few times I’ve tried it.

I find the offline support interesting, as I know the networks (especially Visa), are strongly trying to push the concept of an online-only payment environment.


This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.