Risk Profile & Identity
Wealth management · CRM & CLIENT APP · PRODUCT DESIGN
Risk Profile & Identity
Bringing two externally managed regulatory checks into the client app and CRM to reduce administration and improve completion.
12,630+
relationship manager hours saved a year
~75%
less time per client
~21,900
cases processed
~$60k/yr
tool retired
Reported task time fell from 60 to 15–18 minutes for identity verification (turnaround 14 → 8 days) and from 30 to 5 minutes for the risk profile (turnaround 10 → 3 days), measured across real cases.
Role
Product Designer · led design
Company
Wealth management firm
SCOPE
Internal CRM and the client app
Timeline
Jun → Aug, Oct 2025
Context
At a global wealth management firm, I worked as a Product Designer across the CRM and the connected client experience. My work focused on making complex financial processes easier for clients to complete and for relationship managers and internal teams to manage.
The brief was to bring identity verification and the risk profile questionnaire into our products. Both processes were previously completed outside the client app and CRM, through emails, calls and separate third-party platforms. Relationship managers and coordinators managed requests, transferred information between systems and followed up with clients when something was missing.
There wasn’t an existing end-to-end digital journey we could reuse. We needed to integrate specialist verification and assessment services, connect their results to the client record and design an experience that worked for everyone involved.
What began as a request to digitise two external processes became one connected workflow supporting both independent and assisted completion.
Problem
Identity verification and the risk profile are essential requirements before a client’s case can progress. When either is incomplete, the relevant recommendation cannot move forward. Both also recur during the client relationship, so inefficient completion affects operational capacity, client experience and the speed at which cases can progress.
Before the redesign, identity verification required approximately 60 minutes per client, with an average turnaround of 14 days. The risk profile took around 30 minutes, with a 10-day turnaround.
For identity verification, relationship managers or coordinators requested documents by email, followed up on missing information and coordinated verification through third-party services. Different relationship managers sometimes used different providers.
For the risk profile, clients received a questionnaire outside the app, returned their answers, and relationship managers or coordinators manually entered those responses into a separate risk-assessment platform to generate a result.
Neither journey was connected to the client app or the CRM. Clients moved outside the product to complete mandatory requirements, while relationship managers had to coordinate the work and bring the outcomes back into their existing client-management process.
The underlying problem wasn’t the regulatory requirement itself. It was the fragmented process required to complete it.
To understand the process from different perspectives, I involved 17 participants across research and validation: 10 clients, five relationship managers and two approvers. Their input helped distinguish the client’s difficulties completing the requirements from the relationship manager’s administrative burden and the approvers’ need for a reliable, reviewable record. This made it clear that improving the forms alone would leave much of the underlying coordination problem unresolved.
Key limitations included:
External processes
Neither identity verification nor risk profiling had an end-to-end journey within the client app or CRM.
Jurisdiction-specific identity verification
Identity-verification documents and checks varied by agency and jurisdiction. A universal identity verification journey would not meet every requirement.
Consistent risk profile requirements
Unlike identity verification, the risk profile experience could follow the same assessment structure across jurisdictions.
Different user needs
Clients needed a clear way to complete requests, relationship managers needed actionable results, and approvers needed reviewable records.
Uneven digital confidence
Some clients needed personal assistance even when a task was available digitally.
Solution
I designed a connected workflow that brought both processes into the existing client app and the CRM.
Relationship managers could initiate requests directly from a client’s CRM record, clients could complete them through the app, and progress and results could return to the same client record.
We integrated specialist providers for identity verification and risk profiling, using their verification and assessment capabilities while designing the experience around them.
The two processes share a connected request-and-completion experience, but their underlying requirements are handled differently: identity verification adapts to the relevant jurisdiction, while the risk profile follows a consistent assessment journey across jurisdictions.
What decisions shaped the workflow?
Integrate specialists instead of building verification engines
One option was to develop identity-verification and risk-assessment capabilities internally. That would offer greater control, but would also require engineering resources to build and maintain specialist functionality that dedicated providers already offered.
We chose to integrate specialist identity and risk-profiling providers into our products instead.
This let us focus on the experience that was missing: initiating a request from CRM, guiding completion through the client app, displaying progress, managing exceptions and returning results to the relationship manager.
The trade-off was dependence on external APIs and provider capabilities. In return, we could bring both processes into the existing product experience without taking on the full responsibility of developing the underlying verification and assessment engines.
Adapt identity verification without complicating the risk profile
A single identity-verification journey for all clients would have been easier to design, but identity verification requirements differed across agencies and jurisdictions.
We designed identity verification initiation to account for the relevant agency and jurisdiction, allowing the appropriate verification requirements to be applied through the ID provider.
The risk profile did not need that jurisdiction-based variation. Its questionnaire and assessment experience could remain consistent across jurisdictions through the risk provider.
Keeping these requirements distinct avoided two problems: oversimplifying identity verification and introducing unnecessary jurisdiction-based complexity into the risk profile.
The same assessment flow is initiated across jurisdictions, without jurisdiction-specific branching.
Verification requirements adapt to the client’s agency and jurisdiction before the request is initiated.
Show relationship managers the result before the supporting detail
We explored two approaches to presenting risk profile outcomes. The first displayed the individual assessment metrics prominently, giving relationship managers access to more information upfront. The second led with the client’s final risk assessment and status, while keeping the full report available for detailed review.
Testing with relationship managers supported the result-first direction. Their immediate need was to understand the client’s risk outcome and determine what action, if any, was required. They still needed access to the detailed report, but not as the starting point for every interaction.
The selected approach made the primary result easier to locate without removing the supporting assessment information.
01
Concept A: detail first
The first concept opened on the full assessment — a summary strip followed by statement-by-statement financial personality and knowledge and experience responses — so relationship managers could see exactly how the result was calculated.
02
Concept B: result first
The second concept placed the risk profile inside the client record and led with the outcome: completion status, validity dates and the overall risk level, with risk tolerance, financial personality and knowledge and experience alongside. Confirming the risk level and downloading the report sat with the result.
RELATIONSHIP MANAGER TESTING · 5 PARTICIPANTS · CONCEPT COMPARISON
4/5
looked for the final risk result first
3/5
preferred detailed metrics after understanding the overall outcome
4/5
wanted continued access to the full risk provider report
WHAT RELATIONSHIP MANAGERS NEEDED
01 · Overall risk result
The client’s final risk level, immediately visible.
02 · Clear status
Whether the assessment was complete and ready for review.
03 · Full report when needed
Access to the complete risk provider report for deeper review.
04 · Clear next action
Confirm the result, discuss it with the client or request a change.
03
What testing showed
5 relationship managers compared both concepts. 4 of 5 looked for the final risk result before reviewing any detail, and 3 of 5 found the detailed metrics useful, but only once the overall outcome was clear.
CONCEPT A · DETAIL FIRST
CONCEPT B · RESULT FIRST
✓ Selected
Result first
The overall risk profile is immediately visible.
Detail on demand
Supporting assessment information and the full report stay available without competing with the result.
Action in context
The relationship manager can see what to do next from the same screen.
04
Why Concept B was selected
It matched how relationship managers actually reviewed an outcome: the decision first, the detail second. “Lead with the decision-critical information. Keep the detail accessible, not dominant.”
Preserve relationship manager judgement with a documented reason
A risk profile assessment produces a calculated risk result, but the relationship manager may reach a different agreed outcome after discussing it with the client. The workflow therefore supports an amendment while requiring the relationship manager to record the reason for changing the calculated result.
This preserves both the original assessment and the relationship manager’s determination, making the final outcome understandable to approvers and anyone reviewing the client’s record later.
The required explanation adds a step, but it prevents an important decision about the client from becoming an unexplained change in the system.
01
The calculated result is preserved
The risk provider places the client on a seven-level scale (here, High), with risk tolerance, capacity for loss and knowledge and experience alongside. The status stays Pending Confirmation until the relationship manager reviews it.
02
Judgement is supported, but not silently
The relationship manager can disagree with the calculated level and choose an agreed one here, Medium High. The calculated rating stays in view, a reason for change is required, and confirming records that the result was discussed with the client.
03
Override the outcome, not the evidence
Once confirmed, the risk profile is Completed. Both ratings sit on one scale — agreed Medium High, calculated High — and the reason for change stays on the client’s record alongside the final report.
How was the experience validated before launch?
The workflow needed to make sense to the clients completing requests, the relationship managers initiating and reviewing them, and the approvers responsible for the outcomes.
I involved clients, relationship managers and approvers across research and validation to understand their requirements and assess the proposed experience at different stages.
Relationship manager testing informed the risk profile result presentation. Approvers helped validate the verification requirements, amendment behaviour and records needed for review.
During implementation, I worked with engineering and QA to check the completed journeys and exceptions, including partial completion, expired documents, resubmission and relationship manager amendments. This helped verify that the process worked beyond its ideal completion path before production release.
RAW PROTOTYPE-TESTING NOTES · NAMES ANONYMISED
Visibility
Important actions could be lost in the dashboard.
“Notification blends in”
“Lost at the bottom in the dashboard”
Language
Terminology needed to match how relationship managers describe the decision.
“Confirm risk profile rather than agree risk profile”
“Send risk profile instead of request”
Continuity
Users needed confidence progress wouldn’t disappear.
“Save as we record the information in case I leave the app and it crashes”
“When going back, not instantly clear that you need to press continue”
01
Clicking through wasn’t the problem
Sessions with relationship managers, a drafter, a coordinator and an app user showed they also needed clearer priorities, terminology and recovery behaviour before the workflow could support day-to-day work.
FINDING → CHANGE · IMPLEMENTED IN THE CRM
Make action visible
FINDING
Actions were easy to miss in the dashboard.
CHANGE
Status and primary action lead the risk profile area.
Language of the decision
FINDING
“Agree” vs “confirm” a risk profile confused relationship managers.
CHANGE
Wording built around confirming the risk level.
Result first, report on demand
FINDING
Relationship managers wanted the result fast, with detail available.
CHANGE
Risk level leads; the full report is one click away.
02
Feedback became product decisions
Only changes traceable to testing or stakeholder feedback made it in. Each finding is paired with the change it drove in the CRM.
CHECK & REVIEW QUESTION
WHERE IT IS EVIDENCED
Verification requirements
Does identity verification apply the correct requirements for the relevant agency / jurisdiction?
Requirements follow the client’s applicable configuration accepted documents and FATCA & CRS declarations.
Traceability
Can the original assessment still be reviewed?
The initial risk provider report is available during review; the calculated level stays on the completed record.
Risk-profile amendment
If a relationship manager changes the result, is the original retained?
The record shows the agreed level (Medium High) alongside the calculated level (High).
Reason required
Must the relationship manager record why the risk profile changed?
A comment is captured in Review & Confirm and shown on the record as the Risk Level Change Comment.
03
A valid interaction still needed a reviewable record
Approvers reviewed the requirements and record-keeping behaviour that had to stay true after any client or relationship manager action. The interface itself was designed by the product team.
QA SCENARIO GRID · TRANSITIONS TESTED BEYOND THE HAPPY PATH
Partial / incomplete completion
Keep the request active and show what remains
Missing / rejected document
Client can provide replacement evidence
Resubmission
New evidence returns to review, not a new request
Expired identity verification
Verification becomes actionable and renewal can start
Risk profile amendment
Preserve the calculated result and require a reason
IN DETAIL · REJECTED DOCUMENT → CLIENT RESUBMITS → UNDER REVIEW
Under Review
Action Required
Resubmitted
Under Review
04
We tested the transitions, not just the screens
QA covered partial completion, rejected documents, resubmission, expired identity verification and risk profile amendments, checking each state stayed understandable for the client, the relationship manager and the provider.
What did the first release deliver?
The first release brought both processes into the connected product experience. Relationship managers could initiate requests through the CRM. Clients could complete identity verification and risk profiling through the app rather than relying on the previous external email-led processes. Relationship managers could then view progress and access the resulting verification or assessment information from the client’s record.
The workflow also accounted for incomplete submissions, document resubmissions, unsuccessful outcomes and requests that could not be completed immediately.
Instead of having to establish progress through separate emails and external platforms, authorised users had a clearer view of the request’s current state.
INITIATE REQUEST
01
The relationship manager requests the assessment
The risk profile is requested from the client record in the CRM. The same assessment applies across jurisdictions; unlike identity verification, there is no jurisdiction-specific branching.
ASSESSMENT EMAIL
02
A clear reason to complete it
The client receives an email explaining why the assessment is needed, with a direct route into the Keel app on mobile or desktop.
DASHBOARD
BEFORE YOU BEGIN
SINGLE-CHOICE QUESTION
03
A guided assessment in the app
The dashboard prompts the client to start, sets expectations for the 25 questions, and each question uses the same clear instruction, answer options and Continue pattern.
MULTI-SELECT QUESTION
SUBMITTED
BACK TO THE DASHBOARD
04
Submission creates the handoff
Multi-select questions keep the same journey. Submitting confirms completion, and the dashboard reflects the assessment’s status — completion is a handoff to the relationship manager, not the end.
PENDING CONFIRMATION
REVIEW & CONFIRM RISK LEVEL
AGREED RESULT ON THE RECORD
05
The result continues into the relationship manager’s workflow
The calculated outcome lands on the client record as Pending Confirmation. The relationship manager reviews it, confirms or selects a different agreed level with a comment, and the agreed result is recorded — with no manual re-entry into the risk provider.
01
Requirements are set before the request goes out
The relationship manager sets agency, service, delivery and residency, then chooses client self-verification or assisted verification. The request is initiated from the client record in the CRM.
VERIFICATION EMAIL
02
The request arrives by email
The client receives a clear explanation of the verification requirement, with a single Complete Verification action that takes them into the app.
DASHBOARD
VERIFY IDENTITY
PROOF OF IDENTITY
03
Verification starts in the app
The dashboard surfaces “Verify your identity within 14 days”, and the checklist shows each requirement — proof of identity, proof of address, liveness check and tax residency — before the client begins.
FATCA & CRS
SUBMITTED
BACK TO THE DASHBOARD
04
Declarations, then back to the app
FATCA & CRS declarations are collected through a guided form. Submission ends with a clear confirmation, and the client returns to their dashboard while documents are reviewed in the background.
05
The result lands back in the CRM
Once verified, the relationship manager sees the outcome on the client record — status, completion and validity dates, each requirement’s status and the verification results.
What changed after launch?
Digital completion didn’t mean every client could complete the process independently.
After launch, we found that approximately 15% of clients were not particularly comfortable with technology or did not regularly use the app. They still needed their relationship manager’s help to complete the mandatory processes.
The first release had brought identity verification and risk profiling into our products, but for these clients, self-service alone had not removed the administrative burden.
Rather than treating the finding solely as an adoption issue, we introduced an explicit assisted journey.
A relationship manager could complete the questionnaire and help provide the required documents with the client, whether during a call or in person, through the connected CRM workflow.
Self-service and assisted completion now provide two ways to complete the same requirements, while keeping the same reviewable record.
The important correction was recognising that the goal was complete, reviewable completion, not self-service for its own sake.
01
One request, two completion routes
The relationship manager initiates the risk profile from the client record and chooses how it will be completed — client self-assessment or assisted. The method is a choice inside the existing request, not a separate product or record.
02
Assisted, with a reason on record
Choosing assisted asks for a reason and a description before the relationship manager starts, so the use of the assisted route stays traceable.
RISK PROFILE ASSESSMENT
ASSESSMENT SUBMITTED
03
The same assessment, completed with the client
The relationship manager works through the same Risk Profile Assessment with the client. Submission confirms it was completed on the client’s behalf and moves it into review.
04
Both routes return to one risk profile record
The completion method changes; the record and review don’t. The client record shows the method, the reason and the calculated result, ready for the relationship manager to review and confirm — no second record, no second process.
Impact
Bringing identity verification and the risk profile into the client app and the CRM reduced manual coordination, shortened completion and turnaround times, and supported a substantial volume of cases.
Less time completing checks, less time waiting for results
12,630+
relationship manager hours saved a year
~75%
less time per client
~21,900
cases processed
~$60k/yr
tool retired
Identity verification 60 → 15–18 min, turnaround 14 → 8 days. Risk profile 30 → 5 min, turnaround 10 → 3 days.
The improvement came from connecting two previously external processes to the products clients and relationship managers already used, rather than simply replacing their forms.
How I worked
With
Clients, relationship managers, approvers and engineering
I involved clients, relationship managers and approvers to understand their different requirements and validate the proposed experience. I worked with engineering to connect the identity and risk-profiling providers to the CRM, and collaborated with QA to verify the workflow across completion paths, exceptions and regulatory requirements.
ARTEFACTS
Research, workflow models and validation
My work included current-state journey maps, interview synthesis, the request-state model, jurisdiction-specific workflows, risk profile concept comparisons, interactive prototypes and QA scenarios. These artefacts helped align teams on what the experience needed to do and how it should behave beyond the happy path.
AI AS ASSISTANT
Accelerating synthesis and identifying edge cases
I used AI to accelerate the synthesis of relationship manager interview findings into the workflow’s state model and identify potential edge cases in the flow logic before engineering handoff. The resulting ideas were reviewed against the research findings and validated with the relevant stakeholders rather than treated as final design decisions.
What I learned
Design for different levels of support
I underestimated how many clients would still need their relationship manager beside them. The post-launch findings reinforced that making a task available digitally doesn’t automatically make it accessible to everyone.
Design with approvers, not around them
Involving approvers during design and validation helped us account for verification requirements, amendments, failure states and auditability as part of the experience.
Preserve the reasoning behind decisions
An amended risk rating needs more than an updated value. Recording the relationship manager’s reason makes the outcome understandable to someone who wasn’t part of the client conversation.
Reuse the workflow without forcing identical requirements
Identity verification and risk profiling can share a connected product experience without sharing every underlying rule. Distinguishing identity verification’s jurisdiction-specific requirements from the risk profile’s consistent assessment journey avoided unnecessary complexity.
What’s next
The current identity verification workflow handles verification requirements for one regulatory agency or jurisdiction at a time. Clients whose circumstances span multiple jurisdictions may still need to provide overlapping documents or repeat verification steps.
The next opportunity is to coordinate those identity verification requirements within one client journey, identifying which information can be reused and which checks must remain specific to an agency or jurisdiction.
The risk profile already follows a consistent assessment journey across jurisdictions, so the next step is not to introduce the same jurisdiction-handling model into the risk profile. It is to improve how overlapping identity verification requirements are managed for clients with more complex circumstances.
More case studies