New York City Platform Verification Under Local Law 18

Under Local Law 18, platforms in New York City act as gatekeepers for covered short-term listings: they must verify OSE registration and must not process unregistered short-term transactions in the covered category. For hosts, that gatekeeping appears as a registration field at listing creation, a verification wait, and a listing that does not go live, or goes dark, when verification fails. Understanding platforms as gatekeepers, rather than as neutral advertising boards, helps hosts respond correctly to holds.

Gatekeeping also means platforms have their own compliance incentive. A platform that processes unregistered transactions risks its own enforcement exposure, so it will err toward blocking uncertain listings. Hosts who view a block as a platform error to be argued away will wait longer than hosts who view it as a registration signal to be fixed. The fastest path through a block is almost always a registration fix.

Verification checks that the registration details supplied for a listing match an OSE registration for that unit. That includes the registration identifier, the unit address and, where applicable, host details. A mismatch in any element can fail verification, even if the host is registered for a different unit or under slightly different details. Hosts should compare listing and OSE record element by element, rather than assuming that being registered somewhere is enough.

Verification does not check everything. A verified listing is not proof of building permission, lease permission, safety compliance or genuine presence. Platforms verify registration; hosts remain responsible for the other layers. A host who treats a verified badge as general approval will miss building or presence problems that OSE or a building body may later raise.

The most common failure is no registration: the host has not completed OSE registration, or has registered a different unit. Next is a data mismatch: address format, unit identifier or host name differs between listing and OSE record. Next is an expired or revoked registration still shown on a live listing. Finally, a platform may check the wrong category, for example treating a longer stay as a covered short stay, though hosts should not assume that explanation without checking their own record first.

Diagnose in that order: registration existence, unit match, detail match, validity. Each step has a different fix, and skipping to platform support without diagnosing wastes time. Keep the OSE confirmation as the source document for every comparison, and update listings from it, not from memory.

To fix a hold, correct the listing from the OSE record, resubmit for verification, and check public display after reinstatement. Do not create a duplicate listing for the same unit with altered details to bypass the hold. Duplicates are often matched by address or photographs, and a bypass attempt can lead to account action and a worse enforcement picture. If a hold persists after a correct resubmission, contact platform support with the OSE confirmation details and the listing identifier, and keep that correspondence.

While a listing is held, do not take covered short bookings through direct channels that bypass platform verification, unless a lawful non-covered category clearly applies. Bypassing a hold to preserve income turns an administrative delay into a potential enforcement matter. Pause covered bookings for that unit until verification passes, however unwelcome that pause may be.

A host with the same unit on several platforms must pass verification on each platform separately. Verification on one platform does not carry over to another, and a listing that is verified on one site may still be held on another due to a detail difference. Audit verification status per platform, per unit, monthly, and after every listing edit, since edits can break verification by changing a verified field.

Direct bookings need a parallel check. A direct listing does not go through platform verification, but it still requires OSE registration for covered stays, and it still needs accurate registration display where required. Hosts should not treat direct bookings as a verification-free route for covered stays. The registration duty applies regardless of channel.

Keep a verification file per unit: OSE confirmation, listing views showing verification status, platform messages about holds or reinstatements, and dates for each. That file resolves most disputes quickly, since it shows what was registered, what was listed, and when each changed. If a verification dispute involves OSE itself, the same file supports a query to OSE with documents rather than assertions.

Verify current platform verification steps on nyc.gov OSE pages and platform help pages, treating platform pages as operational guidance. This guide is general information only, last verified on 26 October 2026.