Aaron (00:01)
Hello John and welcome to the show. Absolute pleasure to have you on. Thank you for joining us.

John (00:06)
Thanks for having me. It's been a long time coming. I'm glad I finally made it.

Aaron (00:10)
It sure has!

So it was months ago we met. I think we maybe met at an event at Monzo office or an event where you were talking about marketing mix modeling perhaps.

John (00:24)
Yes, many months ago now.

Aaron (00:27)
That's quite a varied spectrum of data to be working on. Why don't you start by telling us a little bit about what it's like to work where you work and what kinds of data you've actually worked on.

John (00:43)
Yeah, so currently I work at Monzo. So it's like a digital bank started off as sort of like prepay cards. Many people were using it for travel and then it sort of grew to be a proper bank and now has 11 to 12 million customers in the UK and hopefully expanding globally soon. ⁓ This will give you some context on my background. My background has predominantly been in

marketing data. I started my career actually building market mix models, hence why I was talking about that at the analytic engineering meetup. But then sort of moved more, I'd say, back end, just kept on progressing back. So I started off as an analyst, then moved more into analytics engineering, because I sort of care more about building things at scale and like data structures and things like that.

And now I work in the payments sort of business unit of Monzo where we're sort of building out all the models related to different payment schemes.

Aaron (01:49)
Yeah.

Yeah, yeah,

That journey actually from analytics to what you described as more technical, it feels really familiar. I speak to a lot of people and that's a fairly common journey actually as they get more and more into the data and the sort of technical side of it. And we'll return to that in a second. One thing I wanted to say about Monzo before we go too much further for anyone who's not from the UK and this thing, they were really well known for a card, right? Like they had this like fluorescent orange card that was

made them very noticeable and recognisable in the market and in the... Hot coral was it? Okay.

John (02:31)
It's called the Hot Coral. It's

just the official card name, which is actually how I got introduced to Monzo. I just saw someone tap in that card and I was just like, what card is that? And then instantly they were like, it has all these features, are useful for travel. And then I think at that point there was like a wait list to sign up to Monzo. And yeah, eventually got the card and sort of never looked back.

Aaron (02:52)
Yeah.

Yeah. And I think that to me that that's a fascinating differentiation in an undifferentiated market. know, banking is to most users is just the same experience, but it is this small, you know, trendy car that actually made them stand out. And then obviously they offered customer features and then kind of grew from there. I wonder then inside a bank and working on the data inside a bank.

John (03:18)
Mm-hmm.

Aaron (03:23)
What's it like? What? But you know, all these other experiences you had, you're sort of always a versus like what's it like in a bank versus working on traditional marketing data?

John (03:35)
I would say the level of scrutiny is higher. ⁓ Obviously there's lots of regulation, there's lots of audits and things like that. when you're, think in marketing there's sort of a perception of the general direction is okay. We can accept differences, but in total, if the proportions are right, we can accept that. ⁓ And I think also in marketing there's known

flaws in the data, like you can change your attribution model and then the picture changes. If your tracking fails, then potentially your numbers are going to look different between your source system and your third party system just because of tracking. So we kind of expect like a level of error of like, you know, between one and 5%, sometimes even higher. But within banking, it's it's almost to the penny.

you want to be correct. Ultimately, it's like every penny needs to be accounted for, which I think is very, different to what I've been used to when I was in the marketing side. I think it's okay for me because I've always been that person that if it's a 1 % discrepancy, it's 1 % too high. So I've always tried to whittle it down to as low as possible. So I think I'm quite used to doing reconciling things and

⁓ I get annoyed by the penny mismatches. So maybe Bankum was like my true calling and I've arrived.

Aaron (05:08)
It's interesting,

both the analytics to engineering journey plus the same marketing to banking journey. It does sound like it is found in this kind of environment where it matters, you're getting it exactly right. What does it look like internally when it's not right? Is it process? Is it technology? Is it perfect data when it lands? What's it like to get it right inside the bank?

