Security & data handling

You are about to put invoices, payroll, till takings and payment credentials into someone else's software. This page describes what protects them. Every measure listed is implemented in the product today — we have deliberately left out anything we intend to do but have not done.

Last updated: August 2026

Getting in

  • Passwords are hashed with bcrypt at cost factor 12. We cannot read your password, and it is never written to a log.
  • Sign in with Google is verified against Google's published signing keys, with the audience pinned to our application and the address required to be Google-verified. An email address on its own is never accepted as proof of identity.
  • Sign-in attempts are rate limited per email address and per IP, and failures are written to the security audit log.
  • Sessions are held in an HttpOnly, SameSite=Lax cookie, marked Secure in production, carrying a signed token rather than your credentials. It expires after 30 days or when you sign out.
  • Treasury actions can require a separate passcode, stored only as a hash — so someone with a live session still cannot move money without it.

Keeping tenants apart

  • Every query is scoped to a workspace in the data layer, not in the interface. Isolation does not depend on a screen hiding a button.
  • Switching workspace re-derives your access from the database rather than trusting what the browser claims.
  • Roles carry explicit permission sets, and privileged actions re-check them server-side on each request.
  • Cross-workspace analytics exist only in the platform-admin console, which is restricted to our own operators and is separately audited.

Where your data actually sits

  • Business and POS records are held in a managed MongoDB Atlas cluster, reached over TLS.
  • The AI assistant runs on a model we host ourselves. Your figures are not sent to OpenAI, Anthropic, Google or any other model vendor, and are not used to train anyone else’s model.
  • Payment-provider credentials you store with us — M-Pesa and KCB API keys and secrets — are encrypted at rest under a key held separately from the database.
  • Where a merchant enables Bitcoin, their BTCPay Server instance is infrastructure we run rather than a third-party custodian.
  • We never store full card numbers. Card collection happens at the payment processor, and we hold only tokens and receipt metadata.

Knowing what happened

  • Authentication events, role changes, approvals, exports, treasury instructions and administrative actions are recorded to an audit log.
  • Inbound webhooks from payment and treasury partners are signature-verified before they are acted on, so a forged callback cannot move money or mark an invoice paid.
  • M-Pesa reconciliation compares Safaricom-confirmed receipts against what the POS recorded, and surfaces both directions of mismatch rather than hiding them.
  • Security audit entries are kept for 365 days and then removed automatically by the database.

Self-hosted AI, in plain terms

Most business software that added an AI assistant did it by forwarding your data to a model vendor. We run the model ourselves. When you ask the assistant why last Tuesday was slow, the summary it reads — your revenue, your overdue clients, your staff's names — goes to a machine we operate and no further.

The platform can fall back to a third-party model provider if our own becomes unreachable. We would rather tell you that than let you assume otherwise. We will confirm the active configuration on request, and enterprise customers can require in their contract that the fallback stays switched off.

What this page does not claim

  • No system is unbreakable. This is a description of current practice, not a warranty, and not a promise that the Service cannot be compromised.
  • Your side matters as much as ours. A shared password, a stale team member who still has access, or a device someone else can open will defeat all of the above. Remove access when people leave.
  • Some things are outside our control. Payments settle at Safaricom, KCB and Paystack under their rules; WhatsApp messages travel through Meta; on-chain transactions are public and permanent, and we cannot reverse or erase them.
  • Reconciliation is an aid, not an audit. We surface mismatches; a person still has to resolve them, and the figures we show are not an accounting opinion.

Reporting a vulnerability

If you believe you have found a security issue, please tell us before telling anyone else, and give us a reasonable opportunity to fix it. Include enough detail to reproduce it. We will not pursue legal action against researchers who act in good faith, avoid privacy violations and service disruption, and do not access or modify data belonging to others.

Reach us through the contact route listed in the Terms of Service, marking the message as a security report so it is routed immediately.

See also the Privacy Policy for what we collect, who processes it and how long we keep it, and the Terms of Service for the commercial terms.