Privacy Policy

This Policy explains how personal information is used across Malaka — the marketplace where travellers discover and book curated sailing holidays, and where people who already have a yacht can find a skipper. It is written to be read in layers: a plain-language summary in each area, then the detail beneath it.

Malaka is a single platform used in different contexts. The same account can be a Traveller browsing the marketplace, a Crew member on a Trip, the Booking Owner who paid, a Group Leader coordinating others, or a Skipper offering a professional service. What information is used, and who can see it, depends on the context you are acting in — not on a fixed, one-size-fits-all profile.

The entity responsible for personal information processed through Malaka, and how to reach it, are set out below. These details are structured and ready for the approved information to be inserted.

Depending on how you use Malaka, information from the categories below may be processed when it is relevant to the feature you use. Malaka does not collect every possible field for everyone at all times — this is a map of what can be involved, not a checklist of what is always held.

Your account and profile hold global information — the parts of your identity that stay the same across every Booking and Trip. Depending on what you provide, this may include:

• name and email;
• country and language;
• phone number, where supplied;
• profile image;
• travel preferences;
• account and security metadata (for example, sign-in and security events).

Travel preferences

Preferences may include destinations, sailing style, booking-mode preferences, self-declared sailing experience and preferred months. Where that product functionality is active, preferences can support personalisation and discovery — helping surface relevant trips. This does not describe any profiling algorithm or scoring.

A Booking records the commercial arrangement; a Trip (the Holiday Hub) records the operational reality of sailing. They are related but distinct, and they carry different information.

Booking data

Depending on the booking, this may include the Booking reference, booking mode, booked dates, the Booking Owner, any Group Leader role, party size, the selected Experience or Departure or an accepted skipper Offer, recorded commercial terms, and payment status. Booking records do not hold raw card data.

Trip data

A Trip may involve Trip dates, the skipper, the Boat, route or meeting point, the Crew roster, readiness, operational communications and checklist status. Not every participant sees all Trip data — access follows role and operational need, as described in the sections that follow.

Trip-specific traveller information for a Crew member may include, only when genuinely needed for the Trip, legal/travel name, nationality, date of birth where truly required, travel document information, an emergency contact, travel logistics, dietary or practical preferences, accessibility or practical needs, and any required documents — depending on the Trip and operational requirement.

Accessibility and practical needs are treated as sensitive and private: Malaka should collect only the practical information needed to support the relevant Trip or request. An emergency contact is Trip-specific and private — it is not a public profile field, and access is restricted to operational need.

Other Crew members do not see another traveller's sensitive data. Sharing a Departure does not mean sharing personal-data access.

A Skipper's professional information falls into two clearly separated layers: a public professional profile and restricted professional evidence.

Malaka may use an identity-verification workflow or service. Documents move through a set of canonical statuses so that everyone involved sees a consistent review state:

Uploaded does not mean Verified. Verification records a platform review state; it does not itself guarantee universal legal validity.

Payment handling is kept separate from the rest of your data. Malaka may process the payment-related metadata needed to operate Bookings and payments; the actual payment instrument may be handled by a third-party payment provider.

What payment information is shown

Account and public interfaces should generally show amount, currency, status, a masked method and a transaction reference. Full card number (PAN) and CVV are never displayed.

Skipper payout data

Professional payout information is private. Bank or payout details are not exposed to travellers.

Messaging on Malaka is contextual. Different conversations exist for different purposes, and their privacy boundaries matter:

• the Trip Group — operational coordination for a Trip;
• a private Booking / commercial thread;
• Skipper Request and Offer conversations;
• direct skipper messages;
• Support conversations.

Competing skippers responding to a Skipper Request should not see one another's Offers, prices, conditions or private conversations. Any Admin access to these is permissioned.

Reviews can involve public reviews, private feedback, a skipper's public response, and moderation metadata. Private feedback is not public. This prototype does not claim reviews are anonymous unless that behaviour is actually defined. Related guidance lives in the Community & Review Guidelines (Page 102).

Support may access the information needed to understand the issue you raise. Support does not automatically gain unrestricted access to raw identity documents, financial credentials or Trust & Safety narratives.

Trust & Safety information is more restricted. It may include reports or allegations, linked operational records, case status, restricted evidence and internal review notes. Malaka does not disclose sensitive investigation practices here.

Operating a platform involves some technical information. Potential categories include device and browser information, IP or network information, authentication and security events, product usage events, and diagnostics.

Cookies and similar technologies are covered separately, so the detail lives in one place rather than being duplicated here.

See the Cookie Policy (Page 99) for information about cookies and similar technologies. No vendor list is reproduced here.

Information is used for defined product purposes. These describe what the information is for; the legal basis for each is handled separately in the next section.

• create and manage your account;
• provide marketplace discovery;
• create and manage Bookings;
• operate Trips;
• manage Crew;
• facilitate Skipper Requests and Offers;
• process payments;
• verify professional information;
• provide support;
• maintain platform safety and integrity;
• communicate operational updates;
• improve the product where legally permitted.

Operational Booking and Trip communications are distinct from marketing. Any marketing communications — channels, lawful basis and opt-out — are [To be provided].

The legal basis for each processing purpose must be mapped and approved before publication. The table below is the structure ready for that analysis — the bases themselves are not decided here.

Information may be shared with categories of recipients where operationally or legally necessary. These are categories, not confirmed relationships or named companies:

• other Trip participants, where operationally necessary;
• the skipper on a Trip;
• payment service providers;
• an identity-verification provider;
• a communications provider;
• hosting / infrastructure providers;
• an analytics provider;
• professional advisers;
• authorities, where legally required.

Where personal information is transferred across borders, the locations and the safeguards that apply must be set out here.

Different categories of information may need to be kept for different periods once retention is legally defined. The framework below is ready for those approved periods:

Replacing a document does not necessarily delete historical verified documents instantly; document version-history and retention rules are [To be provided].

Malaka is designed to apply appropriate technical and organisational safeguards to personal information. As a matter of product design, sensitive data should be available only according to role, context and permission — for example, a Group Leader sees readiness rather than document values, Support access is narrower than Trust & Safety access, and Admin document metadata is separate from secure file access.

Rights available to you depend on applicable law. Depending on your jurisdiction, the following rights may apply:

• access;
• correction;
• deletion;
• restriction;
• objection;
• portability;
• withdrawal of consent, where applicable;
• complaint to a supervisory authority.

Account deletion

A deletion request is not necessarily immediate account erasure. Active or upcoming Bookings, Trips, legal obligations, security or dispute needs may affect how a request is handled, depending on applicable rules. Final wording and any retention exceptions are [To be approved]. Requests do not carry a promised completion deadline in this prototype.

This prototype does not claim that Malaka does or does not carry out legally significant automated decision-making. It does not describe any traveller score, skipper quality score, risk score or behavioural profiling.

The contact points for privacy matters are set out below, ready for the approved details.

This Policy sits alongside Malaka's other public policies. See the full set at the foot of the page, or jump to a related policy below.

A single visual view of the journey — from a traveller, through a Booking, into a Trip — and how the sensitivity of information changes at each step.

This is a product-level illustration of how access is designed to work — not a technical architecture claim.

An at-a-glance view of how visibility changes by role. This is a product-level illustration — it simplifies real access rules and does not define legal entitlements.

A concrete example makes the boundaries clearer. The document below uses synthetic sample data only.

In shared Departures, individual berth or cabin Bookings can place unrelated parties on one Departure or Trip. One party's commercial terms, payment, sensitive documents and private Booking messages are not exposed to another unrelated party.