John (05:38)
Yeah, I think ⁓ there's just different layers to it. So there's risk and controls. So sometimes we accept there's a difference, but we need to know exactly why there's a difference. So for example, there might be an incident where ⁓ data wasn't sent ⁓ from the back end because something went wrong. But we've recorded that as a

bank movement in another system. And if those systems don't reconcile, we just need to know why they don't. And then we just recall that as ⁓ like a mistake. And then it allows us to kind of audit what's what's what's going on. And then I think to your point, there's the technology side where there's ⁓ systems that are working in the background trying to reconcile different sources together. And if there is a discrepancy,

it will automatically fire some sort of alert that we want to investigate. the technology helps us expose the problem, but then people need to figure out why there is a difference. don't think we're quite at the stage where the technology tells us what was wrong. It kind of takes the manual kind of looking into the data.

Aaron (06:57)
Yeah, yeah, that makes sense actually. So, you know, I've worked in banking and banking software and, you know, the level of rigor around the technology changes is much higher than other industries and those systems, both people and technology, I think that that's one of the things that I noticed about the environment. The tools though, that they're actually using, are they bespoke built or are they off the shelf? Are they like regular things people have heard of or are they like...

What are these tools that are processing the data and capturing the differences and doing the checking?

John (07:34)
I guess to give you context of how Monzo works from an architecture perspective, have the back-end system is sort of in AWS. And then what we do is we send those events to our warehouse, which is in BigQuery. And then we would build DBT models on top of the data that's in ⁓ BigQuery. And then with that, you have

like the usual testing and alerting that we would have in place to help us understand if there's discrepancies between models, I guess, at a sort of daily level. But then each half, we get audited. And that's where we would do, we will run bespoke models, still DVD models, but these models will actually just show month by month.

the differences between two data sources. Well, actually, in our case, it's three different data sources. And ultimately, you all three of these data sources to have an exact match. And then if there is an exact match, we would go and look at that particular month and understand why there's a difference. And so far, I don't think we haven't been able to not explain any differences, which is ⁓ obviously a good thing.

Aaron (08:59)
Yeah, and I think that, you know, that level of scrutiny and obviously affects your architecture, you know, obviously affects, you know, how much data you hang onto and process and, and, you know, the methods when it comes to delivering change, there's the onus on you as the individual or are there like development teams, testing teams, like are there gates? How does that side of it work?

John (09:26)
⁓ I think at Monzo there's like a very much a big ⁓ culture of like all ideas are welcomed. And it doesn't matter if it comes from someone senior, someone junior, like as long as it's a good idea, it's just about sort of writing a proposal and gathering feedback and it can ⁓ be brought forward. Like before, we didn't have these alerts that would ⁓ say

there's a 20 pound difference between this account and this account. But someone has bought that forward and said, ⁓ I think I could create something in maybe a few weeks to trial it. And then everyone's gone, this is awesome. Let's roll it out to multiple teams. So I think, yeah, the culture of Montauk is like an idea comes from one person and then it can be expanded. ⁓ Like this is a non data example, but like,

There's a new feature in Monzo called Undo Payments, which if you send like money to an account that you didn't want to, or say if I want to send you £10 but I accidentally sent you £100, I have the option to undo it within a certain time limit. And that idea came from a hackathon last year. And it's like, it's so cool seeing something that was just an idea last year that is rolled out.

a year later and it's like sort of like receiving all this good press and I think though it's not just the big things like that like undo payments that kind of get formed it's also small things like how do we send slack alerts to how do we get alerts sent to a slack channel it's also comes from just someone's idea and they just make it happen

Aaron (11:18)
Sounds cool. It sounds like quite a freedom, know, freedom to propose things. It's like quite a cool environment to work in. What would you say the biggest challenges for you are at the minute?

John (11:33)
I would say the biggest challenge at the moment, I guess what I'm personally facing is I've come into Monzo about a year and a half now. I've inherited a team and inherited a lot of just things. There's a lot of data models where we have ⁓ in payments alone, we have like thousand dvd models and being able to understand

