Built for financial data — and specific about how.
AgencyTier holds real financial information: policies, premiums, commissions, client details. Most vendors answer that with a page of reassuring adjectives. This page names the actual controls instead — where each one is enforced and what it does — because you may have to vouch for this software to a carrier or a compliance officer, and an adjective is not an answer you can pass along.
What is true today.
Each of these is implemented and checked against the codebase, not planned.
Every agency is isolated at the database
Row-level security is enforced in Postgres itself, not in application code — so an agency cannot read another agency's book even if the app were wrong. Access follows the hierarchy you actually built, and upline visibility is read-only and granted by consent from below.
Encrypted in transit, everywhere
TLS on every hop, verified by audit rather than assumed: no service reaches anything over plain HTTP, the client talks to the database over TLS, and the site is served over HTTPS.
Encrypted at rest
AES-256 disk encryption on the managed database, always on. The highest-risk records carry a second layer of field-level encryption with a per-agency key, so that data is ciphertext even inside the database.
The most sensitive identifiers are never stored
No social security numbers. No account numbers. No driver's licence numbers. The strongest control available for a class of data is not to hold it, and for these we do not.
An append-only audit log
Sensitive record access is written to a log that cannot be updated or deleted, even by the application. Cross-agency reads and the highest-risk records are audited individually.
A server-side MFA gate on client data
The check sits in the database in front of every read and write of client information, rather than in the interface where it could be bypassed. It is built and switches on before the platform carries real client data.
Your agency’s book is yours alone.
A downline is not one company. Every agency on the platform is isolated from every other, access follows the hierarchy you actually built, and an upline sees only what consent below grants them — read-only, and never a back door into another agency’s book.
What each role sees
Agent
Their own journey and their own book
Trainer
Milestone requests, path progress
Agency owner
Production, downline, aggregate signals
Upline
What consent below grants — read-only
Another agency
Anything of yours
Why the controls are shaped this way.
A list of controls tells you what exists. These are the choices that decide whether they hold up — where enforcement lives, what data never gets collected, and who has to grant access before anyone gets it.
Isolation is enforced below the application
Tenant scoping lives in Postgres policies that run as the calling user, so a query cannot opt out of them. A write that names the wrong agency is rejected by a database trigger as a second line of defence, and the isolation rules are covered by their own test suite rather than assumed to hold.
The riskiest identifiers are designed out
Social security numbers, account numbers and driver's licence numbers are not collected, not stored and not derivable. A control you can remove entirely beats a control you have to operate, so for these three we removed the data.
The MFA gate is a database condition, not a screen
The second-factor requirement is built as a condition on the tables that hold client information rather than a step in the interface, so a direct API call cannot route around it. Like the rest of this list it switches on before the platform carries real client data — the point being where the check lives, which is not somewhere it can be skipped.
Upline visibility is granted, never assumed
An agency above you in the hierarchy does not get a key to your book. Visibility is read-only, scoped to the hierarchy you actually built, and comes from consent given below — and cross-agency reads are written to the audit log individually.
Your data leaves as easily as it arrived
An agency owner can generate a full export of their own records and download it, without asking us and without a support ticket. We would rather keep you because staying is worth it than because leaving is difficult — and being able to take the whole book out is also what makes an isolation claim something you can check.
The claims on this page are audited against the code
Every statement here is checked against the platform's own security posture tracker and its migrations before it ships. In August 2026 that review pulled three claims off this page. We would rather do that than leave them up.
Bring your compliance questions.
We would rather answer the hard ones on a call than have you find out later that we skipped them.