Global Chains ERP — Privacy Policy

1. Who this Policy covers

This Policy applies to visitors to our websites, registered users, organization administrators and members, payors or counterparties who interact with public or tokenized flows we host (such as hosted invoice or payment pages or vendor submission links), and individuals whose information is submitted into the Service by a customer (for example employees, vendors, or clients of our customers).

If you interact with the Service only as an employee or contact of our customer, that customer is typically responsible for informing you about processing and for honoring privacy requests for business data they control. We may still process certain information as an independent controller for security, billing, and platform integrity.

2. Controller and processor roles

The Service is multi-tenant. In general:

• Customer as controller: For data your organization inputs or connects—such as invoices, payables, clients, vendors, chart-of-account style references, payroll fields, files, treasury configurations, and business communications metadata—your organization is typically the controller, and we process such data as a processor to provide the Service, subject to your instructions, these terms, and any executed DPA.
• We as controller: We act as a controller where we determine purposes and means—for example account creation and authentication events, subscription and billing with payment partners, fraud and abuse prevention, security monitoring, aggregated analytics, product and policy notices, certain cookie-based analytics where not solely on behalf of a customer, and compliance with legal process directed to us.

Where laws require a lawful basis (such as under GDPR/UK GDPR), we rely on contract, legitimate interests (balanced against rights), legal obligation, or consent as appropriate to the activity. California and other U.S. state laws may classify certain processing differently; see Section 18.

3. Information we collect

Depending on how you use the Service, we may collect:

3.1 Account, identity, and access

• Name, email, phone, password or OAuth tokens, session identifiers, organization membership, roles
• Workspace or organization identifiers, invitation and onboarding state
• Security-related events (e.g. sign-in timestamps, device or IP indicators where logged)

3.2 Billing and subscriptions

• Plan, subscription status, usage metrics relevant to billing
• Payment data: typically handled by payment processors (e.g. Paystack or other configured providers). We may receive limited tokens, last-four, receipt metadata, customer references, and transaction status—not full card data where the processor tokenizes it.

3.3 Financial, ERP, and operational content

• Invoices, line items, taxes, approvals, numbering, PDFs, and delivery history you configure
• Payables, bills, vendor banking or payment instructions you store, approval chains, audit trails
• Clients, vendors, counterparties, and contact directories you maintain
• Bank account labels, payment method preferences, reconciliation notes, and similar operational fields

3.3a Point-of-sale and hospitality operations

Where a workspace enables our POS service, we process operational records created at the till. Much of this concerns people who are not our users — a venue's staff and its walk-in customers — and the venue is the controller for it:

• Orders, line items, quantities, prices, discounts, voids, tables, and order timestamps
• Payment rail per order (cash, M-Pesa, bank/card, split, credit) and, where reconciliation is enabled, the matching Safaricom-confirmed receipt
• Staff records: the name of the person who took each order, their sales, tips earned and tip verification state, shifts, and credit tabs they opened. These figures drive payroll, so they are treated as employment data by the venue
• Customer records: names and phone numbers for credit tabs and account customers, outstanding balances and ageing, storefront customer accounts, carts, and delivery details where online ordering is enabled
• Menu, stock, recipes, suppliers, restock requests, device registrations, and printed receipt records
• Derived daily summaries (see section 5A): per-venue, per-trading-day totals of revenue, payment-rail mix, hourly patterns, top products, and per-staff sales used to power analytics and in-product insights

3.3b Payroll and workforce data

Where payroll features are enabled, a customer may store employee names, work email, job title, department, postal address, bank name and account number, mobile-money number and provider, and wallet address, together with salary, expense and payout records. This is sensitive employment data; the employing customer is the controller and is responsible for having a lawful basis to hold it and for telling its employees.

3.4 Treasury, wallets, and blockchain-related data

• Wallet addresses, chain identifiers, transaction hashes, Safe or multi-sig configurations, gas or fee settings, and provider references (including data returned by node providers or wallet-connection SDKs)
• On-chain data is public by nature; we may index or display it to operate features you enable
• Webhook or provider callbacks related to treasury movements (e.g. funding or payout status payloads) may be logged for reconciliation and security

