Designing for certainty
How UX shaped the CLM Platform, RAKBANK's compliance control system. CLM manages a customer's compliance lifecycle end to end, from onboarding through every periodic and event-driven review, in one system the bank can defend in an audit.
The right checks, by the right people, in the right order
01 · What is the CLM Platform?
Less a productivity tool, more a control system
The CLM platform is how the bank manages a customer's compliance lifecycle end to end, from onboarding through every periodic and event-driven review, in one controlled system. It makes sure the right checks happen, by the right people, in the right order, with a complete record the bank can defend in an audit.
CLM doesn't work alone. It pulls customer data from Finacle, the bank's core system of record, and runs its review workflows through IBPS, the bank's process engine. CLM is the layer that sits on top of both, the single place where compliance decisions are made, tracked, and defended.
Section 1
The problem worth solving
The systems were never built to talk to each other
People weren't slow because they lacked effort. They were slow because the systems they relied on were never designed to work together.
The teams who check customers against regulation worked across Finacle, IBPS, separate inboxes, and spreadsheets: systems with no common layer between them. Every review ran against a clock. Every handover blurred who was responsible. And when an audit came, reconstructing what had happened was the hardest part of the job.
Section 2
What we knew and what we didn't
Research, constraints, and the assumption that changed everything.
The insight that changed direction
The assumption we walked in with: staff want to move faster. What research told us was the opposite. Every interview surfaced the same pattern: reviewers aren't optimising for speed, they're optimising for defensibility.
The fear isn't missing a deadline. It's approving something they shouldn't have. That single reframe changed how we approached the entire design: we stopped designing for efficiency and started designing for confidence and control.
"They don't want to move faster. They want to move correctly."
What research told us about reviewers
Section 3
The decisions that mattered
Decision 01
Who decides how work gets distributed?
The options we weighed:
As the platform accumulates case history, there's a real question of whether intelligent assignment, one that factors in reviewer track record, case complexity, and current load, becomes possible. We kept the architecture open for it.
Decision 02
How much should staff be asked to justify?
The options we weighed:
We ruled out silent logging because it produces a record but not a narrative: you can see what happened, but not why. We ruled out full justification because it creates friction at high volume and produces low-quality free text nobody reads.
We landed on structured remarks at the moments that matter. It's the difference between a system that logs decisions and one that defends them.
Section 4
The journeys
5+ roles. One system. Designed around how each of them actually works.
Role 01 · The Reviewer
Open the queue, work the case, leave a record
Reviewers live in their own queue. They open it sorted by SLA breach status, pick up a case, work through the entity's details, documents, and risk score, then route it to outreach or complete the review. Every step leaves a record behind it.
Open the queue, sorted by SLA breach status
Open a case from the queue
Review entity details, documents, and risk score
Route to outreach, or complete the review
Role 02 · The Team Lead
See the backlog before it becomes a breach
Team leads land on the dashboard, see the team's workload and backlog, bulk-assign unassigned cases, and watch for who's getting overloaded, before it turns into an SLA breach.
Land on the workflow dashboard
See the team's workload and backlog
Bulk-assign unassigned cases
Monitor who's overloaded before it breaches
Section 5
What we'd do differently
01
Sequence the roles, don't parallelise them
We started designing the reviewer and team-lead experiences at the same time. What we didn't know yet was how much the team-lead role would grow: the assignment logic, the workload visibility, the escalation controls.
Those requirements only became clear as we got deeper in. By then, decisions we'd made for the reviewer were already pulling in a different direction. If we did it again, we'd get the reviewer experience to a stable place first and let the team-lead layer emerge from it, not alongside it.
02
Design for worry, not just for work
We were good at watching people work. We were less good at watching people worry.
We did eventually design for it: the confirmation states, the explicit warnings, the audit trail that tells you someone else already checked this. But we got there a bit late. That thinking belonged at the start of the process, not the middle.
Want to talk through the details?
Happy to walk through the decisions, the research, and what didn't make the cut.
Get in touch