This larger tablet screen size is not currently supported. Please use VSL on mobile, desktop, or iPad mini.
A detailed map of the information VSL receives from users and connected providers, generates while providing commerce services, and restricts for security, KYC, payment, delivery and AI-commerce purposes.
VSL does not collect an identity document, location point, payout account or AI instruction merely because the platform is capable of storing it.
VSL's data model is commerce-driven. Information enters the platform when a user creates an account, publishes a listing, sends a request, creates a quote/invoice/payment request, pays, receives a payout, connects a social channel, creates a delivery, configures an AI Sales Passport, authorises an AI connection, opens a dispute or asks for support. Each workflow has a different purpose and sensitivity.
The categories below describe data VSL processes when the corresponding feature is used. VSL does not collect every field from every user.
Name, username, business/profile name, email, phone, country, public profile information, password/authentication state, session information, login timestamps, IP/device/browser/user-agent information and account-security events.
Product/service title, description, category, price, currency, images/video, seller identity/username, public contact choices, inventory or availability signals, comments, views, RFQs, quote content, buyer/seller messages and connected-channel references required to continue the commercial conversation.
Order/quote/invoice/payment-request references, payer/payee or seller/customer references, amount, currency, reason/purpose, requested method, instalment choice when used, delivery channel, payment link/token, request status, timestamps and related conversation/order references.
Payment/provider references, invoice/order IDs, amount and currency, payment rail, provider status, verification state, transaction timestamps, quote/FX references where applicable, webhook/callback events, payout state and reconciliation evidence. Crypto flows can also include asset/network, provider payment ID, blockchain transaction hash and confirmation state.
Bank or mobile-money recipient details, wallet address and network, payout preference, destination currency, provider recipient/customer references, ownership/verification status and payout/reconciliation records. VSL does not need or publish a user's private wallet key.
Legal name, date of birth, address, country, phone/email, business-registration and ownership information, beneficial owners, identity number/document information (such as BVN, NIN, national ID, passport or driver's licence where a permitted workflow requires it), selfie/liveness evidence when required, and source-of-funds/source-of-wealth or enhanced-due-diligence information when requested by a provider or legal obligation.
Recipient name/contact, delivery address, instructions, date/window, place/location identifiers where used, latitude/longitude, and live courier/driver location only when the delivery workflow shares it. Mapping requests can send an address or coordinates to a mapping provider in order to resolve or display a route.
Conversation/thread references, sender/recipient identifiers, message content, timestamps, WhatsApp/Facebook account/page identifiers and status metadata needed to route a conversation, payment request or confirmation. Connected services also process data under their own terms.
Seller-controlled business description, tone, selling instructions, negotiation policy, working hours, refund/delivery preferences, pricing rules, languages and escalation instructions where the seller chooses to configure them. These are seller assertions, not independently verified facts merely because they appear in the Passport.
Public business identity/catalog references, currencies, observed/verified capabilities, evidence classification, OAuth client/connection identifiers, authorised scopes/capabilities, prepared-action references, confirmation records, idempotency records, action audit logs and security events. Secret credentials are not part of the public Passport.
IP/device/request metadata, CSRF/authentication events, webhook verification metadata, fraud/risk signals, error records, dispute evidence, delivery proof, support messages, moderation actions and records required to investigate account or transaction integrity.
Some information is generated by banks, payment providers, identity providers, mapping services or connected commerce channels rather than typed directly into VSL.
A verification signal can be public without exposing the underlying identity material.
VSL separates public seller information from restricted verification material. A public Commerce Passport can expose a business identity, catalog, currencies, integration/capability signals and evidence classification, but it does not expose raw BVN/NIN values, national ID/passport images, selfie/liveness material, private bank account details, provider secrets or hidden risk records.
Where an external provider performs verification, VSL retains the minimum VSL-side information needed to prove state and operate the account: provider reference, verification status, timestamps, consent/evidence references and only the underlying data that VSL itself needs or is required to retain.
The exact legal basis depends on the country and processing operation; VSL avoids describing consent as the only basis for all processing.
| Purpose | Typical data | Why it is processed |
|---|---|---|
| Provide account and commerce services | Account/profile, listings, messages, RFQs, orders, quotes, invoices | To perform the service requested by the user and maintain the commercial record. |
| Create/verify payment requests | Amount, currency, counterparties, order/payment references, provider state | To perform the transaction workflow, prevent duplicate/fraudulent actions and reconcile provider truth. |
| KYC/KYB and financial crime controls | Identity/business data, provider KYC state, source-of-funds evidence where required | Provider terms, legal obligations, fraud prevention and risk management; explicit consent is recorded where a specific sharing/verification workflow requires it. |
| Delivery and location | Addresses, coordinates, recipient contact, delivery events | To arrange or track a user-requested delivery and resolve a destination/route. |
| Account/API security | Session, IP/device, authentication, scope, webhook, audit/security events | To protect accounts, integrations and transaction integrity and investigate abuse. |
| AI commerce | Passport instructions, scopes, prepared actions, confirmations and audit records | To provide the seller-configured AI experience while keeping external AI actions bounded and reviewable. |
| Disputes, support and legal claims | Messages, payment/delivery evidence, moderation and support records | To resolve issues, establish what happened and meet contractual/legal obligations. |
| Marketing | Contact details, preferences and campaign event data | Only with the consent/exception and opt-out controls required by the applicable messaging law. |
Sharing is tied to a defined function rather than unrelated resale.
Where a third party acts as its own controller rather than only as VSL's processor, that party's terms/privacy notice also apply to its processing.
VSL applies different access rules to information a user publishes publicly and information exchanged privately between a seller and customer.
Public listings, profile information, product media and public comments can be reviewed by VSL and can be restricted or removed when reported or when they breach VSL rules or applicable law.
Private seller-customer messages and private transaction material are not public content. They remain access-controlled to the participants and systems required to provide the service. Authorised VSL personnel review relevant private material when either participant reports it, opens a dispute, requests fraud/safety/support assistance, or when a valid legal request requires responsive records. The review is limited to the case and does not make the private material public.
VSL can also analyse transaction, account and security metadata needed to protect payment integrity and account security without publishing or routinely opening the underlying private conversation for content moderation.
Legal requests are handled as controlled disclosures, not as general access to user accounts.
VSL reviews requests from courts, regulators, law enforcement and other competent authorities for authority, legal basis, jurisdiction, scope, identifiers and date range. VSL discloses only responsive information that it controls and is legally required or permitted to provide. Provider-held data may need to be obtained from the applicable payment, bank, crypto or other service provider.
Where applicable law requires preservation, VSL can preserve identified records for the required period. Confidentiality and user-notification handling follow the applicable legal process.
See Fraud Prevention, Transaction Monitoring & Lawful Requests →
VSL separates “no longer needed for normal product use” from “must still be retained for security, payment, dispute or legal reasons.”
VSL retains information only for as long as it is reasonably necessary for its documented purpose, while preserving records needed for payment-provider rules, AML/CFT, tax/accounting, fraud/security, disputes, chargebacks, legal claims or mandatory retention. A deletion request can therefore result in deletion, anonymisation, restriction or continued limited retention depending on the specific record and applicable law.
VSL applies a shorter and more controlled lifecycle to highly sensitive KYC material than to ordinary public catalog data unless a legal/provider obligation requires longer retention.
Rights differ by jurisdiction, but VSL uses a consistent baseline for access and correction.
VSL verifies the requester's identity when necessary before providing, altering or deleting account information so that one person cannot exercise rights over another user's data.
Cross-border commerce naturally creates cross-border data flows, but those flows still require purpose, security and transfer governance.
A Nigerian seller can interact with a Canadian buyer, use a global CDN/security network, receive a payment-provider event from another jurisdiction and use a mapping service hosted internationally. VSL documents where processors/providers operate, what data is transferred, the applicable transfer mechanism or contractual safeguard, and whether local data-residency or other legal requirements affect the workflow.
Regional availability is not a permission to reuse personal data for unrelated purposes. Purpose limitation and minimisation remain part of the design even where data moves across borders.
Primary regulator, government and provider materials used to frame this public compliance overview. External documents can change; VSL reviews the applicable source before relying on it for a launch or feature decision.