The compliance function is evolving. The leaders who understand this shift are transforming their organisations. Those who don't are getting left behind.

As you know if you have followed me for a while, I have sat in a LOT of meetings with Compliance leaders.

In the early days of Detected back in 2020 the conversations were almost always the same: process, regulation, risk mitigation. Defensive by default, a real checkbox mentality.

Something has shifted in the last 18 months. The best compliance leaders I speak with now sound less like lawyers and more like product managers. Of course, the baseline is always being compliant and preventing fraud, but the lens they view it through has changed.

They talk about customer experience. About conversion rates. About how long it takes to onboard and what that costs the business. They think about change management, stakeholder buy-in, and iteration cycles.

As we know, we are all in a period of significant disruption. This disruption is having a huge impact on the way businesses are run, with every role under the microscope to ensure there is organisational efficiency. There is pressure on leaders of all businesses to demonstrate that they think about more than just priority number 1 and consider what else their function can be doing to contribute to the business overall.

This has led to a fundamental shift in what it means to lead compliance in 2026 and beyond.

The Old Model: Compliance as a Necessary Evil

For decades, compliance has been treated as a cost centre. A regulatory requirement. Something the business has to do, not something it wants to do. The role of the compliance leader was essentially defensive: keep the regulators happy, avoid fines, don't let anything blow up.

This mindset produced a very particular type of project. When compliance needed to improve their onboarding process, for example, they would typically engage IT or a vendor, specify their regulatory requirements, and expect technology to simply execute on those requirements. The compliance team defined what needed to happen. Someone else figured out how.

The result? Projects that technically meet regulatory requirements but create terrible experiences for everyone involved. Onboarding flows that take weeks when they should take hours. Manual review queues grow faster than teams can process them. Systems that technically work but that nobody actually wants to use.

A good friend is the Head of Compliance at a US Bank. They'd spent 18 months and a significant budget on an onboarding transformation project. When I asked how it was going, she said, "It does what we asked for. It's just that what we asked for was wrong."

Why Product Teams Get Compliance Wrong

There are exceptions: product teams rarely understand compliance deeply enough to design compliance systems well.

This isn't a criticism of product teams. It's a recognition of reality. Product managers are trained to think about user needs, market opportunities, and competitive differentiation. Compliance is a domain with its own language, its own logic, and crucially, its own constraints that aren't negotiable.

I've watched this play out plenty of times. A product team gets tasked with "improving the onboarding experience." They approach it like any other product challenge: user research, wireframes, sprints. They optimise for speed and conversion. They reduce friction wherever they find it.

Then compliance reviews the designs and the wheels come off. That friction the product team removed? It was there for a reason. Those extra steps? Regulatory requirements. The result is a painful back-and-forth where the product team feels like compliance is blocking progress, and compliance feels like the product team doesn't understand the stakes.

I think one of the key things that Product teams could do is view Compliance as experts to work with, rather than a stakeholder to manage.

Compliance requires deep domain knowledge and battle scars that can't be acquired through a few workshops or stakeholder interviews. You need to understand not just the rules, but the intent behind the rules. Not just what regulators require, but how they (and fraudsters) think. Not just today's requirements, but where regulation is heading.

The Change Management Gap

There's a second problem that's equally important but less discussed: compliance leaders often lack the change management skills that modern transformation projects require.

A KYB transformation isn't just a technology project. It touches every team that interacts with customers or partners. Operations. Sales. Customer success. Risk. Legal. Each of these teams has established processes, often built up over years, that will need to change.

Traditional compliance training doesn't prepare people for this. You learn regulatory frameworks, risk assessment methodologies, and audit procedures. You don't learn how to run a discovery process with cross-functional stakeholders. You don't learn how to build a coalition for change across an organisation. You don't learn how to iterate on a solution based on real-world feedback.

These are product skills. And they're exactly what's needed to make compliance transformation successful.

We have invested a lot in supporting this, with great success. A Detected (or GBGDetected) project is a constantly evolving transformation framework which provides our customers with what they need to be successful. Success ensures that compliance becomes a competitive advantage rather than a bottleneck.

What Product Thinking Actually Means for Compliance

Product thinking in compliance isn't about compliance leaders becoming product managers. It's about adopting a different mental model for how compliance systems should be designed and implemented.

The first shift is from requirements to outcomes. Traditional compliance thinking starts with: "What does the regulation say we need?" Product thinking starts with: "What outcome are we trying to achieve, and how do we get there while meeting our regulatory obligations?"