Before, we weren't able to actually see the lineage of these models because Airflow would just break when you tried to expand it. We now have tooling that allows us to see the lineage, which has been super helpful. But again, just trying to see the lineage of 1,000 models is still, even though you can see the bubbles, it's still expanding. You're like, where do I start? ⁓

Aaron (12:22)
Oh, dude, that's what I'm going to you.

John (12:31)
So being able to kind of understand my domain has been difficult because it's sort of the first time I've come to a place where I haven't sort of touched or built everything. So I kind of just knew at my previous place, I was there for quite a long time, but I just knew, oh yeah, this joins to this and that joins to that. And this is, I've created the system for my domain. Well, in this case, the system has been created for me, but.

there's not any sort of clues of what the system is. And you kind of just have to figure it out on the fly. there's been a lot of actually just looking at the code and trying to trace it back yourself to try to get this picture of how all these things interconnect. ⁓ So I think with that, the issue becomes how do you scale that? ⁓ You're kind of scaling things that you don't quite understand.

You're like, oh, why have we done that? Why have we done this? And you sort of run with it. ultimately, there's, I think each year that goes by, you have less understanding of it. So what we're looking to do actually, which is like a Monzo wide thing, like do a re architecture of all the models. And my goal is like,

I don't want to have a thousand models. Obviously if a thousand models is what is needed to tell us the answers that we need, then we'll keep it. If it's 2000, it be 2000. But I just have a hunch that it will be less models that we'll need to be able to ultimately serve the payments business with the data that they need.

Aaron (14:09)
Yeah.

Yeah, yeah,

Where do you start with a challenge like that? How do you even get to the first model to deprecate or remove? What are you thinking?

John (14:29)
I mean, this has been top of mind for me. ⁓ I'm actually thinking about it, yeah, for the last four weeks. ⁓ I think it's been good because a lot of teams have been thinking about it. So for example, I'll speak into the operations team ⁓ who also thought about it and they kind of gave me some, I guess, food for thought that's allowed me to now think about my approach. But there's sort of two approaches. You can think about

the end use case and think and sort of work backwards, ⁓ which in my case, I didn't necessarily want it to do because I still have, ⁓ I'm not sure about the end use cases that well. And also I'm like, are people actually using our data models? So we think that someone wants a transactions model, but are people actually using it? So I would

Aaron (15:20)
Hmm.

John (15:29)
The approach that other teams have taken and I think is a good one is actually just to start from scratch from conceptually what is payments? So ⁓ a payment has, it's almost like what features does a payment have? And it's like, okay, so it's the transfer of money from one account to another account. What features does that have? It has authentication, it has...

maybe a payment limit, et cetera, and sort of building up all these concepts in your mind. And then what are the sort of building blocks that allow you to create, I would say a system. And the way I've sort of come down to it is,

Aaron (16:03)
Mm.

John (16:17)
There's like the, essentially it's all about the movement of money, but the way you move money has different infrastructure to it. So we have faster payments, which is how you send money from a UK bank account to another UK bank account. We have Monzo to Monzo payments. So that's sending money from Monzo customer to another Monzo customer. You have international payments and so on. And being able to understand what are the key components for all these different building blocks.

You can almost have like a unified model. It's kind of my thinking. then how, and then to wrap that up, there's like different layers of use cases. So we have people that want all the detail of this master card's payment has the, I know.

authentication number, the clearing message, charge backs, all this detail and that would be useful for someone in payments. But there's an abstraction of that that is some person just wants to know was there a mastercard payment and was there like a security check on it. So it's almost just like such a it's like a higher level model. So that's also what I'm thinking about is like what are the

Aaron (17:23)
Mm.

Yeah.

Mm-hmm.

John (17:42)
What is the target audience for the groups of models that we're creating? And it's obviously easier to start off with everything and then sort of move to more higher level abstractions that will be used for people that are less into all the details of the payment and just want to know how many payments were sent yesterday. So I think it's, those are the two things. It's like, what are the building blocks? And then what are the use cases at the different layers that we're trying to create?

Aaron (17:53)
Yeah.

Yeah, yeah, yeah.

John (18:12)
And then I think to your

Aaron (18:12)
think that sounds

