Trust
Your clients stay yours. Your practice stays yours.
Practice owners care whether another firm can see their book, whether an adviser can wander into a colleague’s clients, and whether the software pretends work was done when it was not. This page answers that — in plain language first.
What it means for you
Boundaries that match how advice firms work
Four separations that matter on a normal day.
| Layer | What you should feel | If something goes wrong |
|---|---|---|
| Practice | Firm A’s clients never appear in Firm B’s login | The database refuses the rows — not only the menu |
| Adviser book | Own-book advisers only see their clients and earnings | Writes and reads are blocked for out-of-book clients |
| Role / module | People only get the work their role is meant to do | Routes and screens deny access |
| Portal area | Practice vs head-office access is intentional | A forged cookie does not open a portal |
Controls
How we back those promises
Still plain language. The product team can show the technical controls in a security review.
Practices do not see each other
Each practice’s data is separated at the database. A bug in a screen is not enough to pull another firm’s clients.
Advisers stay on their own book
When a role is limited to own clients, that limit is enforced when data is read and written — not only by hiding a menu item.
Access grants are hard to forge
Who may enter practice, head office or other areas is carried in a signed cookie. A made-up cookie does not open doors.
We do not pretend a message was sent
If email, signing or banking is not set up, the product says so. It never reports a successful send that never left the building.
Errors do not leak internals
Technical failure detail stays inside the system. Callers see a clear, safe message — not a stack trace.
Production cannot “accidentally” run in demo mode
Deploy checks refuse live-like environments that still have open demo switches, including missing field encryption for ID and tax numbers.
Browser protections stay on
Modern content security rules limit what scripts can run. That is boring by design — and hard to turn off by mistake.
We test the doors, not only the happy path
Routes are covered by automated tests that must reach a real server. Treating a crash as a pass is not allowed in our bar.
Honesty
What we will not claim
Trust is also knowing where the brochure stops.
- We do not invent customer counts or “zero risk forever” claims.
- Missing email, signing or banking configuration is shown as not set up — never as a successful send.
- Production-like environments cannot leave demo switches on by accident.
- Sensitive identity fields are meant to be encrypted at rest when the product is live.
Bring your security questionnaire to the demo
We will walk boundaries in the product, not only on a slide — and answer vendor review questions without the jargon first.