Security & POPIA

Say the mechanism. Not the assurance.

A managing agent will ask what stops one scheme’s ledger reaching another. A trustee will have to answer the same question to fellow owners, later, in plain language. Both deserve the same thing: not a policy document, but what the software actually does — read from the code that runs it, including the parts that aren’t built yet.

days — the longest an access grant may run
180
days — the longest an access grant may run
days — a passkey session, before you’d sign in again
14
days — a passkey session, before you’d sign in again
minutes — how long a login code stays valid
10
minutes — how long a login code stays valid
guesses — before a login code is dead
5
guesses — before a login code is dead

How it holds

Four mechanisms, not four promises.

Each of these is enforced in code a reviewer can read, not left to whoever remembers to check.

  • 01

    The scheme boundary is the database’s job

    Nexorah holds many body corporates’ financial records in one Postgres database. Every scheme-owned table carries a policy comparing its scheme_id to the one the current request is scoped to — forget to filter a query by scheme, in a report or a hurried fix, and Postgres returns nothing, not somebody else’s arrears. The app itself connects as a role that owns no tables, so there is no code path that can lift the rule by mistake.

  • 02

    Capabilities, not roles

    Every request checks a specific verb — money.view.arrears, votes.cast, access.grant — not a job title. Some authority never comes in role shape: a bank granted thirty days of read-only access to the financials isn’t a role the system has to invent and remember to retire. It’s a capability set with an expiry, checked exactly the way a trustee’s is.

  • 03

    A passkey, and a session you can end

    Trustees sign in with a passkey, bound to the exact domain so it can’t be phished onto a lookalike site, and it requires the person present, not just the device. A one-time code is the fallback. Either way the session is a row in the database, not a self-contained token, so a lost phone ends every session for that person now, not whenever it happens to expire.

  • 04

    Grants that expire on their own

    Access issued to a bank, insurer or auditor is one of four fixed scopes, capped at 180 days and re-checked on every request rather than trusted from the day it was issued. A grant revoked an hour ago stops working now. Every read it produces is written to the same audit trail a trustee can see.


The access model

Four scopes. Never a login.

A grant is not a password with a shorter memory. Every one of the four is read-only by construction — there is no write capability in any of them — and a scope Nexorah doesn’t recognise opens nothing. Failing closed is the only safe default here.

Financials summary
The roll, the funds, the budget. Nothing about who owes what, no documents.
Arrears only
Who owes what, names attached. Nothing about the funds or the budget.
Valuation & claims
Jobs and documents — what an insurer needs for a claim or a renewal.
Full ledger
Everything above, plus the right to export the record. The widest scope there is — and still read-only.

Capped at 180 days, and re-checked on every request rather than trusted from the day it was issued — a grant revoked an hour ago stops working now, not at the next clean-up job. Every read it produces is written to the same audit trail a trustee sees for their own scheme.


Data residency & POPIA

The record lives in South Africa, and it belongs to the scheme.

The database and the application are built to run in Johannesburg — Google Cloud’s africa-south1 region — chosen for POPIA data residency, not picked for cost. Two features send document text outside the country, and they are named below rather than left for you to find. Sectional title here runs on the STSMA and CSOS, and the platform is built around both.

Who can export the record

Trustees hold that right in the access model itself — export sits alongside the audit trail and the decision queue as one of a trustee’s own capabilities, not a favour granted case by case. What isn’t built yet is the self-serve button: today an export is something a trustee asks for directly, and we hand over the whole record — every ledger entry, every document, every audit line — rather than a tap in the product.


Said plainly

What isn’t done yet.

A security page that only lists guarantees isn’t more secure than one that also lists what’s missing. Four things, without softening them.

No outside penetration test yet
Nobody outside Nexorah has tried to break this. We intend to commission an independent test before it carries a live scheme’s money — until then, treat the rest of this page as an engineering description, not a certification.
Sign-in codes aren’t on WhatsApp yet
Codes go out by SMTP where a mail server is configured; without one, the code is written to the server log — fine for a demo, not for a live scheme. WhatsApp, the channel that will matter most for these communities, is written into the code as a declared option but isn’t wired up.
Export is a right, not yet a button
Trustees already hold the capability to export the whole record in the access model, alongside the audit trail and the decision queue. The self-serve download itself isn’t built — today, ask, and we hand it over in full.
Some document text leaves the country
The record lives in Johannesburg, but two features send text abroad. When the deterministic dictionary can’t place a line item, its printed label — “Munisipale dienste”, “Repairs and maintenance” — goes to DeepSeek, outside South Africa, to be classified; and the adviser sends the question’s context there too. Figures never do: the engine computes every number and the model only selects between them. It is still a cross-border transfer under POPIA, the ground for it isn’t documented yet, and the labels aren’t stripped of proper nouns. Both are open items, and a scheme that wants neither can run the engine with the deterministic layer alone.

See the boundary hold, instead of reading about it.

The live demo runs three people — an owner, a tenant, a trustee — against one simulated scheme, so you can watch exactly what each one can and cannot open.