Are We a Compliance Platform or a Process Improvement Platform?

A question came up in a recent conversation that got me thinking: is Detected a compliance platform, or a process improvement platform?

As a KYB/KYC onboarding platform, the answer seems obvious. But when I think about what customers are actually trying to achieve by implementing our platform, it becomes more interesting.

Before moving into compliance technology, I spent years in compliance operations at large payments companies, implementing systems, changing processes and supporting teams, stakeholders and customers. What I learnt is that having the right checks is only part of it. How those checks are carried out, who is involved and the systems they use make just as much difference.

What If Compliance Isn't Actually the Problem?

When people think about compliance technology, they think about the checks: verifying the business, identifying directors and beneficial owners, screening against PEP, sanctions and adverse media, assessing risk and validating documents. All important, but only one part of the process.

The most frustrating part is everything else, especially the chasing. Business details are wrong, UBOs are missing, ID documents have issues, or expected usage doesn't add up with the customer's finances. Each time, someone contacts the customer, waits, reviews and goes round again. Meanwhile, information is keyed into multiple systems and spreadsheets, followed by escalations, four-eyes checks and QA, while analysts are expected to approve at least one application an hour.

No analyst chose compliance because they love admin, yet for many it's most of the day. Experienced analysts should be assessing risk and investigating unusual activity, not filing documents in four places or emailing customers about the wrong document.

You can invest in the best providers and fine-tune your risk assessment, but if they sit inside an inefficient process or across separate systems, the challenges remain. The technology might be better. Is the process?

Spreadsheets, Emails and Endless Chasing. Sound Familiar?

For some of our customers, the change since implementing Detected is huge, and not because they swapped one screening provider for another. The way their onboarding and compliance operations work has changed.

Before, some collected customer information through spreadsheets, requested documents over email and checked registries by hand. Proof of identity and address were reviewed by eye. Screening ran in separate systems, risk assessments lived in spreadsheets and escalations meant long emails with evidence attached.

They were almost certainly meeting their obligations, but at a heavy cost in time, and not only internally. I've seen onboarding dropout rates above 60%. After a lengthy sales process, a business can lose a customer to long forms, repeated requests and delays before they've even used the product. Not every dropout is down to onboarding, but a poor process is hard to ignore.

Now the same activities look very different:

• Structured digital journeys that vary by country, entity type and product, asking only for what's needed, in one go.
• Registry data presented to the customer in real time, so they provide less.
• Real-time identity verification and document authenticity checks that strengthen fraud controls.
• Screening in the same platform, with results on the customer profile, feeding the risk assessment and saved automatically.
• Profiles assigned to the relevant team in the platform, with checklists or escalation forms in place of email chains.

The compliance requirements are still met, but in a completely different way: less admin for analysts, a better experience for customers and stronger controls against fraud and money laundering. It's not doing a manual task slightly faster. It's a better way to do the whole thing.

What If We Didn't Need That Step in the First Place?

Process improvement isn't always about automating a task. Sometimes it's questioning whether the task, or a whole stage, is needed at all.

Take two-stage onboarding: minimal information and basic checks up front, then restrictions when a customer hits a threshold or needs another service, until they provide more. The instinct is to automate the second stage. The better question is whether it needs to exist. Could the information come from business data providers? Could you identify early which customers will need more, and collect it in one journey?

Collecting everything up front isn't always right or possible. Customer experience, data minimisation and relevance matter, and further due diligence is sometimes genuinely needed as a business grows or its risk changes. Then the opportunity is to make that stage structured: reuse what you already hold, focus on what has changed, give the customer a clear journey for anything new, and use configured workflows and checklists so reviews are consistent and results feed the same risk assessment.

The key is understanding which steps are actually needed, then how to do them better.

Automated Onboarding, So Why Are Customers Still Waiting?

Liam recently brought me into a deal that showed why the end-to-end process matters.

The business already had automated onboarding. Yet of around 4,000 customer accounts, over half were restricted and waiting on additional information. In a smaller sample, some had been automatically approved and were accepting payments, then couldn't withdraw their funds for several weeks.

Some restrictions are legitimate, and some holds sit with banks or third parties. But this is someone's money, and weeks without it can stop a business paying suppliers and staff. The goal should be to confirm or rule out concerns quickly so legitimate customers don't suffer.

We found two problems.

Approved today, restricted tomorrow. Customers were automatically approved, then hit requests for information as their volumes grew. Rather than just processing those requests faster, we asked what could have been collected earlier: prepopulating from existing business data, collecting more up front based on anticipated volumes, and using a fuller picture of risk from the start. Not every restriction can be prevented, but fewer requests and earlier warning signs make a significantly better experience for customers and the teams managing them.

When underwriting becomes a bottleneck. Larger customers needed underwriting based on several months of bank statements, reviewed manually, so every further request added time to the decision. We looked at bringing verification and underwriting together. Verification, identity checks and screening build the picture of the customer. Document intelligence extracts the financial information and shows whether more is actually needed. And one customer record is updated throughout, instead of information being passed between teams and systems.

Neither problem needed better compliance checks. Both needed a rethink of how information was collected and how the parts of the process fit together.

Are We Gathering Requirements or Recreating Problems?

Businesses that approach us always start with their current process, and one of their first questions is whether the platform can accommodate it. That's fair: every organisation has its own risk appetite, policies and governance, and technology must support them. But the conversation is almost always about recreating the existing process, not improving it.

