Version 2026-08-13 · all · published

Security Overview

Last updated: 13 August 2026 · Version: 2026-08-13

What is actually in place, written so that somebody deciding whether to trust us with their business can check it rather than take it on faith. Where something is not done, it says so — a security page that lists only strengths is a marketing page, and the omissions are what a buyer is looking for.

The short version

• Card numbers never reach us.
• Money is a ledger that cannot be edited, only added to.
• Every staff action is recorded against a person.
• Two-factor authentication is required for staff, not offered.
• We hold no security certification, and have not yet had an independent

penetration test.

Where it runs

The platform runs on Amazon Web Services in Cape Town (af-south-1) — the data stays on the continent it is about. The database is Aurora PostgreSQL with encrypted storage and automated backups; files live in private object storage, reachable only through short-lived signed links, never by a public URL.

Connections

TLS 1.2 or better everywhere, including between our own services. The database refuses unencrypted connections and its certificate is verified against a pinned certificate authority bundle rather than by trusting whatever answers.

Payments

Card details never touch a Thuma server. The card fields on the ThumaPay checkout are the payment processor's own frames, served from the processor's own domain — we receive a token, never a number. That keeps our PCI DSS scope at SAQ-A, which is the lowest there is, and it means a compromise of our servers cannot expose a card.

Mobile money and cash flow through their own rails; we hold no rail credentials in the app.

Money

The ledger is append-only. Entries are never updated and never deleted: a correction is a new balancing entry, and every transaction must balance before it is accepted. This is enforced by the database, not by a convention somebody could forget — so the history of what moved cannot be quietly rewritten, by us or by anybody who reached the database.

Escrow, driver payouts, merchant remittances and service credits are all postings in that one ledger, which is why they can be reconciled against each other.

Who can do what

• Role-based access for staff, with the permissions of a role listed

explicitly rather than implied by seniority.

• Scoped to markets. A person invited to work Zimbabwe cannot act on

Zambia.

• Two-factor authentication is required, enrolled at first sign-in. There

is no path to a console session without it.

• Every permitted action is audited — who, which permission, which route,

when. The audit is written by the guard that grants access, so an action cannot be taken without producing the record.

• Customers and drivers sign in with a one-time code to their number.

Sessions refresh and can be ended.

Personal information

• Identity documents are uploaded from the handset **directly to private

storage** — they never pass through the API, and there is no endpoint that accepts a file.

• Automated identity checks are made by a named vendor; a human reviews

anything the machine will not clear.

• Consent and every agreement accepted are recorded with the version and a

hash of the exact wording, so what somebody agreed to can be produced years later.

• Retention periods are published in Annex 1 of the Data Processing Agreement.

Building and shipping

Every change is reviewed and has to pass an automated gate set before it can ship: type checking, the full test suite, a boot check, dependency review, and a set of repository-specific gates that fail a build for things like an unreachable screen, an unauthenticated mutating route, or a translation that went missing. Secrets live in AWS Secrets Manager and never in the repository or an image.

Dependency advisories are reviewed on a schedule. Anything accepted rather than fixed carries a written reason and the condition that would change the decision.

When something goes wrong

• Incidents are published at status.thumaexpress.com while they are

happening, with updates, and they stay readable afterwards.

• Businesses on a paid plan have a service level agreement with credits that

are paid automatically — see the SLA annex.

• If a breach affects a merchant's customers, we tell that merchant within 72

hours of becoming aware, with what we know at the time.

Telling us about a vulnerability

Write to security@thumaexpress.com with enough detail to reproduce it. We will acknowledge within two working days and keep you informed. We will not take legal action over research done in good faith that does not degrade service, access more data than is needed to demonstrate the issue, or expose anybody's personal information.

What we do not have

• No SOC 2 and no ISO 27001. Neither is in progress today.
• No independent penetration test yet. The intention is to commission one

before the platform carries enterprise volume; until it has been done, this page will keep saying so.

• No bug bounty programme. Reports are still welcome and still answered.

This page is versioned like every other document here. If it changes, the version changes with it, and the previous version stays readable.

Rendered from thuma_backend/legal/security.md. The wording there is the original; this is a readable copy.