like decent advice for pretty much anyone who's trying to grapple with a large system. Go back to first principles and actually speak to the people who need to use it. then actually that debate about refactor or rebuild is a pretty hard one to answer. But it feels like to me from what you're saying is that with a thousand models you have knowledge the original system designers didn't have.

So that gives you the better perspective to build something more appropriate to the business now and in the future.

John (18:47)
Yeah, and I think that's the whole thing. it's, yeah, it's kind of like a trade off between

It may be easier to migrate in terms of a speed perspective of like just do a like for like migration with some improvements or are you going to just start from scratch and say, this is how I want it to be designed? And I prefer the latter simply because we have more control and

If we do it right, it should be more future proof because we'll have the right documentation, for example. So if I'm not at Monzo no longer, yes. Yeah. And I'm sort of a big believer of like being able to, you want to be able to translate how you were thinking at the time because ultimately someone might look at my system design five years later and think it's absolutely, absolutely rubbish. And it might be.

Aaron (19:28)
Yeah, you'll have lineage from the beginning and you'll produce a result.

John (19:50)
for where Monzo is five years later, when we're in multiple countries and things like that. But I at want them to read what my head was saying at the time and go, okay, it wasn't right for now, but it was right for then. And now I get that perspective. I understand what I need to change to make it more future-proof because yeah, nothing's gonna, what I design now is

Aaron (19:53)
Exactly.

then.

John (20:20)
Yeah, I imagine in 10 years, it may not be appropriate.

Aaron (20:22)
It can't be right.

If the company and the domain keeps growing, it can't be right for everything. And that actually, think before the call, we were chatting about some of your pet peeves and I think you said it was testing. I wonder what the link here is. I sort of have some ideas, but between this big refactor and testing, what's your thoughts on how that works and how it could be better?

John (20:28)
exactly.

Yeah, for me, I was speaking to someone in my team about this earlier. It's just like, when we do this migration, all tests will be removed. ⁓ And we will start from scratch thinking about whether this test is appropriate. So for example, I think people will just whack like a not null test just like on everything. So not null, not null, not null, not null. But, and like fair enough, it may.

it shouldn't be not null, but is it is that true? And if if it if a null value comes in, what are you going to do about it? And if the answer is absolutely nothing, then don't bother write a test for not know because tests are. Yeah, you don't want to create noise, and I've seen it before where like you have so many tests that go through your channel that people get blind to it, and then when the actual real important data comes in, no one sees it because you've just got.

Aaron (21:35)
No reason.

John (21:50)
loads of not nulls or ⁓ inappropriate tests, but tests that you're basically not going to action. And I think every test needs to have an appropriate action. I think that's the structure I want to create in this new migration. Because ideally what I would have is you say what the test is, why it's important, and if it fails, what's the escalation for? So do you go to a particular

a Slack channel say it's failed, some test failures should be causing incidents. Like you have to actually get a group of people together to figure what's up. There's some low level alerts where it's just like, you just need to be informed about it and it needs to be fixed within say seven days. Or you need to read events from the backend potentially. So I think it's just kind of like.

Aaron (22:26)
Mm-hmm.

Mm-hmm.

John (22:46)
I've been like a level categorization of alerts of like, these are serious ones. If they come through, they need to, everything needs to be stopped and we fix them there. And then there's some things that can be fixed within a week. Maybe there's things that should be fixed in a month, but ultimately it's just every single test needs to have a purpose. And when a test fires, there needs to be a equivalent action that everyone knows that is the action to take in the team.

Aaron (23:06)
Mm-mm.

John (23:15)
that we're going to respond to it or you're just going to have, and I've seen it in every single department, every single team, you just have loads of alerts that you do absolutely nothing about.

Aaron (23:26)
Exactly. And so the thing I'm hearing you say, there's two things to change there. Process around the people and what you do about it. And then the technology to take the right action, alert the right person, the right severity. Does the... What?

We have to assume the process doesn't exist yet because there is some level of ignoring tests going on. Does the technology exist or is that also part of the challenge is to bring in new tools to change the alerting to like, is that part of what you need to do now to make that happen?