3.5 Mobile money and regional payment channels

• Where M-Pesa or similar channels are enabled, we may process phone numbers, transaction references, reconciliation keys, and status messages as you or integrations submit them

3.6 HR, payroll, and workforce information

• If you use payroll or HR-oriented fields: salaries or rates, deductions, tax identifiers, national IDs, bank details for wages, attendance or HR notes—often special-category or sensitive under law. Under the Kenya Data Protection Act 2019, section 25, employee salary data, national identification numbers, and similar HR records are classified as sensitive personal data requiring explicit consent and heightened protection. You must have a lawful basis (including employee notice and written consent where required under Kenya DPA s.25) before processing such data. We process such data only to provide the Service per your instructions.

3.7 Files, media, and documents

• Uploaded logos, attachments, contracts, and PDFs you or your users provide
• Where PDF or document parsing is used, extracted text and structure may be processed to populate fields you approve

3.8 Communications

• Email content metadata, delivery status, and SMTP or provider logs when we send system or product emails (e.g. via Nodemailer or your configured mail transport)
• If you connect WhatsApp Business API (Meta)or similar channels, message metadata and payloads may be processed according to your configuration and Meta's policies

3.9 APIs, webhooks, and integrations

• API keys or tokens you create, webhook URLs, request logs, error logs, and integration configuration
• Payloads received from third-party systems you connect to the Service

3.10 Public and unauthenticated flows

• When counterparties use hosted invoice pay flows, vendor link tokens, or similar URLs, we may collect IP address, device/browser data, payment attempt metadata, and fraud signals as needed to operate and secure those flows

3.11 Technical, cookies, and similar technologies

• Cookies, local storage, or similar for sessions, preferences, security, and analytics
• IP address, user agent, referrer, approximate location derived from IP

3.12 Push notifications

• If you opt in to web push, subscription endpoints and keys required for delivery may be stored in accordance with browser standards

3.13 AI-assisted features

• Inputs you provide and outputs generated may be processed by models or automation to deliver features you enable. Retention and subprocessors depend on configuration and provider terms.

3.14 Support and abuse handling

• Ticket content, correspondence, and investigation notes when you contact us or we investigate incidents

4. Purposes of processing

• Provide, maintain, debug, and improve the Service and its features
• Authenticate users, enforce RBAC, and maintain tenant isolation
• Route or orchestrate payments, treasury actions, and notifications as you configure
• Detect, prevent, and respond to fraud, abuse, security incidents, and illegal activity
• Comply with law, regulations, court orders, and government requests
• Perform sanctions and risk screening where required or prudent
• Bill and collect fees; manage subscriptions and trials
• Communicate about the Service, incidents, and policy updates
• Analytics, product development, and benchmarking using aggregated or de-identified data where possible
• Train or evaluate models only as permitted by applicable agreements and settings

5. Automated processing and profiling

We may use rules-based systems or machine learning for fraud scoring, risk flags, categorization, suggestions, or workflow routing. Such processing may produce recommendations only; it does not replace your judgment unless you explicitly configure automation. Where required, you may have rights to human review or to object.

5A. AI features and where your data goes

The AI assistant runs on infrastructure we operate. In our current production configuration the language model is self-hosted— prompts containing your business data are sent to a model running on our own servers, not to a third-party AI provider, and your content is not used to train anyone else's model.

So that you can judge this properly rather than take it on trust, here is exactly how it works:

• What is in a prompt.To answer questions about your business, the assistant is given a compact summary of the workspace you are asking from. That summary can include invoice and payable totals, the names of overdue clients and upcoming vendors, POS revenue and payment-rail figures, named staff performance, employee headcount and — for owners and admins only — salary totals. It is scoped to your workspace; one customer's summary never contains another customer's figures.
• Where it is processed. Under the current configuration, on a model instance we host. Nothing in that request reaches OpenAI, Anthropic, Google, or any other model vendor.
• The honest caveat. The platform supports third-party model providers as a fallback if the self-hosted model is unreachable. If that fallback is ever active, the prompt described above would be sent to that provider under their terms. We will state the active configuration on request, and enterprise customers may require in their agreement that the fallback stay disabled.
• WhatsApp is different. If you use the assistant over WhatsApp, the message itself travels through Meta'sWhatsApp Business infrastructure before it reaches us and after we reply. That leg is governed by Meta's terms, not ours. Use the in-app assistant if you do not want a message to transit Meta.
• What we keep.Assistant conversations initiated over WhatsApp are stored so the thread has continuity. In-product analytics summaries and the plain-language "insights" derived from them are stored per workspace and per trading day.
• Improving the Service. We may use derived, operational metrics— daily totals, payment-rail mix, timing patterns and the insight statements generated from them — to build, evaluate and improve the analytics and AI features of the Service itself. We do not sell this data and we do not hand your content to third-party model providers for their training.

6. Legal bases (EEA, UK, and similar)

Where GDPR, UK GDPR, Kenya Data Protection Act, Nigeria NDPA, South Africa POPIA, India DPDP Act, UAE frameworks, or comparable laws apply, we process personal data under one or more of: performance of a contract, legitimate interests (e.g. securing the Service, preventing fraud—balanced against individual rights), legal obligation, vital interests (rare), or consent where required (e.g. non-essential cookies or certain marketing). Public-sector or employment contexts may impose additional rules.

7. Disclosure, subprocessors, and categories of recipients

We may disclose information to:

• Infrastructure and database providers (e.g. document databases such as MongoDB in cloud regions you or we configure)
• Application hosting and edge/CDN providers that serve our web application and assets
• Authentication and identity services integrated with the platform
• Payment processors (e.g. Paystack for subscriptions or other configured acquirers)
• Treasury or banking-as-a-service partners you enable (e.g. providers receiving webhooks or settlement instructions)
• Blockchain node, wallet, and smart-contract infrastructure (e.g. RPC providers, wallet connection SDKs, Safe stack components, BTCPay Server infrastructure) as required to execute features you choose
• Email delivery (SMTP relays or transactional email vendors) and messaging platforms (e.g. Meta/WhatsApp when connected)
• Analytics, logging, observability, error reporting, and security vendors
• Professional advisers, auditors, insurers, and due-diligence participants
• Acquirers, successors, or affiliates in a merger, financing, or asset sale, subject to confidentiality and legal requirements
• Law enforcement and regulators when we believe disclosure is required by law or necessary to protect rights, safety, and integrity

7.1 Current subprocessors

Naming these is more useful than a category list. Several are engaged only if the relevant feature is switched onfor your workspace — a customer that does not use M-Pesa never touches Safaricom through us.

Not on this list, deliberately:the AI model that powers the assistant. Under our current configuration it runs on infrastructure we operate, so it is not a subprocessor disclosure — see section 5A, including the fallback caveat.

This list may change. We will give enterprise customers notice where contractually required before engaging a new subprocessor that processes personal data on their behalf.

7A. BTCPay Server and Bitcoin payment infrastructure

Where we host or operate BTCPay Server instances on behalf of merchants, we provide server software infrastructure only. We are not a payment processor, payment service provider (PSP), money transmitter, virtual asset service provider (VASP), or custodian in relation to Bitcoin or any other digital asset transactions processed through BTCPay Server.

BTCPay Server operates on a self-custodial model: merchants control their own Bitcoin private keys and wallets. We do not hold, custody, control, or have access to merchants' Bitcoin funds at any time.

In connection with BTCPay Server hosting, we may process:

• Server configuration data and instance settings you provide
• Connection metadata, API credentials, and webhook configurations
• Operational logs required for infrastructure maintenance and security
• xpub (extended public key) data you configure for invoice generation — we do not have access to private keys

On-chain transaction data is public by nature of the Bitcoin network. Transaction hashes, addresses, and amounts recorded on the blockchain are publicly visible and cannot be erased by us or by you. We may display or index this publicly available data to operate features you enable.

