Article
city compliance
MDS
GBFS

Staying Compliant: MDS, GBFS, and City Reporting

The data-compliance layer for shared fleets: what MDS 2.0 and GBFS 3.0 are, what cities require, how real-time speed and zone enforcement works, and how Levy's included feeds and city policy ingestion keep your permit in good standing.

Levy FleetsJuly 1, 202612 min read

Your operating permit is the single most valuable asset in your fleet, and it lives or dies on data. A modern micromobility permit does not just ask you to run safe vehicles. It requires you to publish two standardized data feeds, ingest the city's rules, and prove that your vehicles actually obey them. Miss a feed, fail a conformance check, or let a vehicle rip through a slow zone at full throttle, and you risk fines, fleet-cap cuts, or losing the permit entirely. This lesson breaks down the two standards every city asks for, MDS 2.0 and GBFS 3.0, what regulators actually check, how real-time speed and zone enforcement works, and how Levy's included city-compliance tooling keeps you in good standing across whatever hardware you run.

The good news for your unit economics: city-compliance tooling is part of Levy's included platform core. On the same $0-upfront, revenue-share model (20% of GMV, 15% at 100 to 249 active vehicles on qualifying annual terms, with a $250 per month platform minimum credited against fees), the MDS 2.0 feeds, GBFS 3.0 feed, city policy ingestion, and real-time enforcement come with no separate compliance line item. Before you launch, pair this lesson with scooter rental permits and regulations.

Operational guidance, not legal advice

Permit terms, data-reporting obligations, and enforcement rules vary by city and change often. Treat this lesson as a working overview, not legal or regulatory advice. Confirm the exact requirements in your permit with the issuing agency, and consult qualified legal counsel before you rely on any compliance interpretation.

Why city data compliance is now table stakes

Ten years ago a city asked for a quarterly PDF. Today roughly every major micromobility market runs a data-driven permit program, and the permit is conditional on machine-readable compliance. Cities use that data to enforce fleet caps, verify distribution across neighborhoods, audit parking, and confirm your vehicles respect the slow zones and no-ride zones they publish.

Two open standards do almost all of this work:

  • MDS (Mobility Data Specification), governed by the Open Mobility Foundation, is the regulator-facing standard: how a city pulls detailed operational data from you and how you pull the city's rules.
  • GBFS (General Bikeshare Feed Specification), governed by MobilityData, is the public-facing standard: how availability, pricing, and zones reach trip-planning apps and, in many cities, the regulator's dashboard.

If your permit names any of these, it means these systems, so build them into your launch checklist before you apply, not after you are cited.

MDS 2.0: the regulator's feed

MDS is the granular, authenticated data channel between you and the agency. It is not public: the data is sensitive because it can include trip-level and telemetry-level detail. MDS 2.0 is the current major version, split into distinct APIs, two of which matter most to you.

Provider API: the data you push out

The Provider API is the operator-side feed a city pulls from. It exposes your fleet's operational reality for audit: current vehicles and status, trip records, ride events (start, end, reservation, service changes), telemetry, defined stops and corrals, and periodic reports. Cities poll these endpoints on their own schedule, so the feed has to be live, accurate, and authenticated.

Authentication is where operators most often stumble. MDS Provider endpoints are cryptographically signed, and the city verifies your feed against a published key set (JWKS, a JSON Web Key Set). If your signing keys rotate and your JWKS URL falls out of sync, the validator rejects your feed and you look non-compliant even though your data is perfect. Levy publishes and manages the JWKS for you, so key rotation does not break the pull.

Policy API: the rules you ingest

MDS also runs the other direction. Through the Policy feed, the city publishes the rules you must obey: geofenced speed zones, no-ride and no-parking areas, vehicle caps, distribution requirements, and time-bound restrictions (like an event-day exclusion zone). Your job is to ingest that feed continuously, materialize the zones, and enforce them on the street, reflecting each edit fast.

