Tallify handles the most sensitive information a practice holds: who its clients are, what they earn and own, what cover they have and what advice they were given. This page sets out where that information lives, what leaves the practice server, what never does, and how the controls map to POPIA and FAIS. It is written to be read by a compliance officer or an IT reviewer and to be reused in a practice's own records.
In one paragraph
Every identifiable record lives on one dedicated server in South Africa, either the practice's own or one Tallify operates for that practice alone. Reading documents, extracting client facts and search all run on models on that server. The only external processing is the drafting step, and before it runs the software removes names, identity numbers, dates of birth, contact details and addresses from the structured facts and scrubs them from free text, for the client and the spouse. The name goes back in on the practice server. Nothing is filed and nothing is sent to a client without a named person approving it, and every change, sign-in and communication is logged.
Where it runs
Your own server
A GPU server on the practice's premises or in a South African data centre, joined to the practice's private network. The practice owns the hardware and everything on it. Tallify installs and updates the software over the private network and has no standing access to client data beyond what the practice grants for support.
Hosted by Tallify
Dedicated infrastructure in South Africa that Tallify operates for that practice alone, under an operator agreement, with the same controls. No practice shares a server, a database or a backup with another. The practice remains the responsible party under POPIA and Tallify acts as its operator in the POPIA sense, on written instructions.
What there is not
There is no multi-tenant cloud, no shared database and no public login page. The console name resolves only inside the practice's private network.
How client data moves
On-premise extraction
When an advisor sends a photographed form, a PDF, a Word file or typed notes, the file is stored in the practice vault and read by a vision model that runs on the practice server. That model fills a structured schema: personal details, spouse or partner, dependants, income, expenses, assets, liabilities, cover, retirement contributions, objectives and risk profile, plus a list of contradictions and gaps. A second local pass compares the extraction with the source and flags disagreements for a person to resolve. Totals, loan terms, projections and a tax position are calculated on the server. At no point in intake does the file, the image or an identity field leave the practice.
De-identification before drafting
Drafting the Record of Advice and needs analysis is the one step that uses an external model. Before the request is built, the software:
- removes the identity fields from the structured facts: full name, identity number, date of birth, email address, phone numbers and physical address, for the client and for the spouse or partner;
- scrubs free text (notes, objectives, contradictions, the intake caption) by replacing every occurrence of those values and the names with "the client" and "the spouse", full names first so that partial matches cannot survive;
- recurses into nested structures so that a name inside a list of beneficiaries or a note on a liability is caught as well as a top-level field;
- sends dependants as relationship and age only, and health matters only as they bear on cover ("no severe illness cover"), never as a diagnosis;
- writes the documents with placeholders such as
{{CLIENT_NAME}}, which are substituted on the practice server after the model has finished.
The practice's evaluation suite runs five fictional cases through the whole pipeline and asserts that no identifier appears in the de-identified box. The first run of that suite found a nested-dictionary leak, which is why the scrub recurses; the assertion has passed on every release since. A practice can run the suite on its own server at any time.
The model provider is Anthropic PBC, used through its API under terms that exclude training on customer data. Because the payload contains no identifiers it is not personal information in the POPIA sense, and section 72 on cross-border transfer is engaged only as a matter of caution; practices are advised to record Anthropic as a recipient of de-identified data in their own records.
Access control
- Network. The console is reachable only over the practice's private network (Tailscale), over HTTPS with a certificate for the practice's console name. Machine callers use per-service tokens that never accept a browser session. The only public endpoints are a signed webhook for WhatsApp delivery, which accepts nothing from unregistered numbers, and a health check that carries no data.
- Accounts. Usernames are email addresses. Passwords are hashed with PBKDF2-SHA256 at 200 000 iterations with a per-user salt. A password set by an administrator is temporary and must be changed at first sign-in. Minimum length applies with at least one letter and one digit.
- Sessions. HttpOnly, SameSite, Secure cookies; twelve hours idle and seven days absolute; sign-out-everywhere; changing a password ends every other session.
- Rate limiting. Five failed sign-ins in fifteen minutes, per address or per username, block further attempts for the window. Failures and blocks are logged with the source address and survive a restart.
- Roles. Administrator, advisor and read-only, enforced in middleware. Deletes and user management are administrator only.
- Advisor scoping. A user scoped to an advisor sees and changes only that advisor's clients across every register, the approval queue, intake, and file downloads. Attempts to reach other clients are refused and logged.
- Cross-site request forgery. Browser writes must carry a request header the console sets; a cookie alone is not enough.
- Intake allow-lists. Intake is accepted only from a registered phone number or Telegram account; email approvals only from a registered advisor address, and the decision line must be exactly "Approved" or "Rejected".
The approval gate and consent
Nothing reaches a client without a named advisor: fund notices, replies to client emails and confirmations all wait in the approval queue. A communication is drafted only for a client whose consent to receive communications has been recorded, the skip is logged when it has not, and consent is checked again at the moment of sending. Withdrawal is a single flag that takes effect on the next run. No advice is given by automated means; the FAIS representative signs every Record of Advice, and every draft is marked as not valid until reviewed, amended and signed by the adviser.
Audit and evidence
- Every request that changes something is written to the audit log with user, method, path, outcome and time. Automated callers are recorded as the caller and the advisor they acted for.
- The communications log holds the exact text of every drafted, approved, rejected and sent message, with the approver.
- The advice registers keep every version of every Record of Advice and needs analysis; a new version supersedes, nothing overwrites.
- Controlled vocabularies, date and number validation and identity resolution at intake keep records accurate, which is condition 5 of POPIA in practice.
Together these produce what a regulator or a compliance officer asks for: who did what, when, what the client received, and on whose approval.
Backups and continuity
A consistent snapshot of the database and an archive of the whole vault are taken twice a day and kept permanently on the practice server. A second machine on the practice network can pull every backup it does not yet have, once a day, with nothing ever deleted on either side. Restores are tested and recorded; a practice-sized restore takes seconds. A monitor checks the service, the local models, disk, backup age, job completion and network state every fifteen minutes and alerts on change.
POPIA conditions, mapped
| Condition | How Tallify meets it |
|---|---|
| 1. Accountability | Named roles and scoping; every change logged to a named user; the practice's information officer named in its notice. |
| 2. Processing limitation | Lawful basis is the advisory relationship; consent governs communications; identity stripped before external processing; notices carry a first name and a holding value only. |
| 3. Purpose specification | Purposes stated in the privacy notice: advice records, needs analysis, monitoring, factual updates, regulatory record keeping. Advice records retained for the FAIS minimum of five years, versioned not overwritten. |
| 4. Further processing limitation | No marketing, profiling for sale or model training. The only external processing is drafting on de-identified data, compatible with the advisory purpose. |
| 5. Information quality | Second-pass verification; controlled vocabularies; date, number and identity-number validation; identity resolution against the register; every draft marked as requiring review. |
| 6. Openness | A public privacy notice covering website visitors and practice deployments; reusable wording for the practice's own client notice. |
| 7. Security safeguards | Residency in South Africa; private network only; hashed passwords, session limits, rate limiting; role and scope checks; TLS to the model provider with a de-identified payload; twice-daily backups; monitoring; secrets outside code; full audit. |
| 8. Data subject participation | Every record visible and editable in the console; deletion an audited administrator action; consent flag for objection; no decision affecting a client made solely by automated means. |
Special personal information
Health information can appear in meeting notes. It stays on the practice server and reaches the drafting model only as it bears on cover. Children appear as relationship and age. Advisors are asked to keep clinical detail out of notes unless it changes the advice.
FAIS
The Record of Advice is drafted to the ten sections of section 9 of the General Code of Conduct, with the products considered, the recommendation and its reasons, and the replacement comparison where one applies. The advisor reviews, amends and signs; the signed document is filed on the register with its version history; records are kept for at least five years. Tallify does not give advice and is not a financial services provider; the representative remains responsible for the advice.
Third parties
| Party | Role | What it receives |
|---|---|---|
| Anthropic PBC | Drafting model, by API | De-identified facts only; no training on customer data under its API terms |
| Twilio Inc. | WhatsApp delivery | Message content and phone numbers in transit for intake and replies, when the practice uses WhatsApp |
| Telegram | Intake channel | Message content and account identity in transit, when the practice uses Telegram |
| The practice's mail provider | Advice mailbox | Emails to and from advisors and clients |
| Tailscale | Private network | Connection metadata; encrypted end to end, no content |
Practices that choose their own server can substitute their own mail provider and private network. Fund price vendors deliver files to the practice server and receive nothing.
Incidents and support
Security incidents are handled under BlueBird Digital's incident response policy and the practice is told without undue delay, with what is known, what was affected and what has been done, so that it can meet its own notification duties under section 22 of POPIA. Support is by email to michael@tallify.co.za during South African business hours. Reports of a vulnerability are welcome at the same address.
Read more
The documentation covers the day-to-day: consent, the approval queue, the audit log, backups and scheduled jobs. The privacy notice and terms of use set out the legal position, including the operator arrangement for hosted practices.