John (24:02)
I think my goal is to work with what we have. So we still have dbt alerts and they go into Slack channels. What I would love is to be able to acknowledge alert and it not necessarily fire the next day because that's, you almost want to, yeah, it's like we've already seen it. We've triaged it. Maybe we're going to fix it on Friday, but then if that alert comes in every single day,

I saw the alert on Thursday on Monday and then Tuesday, Wednesday, Thursday, I'm seeing the alert again, even though I've kind of triaged it in my mind, I'm just going to push the fix on Friday. That can cause alert fatigue. So that's one thing I would love to improve, but I haven't necessarily thought about how to do that within the confines of using dbt test alerts.

Aaron (24:52)
Yeah, it's interesting. And yeah, this is, I guess, part of the main, at least the fascination of, you know, as you get to the more technical domains, its infrastructure, its platform, it's solving a lot of people's problems in the, you know, in the, in the round rather than the next issue. Yeah, which can be the sort of more, more analytics focus, business focus tends to be the next question, the next question. Yeah, very, you know,

my experience was it's quite repetitive when you're working on the business. It can be fun and it can be exciting close to the customer, but it can also be a worth just cranking the handle, the same thing. So looking ahead a little bit.

John (25:28)
Yeah, I completely agree.

Aaron (25:32)
What do you think is unique to the banking technology domain? What's down the track that you think they need to respond to? What's the kind of, where's the investment going? And avoid avoiding leading the witness, but you know, is it AI or is it something else? What is it that they need that isn't there now?

John (25:55)
but as in like from a user, like a customer perspective.

Aaron (26:01)
think less so on the customer side and more so your customers. You as a technology provider to the internal stakeholders, that might be more the place I was thinking. What do they need that you're trying to provide?

John (26:16)
I it's, I kind of just see the job as how do we provide insights as quickly as possible for them to make, to inform decision making. I think that's just the name of the game. So you can always, you can obviously leverage AI to do that in the sense of, what were, how many payments were, what was the acceptance rate for MasterCard payments yesterday? And it's just like, it just.

hangs you the number because it has access to your underlying data. I think all that stuff is really, really cool. I think we just need to be careful not to like make it gimmicky. Ultimately, it's just about, I just see, I always go from the perspective of like, what are my stakeholders day to day job? How can I make that better through data? And of course AI is going to be a part of that, but ultimately, but also having like

scalable data models that are easy to understand, even dashboards that are grouped up nicely. There's so much low-hanging fruit that you can tackle without thinking about AI. I think ultimately, you're ultimately your data models and you'll, I think again, I need to go back to my system. If I create a good system, it's easier for AI to leverage that. I don't think I could stick AI on top of what we have now and produce a good answer.

Aaron (27:27)
Yeah.

John (27:43)
So there's the foundational stuff to be fixed first, for sure.

Aaron (27:43)
Yeah, right. The foundation date is not...

Compared to many companies, do you think, well I have an opinion but let me try to this question. Do you think there's more analytics in banking than other companies?

John (28:06)
It's difficult for me to say because ultimately I've only ever worked at Monzo so I don't necessarily know about traditional banks. ⁓ I would say

From what I've seen, there's more of a hunger for analytics. And I think it's when I compare it to the place that I was before was like an e-commerce company. It was just like, they were just so ridiculously data hungry. They would just want every, everything was just like, how can I get data to make a decision? What, what lever can I pull that ultimately like create more money, revenue, reduce my costs? So think it's just like, there's a mentality of like,

data rules or let's just get as much as we can, more data the better, which is maybe not necessarily the best mindset, but it was, it's very cool to be in a place where people are just like, I need data, I need data, where can I get it? Like you're almost like their best friends from that perspective. think within banking, I think there's, I think,

What I've noticed is maybe like data is more operational. It's like, we need this data for this report. And it's just like very much like the number is the number. Can you let us know? And you're like, yeah, there was 10 million transactions yesterday. Cool. But I think there's more.

Aaron (29:33)
less so from

an inquisitive what differences that make to the business perhaps compared to e-commerce.