Levy's city policy ingestion polls each jurisdiction's published feed on a recurring cadence (configurable, confirm the exact interval in your setup), validates every change, and stages new rules for activation, so a policy the city publishes in the morning flows through to your fleet automatically, not on your next manual sync.

GBFS 3.0: the public feed

GBFS is the opposite of MDS in almost every way, and confusing the two is a classic operator mistake. It is public, unauthenticated, and privacy-safe: no rider identity, no trip-level detail. Instead it publishes the real-time state a rider or trip planner needs: where your available vehicles are, their battery or range, your system regions, pricing plans, and geofencing zones. It is what puts your scooters on the map inside third-party apps and gives many cities a live view of your fleet.

GBFS 3.0 is the current major version. A conformant deployment publishes a manifest pointing to the feed files, plus system regions, per-vehicle status, and a geofencing-zones file that tags each zone rule with the vehicle types it covers. Because it is the public, always-on feed, cities and app partners treat it as the fast availability layer, while MDS is the deep audit layer.

Levy publishes a GBFS 3.0 feed for your fleet, so you satisfy both the regulator's requirement and the trip-planner integrations that drive discovery.

Do not confuse GBFS with MDS

GBFS is public and privacy-safe: availability, pricing, and zones, no rider data. MDS is authenticated and sensitive: it can include trip and telemetry detail and is for authorized regulators only. Never expose MDS on a public URL, and never assume a GBFS feed satisfies an MDS Provider requirement. A permit that asks for both wants both, for different reasons. Levy keeps the two feeds separate and correctly scoped.

What cities actually require in a permit

Requirements vary by market, but the pattern is consistent. Expect your permit to demand some combination of the following:

RequirementWhat it means for you
MDS 2.0 Provider conformanceA live, authenticated Provider feed the city can pull, validated against your published keys.
GBFS feedA public, real-time feed of availability, zones, and pricing for trip planners and the city.
Real-time policy enforcementProof that vehicles obey speed and no-ride zones from the city's Policy feed in real time, not on a nightly batch.
Fleet caps and distributionA ceiling on deployed vehicles and, often, minimum coverage in equity or transit-priority areas.
Parking complianceEvidence that riders end trips in permitted areas, frequently backed by end-of-ride parking photos.
Periodic reportingScheduled compliance reports to a city contact, plus on-demand access to your data.
MDS and GBFS city-reporting compliance view
Included MDS and GBFS feeds keep your permit in good standing across every requirement.

The through-line: everything must be demonstrable and automated. A city no longer wants your word that a scooter slowed in a slow zone; it wants the enforcement event in the data. Reporting and enforcement are two halves of one job.

Real-time speed and zone enforcement

This is what separates a permit application from a permit renewal. Publishing feeds proves you can share data. Real-time enforcement proves you can act on it. When a city Policy rule activates, every vehicle inside that geometry must adjust, and a slow zone is the canonical example: a scooter entering an 8 mph slow zone (a common cap, roughly 13 km/h) should have its top speed capped in real time.

Levy materializes the city's policy geofences from the ingested feed, then dispatches a speed-limit command to each affected vehicle through its IoT module the moment the rule is in force. Because Levy is hardware-agnostic across 30+ IoT vendors, one city rule becomes the correct per-vehicle command for whatever mix you run, so scooters from several manufacturers all obey the same zone with no firmware work on your side. Enforcement keys off a fresh GPS fix, not a stale one, so it does not cap a vehicle that has already left a zone or miss one that just entered.

Sidewalk riding is a related demand in many permits, and Levy Vision's sidewalk detection adds a throttle-cut layer that discourages riding where it is prohibited, catching behavior a geofence alone cannot see. It is a parking, helmet, and sidewalk compliance capability that works alongside MDS policy enforcement, not a replacement for it.

Sidewalk-riding hotspot map
Detect sidewalk-riding hotspots and cut throttle in geofenced zones.

Stacked geofences: the strictest rule wins

