BoJ on m-ticket return

[miami]

I have a London -> Liverpool Stations off peak return on a trainline m-ticket which I used on the 10th May to go to Liverpool

On the 12th May I returned from Liverpool to Stoke, and broke my journey overnight

I intend to complete my journey from Stoke to

From my understanding on the routing, London->Stoke->Crewe->Liverpool and return is a perfectly valid route

However as it's an m-ticket it claims "tickets used", rather than "tickets partially used" or similar.

With a paper ticket this is fine. I'm sure that a guard may give me hassle, but am I clear, or is there some hidden terms in the delivery via the trainline that remove the right to an (multi) overnight break of journey on the return leg?

 

[Watershed]

Are you sure it's an m-ticket? If you received an email with a PDF copy of your ticket, it's an e-ticket and in fact you can always show this PDF if the ticket won't show within the app.

There is no restriction on overnight break of journey that depends on the medium of your ticket. Either it's permitted (almost always the case for walk-up tickets) or it's not because of a restriction on BoJ contained within the ticket's restriction code wording.

London to Liverpool Off-Peak Returns have restriction code 9I, which has fairly onerous time restrictions on Mondays-Thursdays, but no BoJ restrictions.

As for Trainline's "used" label, this is misleading and based on the flawed assumption that as soon as a ticket has been scanned the first time, it's used.

For future journeys, I'd stick to retailers that don't charge booking fees or do nonsense like this.

 

[Wallsendmag]

With any type of fulfilment than mTicket this is fine. An eTicket would have no problem with this

 

[miami]

Are you sure it's an m-ticket? If you received an email with a PDF copy of your ticket, it's an e-ticket and in fact you can always show this PDF if the ticket won't show within the app.

It's the ticket you download onto a phone and activate.

For future journeys, I'd stick to retailers that don't charge booking fees or do nonsense like this.

Alas that's not possible with corporate policy. Travelling personally I tend to use trainsplit.

Barriers at Stoke were open, but guard on the train from Stoke claimed "if you're breaking your journey you must continue the next day". She didn't take it further though. That statement is certainly not what I understand from the T&C for an Off Peak Return on any route on the return section (outbound sure, the validity is only 1 day so a BoJ would have to resume the following morningish)

With any type of fulfilment than mTicket this is fine. An eTicket would have no problem with this

But aside from the incomplete claim the ticket is used, is it specifically not fine on an mTicket, or is it just the misreading by staff

(I've had issues in the past at barriers with a paper ticket with a scribble through too, I'm more interested in the actual rules as the staff will hopefully sort itself out in one of the layers of appeals)

 

[yorkie]

It's the ticket you download onto a phone and activate.



Alas that's not possible with corporate policy. Travelling personally I tend to use trainsplit.

Barriers at Stoke were open, but guard on the train from Stoke claimed "if you're breaking your journey you must continue the next day". She didn't take it further though. That statement is certainly not what I understand from the T&C for an Off Peak Return on any route on the return section (outbound sure, the validity is only 1 day so a BoJ would have to resume the following morningish)

The Guard was wrong.

But aside from the incomplete claim the ticket is used, is it specifically not fine on an mTicket, or is it just the misreading by staff

(I've had issues in the past at barriers with a paper ticket with a scribble through too, I'm more interested in the actual rules as the staff will hopefully sort itself out in one of the layers of appeals)

It's valid but you can expect arguments (it shouldn't be this way, but that's the way it is)

 

[Watershed]

It's the ticket you download onto a phone and activate.

If you had to activate it before you could access the barcode, it was an m-ticket. I'm rather surprised that Trainline offered an m-ticket for London to Liverpool. It should be fulfillable to e-ticket.

Barriers at Stoke were open, but guard on the train from Stoke claimed "if you're breaking your journey you must continue the next day". She didn't take it further though. That statement is certainly not what I understand from the T&C for an Off Peak Return on any route on the return section (outbound sure, the validity is only 1 day so a BoJ would have to resume the following morningish)

