July 16, 2026
And where does the RMCP Fit in?
After posting my first Reality Checks video on YouTube, titled Your SOP is not the process, I also had the opportunity to join Francois du Toit CFP® on the PROpulsion LIVE Show, where we spoke about the danger of being too helpful in your advice business.
At first, those two topics may sound like they sit in different rooms. One is about SOPs and processes. The other is about helpful teams, unclear responsibilities, people stepping in, rescuing, patching, fixing, carrying, absorbing, quietly making things work in the background, and often preventing the business owner from seeing where the business is actually under strain. But the more I think about it, the more connected those conversations are.
Because when the real process is not clear, embedded, understood and followed, helpfulness often becomes the thing that holds the business together. Someone remembers what needs to happen. Someone knows which client always needs special handling. Someone knows where the missing document usually sits. Someone knows who to ask, what to fix, what to ignore, what to quietly sort out, and what not to mention unless it becomes a problem.
And on the surface, that can look like a good team. It can look like commitment. Responsiveness. Client service. People pulling together. But underneath that, it can also mean that the business does not actually have a process that can stand on its own. That is where the comment I made around “the SOP is not the process” comes in. And it sparked a really useful follow-up question: Where does the RMCP fit in? Is it an SOP, or is it a process?
It is a good question, because in most businesses, these words get used very loosely. Policy, procedure, SOP, process, framework, manual, checklist, file note, workflow. They all get thrown into the same compliance pot and stirred until everyone nods politely while quietly hoping someone else knows what the difference is.
So this is not meant to be a perfect textbook definition. This is how I would explain it in practical business terms. For me, the SOP is the big picture. It gives the business the broader structure of how a particular area is supposed to work. So, for example, a Client Experience SOP may describe the full client journey from the first enquiry all the way through to client exit. It may explain the different stages of the relationship. First contact. Introductory meeting. Onboarding. Information gathering. Advice preparation. Presentation. Implementation. Reviews. Ongoing servicing. Fee changes. Client queries. Client complaints. Client exit.
That SOP is useful because it gives everyone a shared map. It shows where things fit. It helps the business understand the flow. It gives context. It helps a new staff member understand how one part of the client journey connects to the next. It also helps the business owner step back and see the full experience, instead of only seeing the piece that is currently on fire.
But the SOP is not necessarily where every tiny detail lives. That is where the underlying processes come in. The process is where the reality sits. The process should tell the team exactly what needs to happen. Who does what. When they do it. Which system they use. What evidence must be saved. Which template applies. What gets checked. What happens if information is missing. What must be escalated. Who signs off. What happens when something falls outside the standard path. What “done” actually means.
That is the difference for me. The SOP tells you where the different pieces fit in the bigger scheme of things. The process tells you what actually needs to happen when real people are doing real work with real clients, real systems, real deadlines and real interruptions.
And that distinction matters, because a practice can have a beautiful SOP and still have broken processes underneath it. The client journey may look neat on paper, but if the detail underneath is inconsistent, unclear, outdated, ignored, misunderstood or dependent on one person’s memory, then the business is still exposed. That is why I keep coming back to this: The SOP is the big picture. The process is the reality. And reality is usually where the risk sits.
So, where does that leave the RMCP? By this definition, I would treat the RMCP as a process document. The FICA legislation gives the broader framework. It tells accountable institutions what they are expected to achieve when it comes to anti-money laundering, terrorist financing and proliferation financing risk management. It gives the legal foundation. It sets the expectations. It explains the areas that must be addressed.
In that sense, the legislation is closer to the overarching framework. The big picture of what your FIC/AML/TF environment should deal with – equivalent to what an SOP would do. But the RMCP should translate those obligations into your business’s actual way of working. It should not be a generic document sitting somewhere in a compliance folder, pretending to be useful because it has headings and legal references.
It should explain how your business applies those requirements in practice. How do you identify clients? How do you verify them? How do you deal with individuals, companies, trusts and other client types? How do you determine the client’s risk rating? How do you decide whether simplified, standard or enhanced due diligence applies? How do you screen clients and related parties? How do you deal with sanctions exposure? How do you identify unusual or suspicious activity? What does the team do when something feels off? Who do they escalate to? What must be recorded? What evidence must be saved? How often do you review client information? Who checks that it happened? What happens when the system says one thing but the client file tells another story?
That is not just a policy statement. That is process. And that is why I do not believe in treating the RMCP as some standalone compliance artefact that exists outside the business. If the RMCP does not reflect what actually happens inside the practice, then it is not doing its job. This is also why cookie-cutter RMCPs make me nervous.
Now, to be fair, a template can be useful as a starting point. It can help with structure. It can make sure you do not completely forget major areas. It can give you a skeleton to work from. But a skeleton is not a functioning body. Your RMCP needs to speak to your business. Your client base. Your systems. Your team structure. Your advice process. Your onboarding process. Your review process. Your recordkeeping habits. Your escalation routes. Your risk appetite. Your actual way of working.
A generic RMCP may look impressive in a folder, but if your staff cannot use it to understand what they need to do, it is not embedded. It is decoration. Expensive, regulatory-flavoured decoration, but decoration nonetheless. And that is the part I think many practices miss. The RMCP is not there merely so that you can say you have one. It is there to guide behaviour. It should help staff understand what to do, when to do it, how to do it, when to ask questions, when to stop, when to escalate, and what evidence needs to exist afterwards.
If no one has read it, no one understands it, no one uses it, and it has no connection to the way work is actually done, then the document may exist, but the process does not. And that is where the danger lies. Because the moment a process sits outside the business, people will create their own way of getting the work done.
Sometimes that way will be better than the document. Sometimes it will be riskier. Sometimes it will depend entirely on one experienced person who knows exactly what to do, but has never had to explain it properly to anyone else. And then the business becomes dependent on memory, helpfulness and informal knowledge. Which is fine, until that person is on leave. Or resigns. Or gets too busy. Or gets it wrong. Or assumes everyone else knows what they know.
This is why a process document should live inside the business. Not in the dramatic sense. We do not need to give the RMCP its own desk, coffee mug and emotional support plant. But it should live in the way people work. It should connect to onboarding. It should connect to client reviews. It should connect to implementation. It should connect to file checking. It should connect to advice administration. It should connect to training. It should connect to oversight. It should connect to exception handling. It should connect to management reporting. It should connect to the evidence trail.
And it should change when the business changes. If your system changes, your RMCP may need to change. If your client base changes, your RMCP may need to change. If your team structure changes, your RMCP may need to change. If your process improves, your RMCP may need to change. If your risk exposure changes, your RMCP may need to change. If regulation changes, your RMCP may need to change.
That is what makes it a live working document. Not a once-off project. Not an annual panic exercise. Not something dusted off when the compliance officer asks for it. A working process document.
So, for me, the better question is not simply: Do we have an RMCP? The better questions are: Does it reflect how the business actually works? Can the team understand it? Do they know where to find it? Does it help them make decisions? Does it tell them what to do when something does not fit neatly into the standard process? Does it explain who owns what? Does it link to the systems they actually use? Does it create the right evidence? Is it reviewed when the business changes? And perhaps the most uncomfortable question of all: if I asked three different people in the business how the RMCP applies in practice, would I get the same answer? Because if the answer is no, then the issue is not that the document is missing. The issue is that the process is not embedded. And that is a much bigger problem.
So my view is this: The SOP is the big picture. The process is the reality. And the RMCP, when done properly, should sit firmly in that reality. It should be a practical process document that helps the business meet its obligations, guide its people, manage risk and create consistency. It should not be a document that sits outside the business, untouched and unread, quietly hoping no one asks too many questions.
Because in financial planning practices, the risk is often not that nothing is documented. The risk is that the document and the reality are not the same thing. And that gap is where things tend to go wrong.
As always, the real question is not only whether the document exists. The real question is: What actually happens in the business?