Auto-replies and AI drafts help a brokerage answer faster, but the FSP stays accountable. The rules, thresholds and audit logs compliance should approve.
The first time a client receives a message your brokerage did not literally type, something important has changed — even if the message is a perfectly sensible "thanks, we have received your documents". Under FAIS, the financial services provider remains accountable for what is communicated in its name; the key individual cannot outsource that accountability to a model. So the arrival of AI drafts and auto-replies in the WhatsApp inbox is not primarily an IT decision. It is a set of conduct decisions, and the compliance officer should sign each one off in writing before anything goes live.
This article lists those decisions, using the actual behaviour of ORIS as the worked example — not because the checklist only applies to ORIS, but because vague AI promises are exactly what a compliance officer should refuse to sign. If you are still weighing whether automation belongs in a regulated inbox at all, start with our comparison of a chatbot versus supervised AI for brokers.
Three conduct principles collide with automation. Accountability: the FAIS Act and its General Code of Conduct hold the FSP responsible for representations made to clients; "the system sent it" is not a defence. Advice boundaries: an automated message that strays into recommending cover or quoting terms may constitute advice, with everything that implies about competence requirements and suitability. Record-keeping: automated messages are client communications and must be retained and retrievable like any other — the disciplines from FAIS record-keeping on WhatsApp apply unchanged.
None of this forbids automation. It means automation must be bounded, observable and reversible — which is a specification you can actually write down and test.
Here is what auto-reply under rules means concretely in ORIS, mapped to the sign-off list:
| Control | ORIS behaviour | What compliance signs off |
|---|---|---|
| Scope of auto-send | Auto-reply runs only if the rules are enabled; replies are short service responses of one to three sentences | The rule set: on or off, and for which situations |
| Hard prohibitions | The reply generator is instructed never to promise prices or cover | That the prohibition list matches your licence categories |
| Sentiment gate | Automatic sending only on positive sentiment (neutral optionally); negative sentiment always produces a draft plus a "Draft reply ready" notification for a human | Whether neutral sentiment may auto-send, or only positive |
| Frequency limits | Configurable cooldown in minutes and a maximum number of auto-replies per client | The actual numbers for both limits |
| Escalation | Inbound messages are classified; churn-risk and needs-human cases raise notifications and create entries in Opportunities & Risks | Who monitors notifications and the expected response time |
| Failure mode | If an automated send fails, the message becomes a draft instead of silently disappearing | That drafts are reviewed daily, not left to age |
| Traceability | Audit logs in the compliance settings; conversations and messages retained per client; CSV export | The retention approach and who may export |
Two honest limitations belong in the sign-off file as well: the drafting model is a general-purpose language model, so drafts must be treated as suggestions a human owns once sent; and classification is probabilistic, so the escalation route must tolerate false negatives — meaning humans still skim the inbox rather than trusting the filter absolutely.
Sign-off is not once-and-done. A workable routine: before go-live, run a test set of realistic client messages — including an angry one, a claim question and a price request — and file the outputs with the compliance officer's approval. Then review monthly: sample automated sends against the prohibition list, check drafts are being cleared within the agreed time, and confirm escalations reached a human. Remember the operational constraint that shapes all of this: WhatsApp only allows free-form replies inside the 24-hour customer service window, so automation mostly operates inside live conversations — exactly where tone matters most.
It depends entirely on content. "We have received your documents, thank you" is a factual service message. "You should increase your cover" is advice, whoever or whatever typed it. That is why the prohibition list — no product recommendations, no prices, no cover promises — is the heart of the sign-off, and why it must be enforced in the system rather than hoped for.
Acknowledging a claim message and telling the client a person will respond is safe territory. Anything touching the merits — whether the claim will be paid, what is covered, timelines you cannot guarantee — should route to a human. Claims conversations carry the highest emotional stakes and the highest complaint risk in the book.
Four questions expose most weaknesses: exactly when does the system send without a human, and can we see the rule? What happens on negative sentiment or failure? What limits stop it messaging a client repeatedly? And where is the log we would show a regulator? A vendor without crisp answers is asking you to carry unbounded risk.
There is no single statutory disclosure rule for this in most African markets today, but honesty is both good conduct and good business: identify automated service messages as coming from the brokerage's assistant, and make reaching a human effortless. Transparency also protects you when a client later disputes what was said.
Split the roles: the compliance officer owns the rules — scope, prohibitions, sentiment gate, limits — and any change to them; an operational owner watches the notifications, clears drafts and reports monthly. Concentrating both in one busy person is how settings drift without anyone deciding they should.
Shared WhatsApp inbox, client records, follow-ups and opportunities for the whole brokerage. 15-minute demo.
A demo tells you nothing about where client data goes. The POPIA operator, security and cross-border questions a South African brokerage should ask in writing.
Section 35 of the Data Protection Act, the DPIA that automated decisions trigger, and the ODPC registration a small Kenyan brokerage cannot skip.
Sentiment models score lower on isiZulu and Sesotho than on English. How a brokerage should test its WhatsApp classifier before letting it reply on its own.
