01 · The Question First

One customer, one key.

Are these duplicate customer records? No — and they can't drift into becoming duplicates. EEI identity mints eei_user_id and remains the system of record. When a customer first hits the Exchange, SSO carries that ID over as the OIDC subject and Sharetribe provisions its marketplace user around our key — a projection of our record, not a second customer. Stripe stamps the same ID into account metadata; the wallet ledger and gallery already key on it. Email is display data everywhere except EEI — it's never the join key, so an email change can't split a customer in two.

What our servers never see

No passwords (SSO means Sharetribe never stores one, and the Exchange front end never handles one) · no card numbers (Stripe's PCI vault, entered in Stripe-hosted fields) · no KYC documents or SSNs (Stripe Identity handles verification and 1099-K filing). The highest-risk data in this business never touches infrastructure we operate.

How Verification Works · 60 Seconds, Zero Documents On Our Side

User snaps ID + selfie

Stripe-hosted flow — never an EEI form

Stripe validates & stores

Doc authenticity + biometric liveness (consent in-flow); images stored at Stripe, redactable via API

EEI receives the result only

verified / failed + extracted fields — zero document images cross the line

02 · What's Stored Where

Every system, its data, its key.

System	Holds	Deliberately never holds	Keyed by
EEI Identity (existing)	Master customer record: email, name, credentials, saved addresses; issues SSO tokens	Card data, KYC docs	eei_user_id (PK — minted here)
EEI Wallet Ledger (new, ours)	Store-credit balances as append-only double-entry rows, two-phase holds, statements	Any PII beyond the key — it's numbers and hashes	eei_user_id
EEI Garage (existing — shared w/ FI & CO)	Saved vehicles + current-ride flag; drives fitment filters on every property; purchases stamp which vehicle they fit	—	eei_user_id + vehicle_id
EEI Gallery (existing)	Builds, photos, vehicle specs — plus the new listing back-link	—	build_id · eei_user_id · exchange_listing_id
Fitment engine + VCDB (shared service)	Vehicle-config database (vehicles, chassis, part fitment data) + spec envelopes — every Exchange listing carries a VCDB match key; no-match listings queue for spec-team addition	Customer data of any kind — stateless	n/a
Sharetribe (SaaS)	Marketplace profile (display name + mirrored email), listings & specs, transactions, offers, messages, reviews, per-order ship-to address	Passwords (SSO), card numbers, our wallet balances	st_user_uuid, with sub = eei_user_id
Stripe (under Sharetribe)	Card vault (PCI), Connect seller accounts, KYC identity docs, SSN last-4, 1099-K filings, payout history. Identity flow is Stripe-hosted: user photographs their license + selfie in Stripe's own UI; Stripe validates the document, biometric-matches the selfie (liveness-checked, consent collected in-flow), stores the images, and returns us only a verified/failed result + extracted fields — redactable via API on request	— (this is the vault)	acct_id + metadata.eei_user_id
EEI warehouse (existing BI)	Nightly Integration-API event export: listings, transactions, GMV, wallet entries — joined views for the founders' dashboards	Raw card or KYC data — those never leave their vaults	eei_user_id (the join column)

03 · Record Lifecycle

Born, synced, and deletable.

Create

Provisioned on first SSO login

No import jobs, no batch sync. The first time an FI/CO customer taps into the Exchange, SSO hands Sharetribe the sub = eei_user_id claim and the marketplace user is created around it. Existing retail customers are Exchange members the moment they arrive.

Update

Changes flow one way: EEI → out

Email or name changes land in EEI identity and propagate via fresh SSO claims plus an Integration-API touch-up. Nothing edits customer identity from the marketplace side — the master record can't be forked.

Addresses

Saved vs. shipped

Saved addresses stay in EEI identity. Each order carries its own ship-to snapshot on the Sharetribe transaction — the historical record of where that order went, immune to later address edits.

Delete

One CCPA runbook, full cascade

A deletion request fans out from the master record: Sharetribe user anonymized via Integration API, Stripe handled under its own regulated retention, wallet ledger retained as required financial record with PII detached. One customer key makes the cascade auditable.

For the founders' dashboards

Every event Sharetribe emits (new listing, offer, sale, review) exports nightly into the EEI warehouse alongside wallet entries and retail orders — all joined on eei_user_id. Day one, you can answer: which retail customers also sell used, what share of Exchange credit converts to retail GMV, and lifetime value across the whole family.

Field names illustrative; exact schemas land in the build spec. PII handling as described is the design contract: passwords and payment data never on EEI-operated marketplace infrastructure.