Case study

How a regional transit-rewards program runs on Veodyn

A dozen operators, one rewards program. Off-peak nudges, multimodal missions, and crowding relief, all running on a single normalized feed of every agency's data.

The setup

One region, a dozen transit operators. A county bus system, two municipal lines, a rail operator, a regional bikeshare. Riders cross all of them on a single trip without thinking about where one agency ends and the next begins.

The regional coalition wants to run one rewards program across the whole network. Reward riders for traveling off-peak. Reward them for finishing a bus trip on a bikeshare. Keep them on transit through a service disruption. One program, every agency, one rider experience.

The data problem

That program is hard to build today, and the reason is data, not the rewards idea.

Each operator publishes its own feeds in its own way. A dozen real-time endpoints, each with its own refresh rate, quirks, and gaps. Occupancy data, where it exists at all, stays inside each agency. Bikeshare availability sits in a separate system again. A rewards vendor that wants to run one regional program has to integrate every operator separately, normalize a dozen schemas by hand, and keep all of it working as the feeds change underneath it.

Most programs never get past a single-agency pilot. That is the ceiling almost every real-world rewards program has hit.

The Veodyn architecture

Veodyn federates the region. Each agency runs a node on its own infrastructure. The hub normalizes every node’s feeds into one consistent layer and exposes it through a single open API and an AI query surface. The rewards program calls one endpoint, not twelve. From that one layer it reads:

Schedules and stop geometry (GTFS) to define valid trips, peak windows, and check-in zones
Real-time vehicle positions and arrivals (GTFS-RT) to see what is running, and where, right now
Vehicle load (GTFS-RT occupancy) to see which trips are crowded and which have room
Shared-mobility availability (GBFS) to stitch bikeshare and scooters into multimodal trips

All of it normalized across every operator in the region. That normalized, real-time, multimodal context is exactly what the program could not assemble before.

What the program can do

Each rewards mechanic is powered by a feed Veodyn already federates.

The mechanic	What powers it
Crowding-relief nudge “this train is full, take the next one, earn points”	Real-time occupancy. The mechanic with the strongest evidence behind it.
Off-peak incentive “travel before 7:30 or after 9, earn more”	Schedule plus live load, so the reward windows move with real demand.
Multimodal mission “ride the bus, finish on a bikeshare, complete the chain”	Transit arrivals and live dock availability, together.
Trip corroboration confirm a claimed trip actually happened	Real-time positions and trip updates, so the program can verify a rider was on a route even when there is no fare tap.
Geofenced check-in “check in at any of these regional hubs this month”	Stop and station geometry.
Disruption-to-engagement “your line is delayed, here is a bonus to try the parallel route”	Service alerts and positions.
Proof it worked did peak load actually drop on the targeted lines?	Occupancy and ridership over time, through Veodyn’s analytics surface.

What comparable programs have measured

Incentive programs do not reliably manufacture brand-new riders, and any vendor who promises that is ahead of the evidence. What they reliably do is move existing demand off the peak, at a fraction of the cost of adding vehicles, and make crowded systems work better for the riders already on them.

In BART’s Perks program in the San Francisco Bay Area, the second phase shifted peak trips for roughly $1 per shifted trip, far less than the cost of adding the equivalent train capacity.
In Singapore, after the national Travel Smart program launched free off-peak rides and bus rebates, about 8 percent of one rail line’s morning-peak commuters moved out of the peak, the equivalent of two extra trains and twenty extra buses of capacity.
An earlier Singapore pilot, INSINC, shifted 7 to 11 percent of peak trips for roughly thirty Singapore cents per commuter per week.

These come from comparable real programs. Your region's numbers would be its own. What Veodyn makes possible is running this kind of program across your whole region at once, and measuring whether it actually worked.

Where Veodyn stops

Veodyn is the context layer, not the whole program.

The fare system still owns the tap that proves who rode. The rewards vendor still owns the points engine, the redemption, and the app. Veodyn owns the part that has blocked regional programs until now: one live, normalized view of every agency’s data, open for any rewards or fare vendor to build on. Your vendors keep doing what they do best. You stop paying to reintegrate the same dozen feeds for every new idea.

Why it outlasts a pilot

Because the data layer is open and federated, the program is not locked to one vendor or one agency. Add an operator, it joins the same normalized layer. Swap rewards vendors, the data stays put. That is the difference between a single-agency pilot that ends with the grant and a regional program that lasts.

See it on your network

Tell us which operators and feeds your region runs, and we will map the fit. Book a call.