She was completely wrong. Unfortunately, the complexity of the rules combined with the negligible amount of training (both initial and recurring) given to staff on ticket validity means that I can't say I'm surprised.

 

[miami]

She was completely wrong. Unfortunately, the complexity of the rules combined with the negligible amount of training (both initial and recurring) given to staff on ticket validity means that I can't say I'm surprised.

Thanks, I was fairly sure but it was whether there was something hidden in the m-ticket tos

Maybe the provision of m-tickets is a function of our corporate trainline-business portal.

 

[Haywain]

I'm rather surprised that Trainline offered an m-ticket for London to Liverpool.

mTickets seem to be taking rather longer to die out on corporate channels than elsewhere. I have no idea why.

 

[Bletchleyite]

mTickets seem to be taking rather longer to die out on corporate channels than elsewhere. I have no idea why.

It'd help if the industry would end support for them - would force ScotRail's hand too.

 

[miami]

mTickets seem to be taking rather longer to die out on corporate channels than elsewhere. I have no idea why.

I suspect that they allow automatic refunds if a ticket is unused. Oddly it seems quite common in my (large) company for people to buy walk-up tickets through corporate systems days or even weeks in advance, and then not use them.

(We recently changed provider, although operationally it's still delivered by trainline, and now get emailed saying "your ticket will not be refunded if you don't manually request it", but before it seems it was automatic)

 

[Trainbike46]

As a general point, try to avoid mTickets as much as possible; Either use to superior eTicket format, or use ToD to get paper tickets.
It avoids faff like this

I'm assuming that trainline corporate allows you to select delivery method?

 

[Adam Williams]

Alas that's not possible with corporate policy

If you know the folks involved on the finance side, TrainSplit does have a (frankly, somewhat poorly advertised) B2B offering with support for on-account (invoiced) payments, lodged card payments, displaying travel policies, fully-itemised expense receipts, spending reports, BackOffice access for viewing/managing company bookings and collection of department/cost code/other information at checkout time

 

[Krokodil]

It'd help if the industry would end support for them - would force ScotRail's hand too.

They're less vulnerable to fraud. I suspect that they'll stick around for as long as Open Returns do - they're on their way out according to government policy.

 

[Adam Williams]

They're less vulnerable to fraud. I suspect that they'll stick around for as long as Open Returns do - they're on their way out according to government policy.

They're not any less vulnerable to fraud than E-Tickets are, from a technical perspective.

Client-side security is not security, you cannot trust the environment in which you are executing code when it's controlled by your customer, so the only real security is within the barcode which uses the exact same standard and decentralised eTVD system as an E-Ticket.

m-Tickets need to be sent to /dev/null.

 

[Krokodil]

They're not any less vulnerable to fraud than E-Tickets are, from a technical perspective.

Client-side security is not security, you cannot trust the environment in which you are executing code when it's controlled by your customer, so the only real security is within the barcode which uses the exact same standard and decentralised eTVD system as an E-Ticket.

m-Tickets need to be sent to /dev/null.

They're certainly less vulnerable to opportunistic fraud, even if they'll do nothing about someone determined to hack into the code - you need to know what you're doing to achieve that, it's not something that Joe Bloggs with his iPhone can do. Simple things like reusing the same ticket as if it were a season (from unbarriered stations). With e-Tickets and paper/card tickets there's a reliance on the vigilance of onboard staff (who don't get training in how to spot misuse) whereas mTickets only last for the day (the TfW app prevents screenshots on Android). Obviously this problem goes away if the industry does away with Open Returns in favour of pairs of single tickets (hopefully with Day Returns remaining).

 

[Adam Williams]

They're certainly less vulnerable to opportunistic fraud, even if they'll do nothing about someone determined to hack into the code - you need to know what you're doing to achieve that, it's not something that Joe Bloggs with his iPhone can do. Simple things like reusing the same ticket as if it were a season (from unbarriered stations). With e-Tickets and paper/card tickets there's a reliance on the vigilance of onboard staff (who don't get training in how to spot misuse) whereas mTickets only last for the day (the TfW app prevents screenshots on Android). Obviously this problem goes away if the industry does away with Open Returns in favour of pairs of single tickets (hopefully with Day Returns remaining).

