Every promise the prototypes make, mapped to what must exist behind it — organised on the operational lifecycle: onboarding (a boat is not onboarded until it is payout-ready; identity and compliance checks are onboarding, not a separate function) → the transaction → platform & legal → ops → data.
A boat moves through two stages: registered (visible, config set) → payout-ready (all identity gates cleared, provider account verified, a test pay-in landed). No QR goes into a cabin before payout-ready.
Name, crew count, guidance on/off and text, fee variant, theme later.
A scanned code resolves to the right boat’s hosted flow. All prototype QRs still encode a placeholder — regenerate at deploy.
Joiners, leavers, rotation. A roster change re-triggers the payee gate for the new member.
The gates that make a boat payout-ready. All screening runs inside the provider’s licence, confirmed in writing (§3).
“Send to the crew” is money-moving authority. One boat, one authority; anti-rogue-registration controls.
Who is the account holder of record — captain, owning SPV, management company? Yacht ownership runs through offshore SPVs; since 2022 vessels themselves appear on EU/OFAC lists. Screen boats at registration and periodically. Decision D11 sets the scope of this gate.
At roster entry or claim time (model-dependent), with a re-screening cadence as ongoing state; blocked-payee handling defined before it happens.
A connected account can’t receive funds until the provider’s KYC/KYB clears — days, longer for offshore SPVs. The 15-minute onboarding creates a registered boat; payout-ready follows verification and a cleared test pay-in.
Registration KYC is not session auth. Login, session on a shared wheelhouse iPad, step-up confirmation on send above a threshold, device-loss recovery.
Pilot — same custody rule. Provider escrow exists before the first live tip, even concierge-moved. The manual-SEPA substitute lands in the provider-held account (per-tip virtual IBAN or cent-marked reference) — never in an Ormeria or captain account. Notifications fire captain-first, always.
Working assumptions to react to, not decisions: ledger in the boat’s operating currency, EUR default · guest pay-in currencies EUR / USD / GBP · no tip floor; single tips above ~€50k route through enhanced diligence rather than being capped. Open: account structure (D1) and the statement name the guest’s bank shows (D2).
Bank selection, app approval hand-off, status webhooks. Provider open — direct (TrueLayer / Tink / Yapily / Volt) or bundled via AAZZUR; EU/UK only, card/wire fallback for US-banked guests.
Many banks cap app-approved transfers at €10–25k/day — exactly the flagship ticket sizes. Needs limit intelligence at bank selection, graceful in-flow fallback, and a limit-failure screen that doesn’t exist yet.
Fee computed on top from the live rate card, 3DS/SCA, settling into the same provider account.
The guest can be the designated person; a €50k inbound from an opaque private-bank arrangement is what providers freeze. Needs a “payment under review” state with honest copy.
€10–50k single payments to a QR code; SAR path via the provider; enhanced diligence for very large tips.
“We’ll confirm when it reaches them” is undeliverable: the flow never asks for an email or phone. A minimal capture step with consent copy has to fit inside the two-minute rule (D6).
Defined states: initiated → funded → (under-review) → split-locked → sending → paid → landed; terminal: failed / expired / refunded; per-payee sub-states under sending. Double-tap protection and the guest-facing failure/retry screens the prototype deliberately lacks.
Two distinct FX events with different owners. Only the first is the revenue line.
A rate fixed at the beginning of each day, displayed to the guest as-is — no live quoting or quote-lock machinery; a daily rate-fix job drives every screen that day. Margin is a small bp commission inside the daily rate, positioned to read like a good FX card and well inside private-wealth-bank pricing. Preferred implementation: the provider’s guaranteed daily rate card with Ormeria’s bps on top — the provider carries the intraday move and Ormeria’s FX risk is genuinely nil. If the provider only passes spot, the daily spread must be sized to cover intraday drift: risk bounded and priced, not zero. The crew figure stays guaranteed — “the crew receives the full €12,000.”
Non-SEPA crew (Filipino, South African, Australian) means SWIFT lifting fees and 3–5 days. Needs a decided fee-bearing policy and corridor-specific timing promises, or the full-amount ethos silently breaks for the lowest-paid crew (D7). Two candidates sidestep SWIFT entirely — payroll routing and a stablecoin settlement rail (§2.4).
Card fee %, FX margin per currency pair, absorbed PIS cost; versioned, driving UI and revenue reporting.
CBPR2 (EU Reg. 2019/518) imposes disclosure duties vs ECB reference rates on Union-currency conversions; USD/GBP legs sit outside CBPR2 but under PSD2 transparency and fair-commercial-practice rules. Counsel defines the disclosure pattern per currency pair before any real cross-currency guest payment (D9).
Whether Ormeria may price FX margin at all under the provider’s agent/distributor model is part of the §3 perimeter question. The Phase 1 revenue line is not confirmed until that is.
Refund at the original all-in amount in the pay currency, Ormeria bears bounded drift; plus short / over / duplicate pay-in exception handling (correspondent fees shave wires).
See §2.0 — Ormeria never holds funds. The custody line on the bank sheet is a legal representation.
Share-over-total, quarter steps, deterministic largest-remainder rounding so rows always sum to the total (now also fixed in the prototype); per-tip snapshots so roster changes never rewrite history.
Send atomically snapshots the split, fires payouts and crew notifications, and writes an audit record.
Row-level authorization; no API, deep link or notification payload can leak the table or the total to crew.
Wrong split or missed crew member after money is in flight: a short revocation window, make-whole policy (never clawback from crew), audit link to the original snapshot.
One seam; the model decided by captain research implements behind it; the Phase 2 Ormeria account is just another target. Interlocks with D11.
IBAN validation, status tracking; 1–2 working days holds for SEPA, corridor-specific promises per the D7 policy elsewhere.
Route non-SEPA tips through the boat’s existing crew payroll — yacht payroll providers already solve corridors and payee KYC; one SEPA transfer from escrow replaces N SWIFT wires. To test before adopting: timing (monthly payroll cycle vs the 1–2-day promise), tax visibility (through payroll the tip reads like salary — withholding and social charges can shave it), privacy (payroll admin sees the split). Interlocks with payout model B and D11.
A MiCA-compliant USD stablecoin as the invisible rail behind non-SEPA payouts — fiat at both edges, stablecoin in the middle: minutes instead of 3–5 days, near-zero corridor cost, 24/7. Held by a licensed partner so “Ormeria never holds funds” survives; guest pay-in unaffected. Makes stablecoin support a provider-selection criterion (AAZZUR question + BaaS shortlist). Phase 2 option: a USD wallet + card as claim target — a real differentiator for nomadic, USD-denominated, thinly-banked crew; adds MiCA/CASP partner requirements and a “crypto”-word brand risk with captains and management companies.
Every payout re-checks the §1.2 crew KYC/sanctions state; blocked payees route to defined handling, never silent failure.
Feb 2027 core; verify against the real Aazzur/Equals surface.
Claim-link expiry, reminders, dormancy policy (escalate to captain → hold → agreed disposition), validated against e-money dormancy rules.
7 of 8 payouts clear, one bounces: per-payee sub-states, retries, returned funds, captain visibility, and an explicit rule for when the guest’s “it landed” fires.
Enforced in the pipeline: funds-landed → captain push → captain sends → crew push. No code path notifies crew first.
Authenticated claim links / app, device registration at roster time.
Payout-completion events aggregated per tip firing the guest message; the definition of “landed” depends on the payout model.
Compose surface, light content check, authorship rule still open (blueprint).
Captain’s per-tip choice (and the guest’s “From” signature) honored across every crew surface.
The captain push is a single point of failure (yachts at sea): per-message delivery tracking, channel fallback (push → SMS → email), reminder ladder, escalation for tips unsent after N days, and interim guest status so the promise never goes silent.
Ormeria-level — not per-boat, not per-tip.
TSP vs e-money agent/distributor status: presenting payment screens, instructing payouts and pricing FX margin must fit the provider’s model; agent registration takes weeks-to-months. Written provider confirmation before the pilot; counsel-confirmed analysis well before Feb 2027. Gates the FX revenue line.
The platform routes identifiable income to identified crew across member states; counsel memo before pilot payouts, records kept to satisfy reporting retroactively. The recipient-side consequence — digital tips are traceable income where cash was not — is an adoption risk, tracked in the interview probes, not solved here.
Guest data without an account relationship, crew financial data, attribution data; DPAs, retention, DSAR/erasure vs payment-record retention.
“Held by a regulated provider”, “the full €12,000”, “no fees”, “1–2 working days” are checkable representations; screen copy and operational reality must not drift apart.
Guest T&Cs at Pay, captain/vessel platform agreement (split authority, correction liability), crew payee terms at claim, PSD2-required checkout disclosures.
€120,000 is one keystroke from €12,000; fully refundable until “sent to the crew”, case-by-case after.
Disputes arrive after crew are paid out; reserve / settlement-delay policy decision (D8), evidence tooling.
Tip lifecycle view, search by the ORM-… reference, resend / retry / refund actions, role-based access, operator audit log.
Print pipeline per boat, reissue tied to token revocation (§1.1).
Stuck-payment and late-payout alerts, status dashboard, on-call runbook.
Provider sandbox in CI, a permanent flagged test vessel in production, and a live low-value rehearsal tip through every rail before each pilot boat goes live and after each significant deploy.
Event-sourced lifecycle on the §2.1 state machine, unique references issued in the launch format from the first pilot tip, denominated in the D3 base currency.
Provider balances vs ledger vs payouts vs fee/FX revenue; every cent classified — principal, card fee, FX margin, absorbed cost, absorbed drift. Daily and automated with break alerts by launch. This is what makes “the crew receives the full amount” checkable.
Verify the provider accepts external credits into escrow; per-tip virtual IBANs or cent-marked amounts where references can’t be trusted (interlocks with D1), plus an unmatched-funds queue.
Captain-entered label per tip; no broker integration required.
Scan → paid conversion, rail/currency mix, amounts vs guidance, limit-failure vs abandonment — the H1/H3 instrumentation and later the pricing feed.
What the list above cannot settle by itself.
Per-boat connected account (proposed) vs pooled escrow vs per-tip virtual IBANs — with the chosen provider.
What the guest’s bank statement shows; the legal recipient of the pay-in.
Proposed: EUR base; EUR/USD/GBP accepted; ~€50k enhanced-diligence threshold, no cap.
Beginning-of-day fixed rate, small bp commission. To close: confirm the provider’s guaranteed daily rate card; if spot-only, size the spread and set a re-fix rule.
Margin or pass-through-at-cost on non-EUR payout legs.
Where the email/phone step fits inside the two-minute rule.
Who bears corridor fees, what timing is promised. Payroll routing vs stablecoin rail (§2.4) — decide after captain research + provider answers.
Delay card-funded distributions, or absorb chargeback risk.
Counsel-led, per currency pair, before any real cross-currency payment.
What the captain and crew see when the guest tips in USD/GBP.
Interlocks with payout model A/B/C, sets the KYB scope, and shapes the whole payout design.