How product teams can make verification feel clearer without weakening the controls behind it
By Quadri Ismail
I have watched compliance managers spend days moving between government portals and internal systems to confirm information their own company already held, while an international business payment waited. The exact time and number of portals vary by case, but the pattern is familiar: a legitimate transaction becomes a scavenger hunt for evidence.
It is tempting to blame the rules, or the people who enforce them. In my experience building platforms such as ryno and working on compliance verification tools such as Clearpass NG, the deeper failure is often product design. The system asks the user to bridge gaps between databases, departments, and policies that the product could have made visible and manageable.
The design challenge is not to remove compliance. It is to distinguish necessary controls from avoidable effort. I call the avoidable kind dumb friction: repeated data entry, unexplained document requests, disconnected portals, and a vague “under review” status. Smart friction applies a control when it is relevant, reuses reliable evidence where permitted, and explains what happens next.
That distinction matters because compliance is not a single screen. It is a decision process involving the business, the operator handling a case, and the people who later need to understand or audit the decision.
Friction can be necessary; confusion is optional
A verification step may protect against impersonation, money laundering, sanctions violations, fraud, or inaccurate company records. Removing a required check can create real harm. Yet a user should not have to guess why a check appeared, whether a previous result still counts, or what they can do while a case is pending.
The Financial Action Task Force’s guidance on digital identity describes a risk-based approach: understand the assurance of the identity system and assess whether it is reliable and independent for the risk at hand. That is a useful product principle too. A check should reflect the evidence and risk, rather than trigger the same blanket request for every user. FATF Guidance on Digital Identity
Smart friction is not invisible surveillance or automatic approval. It is a more deliberate interaction: reuse what is valid, ask for what is missing, show the reason, and route uncertainty to a person with enough context to resolve it.
Start with an evidence journey, not a form
A common product mistake is to begin with the fields a team wants to collect. Start instead with the decision the organization must make and the evidence that supports it.
For a business payment, the journey might include confirming the legal entity, checking that the person acting for it is authorized, screening relevant parties, and reviewing transaction-specific details. The exact obligations depend on the institution, corridor, product, and applicable law; this is a design example, not legal advice.
For each evidence item, define:
- Purpose: Which decision or control does this support?
- Source: Where did the evidence come from, and is that source appropriate for this use?
- Freshness: When was it checked, and when must it be refreshed?
- Confidence: Is the result conclusive, incomplete, or ambiguous?
- Action: What should happen when it passes, fails, expires, or conflicts with another source?
This small evidence model changes the interface. If a registry result is current and acceptable for the decision, do not ask the user to upload a scan of the same record. If the source is unavailable, say so and offer a fallback. If a name match is ambiguous, route it for review rather than displaying a generic failure.
A useful request names the evidence, explains why it is needed, states who can provide it, and shows what will happen after submission. “Upload proof of address” is an instruction. “We could not confirm the registered address from the company record; upload a recent utility bill or bank statement so an analyst can complete this check” is a next step.
A unified system needs more than one dashboard
A unified experience does not mean one giant database or a single screen that hides every detail. It means the workflow has a consistent way to gather, evaluate, explain, and preserve evidence across its sources.
A practical architecture has several parts:
1. Experience layer: onboarding, payments, and case status surfaces that tell the user what is happening.
2. Orchestration layer: coordinates source queries, document collection, retries, and case routing.
3. Evidence layer: records the value or result, source, timestamp, confidence, expiry, and permitted use.
4. Policy layer: applies the institution’s configured rules and thresholds, with versioning and jurisdiction context.
5. Case and decision record: stores the outcome, reason, reviewer, overrides, and user-facing explanation.
6. Connectors: integrate with registries, identity providers, screening systems, internal ledgers, and document services.
The boundaries matter. A source response is evidence, not automatically a decision. A policy outcome should be reproducible from the evidence and policy version used at the time. A human override should include a reason. If evidence changes or becomes stale, the system should be able to identify which decisions may need another look.
Security and governance belong throughout the flow: limit access by role, protect sensitive data, define retention, record access, and make correction or appeal paths possible. “Unified” should make accountability easier to see, not harder to locate.
Design for three users, not one
A compliance journey usually has at least three audiences, each with a different definition of a good outcome.
The business wants to complete legitimate work with minimal uncertainty. It needs to know what information is required, why it is required, and whether the payment or onboarding step can continue.
The compliance operator needs a manageable queue, relevant context, and a clear way to resolve exceptions. Showing the source and age of a result reduces time spent reconstructing what happened. A reviewer also needs room to disagree with an automated signal and record why.
The regulator or auditor needs evidence that the organization applied its controls consistently and can explain a decision later. That calls for a traceable record of inputs, source timestamps, policy version, review actions, and outcome.
These users are connected. A UI that conceals uncertainty from the business may create extra support work. A workflow that saves the business a click but strips context from the reviewer may slow resolution. A complete design makes progress legible to the business, gives operators useful context, and preserves an audit trail.
Measure the friction you intend to remove
“Frictionless” is not a useful success metric on its own. Teams should measure whether the process is faster and clearer while the control remains effective. Useful measures include:
- time from submission to a clear outcome, segmented by risk and case type;
- percentage of evidence requests that are satisfied on the first attempt;
- duplicate document or data requests per case;
- cases routed to manual review, and the reasons for routing;
- false positive and false negative rates where those labels can be responsibly established;
- user abandonment and support contacts during verification;
- stale evidence, overdue reviews, and policy exceptions;
- reviewer override frequency and subsequent outcomes.
Pair speed metrics with quality and risk measures. A lower review rate is not automatically an improvement if missed issues increase. A faster average can hide a long tail of unresolved cases. Break results down by market, customer type, language, and accessibility needs to find where the workflow still shifts effort onto particular users.
Start with one journey. Map every request, decision, handoff, and wait. Remove duplicate asks where evidence can lawfully and safely be reused. Make each remaining check explainable. Then test the result with business users and the people who review cases. Keep a rollback path for policy changes and monitor the exceptions after launch.
Compliance should feel like a guided process
The choice is not between strong controls and a usable product. Poorly designed friction can obscure the control without making it stronger: users repeat information, operators lose context, and reviewers inherit a thin audit trail.
A better system asks for evidence at the point it matters, gives each item provenance and a freshness rule, treats uncertainty honestly, and makes the next step clear. It keeps humans involved where judgment is needed and records how decisions were made.
That is what I mean by moving from dumb friction to smart friction. The rules may remain heavy. The experience around them can still be coherent.
Disclosure: I am the founding designer at Ryno Finance and have worked on Clearpass NG. Those practitioner experiences inform this article.
Sources
- Financial Action Task Force, Guidance on Digital Identity.