Trust
FinBoss is an AI team for financial advisers. The AI drafts; a person approves; every external action carries an approval and lands in an archive. These pages describe how that works, who processes your data, and the terms we sign.
AI use and controls
Which models, where a human reviews, what is logged, how fabricated figures are caught, and what the AI is not allowed to do.
Subprocessors
Every third party that can touch firm or client data, what it receives, where it runs, and its retention terms.
Data processing addendum
The template we sign with every paying firm: roles, security measures, breach notice, deletion, subprocessor changes.
The short version
- · Your firm is a data island. Every table is scoped by firm with row-level security; a job or a query cannot cross firms by construction, and an automated suite proves it on every schema change.
- · Nothing leaves without a person. Emails, posts and changes to the client record are proposed by the AI and approved by someone your policy names. The database refuses a send whose approval does not match the exact content.
- · Numbers come from an engine, not a model. Projections use versioned, deterministic tools with visible assumptions. The AI narrates and is checked against the results.
- · Everything is on the record. An append-only, hash-chained audit log; a communications archive with the final content, recipients, disclosures and approval; export on demand.
- · Model providers keep nothing. Zero-retention API terms; no training on your data; prompts carry an opaque household id, not names with account numbers.
- · Adversarial input is data. Documents, transcripts and emails are passed to the model as delimited data, screened for planted instructions, and an eval suite with injection canaries runs on every change.
Programme status
| Tenant isolation suite (pgTAP) on every migration | In place |
| Golden-task evals with injection canaries in CI | In place (30+ tasks per playbook) |
| Hash-chained audit log with verification | In place |
| Point-in-time recovery and restore drill | PITR enabled; drill runbook written; first drill scheduled for the beta quarter |
| Security review against the database advisor | Done 2026-09-29; findings fixed |
| External penetration test | Before general availability, then annually |
| SOC 2 Type I | Three months after general availability; Type II within twelve |
| Incident response runbook with 72-hour customer notice | Before beta |
| Cyber insurance | Before general availability |