John Smith with his Android phone and access to Google can figure out how to install Magisk and a module that makes screenshotting possible again, though. The work has already been done and published online for the masses to make use of with very little technical knowledge.

Any security approach which relies on lack of understanding of how it works/how it can be bypassed is doomed to failure - indeed in the world of cryptography we have a term for that: "security through obscurity".

 

[Wallsendmag]

They're certainly less vulnerable to opportunistic fraud, even if they'll do nothing about someone determined to hack into the code - you need to know what you're doing to achieve that, it's not something that Joe Bloggs with his iPhone can do. Simple things like reusing the same ticket as if it were a season (from unbarriered stations). With e-Tickets and paper/card tickets there's a reliance on the vigilance of onboard staff (who don't get training in how to spot misuse) whereas mTickets only last for the day (the TfW app prevents screenshots on Android). Obviously this problem goes away if the industry does away with Open Returns in favour of pairs of single tickets (hopefully with Day Returns remaining).

I can’t see any good reason for retaining mTickets along with e and s Tickets, the soon they’re gone the better as ever security is in the barcode

 

[Krokodil]

John Smith with his Android phone and access to Google can figure out how to install Magisk and a module that makes screenshotting possible again, though. The work has already been done and published online for the masses to make use of with very little technical knowledge.

Any security approach which relies on lack of understanding of how it works/how it can be bypassed is doomed to failure - indeed in the world of cryptography we have a term for that: "security through obscurity".

Which is still better than the situation with eTickets where you can present the same one day after day and just hope that no one is checking properly with no effort required - and I've caught people who have been getting away with it for the best part of a month. I don't care what John Smith theoretically can do, I care about what John Smith actually does do - I think that I may be more familiar with John Smith than you are, he doesn't go out of his way to avoid fares, he just takes advantage of open goals when they present.

Repeated reuse of eTicket and paper/card open returns has become a significant proportion of fraud on some routes since the pandemic. I've never seen an mTicket barcode reused, and I don't miss much.

 

[Adam Williams]

Repeated reuse of eTicket and paper/card open returns has become a significant proportion of fraud on some routes since the pandemic.

So why aren't tickets being scanned consistently? Fares reform is not a silver bullet answer to a problem of inadequate staffing or on-the-ground staff not doing their job properly (which there is usually a reason for - I would posit that the state of industrial relations between the unions and govt hasn't exactly helped matters here) and has a number of downsides for passengers who are honest who lose rights.

I think it's interesting that non-technical folks often think problems that are non-technical in nature can be solved by throwing technology at the problem.

I can’t see any good reason for retaining mTickets along with e and s Tickets, the soon they’re gone the better as ever security is in the barcode

@Wallsendmag has hit the nail on the head. m-Tickets are an outdated, "lazily-designed" (to work with the lack of barcode infrastructure in use at the time they were introduced) fulfilment method with a whole host of problems that have been documented in quite some detail on this forum. They need to go.

I think that I may be more familiar with John Smith than you are, he doesn't go out of his way to avoid fares

I don't know, I see a minority (but a fairly significant one) of the general public attempting to take advantage of the refund and delay repay system. Some of them are quite brazen and determined to defraud.

I've never seen an mTicket barcode reused, and I don't miss much.

With respect, how would you know? Anyone with an ounce of sense who is defrauding the railway in this manner isn't going to try this when the barcode has been scanned, that would just be stupid.

 

[yorkie]

There is no good reason for m-tickets to be retained; they cause so many problems. The idea that they are more secure is a fallacy; the solution to the problem of tickets not being scanned is best solved by actually scanning the tickets.

 

[Krokodil]

