How Park Graph Verifies Lot Operators

A parking platform is only as trustworthy as the operators on it. The most expensive form of fraud at unattended lots is not card theft — it is a fake "operator" listing a real-looking lot (often a property the fraudster does not own or manage) and collecting payments before the property owner notices. The defence is operator verification, run before any driver can pay, and re-run continuously.

The five-gate model below is the entire process. Each gate produces an artefact (a Stripe verification result, a photo, a county-record match, a micro-deposit confirmation, a fraud signal score) that is retained for the seven-year audit window described on /trust/security.

Most operator verification programmes stop at onboarding. Park Graph does not, because the most damaging fraud patterns show up after a clean onboarding — an operator with a clean identity who later cycles through payment-method abuse, or an operator whose chargeback rate quietly creeps up over weeks. Ongoing monitoring is the gate that catches that.

Watched signals include chargeback rate, refund rate, dispute pattern, IP and device fingerprint clusters across sessions (a single device paying for many sessions in many lots minutes apart is a signal), unusual pricing changes (a sudden jump just before a flagged refund pattern), and identity drift (the name on payouts no longer matching the verified identity). A signal that crosses threshold pauses the operator and holds payouts until human review clears it.

The badge means: identity verified by Stripe Identity, business verified, lot-ownership evidence on file, payout bank account ownership matched, and no fraud signal has crossed threshold in the last 30 days. It does not mean Park Graph guarantees the operator's prices are competitive, that the lot will always be available, or that the operator will respond to a refund request immediately. Those are operator decisions; the badge is about identity and authority.

A new operator does not display the badge during their first 30-day window. This is intentional — it would be misleading to slap "verified" on a brand-new operator before our monitoring has a chance to observe their session pattern.

Drivers can flag an operator from any receipt or public lot page. AI agents can flag via the structured-data API. Reports enter the same review backlog as automated fraud signals; they are weighted by source (a confirmed pattern from one driver plus a Stripe Radar signal beats five anonymous complaints alone, but five anonymous complaints in 24 hours is its own escalation).

For a driver who has paid and believes the operator is fraudulent, the fastest path is the bank dispute (Stripe will attach the standard evidence packet — see /trust/payment-security). The Park Graph trust team picks up the parallel trust review on the same incident.

A single onboarding check — for example, a business registration document or a Stripe identity verification — would catch the most obvious fraudulent operators but would miss the patterns we actually see. Operator-style fraud at parking platforms tends to look like one of three things: a legitimate business that lists a lot it does not control; a previously legitimate operator whose payment details have been hijacked by a third party; or a pattern of repeat micro-operators that share infrastructure (IP, device, banking) and chargeback patterns across new identities. A single onboarding check catches the first poorly and the second and third not at all.

The five-gate model attacks each pattern with a different control. Identity and bank verification (gates 1-2) catch the obvious case. Operating-rights confirmation (gate 3) — asking the operator to confirm in writing that they have the right to monetise the lots they list — catches the first pattern by putting the operator on the record. Sample lot validation (gate 4) catches stale or scraped listings by requiring a fresh photograph and a recent operator-side check. Ongoing monitoring (gate 5) is the only control that catches the second and third patterns; it watches for identity drift, banking changes, and chargeback clustering across operators that share infrastructure.

From the operator's perspective, the five-gate model adds about thirty minutes of onboarding work and a small amount of ongoing maintenance: confirm the listing on a 90- day cadence, respond to a flagged-signal email within five business days, and file a re-verification when the operating entity changes. In exchange, the operator gets a verified badge that signals to drivers and AI agents that the operator has cleared the gates, the protection of a fraud- monitoring layer that watches their session traffic, and access to the dispute defence package that uses the verified-identity record on file. The trade is intentionally weighted toward the operator's long-term interest, not their short-term convenience.

On disputes, the operator-verification record feeds directly into the chargeback evidence template. A dispute filed against a verified operator includes the verified identity, the verified banking record, the verified operating-rights confirmation, the original session record, and the audit- log entries for any agent-mediated payments. The same record is shared with the operator in their dashboard so they can see exactly what evidence Park Graph submits on their behalf. The same package is referenced by name in the dispute-handling section of the payment-security page so procurement reviewers reading the two pages side by side arrive at the same understanding of how disputes are run.