John (29:40)
Exactly,

where I think someone will be like, what's this 10, there was 10 million transactions yesterday. What was it? What was it last week? How can we get higher? Should it be higher? And more questions come. I think, yeah, in banking, there's like an element of like, it's just it is what it is. But I also think that's just the journey that we're on. Like ultimately, that's most people just want to know that their numbers are correct. I think that's the first the first step. And then after that, it's like

Aaron (29:50)
Yeah.

Yeah, definitely the foundation.

⁓

John (30:08)
Yeah,

how do you improve those numbers is the next step. I think winning payments were on that journey for sure. We have like a new GM who's like super into the numbers and into details and he's just like, yeah, we need to crank these levers so we can improve our revenue, our revenue numbers. And I think it's an exciting space to be in. I think it's exciting and frustrating because ultimately it's like, you still, you need to fix your foundations before we can really accelerate that.

Aaron (30:24)
Hmm.

John (30:38)
insight which I wish we were a little bit further ahead than don't get me wrong we're in a good place like we can get the numbers but I think it's the difficulty of getting those numbers where you might have to join this table and this table and this table rather than maybe just go to one table or it just being like a simple join you know.

Aaron (30:56)
Hmm.

Yeah,

your gut feel is the question was relatively simple. It should be a relatively simple effort. Yeah, I actually find that quite insightful. if I think about the way you've talked about it, a company on a sort of more digitized digital journey is going to be more data hungry. And actually, you're right. You can't compare necessarily all the banks, but probably the newer, more digital banks are probably more data hungry. Do you have more people who care about the data than

John (31:07)
exactly.

Aaron (31:31)
traditional banking, more operational or possibly more sort of locked in their ways if you like. And that's probably the same in the physical world. E-commerce is like, it's a scale business, whereas a shop on the high street is a very much, you know, who's walking past, it's going to be the same kind of business and you're limited scale.

John (31:55)
Yeah,

I think to add to that is I don't think, again, stolen from a traditional bank, correct me if wrong, I doubt traditional banks are looking at active monthly users or revenue per user. They're just thinking, how many deposits do I have or how much money can I loan out or other...

Aaron (32:13)
Well, they might be, but not as regularly.

Like it might be sort of a yearly report as opposed to like a daily, you know, that kind of order of magnitude.

John (32:23)
Yeah, exactly that. I think that's the difference I would assume is that it's like really the sort of digital banks are thinking about customer acquisition and revenue per customer is probably one of their sort of North Star metrics while a North Star metric for ⁓ a traditional bank might just be like deposits in the bank.

Aaron (32:52)
Mm-hmm.

John (32:52)
and they

wouldn't necessarily care how many customers they have as long as it's like the deposit numbers going up.

Aaron (32:59)
Yeah, like the health over the sort of growth perhaps. Yeah, this has been really cool discussion, Don. Thanks for talking us through what it's like inside a bank. And actually, like my takeaway is quite an interesting place. actually, and particularly if you're into the precision of it and the kind of the things that attracted you, that sounds like a great place to work. Yeah, really delighted to have you on the show. Thanks for coming on and sharing with us.

John (33:28)
Yeah, it's a pleasure. Yeah, glad we finally got to discuss it and yeah, I would say ⁓

Yeah, it's an interesting journey. think I'm to pitch Monzo now. I'll say Monzo is a good intersection of tech and finance. So if that is your interest, I do think Monzo is a great company to work for. And there's a lot of technical challenges to overcome. And then it's also, it depends what your sort of mindset is. I really

Aaron (33:43)
You

John (34:04)
buy into Monzo's vision of making banking work for everyone. when I'm here, it's not just a tagline. I think we live and breathe it by the products that we launch and ultimately how we try to treat our customers.

Aaron (34:17)
Mm-mm.

I that. And I can definitely vouch for it. When you've hosted events there, and there's a huge turnout and a great buzz, there's a definite positive to working for a good brand and a brand that you can believe in. Yeah, that's cool. Thanks. Thanks for sharing.

John (34:36)
Yeah.

Cool. Thank you.