Guest identity vault for hotel groups that verifies IDs at check-in without leaving raw passports and selfie photos in vendor storage.

1. Hotels are now collecting breach-grade identity data during check-in, not just viewing an ID at the desk.
2. The exposed files spanned 2020 through May 2026, proving the storage problem is persistent and can silently accumulate over years of guest stays.
3. Selfie verification in the workflow raises the privacy and compliance stakes beyond legacy photocopying, which makes minimization a more urgent product requirement.
4. Vendor-side failures now force scope reviews and guest notification work, creating a direct budget trigger for hotel groups that want safer identity handling without reversing digital check-in.

Catalyst. Reqrea's exposed Tabiq bucket shows that outsourced digital check-in is now collecting passport scans, driver's licenses, and selfie photos for years at a time, making privacy-safe identity minimization an urgent hotel buying problem rather than a future nice-to-have.

Build a guest identity vault that sits between the hotel's booking or kiosk flow and the systems that record the stay. The product captures ID images and a live selfie once, runs document-quality and match checks, extracts only the fields the property needs, and returns a signed "verified guest" record to the PMS or check-in app. Raw images are stored under strict retention policies, encrypted, access-scoped, and deleted automatically when policy allows instead of being left in general vendor storage. The same control plane gives hotel operators audit logs, residency rules, and evidence for vendor reviews or incident response. The narrow first use case is replacing raw-image storage in outsourced digital check-in for one hotel group before the next security review or vendor renewal.

What's different. Generic identity-verification APIs are optimized for onboarding conversion or fraud scoring, not for hotel-grade retention policies, guest-stay auditability, and PMS-safe data minimization. This startup would own the hospitality control plane that decides what must be kept, where it may live, who can see it, and when it should disappear after verification. Over time, its moat comes from deep integrations into hotel operations systems, policy templates by property type and jurisdiction, and a growing dataset on how to reduce sensitive-image retention without hurting check-in completion.

Jobs to be done

flowchart LR
  Buyer[Hotel digital ops leader] --> Pain[Raw guest IDs live too long in vendor storage]
  Pain --> Product[Guest Identity Vault]
  Product --> Outcome[Verified stays with lower breach exposure]

Executive takeaways

• The Reqrea/Tabiq exposure shows outsourced hotel check-in vendors can quietly become multi-year archives of passports, licenses, and selfies, turning a routine arrival workflow into breach-grade risk.
• Hotels are unlikely to roll back digital arrival: 70% of travelers say they would skip the front desk, and Mews reports 30% of U.S. reservations already use kiosk check-in where it is offered.
• The market gap is not basic identity verification. It is policy-safe identity minimization: verifying once, passing only required fields and attestations into hotel systems, and proving deletion/access controls later.
• The most promising first buyers are multi-property hotel groups under staffing and audit pressure that already use digital check-in, kiosks, or pre-arrival registration and now need a safer control layer rather than a workflow rip-and-replace.

Market definition

A hospitality identity-control layer that runs document and selfie verification for pre-arrival or kiosk check-in, then sends only policy-approved guest fields and verification status into PMS or check-in systems while minimizing raw document retention.

Customer and buyer

Primary users are digital operations, IT, privacy, and front-office leaders at 20-200 property hotel groups using outsourced online or kiosk check-in. The buyer is typically the CIO, chief digital officer, or VP of hotel operations who owns guest-arrival tooling and vendor risk.

Buying triggers

• A security review, breach scare, or vendor renewal forces the hotel group to explain where passport scans and selfies live and how long they are retained. [1][4][5]
• Persistent front-desk staffing shortages make hotels keep self-service arrival even when compliance teams become uncomfortable with raw ID storage. [12][15]
• Traveler demand for skipping the desk means operators need a safer digital-arrival model, not a return to manual photocopying. [10][11][13]

Willingness to pay

Hotels already fund arrival automation because labor and revenue effects are tangible: Mews markets seven-month payback, cites double-digit labor-hour savings, and reports higher upsell conversion through self-check-in. That means a minimization layer can ride existing digital check-in and compliance budgets even though public list pricing remains sparse. [11][12][14][15]

Category dynamics

