Customer Risk Assessment
Rebuilt RAKBANK's CRAM risk calculator, turning a patchwork of Excel files, PDFs, and disconnected systems into a single digital assessment with a full, defensible audit trail.
Every rating, fully defensible
Where it all started
RAKBANK's compliance team rates every customer's risk through a tool called CRAM. The old version lived across Excel files, PDFs, and unconnected systems. Staff had to chase down data and stitch a score together by hand.
That made assessments slow, easy to misread, and hard to defend. When a regulator asked how a rating was reached, the answer lived in old email threads and handwritten notes.
So I set out to turn that scattered process into one tool that could stand up to scrutiny.
What I was solving for
The goal was a tool that produced not just a score, but a defensible decision, one any auditor could trace end to end.
Why did this customer get this rating?
Could we defend it, months later?
The core design challenges
- Consolidate scattered data into one structured form
- Keep the presentation neutral: inform, never nudge a verdict
- Make every decision traceable, with a full audit trail
"The moment an analyst can see which fields move the score, they stop assessing the customer and start working toward a number."
Risk Manager, RAKBANK
Who it's for
Three groups interact with CRAM, each with a different mental model, responsibility, and risk tolerance.
- Compliance officers: primary assessors who complete risk evaluations. They need clarity, speed within accuracy constraints, and defensible outputs.
- Risk managers: reviewers who approve or challenge assessments. They need transparency into how a score was derived, and the full override history.
- Auditors: internal and external reviewers examining past decisions. They need complete, timestamped records of every input and change.
How I approached it
I treated this as a workflow problem before a UI problem, understanding how an assessment actually moves through the compliance team before drawing a single field. The regulatory logic had to be right before the interface could be.
The journey
-
Stakeholder interviews
Deep conversations with compliance officers, risk managers, and auditors to understand each group's needs.
-
Workflow & compliance mapping
Mapped the full assessment journey across tools and handoffs, against the regulatory requirements driving it.
-
Concept design
Translated the workflow into a single unified form, with clear data provenance built in from the start.
-
Prototype testing
Iterated with compliance officers to validate the form structure and the override workflow.
-
Phased delivery
Rolled out in phases, running in parallel against the legacy process until the new tool earned trust.
Where it broke down
The original CRAM wasn't a single tool at all. It was a fragmented patchwork of spreadsheets, PDF forms, and disconnected data sources that staff had to reconcile by hand.
- Data spread across multiple disconnected systems
- Fields arranged arbitrarily, with no structured form
- System data and manual input mixed together
- PDF reports showed numbers, but no reasoning
- No audit trail when a rating changed
Principles that guided it
Four principles, drawn from compliance requirements and user research, shaped every decision.
- Audit-first: every interaction produces a defensible record. No action without attribution.
- Neutral presentation: fields never reveal how much they sway the score, so assessors record what's true instead of steering the outcome.
- Progressive disclosure: complexity surfaces only when needed. Simple cases stay simple.
- Prevention over correction: validation happens inline, before submission. In compliance, a wrong submission costs too much to fix after the fact.
One form, the way staff actually work
The redesign puts the whole assessment on a single page, organised by data source. System-populated fields are visually distinguished from manual inputs, and a sticky in-page nav keeps long assessments oriented, no more stitching a score together across tools.
A verdict, with its receipts
The final summary pairs the calculated rating with everything behind it: the score band, the customer context, and the maker, checker, and timestamp. Print or export it, and the full audit trail travels with the decision.
Behind the design
The board where the work actually lived: competitive analysis, personas, empathy maps, user stories, and a problem statement on the discovery side; information architecture, low-fidelity wireframes, and a component inventory on the solution side.
What happened next
A scattered, manual process became one tool the compliance team could trust.
- Assessment time cut through a single consolidated workflow
- A full audit trail on every assessment, no more reconstructing records by hand
- System and human input clearly separated, every time
- Three-tier reporting: verdict, rationale, and evidence
Looking back
Compliance UX isn't about making things beautiful. It's about making correctness achievable and defensibility automatic.
The hardest problem wasn't the form. It was the override workflow. Getting the balance between flexibility and accountability right took three rounds of testing.
And the officers' biggest frustration was never complexity. It was lack of trust in the outputs. Making data provenance visible turned out to be the most impactful decision I made.
Want to talk through the details?
Happy to walk through the research, the design decisions, and what didn't make the cut.
Get in touch