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 server in South Africa: one the practice controls, or one Tallify operates for it. Each practice is its own installation, with its own database, document vault and backups. Before anything leaves the server for an outside model, the software removes names, identity numbers, dates of birth, contact details and addresses on that server by code, and a fail-closed check stops any request that still carries them. Claude, from Anthropic, reads the de-identified facts and drafts the Record of Advice, the needs analysis, client replies and fund-movement notices, and the weekly cover briefing, and reads the free-text answers of a fact find that the rules on the server could not read (a practice may choose rules only); the names go back in on the practice's server. Local models on the server build the search index, run an extra check for names before anything is sent to Claude (without one running, the code's own removal and the check still apply), read an uploaded Astute CCP report, and read the assisted channel (photos and notes sent over WhatsApp or uploaded in the console); nothing they read leaves the server, and the onboarding fact find does not depend on them. Messages and emails the practice sends and receives pass through its WhatsApp and mail providers, listed under Third parties. Nothing is filed, and no drafted reply, reminder or update goes to a client, without a named person approving it, unless the practice chooses to let a kind of WhatsApp notice go without approval (none does by default); the practice's templated emails (onboarding pack, review sheet, signed-letter copy, receipts, welcome) wait for approval too, and only the one-time signing code goes at once. Every change, sign-in and communication is logged.
Where it runs
A server the practice controls
The practice's own hardware or a private server it rents in South Africa, joined to the practice's private network. A GPU is needed only if the practice uses the assisted channel; without one, the names check and the Astute CCP reader fall back to code. The practice owns the server 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 in South Africa
A server in South Africa that Tallify operates, under an operator agreement, with the same controls. Each hosted practice is its own installation, with its own database, document vault, backups, services, settings and sign-in. One server can run several practices' installations side by side. Client data, vaults and backups sit on an encrypted volume. The practice's console has its own web address, reached through a Cloudflare tunnel. The practice remains the responsible party under POPIA and Tallify acts as its operator in the POPIA sense, on written instructions.
What is never shared
No practice shares a database, a document vault, a backup or a sign-in with another practice.
How client data moves
Identity never leaves
Everything that identifies a client is kept on the practice's server and never sent to an outside model: names, ID numbers, dates of birth, contact details, addresses, policy and account numbers, and the ID and proof of address the client sends through the onboarding link. The fact find the client completes through that link is read by code on the same server, so the identity in it is known field by field before anything else happens.
Before any request is sent to Claude, that identity is removed by code. A leak check then looks again, for the names on file and for any email address, ID number, phone number or policy or account number. If anything is still there, the request is not sent: a draft stops, with an error that names no identity, a fact-find answer stays on the server for the adviser to read, and a fund notice or the weekly cover briefing is shown as withheld, with the reason.
What Claude receives is the case without the person: ages, relationships, marital regime, income, expenses, assets, liabilities, existing cover, goals and risk profile, with the people named by role ("the client", "the spouse"). The figures the needs analysis rests on are calculated on the server by code. Claude reads those facts and writes; the names go back in on the practice's server after it has finished. When a fact find arrives, its free-text answers that the rules on the server could not read (a note, the wording of a goal) are scrubbed the same way and sent to Claude to place in the right fields; it never overrides an answer, and a practice may choose rules only.
How identity is removed
Before a request to Claude 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, the spouse or partner, children, beneficiaries and anyone else on the file, and the adviser's own name;
- scrubs free text (notes, goals, contradictions, captions) by replacing every occurrence of those values and the names with roles such as "the client" and "the spouse", full names first so that partial matches cannot survive, and removes email addresses, ID numbers, phone numbers, policy and account numbers and long digit runs wherever they appear;
- 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, never by name or date of birth;
- asks a local model on the server, where one is running, to list any other people the free text names, so a name that stands beside no relation word is removed too; without it the code's own passes and the leak check still run;
- writes the documents with placeholders such as
{{CLIENT_NAME}}, which are substituted on the practice server after the model has finished.
Every release passes a test gate before it is deployed. The de-identification tests put fictional clients with planted names, ID numbers, contact details and everyday words that are also names through the whole pipeline, and assert that no request carries anyone on file. An early run found a name inside a nested list, which is why the scrub recurses.
The model provider is Anthropic PBC, used through its API under commercial 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.
Local models and the assisted channel
Local models run on the practice's server, and the files they read never leave it. They build the search index, make the names check above, read an Astute CCP report uploaded on an intake, and read what comes through the assisted channel. The onboarding fact find does not depend on them. A GPU is needed only if the assisted channel is used: without one, the names check and the CCP reader fall back to code.
The assisted channel is for an adviser who has a photo of a form, a PDF, a Word file or typed notes rather than a completed fact find. The adviser sends it over WhatsApp or uploads it in the console, and a model on the server reads it into the same fact-find fields, then makes a second pass against the source and flags disagreements. There is no accuracy promise: every figure is checked by the adviser on the review form before the client is committed, and the form will not commit while a flag is open. The assisted intake documentation covers the details.
What is open to the internet
| Surface | Who uses it | How it is protected |
|---|---|---|
| The practice's sign-in | Advisers and staff | On a practice's own server, reachable only over its private network. On a hosted practice, its own web address. Either way: a hashed password, five failed tries in fifteen minutes block the address (twenty block the username, and its owner is emailed), and a six-digit code sent by email after the password. |
| The client's onboarding link | One client | A personal link carrying 32 random bytes; only its hash is stored. It expires after 30 days and a new link cancels the old one. Each link and each address is rate limited, and signing the disclosure letter needs a one-time code sent to the client's email address. |
| The sign-up form | New clients | Rate limited per address and overall, a hidden honeypot field, a size limit, and no new sends accepted while ten wait in the queue. An email address, cell number or ID number typed here is never taken as proof of who sent it: a form matched that way is flagged for the adviser to confirm, an ID number alone links it to nobody, and it does not count as the client's fact find until the adviser commits it. |
| connect.tallify.co.za | The practice, once, to connect its WhatsApp number | A one-use link an administrator creates in the console, valid for seven days; only its hash is stored. The Meta sign-in is checked on the server against the practice's WhatsApp Business account, and Meta's own callbacks are signed and checked. |
| The WhatsApp webhooks | Twilio and Meta | A request larger than a webhook needs is refused before it is read, and the signature on every request is checked; an unsigned or wrongly signed request is refused. |
Besides these, a health check that carries no client data, and the practice's blank disclosure letter, blank fact-find spreadsheet and logo, which the pack email and the sign-up page link to and which hold no client data.
Access control
- Network. Browsers reach Tallify only over HTTPS. On a practice's own server the console is reachable only over the practice's private network (Tailscale). A hosted practice's console has its own web address, reached through a Cloudflare tunnel, behind the sign-in below. Machine callers use per-service tokens, checked in constant time, that never accept a browser session; the mail poller acts only as the adviser it names.
- Sign-in code. After the password, a six-digit code is sent to the user's email address, in the body of the email, never its subject. The sign-in waits 30 minutes for it and allows five tries in all; a new code can be sent at most three times in ten minutes and does not add tries. A device can be remembered for 30 days; signing out everywhere forgets every remembered device, a new password forgets every other one, and a temporary password set by an administrator forgets them all. A sign-in that emails a code can be started six times an hour and twenty times a day for one username.
- 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. Passwords have at least ten characters with a letter and a digit; the 1,000 most common passwords, the username and the practice's name are refused.
- Sessions. HttpOnly, SameSite, Secure cookies, under a __Host- name on HTTPS so no other site can set or replace them; the server keeps only a hash of each session's cookie and clears ended sessions every minute; 30 minutes idle by default (the practice can change it) and seven days absolute; signing out is a button, never a link another site could trigger; sign-out-everywhere; changing a password ends every other session, and a temporary password is removed from the server once it has been changed.
- Rate limiting. Five failed sign-ins in fifteen minutes from one address block that address for the window; twenty on one username block that username in any browser that has not signed in with it before, and email its owner, so nobody can hold an adviser out of their own browser. A wrong current password when changing a password counts the same. Each try is counted before the password is checked, so tries sent at the same moment cannot slip past the limit, and the address is the one our own proxy saw (an IPv6 connection counts as its whole network block). Failures and blocks are logged with the source address and survive a restart.
- Limits on drafting and sending. An intake has one draft at a time. One person can start ten drafts an hour, and a practice forty a day, with a daily limit on what its drafting may spend on Claude (US$25 by default); the practice can change each number. A refused draft says which limit was reached and when drafting opens again, and the first refusal of the day for each limit alerts Tallify. One person can also send thirty fact-find packs and start ten market updates an hour. These counts, and those of the sign-up form and the onboarding link, are kept in the practice's database, so a restart does not reset them.
- Roles. Administrator, adviser and read-only, enforced in middleware. Deletes and user management are administrator only.
- Adviser scoping. A user scoped to an adviser sees and changes only that adviser's clients across every register, the approval queue, intake, and file downloads. Attempts to reach other clients are refused and logged.
- Server accounts. Tallify's services run under their own unprivileged account, each with a private temporary folder and no way to gain privileges. It can write the practice's data, but not the program code it runs, which belongs to the server's administrator account. Secrets sit in files outside the code that only the administrator and the service account can read.
- Cross-site request forgery. Browser writes must carry a request header the console sets; a cookie alone is not enough. The sign-in, sign-in code and sign-out forms carry a token that must match a cookie only this site can set, so another site cannot sign a browser in or out.
- Browser protections. Every console page and every client page is sent with a strict Content-Security-Policy: a script runs only if it came with the page and carries a value that changes on every load (the signing page also loads a PDF viewer from a public library, each file checked against a fixed fingerprint), and no other site can show a Tallify page inside its own. Pages also tell the browser not to guess file types, to send no referrer, and to keep the camera, microphone and location off; over HTTPS the browser is told to use HTTPS only.
- Uploaded files. A file is taken only when both its name and its first bytes say it is a kind the page accepts (a photo, a PDF, a Word or Excel file, or plain text where notes are typed), whether it is uploaded in the console or the onboarding link, emailed or sent on WhatsApp. Its size is counted as it arrives, so an oversized upload is refused before it is stored, and a Word or Excel file that would open to more than 40 MB is refused unopened. A spreadsheet is read only within fixed limits on rows, columns and sheets, however large a range it claims to fill, and one with more than 200 worksheets is refused.
- Who can send what. WhatsApp messages are matched to the register. Notes and documents from an active adviser's number become intakes. A message from a client or prospect on the register goes to their file, and when the client has consented to communications a reply is drafted for approval. Any other number gets one short neutral reply and nothing else happens. Fact finds and documents by email are accepted only from an active adviser or a registered client or prospect, and are acted on only when the practice's own mail server confirms the sender's domain (DMARC, DKIM or SPF); anything else is kept for the adviser and acted on by nobody. Email approvals come only from a registered adviser address, must carry the reply reference that went only to the adviser with the draft, and the decision line must be exactly "Approved" or "Rejected". Replies drafted to client messages are limited per sender and per practice each day.
The approval gate and consent
Replies to client emails and WhatsApps, review and birthday reminders, welcome messages, fund notices and market updates all wait in the approval queue until a named adviser approves them. A practice can choose, in writing, to send a kind of WhatsApp notice (a birthday greeting, for example) without approval; none is set by default. The practice's templated emails (the fact-find pack, the review sheet, the thank-you for a returned fact find or document, the signed copy of the disclosure letter, the welcome email) wait in a Review email approvals queue, where the wording can be edited before a named adviser sends them. The only message that reaches a client without an adviser's step is the one-time code for signing the disclosure letter, which the client sets off. Consent is checked when a message is drafted and again when it is approved. Every update the practice starts (fund notices, reminders, birthday and welcome messages, market updates) and every WhatsApp reply needs recorded consent, and the skip is logged when it is missing. A reply to a client's own email is drafted without it, because the client wrote first, and the fact-find pack goes because the person asked for it. Withdrawing consent is a single flag: it stops new drafts from the next run, and anything already waiting is refused at approval. 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. Opening a client's documents (drafts and filed records of advice, ID and FICA documents, fact finds, signed letters) is logged too, with the client. Automated callers are recorded as the caller and the adviser 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.
- A disclosure letter signed through the onboarding link carries a signature record page: the document fingerprints, the time in South African time and UTC, the signer's internet address and how the link reached them.
- 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 private 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 removed by code before any 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 processing by an outside model is Claude reading and drafting on de-identified data, compatible with the advisory purpose. |
| 5. Information quality | Facts read from the client's own fact find by code; a second-pass check and an adviser review of anything read through the assisted channel; 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; a private network, or a sign-in with a code sent by email; hashed passwords, session limits, rate limiting and drafting limits; strict browser security headers; uploads checked by content; role and scope checks; identity removed by code with a fail-closed check before anything is sent to the model provider; TLS to the model provider with a de-identified payload; signed webhooks; 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 a fact find or in notes. It stays on the practice server with the client's identity; whatever reaches Claude carries no identity. Children appear as relationship and age. Advisers are asked to keep clinical detail out of notes unless it changes the advice.
FAIS
The Record of Advice is drafted to section 9 of the General Code of Conduct, in the practice's own layout, with the products considered, the recommendation and its reasons, and the replacement comparison where one applies. Every draft is checked for the section 9 items, and filing is refused while an adviser flag is still open. The adviser 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 | What for | What it receives |
|---|---|---|
| Anthropic PBC (Claude) | Reads the de-identified facts; drafts the Record of Advice, the needs analysis, client replies and fund-movement notices, and the weekly cover briefing | De-identified facts only; no training on the data under its commercial terms |
| Twilio Inc. and Meta Platforms (WhatsApp) | WhatsApp messages to and from the practice | The message and the phone number, when the practice uses WhatsApp |
| Cloudflare, Inc. | Hosted practices only: the tunnel to the server, DNS and TLS termination | The hosted practice's web traffic. TLS ends at Cloudflare, so the traffic passes through Cloudflare's network |
| GoDaddy | Practice and Tallify mail: Tallify's mailboxes (such as advice@tallify.co.za, read over IMAP) and any practice or adviser mailbox hosted at GoDaddy | The emails sent and received |
| Tailscale | The private network for an own-server practice's console, and the relay that brings WhatsApp webhooks to the server | Network metadata; connections are encrypted end to end |
A practice can connect its own mailbox (Google Workspace, Microsoft 365 or GoDaddy), and its own mail provider then carries its client email. Fund price vendors and Astute deliver files that the practice loads, and receive nothing from Tallify.
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.