I suspect someone missed a 5 on the front of the latitude of the lat and long of your TV licence> Blockquote
Possibly 
Iāve just had another quick look and here is Amazon Prime purchase in Luxembourg⦠
And I went to a cash machine 600 miles away at some point.
The point is that theyāre not at all accurate. Itās just a nice gimmick (if thatās the word) to see them all overlaid on a map - but I certainly wouldnāt rely on them for anything else
This isnāt the fault of Monzo, itās just the information theyāre sent.
The Amazon one could be accurate, if they based the transaction in Luxembourg for some reason.
It will be, Amazon for the Uk is operated by Amazon Europe which is run out of Luxembourg
Edit:
https://www.amazon.co.uk/gp/help/customer/display.html?nodeId=201909000 Bullet 18 shows addresses
@bruno My water bill from Dwr Cymru is listed as āUNPAID DD (Direct Debit)ā in the description field of my CSV export, despite the app correctly identifying it as from Dwr Cymru with the correct logo and being debited from my account every month no problem. Should I flag this as āSOMETHING WRONG? TELL US!ā in app or is this expected behavior?
Iād think this is unrelated to any work weāre doing here at the moment, and will be down to some weird merchant data we received, meaning itās expected behaviour. But just in case, can you DM me the transaction_id for this payment?
Great idea, weāve added a new column with this info called Type!
Yeah location isnāt always accurate. We get very basic data from Mastercard and run our own enrichment on top (for the name, logo, category and location). It works okay for a pretty feed, but I donāt think itās that useful to drill down into spending insights based on location data. Weāll still keep the current address column but wonāt expand on it.
Noted, weāll make two user friendly date and time columns.
Weāve added a new column for counterparty, this will include the pretty merchant name, or name of the other person when itās a P2P/FPS. The new column Type includes whether itās Mastercard, P2P, FPS, Cheque, etc, which leaves Description to show any additional information as an optional column.
This is progressing well but you wonāt see any changes in the app just yet. Weāll let you know once itās live ![]()
Sounds great. Will this include the pot name as a recipient? So for example the type would be pot transfer and the counterparty would be the pot name? This may make it easier to track individual pot balances (if you ignore the issues that will arise when renaming pots and conflicts that might occur if you name your pot the same as an existing counterparty)
Very exciting that CSVs are getting some love! Have you decided against including a Balance column, or is that still being considered? 
That is great!
Maybe we could get a PotID included as well?
Wonderful!
Iāll wait quietly now but very pleased this will be added.
Yes, Yes.
Amazon is using ISO formatting too.
Whatās your point?
It is better!
For who?
I understand standards, I work with them. But this is NOT better for most people who just want a date and time that looks like a date and time. STORE the data that way, sure, but give users an option that makes sense to them.
Iām guessing but confident it is the larger share of Monzo users who would better understand a date and time expressed a different way.
Anyway, itās been stated it will be an option, so letās end this discussion and agree to disagree.
The issue is it is unambiguous.
Without specifics, given CSV is plaintext, dates could be interpreted incorrectly dd/mm/yyyy or mm/dd/yyyy
And the majority of users will accept that and figure it out when they see 23/02/20 or some such.
Think about the humans who will use this. Not the technology. Not everyone thinks the way you or I do. There are other options.
Done now. No point arguing with someone who just wants to argue.
@bruno, I donāt know if you are aware of this (I wasnāt before today), but the CSV format is slightly different depending on whether you export the CSV as a statement (from the Summary screen) compared with exporting a CSV from a search result in the main feed. As part of your work to clean up the CSV export, could you make the format consistent between the search and statement exports?
Also, the search export includes transactions from the prepaid card, whereas the statement export excludes all prepaid transactions. This means thereās no (easy?) way to get an āAll Timeā export that includes prepaid transactions.
Statement export headers:
id,created,amount,currency,local_amount,local_currency,category,emoji,description,address,notes,receipt,category_split
Search export headers: (omits category_split)
id,created,amount,currency,local_amount,local_currency,category,emoji,description,address,notes,receipt
Statement export line:
tx_00009fUViogGs8ECOCftB4,2019-01-05T14:35:41Z,-1.45,GBP,-1.45,GBP,General,š®,POST OFFICE COUNTER TOWNNAME GBR,17 Any Road,,
Search export line:
tx_00009fUVvogGs8ECOCftB4,2019-01-05 14:35:41 +0000,- 1.45,GBP,- 1.45,GBP,general,š®,Post Office,"17 Any Road, TownName AN1 4XX",
Differences:
- search export date format is different, doesnāt include
TorZ, uses spaces and a time zone offset instead - search export has
-sign separated from the amount by a space - statement export capitalises category name, search export doesnāt; additionally, not shown in this example, the statement export uses a space between a two-word category name, whereas the search export uses an underscore
- statement export uses card network merchant name with town name and country in all caps, search export uses Monzoās corrected and properly capitalised name
- statement export address includes only the building number and street name, search export provides proper full address with postcode (presumably from Monzoās merchant enrichment database)
- search export is missing the
category_splitcolumn (as noted in the headers
)
Hey @jzw95 thatās really interesting, I wasnāt aware of the difference either!!
I think weāll keep this out of scope. Search is something completely different that should be kept separate from this. Iām pretty sure Search exports are calculated locally from the feed, thatās why it includes Prepaid data.
This is what we have right now, will likely be the final format. Hereās how a P2P looks like.


