Feedback Request – Delay Repay Wizard Launch

[Steven Fuzesi]

Hi Everyone,

We’ve finally managed to get https://delayrepaywizard.co.uk/ live!

This started as an experiment to see if we could kick off a dev business with a real example. The idea came from my son — automating the “delay repay” compensation process. I’ve commuted into London for over 35 years, been delayed countless times… and only claimed once!

Originally, we aimed to fully automate everything, but handling user credentials turned out to be too tricky for now. Instead, our first release lets you quickly find your delayed journey and see what you could claim.

It’s been a big learning experience, especially releasing into the wild in today’s world of interconnected services. I never thought I’d be wrestling with timetable and routing flat-file data again — felt like my mainframe days all over!

The schedule data is being updated over the next day or so, but you should already be able to find most train journeys. Some UI tweaks are still on our list, but as you know, you can tweak forever — so we decided it was better to get it in front of the experts (that’s you).

Please take a moment to have a look and let us know your thoughts. All feedback is welcome — be as brutal as you like!

Cheers,
Steve

[Steven Fuzesi]

BTW any feedback can be via he...@fuztec.com

thanks

[Christoper Stafford]

Hi Steven

I'd slightly caution that this product appears to give people a handy list of trains and delays, allowing them to pick the train with the maximum delay rather than the one they actually caught. It would then facilitate them in making a fraudulent claim. There have been products in the past which did this, and it was chased down pretty hard by the train companies. I'm not suggesting that is what you are trying to achieve, but it's worth being aware that it's a potentially significant use-case for the product, and could be viewed quite dimly.

Thanks

Chris

[Steven Fuzesi]

Hi Chris
yes that use-case was a concern but ultimately the central 'ticket' usage database should weed out claimed for tickets that have barrier / inspector timestamps that don't match the late train.
but yes point taken that we may get run out of town
cheers
steve

[Evelyn Snow]

Hi Steven,

I think you have a very optimistic view of the rail industry's ability to detect fare evasion.

Evelyn

[Steven Fuzesi]

Hi Evelyn
start out optimistically flying by flapping hands and then hit the ground... point taken

true, tickets are not always scanned, unmanned barriers are open, and on my packed journeys into London I rarely had the ticket scanned by the conductor

we wanted the app to just be anonomously usable, but as the feed back suggests, we will need email login, that's validated, and then we can throttle any fishing behaviour - I'll ask AI

thanks for the reality check... I hope we haven't built the wrong app to advertise our dev skills

cheers

[Evelyn Snow]

Hi Steven,

My line of thought was more that paper tickets without aztec codes on them cannot be scanned and
tracked centrally. In some cases they might be stamped with the headcode of the service taken, but
this isn't a universal practice.

As you point out, even for tickets which can be tracked more closely, there's quite a few
situations in which it won't be possible for a TOC to be certain of the service taken: DOO
operators depend entirely on gatelines and revenue inspectors; In my personal experience, I've
found guards sometimes don't check before I'm off the train, and in any case often don't bother
checking when I'm dressed as a tangerine.

I'm not sure that requiring login or applying throttling really fixes the problem in the eyes of
train operators. If I've got a ticket I know hasn't been checked (or is a paper ticket, at that)
and I know when the ticket was issued (this is printed on the ticket, of course), this interface
makes it very convenient to maximise my delay repay for a journey where I did experience some delay
by picking a more delayed itinerary than the one I actually took.

Evelyn

[Steven Fuzesi]

Hi Evelyn

tangerine? an interesting citrus fruit to pick over the other more popular ones.

true, human nature will err on the side of more compo, if another train, say leaving Reading for Paddington, 2 mins after the one you got on is delayed by 31 mins instead of your 29 mins one

I was under the impression that paper tickets with mag strip all have unique ticket ids and if scanned at barrier go into same ticket DB?

Isn't there a move to just give receipt like paper tickets with barcodes, so all need to be scanned.

Plus don't network rail hand over a bag of money to the TOCs each month for infrastructure failures - not rail TOCs fault (that came from a dev who worked for a while with one of the TOCs)

anyway let's see if I get a visit from the fat controller anytime soon

cheers

