← All writing

The Integration Tax: the £300K problem nobody names

Mid-market iGaming operators are quietly paying £300K–£600K a year in engineering and compliance overhead just to manage fragmented vendor stacks. Nobody calls it the Integration Tax, but that is exactly what it is.

·2 min read

There is a cost that mid-market iGaming operators carry that never appears on a P&L but shows up everywhere else: in delayed product launches, engineering backlogs, compliance incidents, and senior talent spending months on work that should not exist.

I call it the Integration Tax. The reason nobody names it is that it is hidden inside line items that look like normal operating costs.

What the Integration Tax actually is

The average mid-market iGaming operator manages between 15 and 30 active vendor integrations at any given time. Payment providers, game aggregators, KYC and AML tools, CRM systems, responsible gambling platforms, analytics, bonus engines. Each one has its own API, its own data format, its own update cadence, its own failure modes.

Maintaining these integrations requires engineering time. Not product engineering — maintenance engineering. Keeping the pipes running, handling deprecations, rebuilding connections when vendors update their APIs, debugging failures at 2am when a payment integration breaks during peak hours.

The best estimate I have seen puts this at £300,000 to £600,000 per year in fully loaded engineering cost for a mid-market operator. That is before you count the compliance overhead.

The compliance dimension

Regulators across major iGaming markets are tightening requirements around data governance, auditability, and player protection. When your stack is 20 different vendor integrations connected by custom code, demonstrating that traceability becomes genuinely difficult. Every integration point is a potential gap in your audit trail.

This is the compliance dimension of the Integration Tax, and it is accelerating as regulatory frameworks evolve across Europe and beyond.

Why it persists — and why it does not have to

The Integration Tax persists because the alternative has always been worse. Building and maintaining integrations yourself is painful, but the tools available to replace that work have not been good enough until now.

One integration layer, 300+ connectors, compliance-native architecture. The Integration Tax is not inevitable — it is a problem that has not had a good solution. That is changing.

← Back to writing