Your map is not a single layer. You have your own operator zones (service area, parking, no-go, slow, ride zones), and on top of them sit the city's policy zones. When they overlap, there has to be a deterministic answer. Levy resolves it with stacked-geofence priority: zones are ranked so that at any point the strictest applicable rule wins, and city policy geofences outrank the zones you draw by hand.

The payoff is that you cannot accidentally undercut a city rule with a looser operator zone. If the city drops a 0 mph no-ride zone over a plaza where you had a ride zone, the city rule wins automatically, and the dashboard surfaces the conflict so you see which of your zones is overridden. That audit trail is itself compliance evidence: it shows the city its rules are the ones enforced.

How Levy keeps you compliant

The onboarding flow takes you from an approved permit to live, enforced compliance. For the full technical walkthrough, see Levy's MDS and GBFS city-compliance documentation.

1

Hand the city your endpoints during the application

When you apply, hand the city your MDS Provider endpoint URLs, JWKS key URL, and GBFS 3.0 feed root. Levy generates and hosts all three, so your application shows conformance from day one.

2

Configure the jurisdiction once approved

In the dashboard's compliance section, add the jurisdiction and paste the city's published Policy feed URL. That link turns the city's rules into your enforced zones.

3

Let policy ingestion materialize the geofences

Levy polls the Policy feed, validates each change, and materializes the geofences on an ongoing basis. New or edited rules flow in continuously, with no manual sync.

4

Confirm real-time enforcement is live

You enable speed and no-ride enforcement. Verify that vehicles entering a slow or no-ride zone get the correct command, and check the conflict banner for any operator zone the city now overrides.

5

Turn on reporting to the city contact

Add the city's contact, and share the city-portal magic link so the agency can view its own live data. Any scheduled digest cadence is implementation-specific, so confirm what your setup supports.

Reporting and staying in good standing

Enforcement keeps you legal in the moment. Reporting keeps your permit renewable. The reporting layer has two parts.

First, the automated feeds do the heavy lifting: your MDS Provider feed gives the city deep, authenticated access, and your GBFS feed a live public view. Second, Levy adds a city-facing surface: each city contact gets a magic-link login to a portal bounded to that jurisdiction's geometry, seeing only the fleet, trips, and corrals inside their boundary. Any scheduled digest cadence on top of that is implementation-specific, so confirm what your setup supports. No spreadsheet assembly on your side.

Parking compliance folds in too: Levy Vision's end-of-ride parking check can be exported to cities through MDS, so a complaint about a blocking scooter is answered from the data.

Audit yourself before the city does

Treat the compliance dashboard as your pre-audit. After any policy change, check the enforcement events, watch the conflict banner for operator zones shadowed by city rules, and confirm the city contact still has working access to their portal. Catching a broken JWKS URL or a stale policy yourself is a quick fix. Catching it because the city flagged it is a permit conversation.

By vehicle type: what changes

The standards apply across shared micromobility, but the specifics shift by form factor. GBFS 3.0 tags each zone rule with the vehicle types it covers, so you can enforce different rules for scooters and bikes on the same map.

Kick scooters carry the heaviest compliance burden, since most permit programs were written around them. Expect full MDS Provider and GBFS requirements, tight slow-zone and no-ride enforcement, and close scrutiny of sidewalk riding and parking. Speed caps are the most common enforcement action, so real-time zone-based speed limiting is non-negotiable, and end-of-ride parking photos are frequently required.

Frequently asked questions

Put it into practice

Compliance is not paperwork you do once. It is a live system: publish accurate feeds, ingest the city's rules continuously, enforce speed and zones on the street in real time, and report the proof back automatically. Get that loop running before you apply and permit renewals stop being a scramble. Because Levy provides the MDS and GBFS feeds, the city policy ingestion, and the real-time enforcement as included tooling across your whole hardware mix, the compliance layer is something you configure once and monitor, not a project you rebuild for every market. Want to see how it maps to your city and permit? Book a demo and we will walk your feeds, your policy ingestion, and a setup built to keep your permit in good standing.

Ready to put this into practice?

Model your fleet economics in two minutes, or talk to our team about launching your own branded fleet with zero upfront software cost.