So why aren't tickets being scanned consistently? Fares reform is not a silver bullet answer to a problem of inadequate staffing or on-the-ground staff not doing their job properly (which there is usually a reason for - I would posit that the state of industrial relations between the unions and govt hasn't exactly helped matters here) and has a number of downsides for passengers who are honest who lose rights.

Tickets are being scanned, that's how I know that they're being reused (I dread to think how much they're getting away with when the equipment is faulty or they get on an Avanti service where a work to rule is in place). There has however been no refresher or update training in at least half a decade. Staff seem to be expected to absorb information by osmosis. No one higher up bothers to brief staff on the need to double-check the scan history at the bottom of the screen.

I see a minority (but a fairly significant one) of the general public attempting to take advantage of the refund and delay repay system. Some of them are quite brazen and determined to defraud.

I'd half categorise that under "open goal" rather than "going out of their way". To pick a non-tech example, most opportunists sit down and hope that they aren't asked, they don't go to the trouble of hiding in the bog.

With respect, how would you know? Anyone with an ounce of sense who is defrauding the railway in this manner isn't going to try this when the barcode has been scanned, that would just be stupid.

If I am able to catch eTickets and PRTs with long scan histories, it would stand to reason that I should just as easily be able to catch people doing the same with mTickets, unless the system doesn't let them.

CCSTs of course don't allow you to tell what use it's had previously, but when someone boards at A with a B-A-B open return issued only 10 minutes before then it's pretty obvious what they're up to. Ticket dated to prevent reuse (BOJ prohibited on this ticket).

Also dated are the return halves of Open Returns the students bought on their way home last night. With this particular group of students I even date the PRTs as a belt-and-braces measure, it stops them showing me the exact same ticket tomorrow, or trying to pull the wool over the eyes of a guard without a working scanner.

 

[Adam Williams]

CCSTs of course don't allow you to tell what use it's had previously

You'd be able to see if it had been through a barrier, if you were issued with the right kit.

 

[Krokodil]

You'd be able to see if it had been through a barrier, if you were issued with the right kit.

Neither origin nor destination are barriered in this case.

 

[crablab]

CCSTs of course don't allow you to tell what use it's had previously, but when someone boards at A with a B-A-B open return issued only 10 minutes before then it's pretty obvious what they're up to.

Probably being dense, but could you expand a little on how this is "pretty obvious" please?

I understand the issue with reusing the open return coupon, but why would they not have purchased, issued and used the ticket starting from 'B' (the outward portion)?

 

[yorkie]

Probably being dense, but could you expand a little on how this is "pretty obvious" please?

I understand the issue with reusing the open return coupon, but why would they not have purchased, issued and used the ticket starting from 'B' (the outward portion)?

I think @Krokodil is saying that they hope to not be checked so that they can reuse the same ticket on a subsequent day (which they couldn't do with an outward portion)

 

[transportphoto]

If I am able to catch eTickets and PRTs with long scan histories, it would stand to reason that I should just as easily be able to catch people doing the same with mTickets, unless the system doesn't let them.

It’s interesting to see how different TOCs use different technologies to check tickets. I’ve been shown an insight into TTK (The Ticket Keeper) which is used by some TOCs.

When scanned, details are presented with a quick traffic light summary at the top - green for “Ticket okay to…”, amber for railcard/purchase after departure/manual check/etc, and then red for already clipped (to destination/similar)/wrong date/etc.

To view scan history requires moving onto a different screen - although is definitely there.

Perhaps off topic - but can you see comments left by other TOC staff? E.g. if a guard from TfW was to annotate “no railcard” or “please pass on…” - would you be able to see it as a GWR guard? (TOCs as examples only.)

 

[crablab]

that they can reuse the same ticket on a subsequent day (which they couldn't do with an outward portion)

Sure. But they just discard the outward portion entirely!?

I guess I don't understand why they don't start at A with the open return, use the outward portion and then reuse the B-A inward portion. It doesn't make sense to buy an open return ToD to just discard the outward portion, if you presumably have to make that journey anyway (although I can see the "optimisation" technique they might be applying here).

 

[Wallsendmag]

It’s interesting to see how different TOCs use different technologies to check tickets. I’ve been shown an insight into TTK (The Ticket Keeper) which is used by some TOCs.

When scanned, details are presented with a quick traffic light summary at the top - green for “Ticket okay to…”, amber for railcard/purchase after departure/manual check/etc, and then red for already clipped (to destination/similar)/wrong date/etc.

To view scan history requires moving onto a different screen - although is definitely there.

Perhaps off topic - but can you see comments left by other TOC staff? E.g. if a guard from TfW was to annotate “no railcard” or “please pass on…” - would you be able to see it as a GWR guard? (TOCs as examples only.)

You don't even need to look at those, the handsets are programmed to make different sounds for valid and invalid tickets.

 

[crablab]

You don't even need to look at those, the handsets are programmed to make different sounds for valid and invalid tickets.

This seems largely good. It potentially removes issues/arguments about the validity of tickets (eg. Paddington off-peak) where staff cannot be reasonably expected to remember all possible permitted tickets. However, this is only true as long as:
a) the software has been written well and can calculate validity correctly (seems obvious but...)
b) data entering the system is accurate and robust. We wouldn't want a situation where clips were being incorrectly ascribed to the wrong location, for example (as that could give the impression of overriding, on inspection of someone's Trainline account...)
c) an element of discretion still exists and "computer says no" doesn't take over.
d) it isn't used as an excuse to implement ever more complex tickets or onerous restrictions that passengers are supposed to understand and comply with.

