In theory there’s absolutely no reason I couldn’t do that, it’s just about making sure that all the systems are highly accurate and consistent, and also working out how the UX would work for that (having never used any of those services)!
There are so many things you can do with the API, my plans in places are very much stretching the definition of what this project started out to be without going completely out of bounds.
I’ve been wittering for (literally, now) years that the most significant Monzo marketplace will end up being with third party apps / extensions / integrations. This will keep folk in the Monzo ecosystem - but could almost certainly be monetised effectively. Think of an app store for Monzo.
He won’t see or read it, but I’m gonna tag @anon91821566 because this is not just cool, it’s (imo) super important to the future of Monzo!
I can really imagine moving more of my spending through monzo to get this record. Amazon for example I pay currently with a credit card but the data gain would make me shift to using Monzo instead.
I truly believe there will become a time within the next 3 years where people just expect this level of enrichment on all digital if not all transactions going through their account.
It’s weird because I still constantly think about the original marketplace and how I could easily buy services without having to provide a tonne of information. This has been partially done in Monzo+ but not to the same degree, I genuinely do see a place where 3rd parties could provide these integrations whether it’s into a new energy contract, a subscription for a service like this, or a free add-on for something else.
I see a lot of potential in this, I would personally love to take this project so much further but alas unless I win the lottery this week I won’t be able to afford to become an AISP Shame
This shouldn’t be a requirement though, open banking should allow Monzo to see your transactions as they happen and essentially have them as a separate feed in your Monzo app. Receipts could be added to those. This is obviously not there yet but something that would be ace further down the line.
There does seem to be a huge shift in mentality towards what a bank/app can do - and I think for me this thread has highlighted the power of the Monzo API / framework.
I knew the API existed, and have used it to sling my own data around, but had no idea you could use it to build features that appear inside Monzo.
Why are there not more already?!
Two of my favourite banking/budgeting services both have APIs - (Monzo and YNAB) - yet there’s no super easy way to routinely export everything I do within Monzo to YNAB. If only!
Would love to hear over DM more about how you think this workflow would use - with screenshots if applicable. Never used the tool so really need details.
If I think it’s feasible, I can work on a prototype with you?
So classic James, it’s currently 11:17 and I’ve not eaten but have been making some good progress tonight
Tonight two big things happened:
Started work on a new system which aims to make debugging errors much quicker. This has already helped wonders! (We’ve not had that many failures today )
Started work on a new merchant engine. This new system is a lot more flexible, especially for receipts which contain multiple receipts (that may or may not be the same transaction). Still a work in progress but it has enabled us to add a new merchant: Deliveroo!
Hoping to keep moving on these improvements, and improve support for Amazon split orders and improving overall success %!
edit://
It’s worth noting that I fully understand the risks of working on an API which is very much listed as beta and not really designed for public applications. (I’ve had experience with my Morezo project, different thread and I released that. Had just over 50 users at it’s prime, but had to patch once or twice due to API issues)
Whitelisting everyone is a very manual and tedious action. I can’t, and am not going to try to automate it. Small price to pay for the substantial gains to be had.
Would love to help out testing- and development-wise. How modular is the code (as in, are you creating it in a way that other developers could theoretically create their own rules for parsing emails?) ?
This reminds me a bit of something Google don’t push that much anymore, which is Email Markup. It would require developers to include structured hidden information in their emails. Google would (from a whitelisted set of senders) extract this information and create actionable events, eg downloading a plane boarding pass, creating a reminder, checking in etc. Super cool that this doesn’t require us waiting on the merchant’s side.
Do you have a new invite link for Slack as the one 5 days ago is dead? Cheers
The code is pretty modular, and the new refactor is going really well in terms of making the merchant handlers themselves considerably smaller/simpler and increasing the reusability of them.
I’ll be doing a full write up on the technical end, but the email extraction is completely separate to the transaction matching. Ingest (which is what turns the email payload into something I can process) is also separate.
For the Slack, this link should not have any expiry on it! If you’re having issues - DM me.
At present, there are no plans to share this on GitHub. I am however planning on breaking the services down to make the email extraction something people can use independently.