Research behind RiskDesk Copilot
Understanding the work before designing
RiskDesk began with a simple assumption: KYC teams handle large volumes of alerts, so helping analysts reach decisions faster could improve the workflow. Before designing anything, I wanted to understand whether speed was really the problem. Because RiskDesk is an independent concept, I did not have access to a client, real customer data, or KYC analysts. The research is therefore based on secondary sources: regulatory guidance, industry reports, role documentation, public product materials, and selected user reviews. The goal was not to imitate primary research. It was to build enough domain understanding to form credible product hypotheses and be clear about what would still need to be validated with real analysts.
01. What makes KYC review difficult?
A screening alert is only a signal. A customer might be flagged because their name resembles a watchlist entry, because information is missing, or because another source raises a potential concern. The analyst still has to determine whether those signals actually belong to the person or company being reviewed. That means comparing sources, resolving discrepancies, understanding what is missing, and documenting why a particular outcome was reached. The research consistently pointed to a workflow based on interpretation rather than simple checklist completion. Role documentation also describes analysts classifying alerts, investigating ambiguous cases, and recording the rationale behind their decisions.
90 to 95%
of screening alerts may be false positives
88%
of firms keep KYC data in two or more systems
The same industry poll reported that 46% use between five and nine systems, showing how fragmented the information behind a single case can become.
What this suggested
The challenge was not simply detecting more risk. Analysts were already spending significant effort separating relevant signals from noise and rebuilding the context needed to make sense of a case. That pointed toward a different opportunity: Let the system do more of the gathering so the analyst can spend more time interpreting.
02. The decision itself was not the biggest source of work
My original framing focused on speed:
How might we help KYC analysts resolve complex onboarding cases faster and with more confidence, while keeping them in control of the final decision?
But mapping the workflow challenged that assumption.
The journey looked more like:
Open alert → Gather context → Interpret → Decide → Document → Close or escalate
The strongest friction appeared in two places:
Before the decision
Analysts have to gather information across systems, compare records, investigate conflicting signals, and determine what is still missing.
After the decision
They need to explain the reasoning clearly enough for another analyst, reviewer, or auditor to understand later.
The actual decision can be relatively quick once enough context exists. The synthesis therefore identified the work around the decision as the more useful design opportunity.
The reframed opportunity
How might we reduce the work around complex KYC decisions while keeping judgement and accountability with the analyst? This became the foundation for RiskDesk.
03. The workflow involves more than one person
Secondary research also suggested that KYC cases often move through several operational roles. I used three proto-personas to understand how information needs to travel through that chain. They are based on desk research, not interviews, so they should be treated as working models to validate later.
Primary proto-persona
Maria · First-line analyst
Handles the highest volume of alerts.
Needs:
clear prioritisation
evidence gathered in one place
understandable signals
less repetitive documentation work
Secondary proto-persona
Diego · Senior analyst
Receives more complex or escalated cases.
Needs:
the context behind the escalation
visibility into unresolved evidence
a clear record of what has already been reviewed
Secondary proto-persona
Laura · Team lead
Is responsible for throughput and quality across the team.
Needs:
consistent documentation
decisions that can be reconstructed later
visibility into where judgement may be diverging
The detailed proto-persona work also surfaced a useful tension: the first-line analyst needs efficiency, while senior and lead roles depend on the quality of what gets passed downstream.
Product implication
The core workflow would focus on the first-line analyst, but the record they create had to remain useful beyond that moment.
That led to an early product principle:
The system gathers, the analyst interprets, and every decision leaves a trace.
04. AI introduced a second problem: influence
The research did not only point to operational friction.
It also raised a question about how AI should participate in a decision that still belongs to a person.
The EU AI Act’s human-oversight provisions explicitly identify automation bias as a concern for high-risk AI systems: people may rely too heavily on automated outputs when those outputs influence human decisions.
I used this as a design consideration rather than as a claim that RiskDesk itself has a particular legal classification.
This created an important tension:
AI could reduce workload, but a convincing recommendation could also influence how the analyst interprets the evidence.
That became one of the questions the design needed to address.
05. What existing products already do well
I reviewed six products across onboarding, case management, screening, fraud, and identity decisioning:
Unit21, Alloy, ComplyAdvantage, Sumsub, Sardine, and Socure.
The review focused on interaction patterns rather than visual styling:
how risk and priority are presented
how recommendations are explained
how evidence is organised
how escalation works
how decisions are documented
how uncertainty is represented
The analysis was based on public product pages, documentation, technical material, and selected reviews. I did not have access to the products in production, so the teardown only describes what could be observed from those sources.
Several patterns were already well established
Consolidated evidence
Information from different sources is brought into one case view.
Explainable signals
Products increasingly show why an alert was triggered rather than presenting only an opaque result.
Priority without verdict
Some products distinguish investigation priority from the likelihood that a customer has done something wrong.
Structured reason codes
Reason codes make outcomes easier to compare, review, and audit.
Automatic audit history
Actions and decisions can be logged without adding more manual documentation work.
These became baseline patterns for RiskDesk rather than areas where I needed to invent something new.
06. Where I saw room to explore
The competitive matrix compared eight patterns across the six products.
The least represented pattern in the public materials reviewed was:
Making uncertainty and missing evidence explicitly visible.
Most of the products clearly supported risk detection, alert explanation, evidence consolidation, or auditability. There was less visibility into questions such as:
What information is still missing?
Which sources conflict?
What prevents the case from being assessed?
What should an AI assistant do when the evidence cannot support a reliable recommendation?
The matrix deliberately treated “not documented” differently from “does not exist”, so this was not a claim that competitors never support these situations. It was simply the least visible pattern in the material reviewed.
The opportunity
RiskDesk could make what is not known as visible as what is known. That idea eventually produced two separate concepts in the product:
Evidence state
Describes the condition of the available evidence:
Sufficient
Missing information
Conflicting evidence
Copilot assessment
Describes whether that evidence is enough for the AI to support a reliable recommendation:
Unable to assess
This distinction became important because a case can contain conflicting evidence while the Copilot simultaneously acknowledges that it cannot responsibly support an outcome.
07. From confidence to evidence
An early concept used a familiar AI pattern:
Recommended action→ 92% confidence
It looked efficient but, it also introduced two problems.
First, showing the recommendation before the evidence could anchor the analyst on the AI's interpretation.
Second, a precise confidence number could make the recommendation feel certain without showing what evidence remained missing or contradictory.
The design therefore moved away from treating confidence as the central communication mechanism.
Instead:
Evidence comes first.
The analyst sees the signals, sources, gaps, and contradictions before an AI recommendation appears.
When that evidence cannot support a reliable recommendation:
The Copilot can say “Unable to assess” instead of forcing an answer.
The design explorations consistently preferred this evidence-first hierarchy over recommendation-first or equally weighted layouts because it created more space for the analyst to form their own interpretation.
This remains a hypothesis, not a validated solution.
08. AI should help after the decision too
The research journey showed another important source of effort: documenting the outcome. Two obvious solutions created opposite problems.
Free-text rationale
The analyst writes everything from scratch.
This preserves ownership, but keeps the manual documentation burden.
Fully generated rationale
AI writes the explanation.
This reduces effort, but creates a risk that the analyst approves reasoning they did not fully form or verify.
The design exploration therefore chose a middle ground: Structured reasons + editable AI-assisted draft
The final flow became:
1. The analyst chooses the outcome.
2. The analyst selects the reasons supporting it.
3. They can add optional context that the structured reasons do not capture.
4. Only then does RiskDesk prepare an editable rationale linked to the evidence already reviewed.
5. The analyst reviews and owns the final explanation.
This was chosen specifically to reduce documentation effort without handing authorship of the judgement to the AI.
09. The resulting product direction
The research ultimately moved RiskDesk away from the idea of an AI system that simply helps analysts make decisions faster.
The product direction became:
Gather
Bring fragmented customer information, screening results, documents, and sources into one case view.
Explain
Help the analyst understand why signals matter and where information conflicts.
Show uncertainty
Make missing information visible and allow the Copilot to withhold a recommendation when the evidence is not enough.
Leave the judgement human
The analyst chooses what happens next and commits to an outcome before AI helps document it.
Make the reasoning traceable
Connect the final rationale to evidence, reason codes, case state, and history so someone can reconstruct what happened later.
What still needs validation
Everything above supports a direction, not proof that the final interaction works. RiskDesk has not been tested with KYC analysts.
The most important questions are therefore behavioural.
Does evidence-first presentation encourage more careful review?
Test cases where the Copilot is:
correct
convincing but incorrect
unable to assess
Observe whether analysts inspect the evidence before acting.
Are the evidence states understandable?
Check whether analysts understand:
Sufficient
Missing information
Conflicting evidence
and how those differ from the Copilot assessment:
Unable to assess
Does the Decision Composer improve documentation?
Compare: Free-text rationale vs Structured reasons + editable AI-assisted draft
Look at clarity, completeness, editing effort, and whether the final explanation still reflects the analyst's reasoning.
Does the workflow match real KYC practice?
Validate terminology, evidence requirements, escalation behaviour, and decision boundaries with active compliance specialists.
The question that could change the design
If analysts still accept an AI suggestion without reviewing the evidence, is changing the order enough, or should they form an initial judgement before seeing the suggestion?
Takeaway
The difficult part of KYC review was not simply reaching a verdict. It was assembling enough context to understand the case, recognising when the evidence was not enough, and leaving behind reasoning that another person could understand later.
Sources
01 FATF — The FATF Recommendations (jun 2025): fatf-gafi.org/publications/Fatfrecommendations
02 FATF — R.10 Customer Due Diligence, síntesis: financialcrime.lu
03 Flagright — Understanding FATF Recommendations for AML Compliance (feb 2026)
04 EU AI Act — Article 14, Human Oversight: artificialintelligenceact.eu/article/14
05 European Commission — Regulatory framework for AI: digital-strategy.ec.europa.eu
06 SymphonyAI — KYC market shift to continuous risk monitoring (apr 2026)
07 KYC360 / SIFS session poll, vía fintech.global (apr 2026)
08 Sardine — Reducing false positives in sanctions screening
09 ShadowDragon — Biggest KYC challenges & verification process (2026)
10 Jinba — Best KYC automation tools, práctica de compliance citada (apr 2026)
11 LlamaIndex — KYC automation (may 2026)
12 Hyperverge — KYC Analyst Career Guide 2026
13 Velvet Jobs / SMBC / AML Square — KYC Analyst job descriptions (2026)