TBBN.Merchant Platform docs
Securitydocs/legal-flags/open-legal-questions.md

Open Legal / Compliance Questions

These are deliberately not resolved by this scaffold. They require the founder and/or counsel, not an architectural decision. Nothing in this repo silently assumes an answer to these — treat this file as a blocking checklist before the referenced milestone.

1. Merchant-of-record exposure for seller boost payments — RESOLVED (removed)

TBBN charges individual consumers (sellers) directly via Stripe for listing boosts — this flow was removed entirely on 2026-07-02 (see docs/business/conflict-resolution-log.md item 14). services/boost-payment-service no longer exists. TBBN now has exactly one payment flow (merchant SaaS billing, business-to-business), so the merchant-of-record, consumer sales-tax nexus, consumer refund policy, and KYC/AML questions this item originally raised no longer apply — there is no flow in which TBBN charges an individual consumer for anything. Left in this document, marked resolved, rather than deleted, so the reasoning for the removal stays discoverable.

2. Cross-border seller identity federation and data protection

Identity federation deliberately links one person's data across otherwise-independent merchant businesses (services/seller-identity-service) — this is exactly the kind of cross-controller personal-data linking that GDPR Article 6 lawful-basis analysis, and potentially ePrivacy rules around OTP/SMS delivery, are built to scrutinize. Open questions:

  • What is TBBN's lawful basis for linking a seller's records across Merchant X and Merchant Y without a direct TBBN-seller relationship at the time of first verification (verification is merchant-initiated, not seller-initiated)?
  • When a federated seller's record spans an EU merchant and a non-EU merchant, whose jurisdiction's data-subject rights (access, erasure, portability) apply to the federated record as a whole?
  • Data residency: does EU seller data need to stay in an EU region regardless of where the matching merchant is hosted?
  • Required disclosures to sellers at the point a merchant submits their verification (are they told their data may be linked/shared with TBBN and potentially exposed to other merchants if they opt into global visibility)?

Blocking milestone: before onboarding any EU-based merchant, and before GLOBAL/BOTH listing visibility is enabled for any merchant with EU sellers.

3. TBBN Space — custody liability and money-transmitter exposure (Phase 23)