When you think in requirements, you tend to build systems that are technically compliant but practically awkward. When you think in outcomes, you design experiences that work for everyone and happen to be compliant.

The second shift is from static to iterative. Most compliance projects are treated as discrete initiatives: define requirements, build system, deploy, done. Product thinking recognises that no system is ever truly done. You launch, you learn, you improve. You build feedback loops. You measure what's working and what isn't.

The third shift is from internal focus to user focus - and there are two core user groups. Compliance teams traditionally think about their own needs: audit trails, risk documentation, regulatory reporting - which is fine. Product thinking adds a layer: how does the customer experience this? How does the operations team experience this? Where are the friction points that drive abandonment or manual workarounds? How do we run a system which means both are catered for.

The New Breed of Compliance Leader

The compliance leaders who are thriving today share certain characteristics. They're deeply knowledgeable about regulation and the changing fraud landscape, of course, but they're also curious about technology and how it can be applied. They speak the language of the business, not just the language of compliance. They see their role as enabling growth, not just preventing problems.

These leaders measure different things. Not just "did we pass the audit" but "what's our average time to approval?" Not just "are we compliant" but "what's our customer satisfaction score for the onboarding experience?" Not just "did we catch the bad actors" but "how many good customers did we lose to false positives?"

They also build different teams. They hire people with operations backgrounds, not just regulatory backgrounds. They partner closely with product and engineering rather than sitting in isolated compliance silos. They invest in understanding data and automation, because they know that's where the leverage is.

How Technology Enables the Shift

This transformation in compliance leadership is both enabled by and demands different technology.

The old model worked with old technology: point solutions for specific problems, manual handoffs between systems, limited visibility into what was actually happening. A compliance leader could define requirements, hand them to IT, and wait for something to be built.

The new model requires platforms that can be configured rather than custom-built. Technology that compliance leaders can shape themselves, without waiting for engineering resources. Systems that provide real-time visibility into operations, not just monthly reports.

At Detected, we built our platform specifically for this new type of compliance leader. Not just another tool that does what you tell it, but a system that enables compliance teams to experiment, iterate, and improve. Configurable workflows that don't require code changes. Decision engines that compliance teams can tune themselves. Dashboards that show what's actually happening, not what happened last quarter.

The goal isn't to replace compliance expertise with technology. It's to amplify that expertise. To give product-minded compliance leaders the tools they need to execute on their vision without being bottlenecked by IT backlogs or vendor roadmaps.

The Strategic Imperative

This shift from checkbox compliance to product-minded compliance isn't just nice to have. It's becoming a strategic imperative.

Regulation is getting more complex, not less. AMLD6 in Europe. Evolving FinCEN rules in the US. Increasing scrutiny across every jurisdiction. Compliance teams that can only operate in reactive mode will be overwhelmed.

At the same time, customer expectations are rising. Businesses that experienced smooth digital onboarding with consumer fintech products now expect the same when they're the customer. A three-week compliance review process that was acceptable five years ago is a competitive disadvantage today.

The organisations that will win are those that figure out how to be both highly compliant and highly efficient. How to satisfy regulators while delighting customers. How to manage risk without creating friction.

That's not a technology problem. It's not a regulatory problem. It's a leadership problem. And it requires a new type of leader to solve it.

Making the Transition

If you're a compliance leader reading this and recognising yourself in the old model, here's the encouraging news: this transition is learnable. You don't need to go back to school or completely reinvent yourself.

Start by changing how you measure success. Add customer-facing metrics to your compliance scorecards. Track time-to-approval alongside audit outcomes. Measure false positive rates alongside catch rates. There is unlimited information these days, you have no excuse for not locating best practice.

Then change who you talk to. Spend time with your sales team, not performatively – actually sit with them and learn about what they need. Sit in on customer calls. Understand what the business is actually trying to achieve, not just what they're asking compliance to approve.

Finally, change how you approach projects. Making decisions is only possible if you realise that there will be errors, planning for the 0.000001% edge case kills so many projects before they even start. Build feedback loops and actually use them.

The compliance leaders who make this shift will find their influence and impact growing. They'll move from cost centre to strategic partner. From necessary evil to competitive advantage. From blocking progress to enabling it.

That's not just good for their careers. It's good for their organisations. And frankly, it's good for the compliance industry as a whole.