Who else handles your data
Draft, published while still under review. It may change before launch. Written against docs/legal/data-inventory.md. Placeholders in [brackets] need your decision: the DPA status of each processor is something only the account holder can confirm, and the links have to be taken from the accounts you hold.
Last updated: [date] · Controller: [legal name and address] · Contact: [email]
The processors
Every company below handles some part of your data on our instructions. Nobody else does, and we do not sell your data or use it for advertising.
| Who | What they hold | Where | DPA status | Their terms |
|---|---|---|---|---|
| Neon | The whole database | London (eu-west-2), encrypted at rest | [signed / pending / standard terms accepted] | [url] |
| Fly.io | The running code, and debug page captures on a London volume | London (lhr) | [signed / pending / standard terms accepted] | [url] |
| Kernel | The browser that signs in to TfL, and its cookies, one profile per customer | UK egress | [signed / pending / standard terms accepted] | [url] |
| Resend | Email addresses and message contents | EU region | [signed / pending / standard terms accepted] | [url] |
| Stripe | Name, billing address and payment details | [region on the Stripe account] | [signed / pending / standard terms accepted] | [url] |
| Transport for London | The claim itself | UK | Not applicable: TfL receives the claim, it does not process data for us | [url] |
Transport for London is in the table because your data reaches it, not because it works for us. When we submit a claim, TfL is the recipient and decides for itself what to do with what it is sent. That is the point of the service.
What that means in practice
Neon holds everything the service knows: your email address, your card label, your journeys, our delay estimates, your claims and the audit trail. It is a London region and encrypted at rest.
Fly.io runs the code, and the debug page captures live on a volume attached to it. Those captures are copies of your own signed-in TfL pages, so they are treated as personal data and deleted after 30 days.
Kernel provides the cloud browser you sign in to TfL through, and keeps that browser's cookies in a profile of your own, separate from every other customer's, so the one sign-in you give holds for the whole check: the pages we read and any claim we file. It does not save you from signing in next time. TfL asks for a fresh sign-in and a new text code every time, and we cannot start a check without you. The profile holds a live TfL session while a check runs. Closing your account deletes it.
Resend sends the emails: the sign-in link, the message telling you a check is ready for your sign-in, and the results of a claim. It sees your email address and what we wrote to you. Its EU region is the only processing in this table outside the United Kingdom, and the safeguard for that transfer is [safeguard].
Stripe
The Stripe account went live on 18 September 2026.
The billing code is not built. There is no Checkout flow, no subscription and no webhook, nobody has been charged, and Stripe holds nothing for this service today. The row above describes what Stripe will hold once billing exists: your name, your billing address and your payment details.
Those never reach our servers. You would enter a card on Stripe's own page, and what comes back to us is whether the subscription is paid, not the card.
Changing this list
If we add a processor, or move one, we will tell you by email before it starts handling your data.