Per TBBN_Flow.docx §7.5, carried forward unresolved into the actual implementation (services/space-service):

  • Custody liability. If a Space host holds an item during a drop-off/pickup window and it's lost or damaged, who carries liability — the host, or TBBN? Needs Terms-of-Service language and possibly insurance guidance for hosts before this ships to real users.
  • Money-transmitter exposure — genuinely different from item 41 below. Unlike checkout-orchestration (where TBBN "never touches the funds," per that item), TBBN Space does hold a trader's payment between collection and payout to the host (SpaceBooking.status: PAID → CONFIRMED/COMPLETED, per §11's "holding it until the booking is confirmed"). This is TBBN acting as an intermediary holding third-party funds before disbursing them, minus a commission it sets — the exact shape money-transmitter licensing analysis exists to scrutinize (cf. how Stripe Connect's own platform-liability model and state money-transmitter exemptions are structured). Not analyzed here; flagged for counsel before Space accepts real payments.

Blocking milestone: before space-service is connected to a real Stripe Connect account (currently ConsoleStripeConnectAdapter, a dev simulation only) and before any real trader payment is collected.

4. Headless Sellers — accountability with no linked account (Phase 27)

A "headless" Seller (Seller.userId: null, gated by Merchant.headlessSellersAllowed) lets a Merchant complete a barter trade for a trade participant who has never created a TBBN account. Two open questions this genuinely introduces, not present when every Seller had a User:

  • Misrepresentation/dispute accountability. If a headless Seller's side of a trade is misrepresented (wrong condition, item swapped, no-show), there is no TBBN account to hold accountable, ban, or contact directly — the Merchant is the only party TBBN has a relationship with. Whether the Merchant's Terms of Service with TBBN makes the Merchant contractually responsible for its headless Sellers' conduct is a drafting question, not decided here.
  • Reputation/review integrity. reputation-service's Review model requires a real TradeSession/SpaceBooking a reviewer was party to, which still works normally for a headless Seller's counterparty — but a headless Seller itself can never accumulate a Seller.reputationScore-driving review history a future trading partner could check, since there's no account for that history to attach to across trades with different Merchants.

Not blocking (headless creation is opt-in, gated by tier, and the Merchant explicitly provisions it) but worth counsel review before this is marketed as a mainstream capability rather than an edge case.

5. Headless Space bookings — a client TBBN has never verified at all (Phase 32)

The Space API's headless booking path (SpaceBooking.bookedByBusinessId + externalClientRef, gated only by a Business holding a valid SpaceApiKey) lets a third-party business reserve a TBBN Space on behalf of a client TBBN has never seen in any form — not even the thin identity a headless Seller has via its Merchant relationship. Two questions this introduces:

  • Who is responsible for that client's conduct at the Space? If a headless-booked client damages a host's property or fails to show up, TBBN's only relationship is with the API-key- holding Business, not the client. Whether that Business's Terms of Service with TBBN (or its own terms with its client) allocates that liability is a drafting question, not decided here — and this is a strictly thinner identity chain than item 4's headless Seller, which at least routes through a real Merchant relationship.
  • Host consent to an unknown third-party booker. A host enabling Space today consents to bookings from TBBN Marketplace members; whether that consent extends to a booking arranged entirely through an API-key holder's own product (which the host may never interact with directly) is worth an explicit Terms-of-Service statement before this is marketed broadly.

Not blocking (headless booking is opt-in for the API-key-holding Business, and the underlying Space booking/payment/payout mechanics are unchanged) but worth counsel review before scale, same posture as item 4.

6. Free-space listing fee dispute liability (Phase 34)

A Business that lists a Space for free owes TBBN a flat listing fee (BusinessOneTimeCharge, currently PENDING-only — see docs/business/pricing.md's "Free-space listing fee" section). Two questions this introduces, not yet resolved:

  • Dispute liability. If a Business disputes the charge (e.g. a Space is deleted immediately after creation, or the Business contests the fee amount itself), what's the resolution path? No refund/waiver workflow exists yet beyond the schema's WAIVED status hook.
  • Fee-change retroactivity. Once admin.tbbnetwork.com (Phase 35) lets TBBN staff change PlatformFeeSchedule's amount, does a change apply only to Spaces created after the change, or could it retroactively affect an already-PENDING charge? Not decided — the current implementation always reads the schedule at charge-creation time, so a later schedule change never touches an existing charge, but this hasn't been confirmed as the intended policy.

Blocking milestone: before this fee is ever actually collected via a real Stripe charge.

7. Verified-email-domain spoofing risk for RESTRICTED_EMAIL Spaces (Phase 34)

A Space's RESTRICTED_EMAIL visibility (e.g. a university restricting a study room to @cornell.edu) trusts a marketplace member's User.email at face value — this repo has no email-domain-ownership verification step anywhere (registration accepts any email a user provides, verified only via the existing OTP flow, which proves inbox access, not institutional affiliation). A host restricting a Space to a domain has no guarantee every User registered with that domain is a real affiliate of that institution. Not blocking (this is a visibility/convenience feature, not a security boundary TBBN advertises as strong), but worth counsel/product review before marketing this as a real access-control guarantee to institutional hosts, same posture as items 4/5.

Non-blocking but worth counsel review before scale

  • Money-transmitter licensing analysis specifically for the checkout-orchestration flow (TBBN never holds funds, but does pass trade-amount figures and redirect flows between two merchants' checkouts — confirm this orchestration-only role doesn't itself trigger money-transmitter registration in any US state or equivalent elsewhere, even though TBBN never touches the funds).
  • Terms of service / liability allocation between TBBN and merchants for a trade that fails after one side has paid (e.g. PAYMENT_FAILED on side B after side A already completed CHECKOUT_A_COMPLETE) — the state machine models this cleanly technically, but the contractual remedy (who's responsible for making side A whole) is a legal drafting question, not an engineering one.