I guess my overarching worry is that the data may be used for fishing expeditions and perfectly legitimate travel patterns will be seen as "suspicious" (eg. missing clips at gatelines when starting short or splitting) and the burdon of proof placed on the passenger to defend their actions in response to a hostile letter sent by TIL...

I'm under no illusion that many who frequent the Disputes sections are bang to rights, but the railway doesn't always get it right, especially with complex ticketing matters, and the ease by which they can extract significant settlements from people by threatening prosecution is somewhat concerning. People are very worried about a criminal record nowadays and I'm sure there are those who choose to settle, rather than chance their luck in court despite the railway being in error.

It's not entirely clear who owns or has access to this data and for what purposes it is being used. This is especially important when it is being used for prosecutions.

That said, I do appreciate the significance of ticket fraud on the railways and the part technology can play in identifying that at scale.

 

[Haywain]

This seems largely good. It potentially removes issues/arguments about the validity of tickets (eg. Paddington off-peak) where staff cannot be reasonably expected to remember all possible permitted tickets. However, this is only true as long as:
a) the software has been written well and can calculate validity correctly (seems obvious but...)
b) data entering the system is accurate and robust. We wouldn't want a situation where clips were being incorrectly ascribed to the wrong location, for example (as that could give the impression of overriding, on inspection of someone's Trainline account...)
c) an element of discretion still exists and "computer says no" doesn't take over.
d) it isn't used as an excuse to implement ever more complex tickets or onerous restrictions that passengers are supposed to understand and comply with.

I guess my overarching worry is that the data may be used for fishing expeditions and perfectly legitimate travel patterns will be seen as "suspicious" (eg. missing clips at gatelines when starting short or splitting) and the burdon of proof placed on the passenger to defend their actions in response to a hostile letter sent by TIL...

I'm under no illusion that many who frequent the Disputes sections are bang to rights, but the railway doesn't always get it right, especially with complex ticketing matters, and the ease by which they can extract significant settlements from people by threatening prosecution is somewhat concerning. People are very worried about a criminal record nowadays and I'm sure there are those who choose to settle, rather than chance their luck in court despite the railway being in error.

It's not entirely clear who owns or has access to this data and for what purposes it is being used. This is especially important when it is being used for prosecutions.

That said, I do appreciate the significance of ticket fraud on the railways and the part technology can play in identifying that at scale.

I suspect you are overthinking it, and what @Wallsendmag should have said was valid and 'not obviously valid' tickets.