If you aren’t from Melbourne and haven’t heard of myki, it is a public transport ticketing system that has been the subject of a lot of criticism, mostly because of cost blow-outs, technical issues and general customer dissatisfaction. I wont go into the details, but rather point you at the wikipedia article which summarises them well.
If you don’t know what MykiLeaks is, then I encourage you to check out the website. It consists of only 2 pages, so it wont take you long.
How did MykiLeaks come about?
I began using a myki card in mid 2010 on my travels around Melbourne, and after a number of weeks decided to check over my statement to ensure I was being charged correctly. The first thing I noticed was how poorly presented the trip data is. More on this in a separate post, but the bottom line is that it’s very time consuming to determine what fare you were charged on a given day, and hence difficult to ensure you’ve paid the correct fare.
After discovering that I’d been overcharged a small amount (and successfully applying for reimbursement), I decided to write a Python script to check over my statement automatically, in order to save myself the trouble. I then began to wonder if other people had been overcharged, and canvassed my friends, asking the myki users among them if they’d be willing to send me their statement for analysis. I received a small number of myki statements, and soon realised that I wasn’t an isolated case. In two evenings MykiLeaks was created, and a small press release to MX magazine had the statements rolling in.
How does MykiLeaks work?
The website accepts myki statements in PDF form, and immediately extracts the travel data into a plain text file, deleting the original PDF and the user’s personal information therein. For each day of travel in the statement, MykiLeaks determines the maximum fare payable by the customer, based on the zones travelled through and the trip duration. Then, a comparison is made between this maximum and what the user actually paid. Detected overcharges (if any) are presented to the user, as well as some copy-and-pastable text for the user to apply for reimbursement with. Check out the sample statement assessment and see for yourself.
So how many people are being overcharged?
In April 2011 an estimate was made using the relatively small sample of statements (roughly 270) that had been submitted up until that time. The results indicated that as many as one third of customers had some sort of discrepancy on their statement. Now this statistic seems very large, and it may well be exaggerated due to the higher probability of a myki user submitting their statement if they already suspect an overcharge. Nonetheless, a proportion larger than 1% is completely unacceptable by any reasonable expectation of system quality, and considering we’re dealing with money, my belief is that there should be an expectation of a 0% error rate. After all, we expect that from our financial institutions, and myki money is still money.
Since this statistic was published in The Age, a further 3000 statements have been submitted to MykiLeaks. A press release is forthcoming on the results of these statement analyses.
How are people being overcharged?
I plan to answer this question in detail in a future post, however the most common overcharge patterns are:
- User travels within zone 2 and zone 1/2 overlap, but is charged a zone 1 fare
- User travels on a Saturday or Sunday and pays more than the $3 weekend cap
- User forgets to touch off on a train journey, and is charged a default fare, however the total amount charged for the day exceeds the maximum daily cap of a daily zone 1 and 2 ticket
Why are people still getting overcharged?
Good question! Considering that overcharging has been a problem since the early days of the rollout, there’s no satisfactory reason why a suitable fix or workaround has not been implemented. Even if the cause of the overcharging cannot be fixed without significant hardware changes, a satisfactory workaround would be to regularly audit all statements (similar to how MykiLeaks functions), and automatically reimburse the overcharges. Currently, the onus is on the end user to detect an overcharge, and then request reimbursement.