Apologies if i wasnt clear. When travelling, the passenger would effectively be paying a full adult fare. The Railcard would not be linked to the card itself, and RPIs would not see a Railcard discount, but a full adult fare.
The Railcard would be linked to the TfL account, and the discount is only applied after a journey is complete, if it is eligible for the discount. If its possible for the capping to be processed after the fact, surely the railcards could be as well?
I'm afraid I still don't see how this addresses the concern about the bearer's entitlement to use the Railcard. Remember, the Railcard is only valid for use by the person to whom it has been issued, and this is established in the present system by the revenue inspector checking that both the ticket and Railcard are presented together. How is this check performed - or replaced - in your proposal?
Given how ubiquitous mobile coverage is nowadays, these arguments don't really convince me anymore. We have 4G on the Jubilee, WiFi at most other tube stations - you could implement it with a bloom filter that gets refreshed at every point where there is coverage available - even if every person in the UK owned a railcard it'd still fit into 100MB.
Ubiquitous, but not universal and uninterrupted. And you can pretty much guarantee that the time its needed the most will be the time that it's not available.
I should add for the avoidance of doubt that the rationale I gave above is the one that has been given by TfL in the past. Personally I completely accept that it was reasonable at the time, but can agree now that its standing has been changed somewhat by advances in connectivity over time.
EDIT: I see @Mojo has expanded on the rationale in #25.
Nevertheless, as
@najaB notes, those advances haven't yet delivered uninterrupted connectivity so you'd have to implement the full-list-carried-on-device part of the proposal anyway. Technically I don't think that this is anywhere near the challenge now as it would have been even ten years ago, given that mobile devices have far more storage space and processing power now, but it still introduces security concerns in maintaining and distributing the Railcard-associated-card list. These might be easy to overcome, or they might not - I don't have experience sufficient to say.
Alternately, you don't keep the list on inspection devices and just accept that whenever an inspector's device cannot make live queries against the database passengers will be able to present discounted cards without being verified. I wouldn't want to hazard a guess as to the rate at which that would occur, but there is an argument that accepting a certain amount of 'leakage' is still cheaper than implementing the watertight solution.
Let's not forget as well that even registering the Railcard against a contactless card will need architecture that doesn't exist (AFAIK) yet - if it's done via TVMs as per the current Oyster process then it will require the TVMs be able to connect and write to the accounts database, as opposed to simply writing to the Oyster as they do now.
Simple fix: Require customers to wait 1 day before travelling for their Railcard discount to take effect.
You can refresh the bloom filter at least once a day, I refuse to believe a revenue inspector can be outside of mobile data coverage for an uninterrupted 24 hours.
And if I want to travel today?
This would also be a question of acceptable leakage. If you design the system to be at the watertight end of things, you'd simply say "too bad - the discount takes effect at 0430 on the day after it's added to the card" because that unquestionably gives time for the on-device list to be updated by the time RPIs are clocking-on the next morning. At the other end, you'd allow same-day travel on the grounds that the list will probably be updated much sooner than the next morning, and that even if it isn't the maximum window of opportunity for exploitation of an improperly-transferred discount will never exceed 24 hours.