[Evelyn Snow]

Hi Steven,

It's an orange-coloured fruit, an orange felt too obvious!

My understanding is that the paper tickets have quite limited space on the magstripe and don't
include identifiers. They've been around for a while and the original idea would have been to have
enough to reliably operate ticket barriers, but not much more.

Evelyn

> --
> You received this message because you are subscribed to the Google Groups "A
> gathering place for the Open Rail Data community" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to openraildata-t...@googlegroups.com.
> To view this discussion, visit https://groups.google.com/d/msgid/
> openraildata-talk/6adda37c-ad3a-4820-8913-16f167da24b4n%40googlegroups.com.

[Ryan Woolies]

Hi,

Not quite brutal feedback but an important failing is that it doesn't work for multi-leg journeys :(
 In my experience (Scotland) much Delay Repay stems from missed connections.

An example to test your wizard is Aberdeen to Glasgow Queen Street, departing at 11:01 on 20th Aug 2025. It's a short connection at Dundee and a very common single advance ticket journey.

The wizard highlights an 8 minute delay arriving into Dundee (at 12:16 vice 12:08) but doesn't recognise that the 12:15 connection to Glasgow is missed and arrival at the destination was actually +26. (Next train Dundee - Glasgow after missed service is 12:53).

Hopefully you can get a more local example to better understand and enjoy coding how to figure potential real journeys during disruption!

Ryan

On Thursday, 21 August 2025 at 14:07:52 UTC+1 Steven Fuzesi wrote:

[Steven Fuzesi]

Well spotted Ryan.

The UI needs to clearly indicate that the 'scheduled' journey was impossible to complete due to missing the connection.

And an interesting feature you propose - 'what was the real journey' due to the scheduled ones not stacking up properly.

Currently a multi-leg journey is resolved purely on the schedule expected arrival/departure/platform wait times, then based on the best journeys (fastest, least changes, etc) derived via the hellish routeing data, we lookup HSP (not an API that likes to be bombarded) for these few best journeys.

There is a feature in the non-public test page that allows click through on a leg to find the real journey you took - basically tweak the time you left Dundee - but this has not made it into the public UI.

We also have an issue with working out some odd 'via' journeys. If you just use timetable and routeing guide data, you get a fairly good attempt at the multi-leg journey. But not always matching the various ticketing apps (Nat Rail JP, Trainline, GWR, RailForum, etc) version of a valid multi-leg journey. Using the fares data was a bridge too far mentally and we want to avoid more data in mem - the app loads all required data (JSON) into mem for processing, with persistence caching only for HSP lazily. So to returning to the point, I'd like to add a 'via' field(s), so the user does there legit journey as indicated on the ticket.

My son, being modern and having worked in a microservice based startup, is all about MVP, whereas I'm let's-just-add-this-teeny-bit, as I know s/w is never released on time, hence we have all the time in the world.

Thanks for the feedback.

If nothing else, it shows how complicated the raw rail data is to work with - every ticketing app has re-invented the routeing guide data processing - but I guess you all know that.

[Tom Cairns]

As someone who was loosely involved in the last round of these sites existing (although I didn't run one myself), it's probably worth adding a few things.

One of them converted to becoming the supplier of choice for some TOCs wishing to manage delay repay claims, several shut down due to Covid and I believe at least one was involved in a fraud investigation and shut down not that long later. I think at the peak there were at least 5 or 6 of them?

The TOCs do have some anti-fraud measures in place which can do detection but have not historically looked particularly nicely at sites designed purely to look at historical delay with the view of aiding delay repay claims. A few individuals have historically deliberately use these to find trains they did not travelled on. Sites which don't solely steer that angle seem to all still be around.

In terms of ticket scan data, etc, it's OK for e-tickets where they are scanned. Paper tickets don't really have a unique ID and it would be safe to assume that doesn't go to a central database. Schedule 8 repayments may be automatic but it goes both ways - sometimes its quite revenue neutral and there have been trials where NR and TOCs don't pay each other and work together towards a shared goal of improving performance. Not sure if that is still in place anywhere.

Tom

> talk/aKe1WBOTTg3Qx3xm%40evelyn.moe.