Walk into most regulated entities in GIFT IFSC and you will find a well-kept compliance folder — risk management, AML/CFT, conflict of interest, outsourcing, cybersecurity, each one drafted, approved by the Board, dated and filed. On paper, it looks complete.
But a policy sitting in a folder is not compliance. It is a statement of intent. The real work begins after the Board approves it.
This is easy to miss. When a regulation asks for a policy, the instinct is to draft it, get Board approval, file it and move on. The requirement feels closed. In practice, approval is where compliance starts, not where it ends. A policy can be well written, properly approved and neatly filed, and the entity can still not be doing what the policy says.
Take a Conflict of Interest Policy. It says conflicts must be identified, recorded, assessed and managed. Approved and filed, fine. Now an actual conflict arises — a proposed transaction where a director or a group entity has an interest. Who spots it? Where is it recorded? Who reviews it, decides the treatment, documents the decision? None of this is answered by producing the policy. Each question needs a process running behind it. That gap — between what the policy says and what the entity can show it did — is the implementation gap.
The pattern repeats everywhere. An AML/CFT Policy prescribes CDD and ongoing monitoring; the real question is whether those checks were done for each client and whether the records exist. An Outsourcing Policy calls for vendor due diligence and periodic review; the question is whether that actually happened for the fund administrator or the technology vendor the entity relies on. A Cybersecurity Policy speaks of access controls and periodic reviews; the entity should be able to show how those controls run day to day, not just that a document mentions them. In each case the policy tells you what should happen. Only the process, and the records it throws off, tell you what actually happened.
One way to picture the full chain is this:
Regulatory Requirement → Policy → Process → Responsibility → Control → Evidence → Monitoring
Most of the effort goes into the first two links, because that is the visible, document-heavy part. But if the chain stops at the policy, everything to the right of it is missing — and that is exactly where scrutiny goes.
Because in any serious review, the conversation rarely stops at “Do you have a policy?” That answer is easy and almost always yes. The harder questions come next: “Show me how it is implemented,” and then “Show me the records.” For every material requirement, there should be a clear line to a process and to evidence. If the policy requires a quarterly review, there should be a named owner, a schedule and records showing the reviews were done. If it requires approval before an activity, there should be proof that approval was taken. If it requires escalation, there should be a route for it and some trace of the cases that went up. The policy tells you what should have happened; the records tell you what did.
This is really the difference between approved and implemented — two words that hide a lot of risk in the space between them. An Outsourcing Policy is approved when the Board signs off. It is implemented when there is a real due diligence process, an outsourcing register that is actually maintained, reviews that actually take place, and records of those reviews. The first is a document. The second is a working control.
You don’t need a big exercise to find the gaps. Take each major policy and put five plain questions to it. What does it actually require, broken into its real obligations rather than read as one document? Who is responsible for each — by name or role, not just “the organisation”? How is it done in practice? What evidence does that process generate? And how does the entity check the control is working? If you can answer those for a requirement, it is genuinely implemented. If you can’t, the policy exists but the implementation doesn’t — and it is far better to find that yourself than to have IFSCA or an auditor find it for you.
None of this is an argument against policies, or against the people who draft them. Documentation and implementation are simply two different parts of the same job, and it is the second part that quietly gets less attention. A policy tells the organisation what it has committed to do. Whether that commitment has actually been built into how people work, and whether the entity can show it, is the part that decides how a review goes.
So the aim isn’t to keep a file that looks good when someone asks to see it. It’s to run a set of controls that hold up under scrutiny because the organisation genuinely does what its own policies say. Everything else is just paper that reads well.
