One database per brokerage
Every brokerage is set up with its own dedicated Neon Postgres database. Your clients, enquiries, and files physically live apart from every other brokerage, not in shared tables separated only by a column.
Security and trust
Built in and by designStraight answers for your security review.
You're trusting us with your clients' financial lives, so here are the direct answers: where your data lives, how the AI agent stays inside the advice boundary, and how every automated action is recorded. We don't hold SOC 2, ISO or PCI certification, and we won't pretend otherwise. We'll show you exactly what is built instead.
Data isolation
Your data lives in its own database, never shared with another brokerage.
Your brokerage gets its own dedicated database. The only thing in the small platform database is reference and routing data, plans, staff logins, and the lender and loan-product catalogue. Your clients' data never sits next to another brokerage's.
Private file storage, not a shared pool
Uploaded documents go to that brokerage's own private, isolated file storage. There is no shared pool to read across, so one brokerage's files are never a lookup away from another's.
No shared pool to leak through
There is no shared table to leak from, so the most common data-leak path in shared systems, a forgotten filter exposing another brokerage's rows, cannot occur by construction. Links between the platform database and a brokerage's own database are immutable string identifiers, not live relationships, so no query path reaches from one brokerage into another. This is a structural data-separation guarantee against the shared-pool leak, not a claim that no software bug of any kind can ever exist.
Data residency
Your residency rules are honoured in code, not on a promise.
Every AI provider and model an agent can use comes from a platform-curated catalogue, filtered by your per-brokerage residency setting. If you operate where external providers or data retention are restricted, you're served within those limits, and nobody can point the AI at an arbitrary, un-vetted model.
Residency rules follow your market
Data-residency rules vary by industry and country, so they follow the module built for your market, not one hardcoded setting for the whole platform. The Australian mortgage module carries its country's residency posture; a future module for another country brings its own.
Fail-closed by default
Across the platform, doubt resolves to the safe action. A call that cannot resolve its language, market, or policy will not start, and a trace the platform cannot confidently place is dropped rather than sent.
Deterministic AI compliance
The advice boundary is enforced by code, not by a prompt.
The shortcut is to write compliance rules into the AI's prompt and hope the model obeys. A prompt instruction is a suggestion, not a guarantee. TomoBroker pins the boundary to deterministic code the model cannot argue with.
There is no advice feature
The AI agent does not give personal financial advice. There is no "advise" or "submit" action for it to call, so it cannot recommend a specific loan, assess suitability, or lodge anything, even when a client pushes for it. It hands off to an accountable broker instead.
Disclaimers are set by your market, verbatim
Two deterministic guards run every turn: an input-side guard matches a client's message against the disclosure rules for your market and forces the required disclaimer plus a human-handoff offer; an output-side guard redacts regulated-advice phrasing from the AI's free text. When voice is enabled, the required disclosure is spoken word-for-word and guaranteed to complete. None of it is generated by the model, so it cannot drift or be talked out of.
Deterministic tools do the maths
Dates, calculations, matching, and state changes run in deterministic tools, not in the model's free text. The model cannot invent a rate, a repayment, or a date, because those come from the same engine the dashboard uses.
Audit and transparency
Every automated action is recorded and reconstructable.
When the AI acts, it runs on the same rails your team does: one brokerage, one enquiry, the same permissions and audit trail. Every action is attributable, which actor, for which client or enquiry, under which market, with which model, and you can reconstruct it long after the fact.
What is recorded
- Append-only AI agent sessions and turns record what the agent did, turn by turn: every message, every tool call with its inputs and outputs, and every fact it extracted, attributed and immutable, with that fact's source and verification status.
- An append-only ledger records every model call, which provider and which model, for cost and accountability.
- Immutable point-in-time snapshots freeze what the broker saw at a moment in time, for example the matched loan products and their rates the instant an enquiry was qualified, so "what did the broker see then?" can always be reconstructed.
- A model-selection stamp on every run records the provider, model, and settings actually used, so a run can be audited and replayed.
What staff can see
We improve the AI without reading your clients' conversations.
Observability is built to watch the platform without harvesting private financial conversations. Content stays off unless someone deliberately turns it on for a brokerage.
Content is off by default
When AI-run traces are exported for observability, the system sends identifiers and classifications, not the conversation. Content is turned on only when an operator deliberately enables it for a specific brokerage; it is never on by default.
Per-brokerage telemetry isolation
Each brokerage's traces go to that brokerage's own separate project, carrying the dedicated-database isolation through into monitoring. Export is fail-closed: a region mismatch or a registration the platform cannot verify means the trace is discarded, not sent to the wrong place.
Redacted logs, masked secrets
Logs are redacted of secrets and personal information. Secret masking strips credentials from anything exported while leaving legitimate content intact. The cost and usage ledger records metadata about model calls and refuses content-bearing fields; it never stores the conversation.
Honest note: V1 ships with no live external monitoring instance connected, a null sink. Connecting a real one, and ever enabling content, are deliberate operator steps, not the default.
On certifications
The plain answer, up front.
TomoBroker holds no SOC 2, ISO, or PCI certification to cite, and we do not claim one. The posture on this page is built into the platform and by design, not externally certified or audited. We would rather say that plainly than imply a compliance badge we do not hold.
- No SOC 2, ISO, or PCI certification
- Facilitates compliance, does not replace it
- Nothing here is legal advice
- The broker and licensee stay accountable
Due-diligence Q&A
The answers your security review needs.
Short, honest answers. Anything not covered here, ask us and we will send you the detail.
Each brokerage is set up with its own dedicated Neon Postgres database and private, isolated file storage. Your clients, enquiries, and uploaded files live apart from every other brokerage. A small platform database holds only reference and routing data, plans, staff logins, and the lender and loan-product catalogue, and never holds one brokerage's client data next to another's.
Security and trust
Bring your compliance team the answers up front.
See the isolation, the audit records, and the AI guardrails on a call, and ask us anything the page did not answer. Book a demo, or start free and explore the platform yourself.