An AI answering clients on WhatsApp can put a brokerage inside section 38 of the fit and proper rules. The FAIS advice test, and what applies beyond it.
Most compliance conversations about AI in a brokerage stall on the wrong question. The question is not whether the FSCA permits a model to write to clients — nothing in the FAIS framework prohibits it. The question is narrower and much more consequential: at the moment your inbox answers a client without a person in the loop, is the brokerage furnishing automated advice? Because if it is, a specific section of the fit and proper Determination switches on, and it asks for documentation most brokerages do not have.
This is a scoping exercise, not a philosophical one. Two definitions decide it, both of them short. Get them straight before the first auto-reply goes out, and you will usually find you have a design choice rather than a compliance problem.
Section 1 of the Financial Advisory and Intermediary Services Act, 2002 defines advice as any recommendation, guidance or proposal of a financial nature furnished by any means or medium in respect of the purchase of, investment in, variation, replacement or termination of a financial product. "By any means or medium" already covers WhatsApp; that argument was settled long before anyone connected a model to an inbox.
The useful part is the carve-out. Section 1(3)(a) says advice does not include factual advice given merely:
It also excludes an analysis or report on a product where there is no express or implied recommendation that a particular transaction is appropriate to the client's objectives, situation or needs.
Read against a real WhatsApp thread, that list is generous but it has hard edges. The moment a reply implies that something is appropriate for this client, the carve-out is gone.
| Typical automated reply | Where it sits |
|---|---|
| "We have received your documents, your consultant will confirm by Tuesday." | Routine administrative query — not advice |
| "Your premium is collected on the 25th of each month." | Objective information — not advice |
| "To add a vehicle, send us the licence disc and we will request a quote." | Procedure for entering into a transaction — not advice |
| "Your funeral benefit covers immediate family as listed in the schedule." | Description of the product — not advice, provided it is accurate and not tailored |
| "Given your new baby, you should increase your cover." | Recommendation — advice |
| "That excess is quite high for a car like yours, you would be better off on the other option." | Guidance on a variation — advice |
| "You probably don't need the extended warranty." | Proposal to terminate or not acquire — advice |
Note what the borderline cases have in common: the model has inferred something about the client's circumstances and drawn a conclusion. That is exactly what a good language model does well and unprompted, which is why the boundary has to be designed rather than hoped for.
The Determination of Fit and Proper Requirements for Financial Services Providers, 2017 defines automated advice as "the furnishing of advice through an electronic medium that uses algorithms and technology without the direct involvement of a natural person".
Both limbs must be present. Advice alone is ordinary FAIS territory — a licensed representative, a needs analysis, a record of advice. Automation alone is not regulated as advice at all. It is the combination that triggers section 38, and the pivot is the phrase "without the direct involvement of a natural person".
That phrase is where your architecture earns its keep. A model that produces a draft which a representative reads, edits and sends has a natural person directly involved in the furnishing. A model that composes and transmits a recommendation to the client on its own does not. The distinction is not a label you apply in a policy document; it has to be observable in the system and in the audit trail.
In ORIS the boundary is a rule set rather than a promise. Auto-reply runs only where a broker has enabled it, subject to a cooldown in minutes and a cap on auto-replies per client; the prompt forbids promising price or cover and forbids advising; a negative sentiment always produces a draft in the pending queue with a "Draft reply ready" notification instead of a send; and a failed send falls back to a draft. Anything the classifier reads as an upsell or cross-sell signal, or as high churn risk, escalates to the broker. That configuration is what keeps the human in the furnishing — and it is what a compliance officer should be able to show, not describe. Our sign-off list for AI drafts and auto-replies covers the decisions to record before go-live; if you are still choosing an approach, the comparison of a scripted chatbot and supervised AI frames the trade-off.
Section 38 applies in addition to the general governance requirements in section 37. Stripped of the numbering, it asks for four things.
1. People who genuinely understand the system. You must have human resources competent to understand the technology and the algorithms, the methodological approaches and the assumptions embedded in them, the preferences or biases in those approaches, the risks and rules underpinning them, the risks to clients arising from the advice, and to monitor and review the advice generated for quality, suitability and compliance with the Act. A vendor demo does not satisfy this. "Our supplier handles that" is not a person in your firm who can answer an FSCA question.
2. Policies for monitoring, review and testing — including the filters. You need documented procedures to monitor, review and test the algorithms and the advice they generate; to monitor, review and test the filters that screen out clients for whom the automated advice is not suitable; and to set out the level of human review that will be undertaken. The filter requirement is the one most firms miss. If your answer to "which clients should never receive automated advice" is unwritten, you have no filter to test.
3. Documentation and change control. Section 38 is unusually specific here: system design documentation setting out the purpose, scope and design of the algorithms and filters; a documented test strategy covering test plans, test cases, test results, defect resolution and final results; change-management processes including security arrangements against unauthorised access to the algorithms; the ability to control, monitor and reconstruct any change; review whenever something affects relevance, including changes in the law; controls to suspend the provision of advice if an error is detected; and frequent monitoring of performance through timely review of the advice given. Read that list as an engineering standard, because that is what it is. The kill switch in particular is a functional requirement — know today who can turn automation off, and how fast.
4. Technological resources. Enough capacity to maintain client records and data integrity, protect confidential information, and meet current and anticipated operational needs.
None of this is unreasonable for a firm that has decided to let software advise clients. It is simply disproportionate for a firm that only wanted faster answers to "has my claim been paid?" — which is the honest reason most brokerages should stay out of scope deliberately rather than by accident.
If you want automation without section 38, three decisions do most of the work, and all three need to be visible in the system rather than asserted in a manual.
One caution on scope drift. Section 38 attaches to what the system does, not to what you intended it to do. A model that was configured to answer administrative questions but has started reassuring clients that their cover "should be fine" has moved the firm across the line without anyone deciding to. That is an argument for sampling real outbound messages every month — a small, boring review that is far cheaper than the alternative. More on this theme in our articles on AI in a brokerage.
On the ordinary reading, no. The definition of automated advice requires the advice to be furnished without the direct involvement of a natural person, and a representative who reads, amends where needed and sends the message is directly involved. What matters is that the approval is real and evidenced, not a bulk click on a queue of two hundred drafts — a rubber stamp invites the argument that no person was genuinely involved.
Those messages fall squarely within the section 1(3)(a) carve-outs for routine administrative queries and objective information, so they are not advice and section 38 does not bite. The risk is not the message you designed but the one the model improvises when a client asks something adjacent. Constrain the output, log what goes out, and review a sample.
Partly, and only if you hold it. The design documentation and test strategy can originate with a supplier, but the obligation to have competent people who understand the algorithms, biases and client risks sits with the FSP, as does the ability to reconstruct changes and suspend the service. Ask for the documents, the change log and the suspension mechanism in writing before you switch anything on.
Not on its own. Scoring, routing and prioritising are internal processing decisions and no advice reaches the client, so the automated advice definition is not engaged. A separate question arises under POPIA where a decision about a client is taken solely by automated means, which we cover in our article on risk scores and POPIA section 71.
A one-page, dated statement of what automation in your inbox may and may not send, with the escalation rules, the client and message-type exclusions, and the name of the person who can switch it off. It is the document a compliance officer, an insurer doing due diligence and an FSCA reviewer will all ask for, and writing it usually exposes the gap between the configuration and the intention.
Shared WhatsApp inbox, client records, follow-ups and opportunities for the whole brokerage. 15-minute demo.
Silent clients, lapsed policies, an inherited book: sort dormant clients, check consent and reach out on WhatsApp without burning your number.
Notification, documents, assessment, settlement: a brokerage's WhatsApp journey for following up a claim, with sample messages, Meta rules and pitfalls.
A button menu that answers alone, or AI that classifies, drafts and only auto-replies under rules with a human behind it: FAIS advice duties, risk, cost.
A demo tells you nothing about where client data goes. The POPIA operator, security and cross-border questions a South African brokerage should ask.
The FSCA and PA have mapped AI use in the sector. What POPIA section 71 and FAIS ask of a brokerage that scores client risk and drafts replies with AI.
Section 35 of the Data Protection Act, the DPIA that automated decisions trigger, and the ODPC registration a small Kenyan brokerage cannot skip.
Who counts as a representative under the FAIS Act, who the admin carve-out excludes, and what section 13 requires before anyone advises on WhatsApp.
