How much information can operators gain from paper / e tickets?

[williamn]

I'm always intrigued to know how much information can be gained by operators from your mag-stripe physical ticket or e ticket. For example do they know which gateline you passed through and when? Or is the system not that sophisticated?

 

[plugwash]

My understanding

magstripe tickets have very limited data storage capacity, there is a "ticket number" but IIRC it's not big enough to uniquely identify a ticket across the whole country. Some ticket barriers will write back to a ticket to mark it as "used", this being far more common on TFL barriers than NR barriers. Some barriers will also keep a local list of recently seen ticket numbers and reject tickets that have been recently seen (known as a "passback" reject).

e-tickets, paper roll tickets and presumablly other types of "smart" ticket have a unique ID that can be traced back to the issuer and there is a central "scan database" that records when and where they were scanned, along with the type of scan. IIRC there is provision for a "final" scan to berecorded when a ticket is "used up" which will then cause any further scans by an online terminal to reject the ticket,

The scan data may also be looked at to look for combinations of scans that indicate ticket misuse, though it's not clear to me to what extent this is actually done, and whether it's done in real-time or only in retrospect.

 

[Haywain]

Some ticket barriers will write back to a ticket to mark it as "used", this being far more common on TFL barriers than NR barriers.

All barriers should be writing to the mag stripe with details of when the ticket was accepted.

Some barriers will also keep a local list of recently seen ticket numbers and reject tickets that have been recently seen (known as a "passback" reject).

The passback rejection is due to what has been written to the ticket when it previously went though. The barriers retain basic details of the tickets seen but not ticket numbers as they are not encoded to the mag stripe (as far as I remember).

e-tickets, paper roll tickets and presumablly other types of "smart" ticket have a unique ID that can be traced back to the issuer

The issuer is encoded to the barcode (and is detailed in the UTN (Unique Ticket Number, I think) which is usually found immediately below the barcode).

there is a central "scan database" that records when and where they were scanned, along with the type of scan.

Correct, known as the eTVD (eTicket Validation Database).

IIRC there is provision for a "final" scan to berecorded when a ticket is "used up" which will then cause any further scans by an online terminal to reject the ticket,

I'm not sure that's true.

The scan data may also be looked at to look for combinations of scans that indicate ticket misuse, though it's not clear to me to what extent this is actually done, and whether it's done in real-time or only in retrospect.

The information is all there, but not (yet) used anywhere near as well as it might be.

 

[MrJeeves]

there is a central "scan database"

To be pedantic, there is no centralised system. In fact, the whole network is set up to be decentralised, so that every individual eTVD operator receives scan info about every other (relevant) ticket, regardless of whose validation equipment is used.

The passback rejection is due to what has been written to the ticket when it previously went though. The barriers retain basic details of the tickets seen but not ticket numbers as they are not encoded to the mag stripe (as far as I remember).

Yes, as you say, there is no ticket number encoded into the ticket magstripe.

As far as I understand, putting a ticket through a barrier should write the barrier location number to the ticket, as well as the time it was used, which is how passback is prevented.

It's why your magstripe ticket can get corrupted by a faulty barrier, if it fails to rewrite the ticket correctly, and is also why you can hear/see a ticket go back and forth inside some gates a few times if it fails to write this data on the first attempt.