Growth signal 4.1% y/y travel & tourism GDP growth in 2025 (sector proxy)

Validation signals

• A live breach already proved hotel check-in vendors can expose massive archives of identity documents and selfies.
• Travelers are asking for self-service arrival instead of front-desk queues, so safer digital check-in is a live demand problem.
• Hotels remain operationally stretched, especially at the front desk, which makes automation-preserving controls easier to justify.
• Current vendors already capture passport images, selfies, legal forms, and payment details online, proving the workflow is active and budgeted.

Regulatory & technical constraints

• GDPR requires data minimization, storage limitation, and accountability for personal-data processing.
• Privacy by design/default means hotels and processors should collect only the data necessary for each purpose and limit storage/accessibility by default.
• Biometric data used to uniquely identify a guest is special-category data and needs both a lawful basis and a valid special-category condition.
• Japan requires passport presentation and photocopying for foreign guests without a domestic address, so any minimization product must support rules-based exceptions.
• Hospitality integrations must write back into PMS, payment, and kiosk workflows without breaking arrival speed or room-access issuance.

Competition is real but mostly misaligned to the wedge. Canary and Mews optimize guest journey and PMS efficiency. Chekin optimizes legal registration plus identity match. Agilysys optimizes integrated kiosk hardware and PMS workflows. Oracle dominates the system of record. None of the fetched incumbents publicly position themselves around zero-copy attestations, cross-vendor retention governance, or independent deletion evidence; they sell secure storage, operational speed, or broader guest-experience suites.

Why incumbents do not win by default

• Cloud PMS platforms. Oracle and similar PMS vendors already own the guest profile and workflow, but their incentive is to centralize more data in the PMS rather than strip raw ID artifacts down to attestations only.
• Guest journey suites. Canary wins on mobile check-in, messaging, and secure transactions, yet its public story is secure vendor-hosted workflows, not third-party-independent data minimization.
• Local compliance/check-in tools. Chekin is strong where guest reporting, biometrics, and smart-lock access must work together, but its public compliance model still assumes storing guest data and operating country-specific reporting rails.
• Kiosk and hardware-linked arrivals. Agilysys solves the arrival station itself with native PMS and key-dispensing integration, but that makes it a workflow endpoint rather than a neutral control layer that can govern multiple vendors.

Zero Copy Guest ID should launch as a hospitality identity-control layer for hotel groups that already use digital or kiosk check-in, not as a broad guest-experience suite or consumer identity wallet. The first customer is a 20-100 property hotel group whose digital operations and security teams need to keep self-service arrival live while reducing exposure from stored passport scans, driver's licenses, and selfie photos. Research supports the wedge: travelers want to skip the desk, hotels remain labor constrained, and the Reqrea/Tabiq breach shows outsourced check-in vendors can quietly become multi-year archives of breach-grade identity data. The product should verify guest identity, extract only policy-approved fields, write a signed attestation back to PMS and check-in systems, and enforce deletion or retention rules by jurisdiction rather than promise universal no-storage behavior. Go-to-market should be event-driven and founder-led, selling into audit, vendor-renewal, or breach-scare moments where the buyer already has budget pressure and cannot accept a workflow rip-and-replace. The initial proof point is one hotel group deployment across a small set of PMS and kiosk integrations that shows lower retained raw-image volume without hurting check-in completion. The company can build a real control-layer moat through hospitality-specific policy templates, deletion evidence, and cross-vendor integrations, but the market evidence still leaves open whether buyers want an independent vault or only a white-label vendor feature. The year-3 SOM in the research is only $1.4M for the initial wedge, so expansion into adjacent lodging workflows matters early if the first product works.

Problem

• Hotel groups now use outsourced digital and kiosk check-in flows that collect passports, driver's licenses, and selfies, turning arrival automation into long-lived storage of breach-grade identity data.
• Security, privacy, and operations teams often cannot prove where those raw files live, who accessed them, or whether retention matches jurisdictional requirements.

Solution

• Provide a guest identity vault that verifies documents and selfie match once, returns only signed verification status plus required structured fields to hotel systems, and keeps raw artifacts under explicit policy control.
• Start as a thin control layer that plugs into existing PMS, kiosk, and pre-arrival stacks, with configurable residency, deletion timers, audit logs, and manual fallback for jurisdictions or properties that still require exceptions.

