The problem with ride history
A taxi or ride-hailing operator today retains, often for years, a complete record of who you are and where you went. Location history is among the most sensitive data there is — it reveals home, workplace, medical appointments, and personal associations — and concentrating it inside operators has already been abused: Uber's internal "God View" tool, which displayed riders' real-time locations to staff, ended in a settlement with the New York Attorney General.
A ride under Databanking
Booking a ride generates a token. The operator passes it to the driver, and it materialises into a pair of addresses on the dashboard. Once the ride is completed and paid, the addresses are deleted; the full ride record is written to your Databank, and the operator keeps only the date, the fare, and a link token. The driver necessarily sees pickup and destination during the ride — the protection here is that nothing address-shaped remains afterwards, with anyone.
One-bit questions
The link token preserves the legitimate uses of the deleted data. An auditor can ask "did this ride take place?". The operator, with your standing authorisation, can ask "did this rider travel from A to B in the last two weeks?" — and offer a discounted return ride to the airport. Both questions get a yes or a no from your Databank, never your ride history.
What about record-keeping rules?
Some jurisdictions require the opposite of deletion: Transport for London requires private hire operators to keep booking records for twelve months. The link-token arrangement can satisfy the audit purpose such rules serve — each retained record remains verifiable against the rider's Databank — while the record itself stops being a location dossier.
Tokens that expire
Booking tokens and link tokens need not be valid forever: an expiration date can be encoded into the token itself, so that neither the token nor the link it establishes outlives its purpose.