Many processes weren't designed; they accumulated. A new regulation added a check. A system limitation created a spreadsheet. A team needed visibility, so another approval stage appeared. A temporary workaround became permanent. Over time, normal starts to look required.

New technology is the chance to ask: could this information come from a reliable data source instead of the customer? Does every application need the same manual intervention? Do multiple teams need to review the same information? And when a customer says the platform must do something, is that a genuine business requirement or just how they do it today? When we dig into why a business needs a particular integration, workflow or feature, the real need can often already be met more efficiently, or isn't needed at all.

Regulatory and policy requirements must still be met. But if technology offers a better way, we should at least look at it. Otherwise, are we transforming anything, or just moving the same inefficiencies into a new system?

New Technology, Same Old Habits

We've seen this with customers:

• Ticketing. One business wanted to keep passing cases between teams in Jira, even though the platform could assign cases with checklists and internal forms, keeping information and actions together. What was the real requirement: a ticket in another system, or the right team receiving the case with clear actions, visibility and accountability? If the platform already does that, keeping Jira is an operational choice, not a compliance requirement.
• Screening. Another kept screening outside Detected, so results weren't linked to profiles and couldn't feed the configured risk rules.
• Identity verification. A third kept a separate IDV system, disconnected from the onboarding workflow.

The cost goes beyond using another system. If screening and IDV results don't flow back into the profile and risk assessment, they can't support an automated decision. Even when every check is clear, someone has to review them before approval, and if that applies to every customer, straight-through processing is impossible. You've invested in automation but kept the steps that prevent it.

There can be legitimate commercial, technical or regulatory reasons to keep existing providers, and integrations can connect them without replacing them. But businesses should understand what they give up when checks stay separate: it affects how risk is assessed, how decisions are made and how much manual work remains.

Are We Overcomplicating Compliance?

Many organisations want automated onboarding but are reluctant to remove the manual intervention that prevents it.

We spend a lot of time with customers defining risk appetite, configuring risk profiles and setting rules that use business data, screening and identity verification to determine risk and flag who needs further due diligence or manual review. Yet there's often reluctance to let genuinely low-risk customers be approved automatically.

I understand why: compliance teams are accountable, and getting it wrong matters. But if the risk appetite is defined, rules are configured, checks are complete and review triggers are clear, what does manually approving every customer actually add?

Automated approval isn't right for every customer, and automated decisions must be tested, monitored and meet regulatory requirements. But that's the point of a risk-based process: identifying who needs a human review, rather than sending everyone through it. Otherwise processes get overengineered and regulation gets the blame. More steps don't automatically mean better compliance. Sometimes they just mean more work, and time spent on straightforward approvals is time not spent on cases that need real expertise.

Automating individual checks is different from automating onboarding. And having technology capable of straight-through processing is different from designing a process that allows it.

Going Live Doesn't Mean You've Changed Anything

Implementing a platform and adopting a new process aren't the same thing. A business can go live while teams keep their spreadsheets, keep routing cases to other systems or keep extra approval stages because automated decisions feel uncomfortable. The result is new technology without removing the complexity it was meant to address.

Businesses spend a lot of time selecting platforms, defining requirements and configuring workflows, and far less questioning whether existing processes are worth keeping or whether teams will embrace a new way of working.

This is rarely resistance for its own sake. Having been on the other side of implementations, I understand concerns about losing control, disrupting known processes or introducing new risks. But familiar isn't the same as best.

Technology providers have a responsibility to go beyond demonstrating functionality: to understand why processes exist and what customers are trying to achieve, and to challenge the existing approach where there's a better one. But the business shares that responsibility. We can recommend a better process, demonstrate it and configure the platform to support it. As the saying goes, you can lead a horse to water, but you can't make it drink.

Are We Measuring Success or Just Ticking Boxes?

Success isn't just getting the platform live and teams using it. The more useful questions come afterwards:

• Do customers provide the same information fewer times?
• Have completion rates improved and abandonment fallen?
• Have unnecessary handoffs between teams been removed?
• Do screening and verification results feed directly into risk assessment and decisions?
• Can eligible low-risk customers progress automatically, without unnecessary manual approvals?
• Are compliance professionals spending less time on admin and more on genuine concerns?
• Are customers facing fewer avoidable delays and restrictions?
• Are decisions consistent, with the appropriate evidence and oversight?

Faster onboarding is valuable, but not if it moves the work elsewhere or causes problems later. A high automated approval rate isn't success if customers then face restrictions or repeated requests. Compliance doesn't stop at onboarding, so look at the whole customer journey, through to ongoing reviews. Technology should make that process more effective, not just faster.

So, What's the Answer?

I don't think Detected fits neatly into one category.

We're a compliance platform, providing business verification, identity verification, screening, risk assessment and ongoing compliance. We're also a process improvement platform, changing how information is collected, how checks are performed, how teams collaborate, how decisions are supported and how customers move through onboarding. The two go hand in hand.

We can make processes more efficient without removing important controls, so compliance teams spend less time on admin and more on the work they were hired to do. But businesses have a part to play. Investing in a platform to improve your processes means being prepared to question the ones you have: not removing controls or changing for the sake of it, but being open to a better way. Keep operating exactly as before, and there's a limit to what any technology can achieve.

So perhaps the question isn't whether we're a compliance platform or a process improvement platform. Perhaps it's why businesses should have to choose between the two in the first place.