One Process, Many Entities. Redesigning Group KYC at Raiffeisen Bank International
Turning a fragmented compliance process into a centralised platform that bank staff and corporate clients both actually wanted to use.
Raiffeisen Bank International
Lead Product Designer (solo)
8 months
Corporate Banking / Compliance
Figma, FigJam, Dovetail
[ OVERVIEW ]
A dual-sided Group KYC platform for Raiffeisen Bank International. Bank staff got a dense case management workspace; corporate clients got a minimal guided submission flow, both backed by a redesigned data model that finally treats corporate groups as first-class citizens.
Key outcomes
40%
Duplicate document submissions eliminated
30%
Faster onboarding in task-based testing
4.3 / 5
Bank-staff satisfaction post-launch
KYC, Know Your Customer, is one of the most regulated processes in banking. Every corporate client has to be verified before they can do business with the bank.
At Raiffeisen, this worked reasonably well for individual companies.
For corporate groups, it fell apart.
The platform had no concept of a "group." A client with five subsidiaries meant five completely separate onboarding processes. No linking. No shared documents. No way for anyone to see the full picture.
Corporate clients kept submitting the same certificates and filings five times over. Compliance officers couldn't see who had done what. Bank staff opened each case one by one just to figure out where a client group stood.
Solo designer, start to finish.
Research with both user groups, personas, journey maps, information architecture, wireframes, high-fidelity prototypes, usability testing, and handoff to engineering.
The complication: this was a dual-sided product. Bank staff needed a power-user workspace. Corporate clients needed a guided, simple submission flow. Same data layer, two very different experiences.
What the research revealed
Two phases, two groups kept apart
I ran research in two phases.
First, a stakeholder workshop. Compliance officers, product managers, and solution architects mapped constraints on sticky notes. This gave me early alignment on what was technically possible and what was regulatory non-negotiable.
Then, ten user interviews. Five with bank staff, five with corporate clients. Each session had two halves: an open conversation about daily frustrations, followed by a live walkthrough of the existing system.
I kept the two groups separate on purpose. Their mental models are so different that mixing them would have muddied both.
The insight that reframed the project
Clients weren't re-uploading documents because they were confused.
They were re-uploading because the database had no way to link five subsidiaries into one group. Each company was a standalone record. The "repeat submission" pain wasn't a UI problem. It was a data model problem.
You can't design a group dashboard if the data layer doesn't know what a group is.
Before drawing a single screen, I made the case that the underlying structure needed to change. I built it from research findings and support ticket data, then designed the group hierarchy model in Figma as a shared artefact. That file became the basis for three weeks of architecture alignment sessions.
It delayed visible design work. It was the most important decision on the project.
Four personas, two camps
The interviews gave me four distinct personas with conflicting needs.
Bank side: relationship managers and compliance officers. Client side: central KYC contact persons and legal representatives.
Same product, four different jobs.
Key choices that shaped the outcome
Split the experience by role, share the data underneath
The temptation was to find one unified flow. In practice that produces a compromise neither side wants.
Bank staff got a dense case management workspace with filters, bulk actions, and full case history. Corporate clients got a minimal, jargon-free submission portal with one choice per screen.
The "submit once, reuse everywhere" logic lived in the backend, so both sides benefited without seeing each other's complexity.
Modular components for a moving regulation
European KYC rules were evolving during the project: requirements valid in month one needed updating by month six.
I built document and form components to be swappable, so new types and rules could drop in without restructuring the flows around them.
Kept a direct line to the compliance team so changes reached me early.
Pivoted from single cases to group cases once research revealed the real pain
The original brief was to improve the UX of single-case onboarding, including single cases that happened to be part of groups.
Research changed the project.
Interviews made one thing undeniable: the process for corporate groups was where the real suffering was happening. For bank staff, it meant opening dozens of disconnected cases. For clients, it meant submitting the same documents over and over, once per subsidiary.
The problem was bigger than anyone had framed it. And it wasn't something a cleaner single-case flow would solve.
I went back to stakeholders with the research, made the case, and we re-scoped the project around the group experience. Single cases still benefited. They shared the new data layer and components, but the center of gravity moved to groups.
How we built it
The platform is built on four pillars. Each one solves a specific piece of the friction we saw in research.
Pillar 1: Unified dashboard
Group cases and single cases, one view.
Status badges use a consistent vocabulary. Green for Compliant. Amber for In Preparation. Blue for Client Ready to Edit. Red for Overdue.
Filter and search work across everything. No more opening cases one at a time to figure out what needs attention.
Pillar 2: Group case detail
All subsidiaries on one screen, as a card grid. Each card is scannable at a glance.
Below the grid, a Required Documents Overview table gives the document-by-document breakdown: name, legal entity, source (Central vs Local), involved banks, form rules, status.
Bank staff can move from high-level group view to specific document action without leaving the screen.
Pillar 3: Central document repository
Documents that apply to the whole group are stored once, linked to every entity that needs them.
Each document page shows the type, compliance requirements (Duly Signed, Apostilled, Notarised), which bank units need it, and its status per bank.
This was the clearest win from the data model change. Without that change, the repository couldn't exist.
Pillar 4: Client flow and signing
Corporate clients got a guided experience, one task per screen.
Questionnaire, document upload, and signing are split into focused moments. No jargon. No choice overload. Clear requirements and feedback at every step.
Activity log and audit trail
Before, compliance officers couldn't see case history. I designed a timestamped activity log alongside the case view: questionnaire progress, document signing, every status change.
For bank staff, I added an Activities screen with outstanding tasks grouped by type, plus a side panel showing upcoming enrolments and renewal schedules.
Measurable outcomes
40%
Reduction in duplicate document submissions (measured against the old system for a five-entity case)
30%
Faster onboarding in task-based usability testing: biggest gain from the group hierarchy view
25%
Increase in process completion rates; fewer cases stalled mid-process
4.3 / 5
Bank-staff satisfaction in the post-launch survey (open responses: transparency, ownership, less back-and-forth)
The real impact on this project wasn't in the screens.
It was in convincing engineering and leadership to change the data model before any UI work started. The argument was built on research findings and ticket data, not on opinion. That's what unlocked everything after it.
I also learned to design for a moving target. Building components to be swappable cost some upfront effort and saved a structural rebuild six months in.
If I did it again, I'd involve compliance officers earlier. They're usually treated as a review step at the end. On this project, their actual workflows turned out to be some of the richest input I had, and I found that out later than I should have.