Why we win

• The company is optimized for the real buyer pain in hospitality identity workflows: minimizing raw-image retention and proving policy compliance, not maximizing generic onboarding conversion.
• Hospitality-specific integrations, jurisdiction-aware retention templates, and cross-vendor deletion evidence create a more durable wedge than another secure-storage feature inside one check-in product.

Milestones

flowchart LR
  Wedge[Hotel-group audit wedge] --> MVP[Identity vault MVP]
  MVP --> Proof[Deletion and attestation proof]
  Proof --> Expansion[Multi-property and channel expansion]

Founding team

Experiment roadmap

Risk assessment

What must be true

• Hotel groups will fund an independent control layer instead of waiting for existing check-in vendors to add enough retention controls.
• A small set of PMS and kiosk integrations covers enough of the beachhead to win the first 6-12 groups without heavy custom work.
• Policy-based minimization and deletion evidence reduce buyer risk enough to survive procurement even when some jurisdictions still require exceptions.
• Pilot deployments can preserve or improve check-in completion while sharply reducing retained raw identity files.
• The company can expand beyond the initial hotel wedge before the modest starting market caps venture upside.

Open diligence questions

• Who owns budget when the pain appears: CIO, operations, privacy, or a check-in vendor already in the workflow?
• Which target jurisdictions truly require retained passport copies or biometric processing, and how often will those exceptions appear in the beachhead?
• Which PMS plus kiosk or pre-arrival stacks dominate 20-100 property hotel groups in the first target geographies?
• Would hotel groups rather buy an independent vault directly or demand the same capability through current arrival vendors?
• How much of the first contract is durable software spend versus one-time security remediation budget?

Model sanity

• Revenue engine. Base-case revenue is driven by turning two paid year-1 design partners into six production hotel groups by Q4Y2 and then expanding to eight groups at about $180K exit ACV by Q4Y3.
• Must go right. The model depends on audit- or renewal-driven pilots converting into annual software contracts within roughly six months so implementation work does not outrun recurring revenue.
• Model breaks if. The biggest cash-risk condition is slower production conversion plus heavier exception handling, because the downside case pushes the cash low point below zero before the next round.
• Next-round proof. The next financing case is strongest once the company shows six production hotel groups, standardized adapters, and expansion across roughly 120 served properties without gross-margin collapse.

Scenarios

Sensitivity

flowchart LR
  Triggers["Audit or renewal triggers"] --> Pilots["Paid pilots"]
  Pilots --> Production["Production hotel groups"]
  Production --> Properties["More properties and modules"]
  Properties --> Revenue["Platform + verified-stay revenue"]
  Revenue --> GrossProfit["Gross profit"]
  GrossProfit --> Cash["Cash / runway"]

Flags: The model assumes each landed hotel group expands from a 5-10 property pilot into roughly 12-15 production properties by Y3, which is necessary because the initial wedge market is only about $1.4M at year 3. · Revenue per FTE only reaches the SaaS benchmark on an exit-ARR basis, so earlier-than-planned hiring or bespoke integration work would make the company look services-heavy. · Base case still exits Y3 EBITDA-negative, so the company likely needs a next round unless production conversions accelerate or premium modules lift ARPU faster than modeled.

• Hospitality integration drag. Hotel groups may be slow to change guest check-in flows because PMS, kiosk, and vendor integrations are brittle and property-by-property. Mitigation: Start as a thin identity layer that plugs into existing check-in vendors and PMS systems without forcing a full workflow replacement.
• Retention-rule complexity. Some properties or jurisdictions may still require storing certain guest records, which can limit a simplistic delete-everything pitch. Mitigation: Build policy templates that separate required fields from raw images and support configurable retention by jurisdiction and property type.
• Channel squeeze from incumbents. Existing digital check-in vendors may add basic encryption or deletion features once hotel buyers raise the issue. Mitigation: Differentiate on zero-copy attestations, independent audit logs, and multi-vendor policy governance that hotels can use even when they switch front-end check-in tools.