You (the merchant or operator) are solely responsible for all compliance obligations arising from your acceptance of Bitcoin payments, including applicable VASP registration, KYC/AML program requirements, tax reporting, and any licensing required in your jurisdiction.

8. International data transfers

We may process and store data in the United States, European Economic Area, United Kingdom, Kenya, and other regions depending on deployment and vendor locations. Where transfers from the EEA, UK, Switzerland, or other restricted jurisdictions occur, we implement appropriate safeguards such as Standard Contractual Clauses, the UK Addendum, or other lawful mechanisms. Copies of transfer assessments or DPAs may be available to enterprise customers upon request.

9. Data residency and self-hosting

Application and POS data is held in a managed MongoDB Atlas cluster. The web application is served from Vercel's edge network, which means static assets and request routing are distributed by design. We will confirm the specific database region on request; enterprise customers can pin residency contractually.

Two components run on infrastructure we operate ourselves rather than being handed to a vendor: the AI model behind the assistant (section 5A) and, where a merchant enables Bitcoin, their BTCPay Serverinstance (section 7A). Payment-provider credentials that a workspace stores with us — M-Pesa and KCB API keys and secrets — are encrypted at rest under a key we hold separately from the database.

Some processing is unavoidably international: Safaricom and KCB operate in Kenya, Paystack and Meta operate regionally and globally, and public blockchains are worldwide by construction.

10. Security

Specifics are more useful than adjectives. The measures below are the ones actually implemented in the platform today:

• Passwords are hashed with bcrypt at cost factor 12 and are never stored or logged in readable form
• Sign-in with Google is verified against Google's published signing keys, with the audience pinned to our client id and the address required to be Google-verified — an email address alone is not accepted as proof of identity
• Sessions use HttpOnly, SameSite=Lax cookies, marked Secure in production, carrying a signed token rather than credentials
• Stored payment-provider credentials (M-Pesa, KCB) are encrypted at rest with authenticated encryption
• Sign-in is rate limited per email address and per IP, and failures are recorded to the security audit log
• Inbound webhooks from payment and treasury partners are signature-verified before they are acted on
• Every query is workspace-scoped; multi-tenant isolation is enforced in the data layer, not in the interface
• Treasury actions can require a separate passcode, held only as a hash
• Transport is TLS throughout, including to our database and between our own services

No system is perfectly secure.We do not represent that the Service is immune to compromise, "unhackable," or free from defects, and the list above is a description of current practice rather than a warranty. You are responsible for safeguarding credentials, API keys, and devices used to access the Service, and for removing access when a team member leaves.

11. Audit logs, monitoring, and financial traceability

We may record events such as authentication, role changes, configuration edits, approvals, exports, treasury or payout instructions initiated through the Service, webhook receipts, and administrative actions. Logs support security monitoring, dispute resolution, regulatory inquiries, and forensic investigations. Retention follows operational and legal requirements and may extend beyond account deletion where mandated for accounting or anti-fraud purposes.

12. Retention

We retain personal data for as long as necessary to provide the Service, comply with law (including tax, AML, and bookkeeping retention), resolve disputes, and enforce agreements. Where the platform enforces a schedule automatically, these are the periods:

• Security audit logs — 365 days, then deleted automatically by the database
• Bank settlement notifications (KCB IPN) — 90 days
• M-Pesa reconciliation sync windows — 3 days (the receipts themselves are kept as accounting records)
• Vendor submission links and workspace invitations — deleted at their expiry time
• Cached profile photos — kept until the source photo changes or the account is deleted
• Business records(invoices, payables, POS transactions, payroll, ledger entries) — kept for as long as the workspace exists, because they are the customer's accounting records; the customer decides when to remove them

Backups may persist for a limited period after a deletion request. Enterprise customers may negotiate schedules in a DPA.

13. Deletion, export, and account closure

You may request export or deletion subject to law and technical feasibility. Where we act as processor, requests may need to be routed through your organization's administrator. Some information must be retained by law or for legitimate interests (e.g. billing proofs, abuse prevention). Public blockchain records cannot be erased by us.

14. Cookies and tracking

We keep this deliberately small. In normal use the Service sets:

• A session cookie (next-auth.session-token, split across numbered parts when large). Strictly necessary — it is what keeps you signed in. HttpOnly, SameSite=Lax, Secure in production, and it expires after 30 days or when you sign out.
• Vercel Analytics and Speed Insights, which measure page views and load performance. These are configured to be privacy-preserving and do not build cross-site advertising profiles.

We do not run advertising pixels or sell audience data. Blocking the session cookie will prevent sign-in.

15. Marketing

We may send product updates or offers where permitted. You may opt out of marketing communications; transactional or security notices may continue.

16. Children

The Service is not directed to children under 13 (or the minimum age in your jurisdiction). We do not knowingly collect personal information from children.

17. Sanctions, AML, and restricted activity

We prohibit use of the Service for sanctions evasion, money laundering, terrorist financing, fraud, or other illegal financial activity. We may screen data where required, block activity, freeze features, or terminate accounts consistent with law and risk policies.

17A. Cryptocurrency and virtual asset compliance

If you use Bitcoin, cryptocurrency, or other virtual asset features of the Service (including BTCPay Server hosting), you are solely responsible for complying with all applicable laws and regulations in your jurisdiction, including:

• VASP registration and licensing: Virtual Asset Service Provider registration or licensing obligations that may apply to your business under the laws of Kenya, your country of incorporation, and any jurisdiction where you operate or have customers
• AML/CFT obligations: Anti-money laundering and counter-financing of terrorism program requirements, including customer due diligence, transaction monitoring, and suspicious activity reporting
• Tax reporting: KRA (Kenya Revenue Authority) guidance on the tax treatment of virtual assets and cryptocurrency transactions, including capital gains, income characterization, and VAT implications
• CBK regulations: Central Bank of Kenya regulations and guidance on virtual assets and digital currencies, as updated from time to time, apply to your use of cryptocurrency features where applicable

We screen for sanctioned addresses where technically feasible using available screening tools, but we make no representation that our screening is exhaustive or complete. You remain responsible for your own sanctions compliance program. We reserve the right to block, restrict, or report transactions associated with sanctioned addresses or persons.

18. Regional privacy rights

18.1 Kenya

Kenya is our primary market, so we call it out first. Under the Data Protection Act, 2019, data subjects in Kenya have the right to be informed of the use of their personal data, to access it, to object to its processing, to have inaccurate data corrected, and to have it deleted where there is no lawful reason to keep it. Complaints may be lodged with the Office of the Data Protection Commissioner (ODPC).

Two points specific to how the Service is used here. First, a venue that records a customer's name and phone number against a credit tab is a data controller under the Act and carries the duty to inform that customer. Second, M-Pesa transaction data reaches us through Safaricom under their own terms as well as ours.

18.2 Other regions

Depending on your location, you may have rights to access, correct, delete, port, restrict, or object to processing, and to lodge a complaint with a supervisory authority. California residentsmay have rights under the CCPA/CPRA, including to know, delete, correct, and opt out of certain "sales" or "sharing" (we do not sell personal information for money in the traditional sense; we may use cookies or analytics that could constitute "sharing" under some definitions—see our Cookie disclosures). Other U.S. states are adopting similar laws. We will verify requests as permitted by law.

19. Breach notification

If we determine a personal data breach requires notification under applicable law, we will notify regulators and affected individuals as required. Customers acting as controllers are responsible for notifying their own data subjects where their business data is affected and they have the relationship.

20. Third-party links and embedded services

The Service may link to third-party sites or embed widgets. Their privacy practices are governed by their own policies. Wallet extensions, banking portals, or social login providers may collect data independently.

21. Changes to this Policy

We may update this Policy to reflect product, legal, or operational changes. We will post the updated Policy with a new "Last updated" date and, where required, provide additional notice. Continued use after changes may constitute acceptance where permitted.

22. Contact

Privacy questions and requests:

Email: privacy@chains-erp.com
Data Protection Officer: dpo@chains-erp.com
Legal notices: legal@chains-erp.com
Address: Nairobi, Kenya. Full registered address available upon written request to legal@chains-erp.com.