I've seen two bad versions of compliance in product development.
In the first, the product team builds the experience they want, gets close to launch, and then asks Compliance to approve it. Controls are bolted on at the end. Screens multiply. Journeys break. Everyone complains that Compliance is blocking the product.
In the second, the organisation does the opposite. Every possible control is pushed to the beginning of the journey. Every customer answers every question. Every risk is treated as though it has already materialised.
The first approach creates compliance debt.
The second creates customer friction.
Neither is particularly good product development.
There is a better way to think about it.
I call it Progressive Compliance.
What I mean by Progressive Compliance
Progressive Compliance is the idea that compliance should evolve with the customer's relationship, behaviour, product usage and risk.
You establish the controls legally required before a customer can access a product or perform an activity.
Then, as their activity changes, their risk changes or they request access to higher-risk capabilities, the level of assurance changes with them.
Put simply:
Don't ask for maximum assurance at minimum risk.
Ask for the assurance required for what the customer is trying to do.
That distinction matters.
This is not about weakening controls. It is not about finding clever ways around KYC, AML, consumer protection, data protection or any other regulatory requirement.
And it certainly doesn't mean delaying a mandatory control beyond the point at which regulation requires it.
It means designing compliance around risk and customer context, rather than treating compliance as one enormous gate every customer must climb over.
That thinking isn't alien to regulation. Risk-based approaches are already fundamental to financial crime frameworks. The FCA, for example, expects firms to tailor customer due diligence to risk and apply enhanced measures where the risk is higher. Its 2026 review of CDD practices specifically highlighted stronger firms tailoring their approach to customer risk rather than treating every relationship identically.
Progressive Compliance takes that principle and asks a product question:
What should that look like in the actual customer experience?
Compliance friction isn't the problem
A lot of product conversations start from the wrong assumption:
"How do we reduce compliance friction?"
I think the better question is:
Where does the friction belong?
Some friction is useful.
I want my bank to challenge a suspicious login.
I want additional verification before someone moves a large amount of money from an unfamiliar device.
I want a financial institution to notice when behaviour suddenly looks nothing like the customer it thought it knew.
The customer problem isn't simply that friction exists.
The problem is friction without context.
Imagine asking a new customer for extensive source-of-funds documentation before they have done anything that requires it.
Or forcing a customer making a routine £50 payment through the same controls as someone initiating a materially larger, unusual cross-border transaction.
The controls may individually make sense.
Their placement may not.
Good compliance design therefore asks three questions about every control:
What risk are we controlling?
Why does this control need to happen now?
What does it cost the customer?
If the team cannot answer all three, I would question whether the control has been properly designed into the product.
Think in layers, not gates
A Progressive Compliance architecture could look something like this.
Layer 1: Foundational assurance
Establish the identity, eligibility, consent, screening and other controls required to create the relationship in the first place.
This is your regulatory foundation.
It should be rigorous, but the experience should still be designed deliberately.
Compliance requirement does not automatically mean bad UX.
Layer 2: Capability-based controls
Different capabilities create different risks.
Holding money may create one set of obligations.
Sending money creates another.
Cross-border transfers may introduce additional considerations.
Increasing transaction limits may require more information.
A business account creates questions that don't exist for an ordinary consumer account.
Rather than treating every future possibility as an onboarding requirement, build controls around the capabilities the customer actually wants to use.
Layer 3: Risk-triggered step-up
Sometimes the customer hasn't changed what they want to do. The risk around the activity has changed.
New device.
Unusual beneficiary.
Material change in transaction behaviour.
Higher velocity.
Unexpected geography.
Sanctions or PEP status change.
A previously normal customer relationship suddenly exhibiting unusual characteristics.
This is where step-up controls become powerful.
Ask for more assurance because something has happened that justifies more assurance.
Layer 4: Continuous compliance
Onboarding is not the end of compliance.
A customer you understood twelve months ago may not look the same today.
Risk profiles change. Behaviour changes. Businesses change. Regulations change.
The FCA's guidance is explicit that firms should continuously monitor customers and ensure activity remains consistent with what they know about the customer and their risk profile.
So good compliance architecture has memory.
Monitoring feeds back into risk.
Risk changes controls.
Controls change the experience.
That is fundamentally a product system.
Consider a fintech customer journey
Imagine a customer opening a financial account.
The traditional temptation is to think:
How much information could we possibly need from this customer? Let's collect it now.
Progressive Compliance asks something different:
What must we know before this relationship begins, and what additional assurance becomes necessary as the relationship develops?
The customer completes the identity and eligibility checks required to open the account.
They start with an appropriate set of capabilities and limits.
Later, they want higher limits.
The additional exposure now justifies additional verification.
They begin making transactions inconsistent with their expected behaviour.
The monitoring system responds.
They initiate an activity that carries greater fraud, AML or regulatory risk.
The system steps up the appropriate control.
The customer gets more capability as the institution gets more confidence.
There are already real-world examples of tiered approaches. FATF's 2025 financial-inclusion guidance describes tiered KYC models where customers begin with restricted capabilities and progressively receive higher limits as additional identity assurance is completed.
The principle is simple:
Capability and assurance can grow together.
This changes how Product and Compliance work together
Progressive Compliance cannot work if Compliance arrives two weeks before launch.
It also won't work if Product treats compliance requirements as tickets to be reluctantly implemented.
The operating model needs to change.
When designing a product, Product should understand the regulatory outcome Compliance is trying to achieve.
Compliance should understand the customer behaviour Product is trying to enable.
Engineering should understand where controls can be automated, monitored and made adaptive.
Fraud and Risk should understand where behavioural signals can provide better decisions than static rules.
Operations should understand what happens when automation cannot make a confident decision.
These teams should be designing one system, not negotiating against one another.
That also means Compliance should be involved while the customer journey is still being designed.
Not because Compliance should design the product.
But because the cheapest time to design a good control is before the architecture assumes it doesn't exist.
You need to measure compliance as a product capability
Passing an audit is not enough.
I would want to know:
- How many legitimate customers are being stopped?
- Where are customers abandoning compliance journeys?
- What percentage of cases require manual review?
- How long does a legitimate customer wait for a decision?
- Which controls generate the most false positives?
- How often are customers being asked for information we already hold?
- Which risk triggers actually predict bad outcomes?
- How much fraud or financial-crime exposure are the controls preventing?
- Which controls create significant customer friction without corresponding risk reduction?
Compliance effectiveness and customer experience should appear on the same dashboard.
Because a control that catches everything by stopping everyone isn't necessarily a good control.
And a beautiful journey that lets unacceptable risk through isn't a good product.
The job is to optimise the system.
This isn't only a fintech idea
The same principle applies in other regulated industries.
In healthtech, viewing general health information isn't the same risk as accessing medical records or issuing a prescription.
In insurance, getting a quote isn't the same as binding a policy or submitting a high-value claim.
In enterprise software, viewing information isn't the same as approving a privileged administrative action.
Different activities create different levels of exposure.
The controls should understand the difference.
The real product opportunity
For years, many teams have treated compliance as something that happens around the product.
I think the stronger companies will increasingly treat it as part of the product architecture itself.
Identity.
Permissions.
Limits.
Monitoring.
Risk scoring.
Step-up verification.
Transaction controls.
Auditability.
Case management.
Customer communication.
These are not simply back-office obligations.
Together, they determine what the product is willing to allow, for whom, under what conditions.
That's product behaviour.
And once you see compliance that way, the conversation changes.
It stops being:
"How do we get Compliance to approve this?"
And becomes:
"How do we design a product that can safely give customers more freedom as our confidence in the relationship increases?"
That is Progressive Compliance.
Not less compliance.
Not invisible compliance.
The right compliance, at the right moment, for the right risk.
And that is how you build regulated products that customers can trust without making them miserable to use.
Responses
Responses are reviewed before they appear.