Trust depends on understandable controls and evidence of how they work. Explore access, financial checks, history, sign-in and recovery, together with their current limits.
TRELVERIQ Governance combines scoped access, organisation isolation, balanced accounts, protected history and encrypted backups. Approval policies include explicit small-team exceptions. These controls are not an independent security assessment.
Collectors and treasurers are mostly volunteers. These controls let them show where every payment went.
By default, the person who raises a money item needs another eligible person to decide it. Configured small-team mode allows a supported self-approval only when no other eligible checker is available, and records the exception. Distinct-step, excluded-party and other-committee requirements still apply.
Each organisation chooses its approval steps and money limits, for example the treasurer first and the president above a set amount.
Every committee keeps double-entry accounts, and every entry must balance. A posted journal cannot be edited or deleted: a mistake is fixed by a reversal that stays visible beside the original. By default a journal needs a reason, and a voucher can need an attachment above an amount the committee sets.
A committee can lock a period so that nothing changes in a closed month, and unlocking it needs a second person’s approval. Closing the year shows a preview first.
Important changes leave history entries with the actor, event and protected record identifiers. History is held separately with tamper-evidence and verification controls; signed checkpoints and retention safeguards support review.
The application’s database account cannot change or delete entries, and a database rule blocks edits for every account. The entries of an organisation are chained: each one holds a SHA-256 fingerprint that includes the one before it, so a change made behind the system’s back breaks the chain, and a check function reports the first entry that does not match.
Good to know. Tamper-evidence helps detect a change; it is not a promise that an administrator with unrestricted infrastructure access could never interfere. Historical entries are not rewritten by ordinary application edits.
Money can be kept in separate funds, such as Relief, Zakat or Building. A restricted fund lists its purposes, and a voucher or expense claim paid from it must name one of them. Fund statements show what came into and went out of each fund.
A campaign’s closing report needs approval, and the person who prepared it cannot approve it.
How records are separated, encrypted and protected from people who should not see them.
Every table that holds an organisation’s records has a database rule, called row-level security, that lets a request see only the rows tagged with its own organisation. The organisation is set inside each database transaction. The application connects with a database account that does not own the tables and cannot switch the rule off. If no organisation is set, no rows come back.
This is a second line of defence behind the application’s own checks, and the database itself enforces it. Which committees a person may see inside their own organisation is checked separately, using the committee tree and the person’s role. A request for a record the person may not see is answered “not found” and written to the audit log.
Good to know. The project’s checklist for every new endpoint includes tests for access across organisations and between sibling committees.
These kinds of details are encrypted in the database with AES-256-GCM, with a key made from the server’s secret key:
Each value is tied to its organisation and its field name, so a copied value will not open anywhere else. Looking up a member by phone number compares a keyed fingerprint (HMAC), never the clear number. The links and QR codes on membership cards, receipts and tickets are signed, so they cannot be forged.
Good to know. The keys are held as settings on the server, not in the database, and can be rotated with a job that can be resumed. There is no managed key vault yet and no separate key for each organisation. Encryption of the server disk depends on the hosting and is not part of TRELVERIQ Governance’s software.
Documents and photos are scanned with ClamAV before they are saved, and the file type is checked from the content, not only the name. In production the server refuses to start without the scanner, unless that is switched off on purpose.
An organisation administrator can grant named, time-limited support access with a reason and a defined scope, then end it early. Support actions remain attributable in history.
Good to know. Money moves, approvals and exports are never available to support access.
Backups you can restore, and the protections the web app sends to every browser.
Every night (02:00 UTC by default) and once when the service starts, the database is dumped and encrypted with AES-256 (OpenPGP). The unencrypted dump is never written to disk. Each backup is decrypted again and its table of contents is read to prove it is usable. The newest 14 days are kept on the server. If an off-server store is set up, which can be any S3-compatible service, each backup is copied there too and kept for 30 days. The backup service reports itself unhealthy when no fully successful run has finished in 36 hours.
Recovery checks have restored encrypted snapshots into disposable databases and checked financial invariants and history verification. A successful local restore is separate from an off-site recovery drill on production-sized data.
Good to know. The recovery point is the last nightly backup, so up to 24 hours of data can be lost. There is no point-in-time recovery yet. The keys for encrypted fields and the backup passphrase are not inside the backups and must be stored apart from them. A drill from an off-server copy with real data has not been recorded yet.
Every page is sent with security headers. The main ones are:
How scripts are authorised
Pre-built pages allow their specific inline scripts by SHA-256 hash. Request-rendered pages use a fresh nonce. Production script-src does not use unsafe-inline when the required build manifest is present.The policy restricts code and connections, blocks framing and disables plug-ins. Configured payment-provider assets have narrow exceptions. The exact header depends on the page and deployment.
Good to know. Inline styles remain permitted. Deployment checks must include the generated script-hash manifest; the development policy and missing-manifest fallback are less restrictive.
Other measures that are in place:
How people prove who they are, and how that is protected.
Members sign in with their mobile number and password, or a supported passkey. Initial passwords must be changed before the app opens. Password hashes are salted and memory-hard; password changes revoke existing sessions. Phone-code recovery needs configured delivery gateways.
Organisation members can choose an authenticator, without an organisation-wide setup requirement. Platform operators complete MFA and may trust a verified browser for up to 90 days. Password changes, authenticator changes or a new browser can require verification again.
After sign-in, the app keeps a short-lived access pass (15 minutes) in memory only. A longer-lived refresh token sits in a cookie that scripts cannot read. That cookie is sent only to the same site and only to the sign-in routes, and the token is replaced each time it is used. If an old token is used again, which suggests it was stolen, the whole chain of sessions is revoked and the event is logged.
On a computer the app signs out after 30 idle minutes by default, and an installed phone app can stay signed in for up to 30 days. The admin can change both. A “My devices” page lets a person sign out a lost phone. Signing out is blocked while unsent offline receipts are still on the phone.
By default, one phone number can ask for 5 codes an hour and one network address for 20. After 5 wrong codes from one address, that address is blocked for that number for 15 minutes. After 20 wrong codes from all addresses together, the code is withdrawn. A new code cannot be asked for within 30 seconds of the last one.
Hourly caps on code deliveries, for the whole system and for each country calling code, limit abuse that would run up SMS costs. All other requests are limited per network address, to 1,200 a minute by default, and public receipt and registration links are limited too.
Tools for members and organisations to get their data out, corrected or erased.
From their own page a member can ask for a copy of their data (a JSON file and a PDF, with a link that expires after 7 days), for a correction of details such as name, date of birth, email or address, or for deletion. The organisation’s handler gets a work list with a due date, 30 days by default, and a reminder 5 days before it. A correction or a deletion needs a second handler to approve it.
Deletion anonymises the member in every record that holds their details, such as dependants, nominees, documents, payer names on receipts and messages, while keeping amounts, dates and numbers so the accounts still add up. Financial records are purged after the retention period, 10 years by default. Records that are not linked to a member, such as non-member donors, walk-in payers and guests, can be found and erased by the handler. An organisation can also export all its data as a zip with a CSV for each table, with a link that expires and a checksum list.
Good to know. Erasure does not reach the audit history, free text typed into posted money records, or claim documents until the retention period ends. Beneficiary records have their own delete action. The data-copy PDF uses basic Latin fonts, so letters from other scripts print as question marks; the JSON copy is exact. The organisation export leaves out files over 150 MB.
Review these alongside the controls when deciding how to introduce the platform.
Create your organisation and set it up with a few members, or read the questions and answers first.