How to scale a compliance function from zero

Most compliance functions are born the same way: a licence application, an auditor's finding, or a regulator's letter lands on someone's desk and suddenly the company needs a function it never budgeted for. I joined Kaizen Gaming when the company was nine people and left when it was around nine hundred, having built three departments from scratch along the way. This is the sequence I would follow again.

Stage 0 — Work out what you are actually licensed to do

Before any framework, policy or hire, write a single page that answers three questions: which entity holds which permission, in which market, and who personally carries the accountability. In regulated markets that page is the spine of everything else. If you cannot produce it in an afternoon, that is your first finding — and you found it before the regulator did.

• Entity → licence → market → responsible individual, on one page.
• Every reporting obligation with its deadline and its owner.
• The five things that would suspend the licence tomorrow.

Stage 1 — The first 90 days: risk assessment before policy

New compliance leads almost always start by writing policies. It is the wrong first move. A policy written before a risk assessment is a guess with a version number. Start with a business-wide risk assessment that names the actual exposures — customer base, payment rails, product mechanics, marketing channels, geography — and score them for likelihood and impact. Everything downstream then has a reason to exist, and you can defend every control in an audit with one sentence: this control exists because of that risk.

If you cannot trace a control back to a named risk, you are not running compliance. You are running paperwork.

Stage 2 — Build the control set once, localise it later

The single biggest scaling error I see is building compliance per market. Team A writes a KYC standard for one jurisdiction, team B writes another for the next, and eighteen months later you own six incompatible operating models and no way to answer a group-level question. Build one control set at group level, then attach a thin localisation layer per market for the things that genuinely differ: thresholds, timeframes, reporting formats, local language requirements, local responsible-gambling or consumer-protection duties.

1. 1.One group standard per domain (AML, KYC, sanctions, responsible gambling, marketing, data).
2. 2.A per-market annex that only records deltas from the group standard.
3. 3.A change log so a regulator can see when a delta appeared and why.

Stage 3 — Hiring order matters more than headcount

The order I have found works when going from one to a real department: first an operational analyst who can clear queues, because a backlog destroys credibility faster than anything else. Then a financial-crime specialist who owns AML and sanctions end to end. Then a regulatory-reporting owner, because reporting is deadline-driven and cannot share attention with investigations. Then, only then, a policy and framework person. Governance is real work, but it cannot be your first hire when the queues are on fire.

• Hire 1 — operations analyst (clear the queue, prove the function works).
• Hire 2 — financial crime (AML, sanctions, escalations).
• Hire 3 — regulatory reporting and licence maintenance.
• Hire 4 — policy, framework, training.
• Hire 5+ — quality assurance and monitoring, which is what turns a team into a function.

Stage 4 — Make the function measurable

A compliance team that cannot show numbers gets treated as a cost centre and loses every budget argument. Instrument the function from week one: queue volumes and ageing, escalation rates, false-positive rates on screening, time-to-decision on enhanced due diligence, reporting punctuality, findings raised and closed. Take those numbers to the board every single time. The moment leadership can see throughput, compliance stops being a black box.

Stage 5 — Multi-jurisdiction operations without duplication

Running several licences at once is mostly an information-architecture problem. One case management system, one customer risk-scoring model with market-specific parameters, one evidence repository organised by control rather than by team, and one calendar that shows every regulatory deadline across every market in a single view. Every duplicated system you avoid is a headcount you do not need to hire and an inconsistency an auditor will not find.

The mistakes that cost me the most time

• Writing policies before the risk assessment existed.
• Letting each market build its own operating model.
• Hiring seniority before hiring throughput.
• Treating training as an annual event instead of an onboarding gate.
• Not keeping evidence at the moment the control ran — reconstructing it later costs ten times more.

What good looks like at the end

A function that can answer any regulator's question within one working day, that commercial teams consult before launch rather than after, and that can absorb a new market without a reorganisation. That is the bar. Everything above is how you get there without burning two years finding out the hard way.