← All work

Case study 01 · Regulated onboarding

A scalable KYC module for a TRCSL-regulated telco

It started with 32,417 rejected orders in the Retail Hub Sales App, the app our sales agents use to connect new customers. It grew into a KYC module for every digital channel, self-service and assisted.

Phase 1 · Proposed, not shipped Phase 2 · In progress
My role
Analysis and design, both phases
Timeline
Oct 2023 – now
Scope
Retail sales spp → all digital channels
Regulator
TRCSL, Sri Lanka

01 · Where it started

What the rejection data said

67% of rejections were capture or data-entry problems, not fraud.

32,417 rejected orders, Aug–Oct 2023, all from the Sales App. Add expired documents and 76% were avoidable.

Share of all rejections, by reason group
Reason groupShareAug → Sep → Oct
Image unreadable
37%
34 → 37 → 41 ↑
ID number mismatch
30%
28 → 33 → 31
Fraud or tampering
21%
26 → 19 → 17 ↓
Expired or underage document
9%
9 → 10 → 8
Wrong or incomplete document
3%
4 → 2 → 4
Capture or data entry (67%) Also avoidable (+9% = 76%) Not a design problem

The trend that mattered

34% → 41%

Unreadable images were getting worse every month, while fraud fell from 26% to 17%.

Top individual reasons

ID number mismatch30%
NIC not clear24%
Driving licence not clear7%
Invalid ID image6%

The three image reasons (24 + 7 + 6) make up the whole “Image unreadable” group.

02

Auditing the flow against the data

Most rejections were avoidable, so I went back through the Sales App’s KYC flow looking for the design flaws behind each reason.

Rejection reasonDesign flaw I foundChange I proposed
Image unreadable 37%The image capture wizard relied on the agent’s judgement for focus and lighting when photographing documents.Auto capture, with on-screen guides that help the agent get alignment, focus and lighting right.
ID number mismatch 30%Agents typed the ID number by hand. Any local ID that passed format validation was accepted, and passports had no format check at all, leaving room for human error and fraud.Read the ID number from the captured document instead of having the agent type it.
Expired or underage 9%No check on the customer’s age or the document’s expiry date before submission.Check age and expiry from the scanned ID before the order can be submitted.

03

Phase 1: fixing the Sales App

Proposed, not shipped
  • Auto capture with guides. On-screen guides help the agent get alignment, focus and lighting right, so image quality no longer depends on judgement alone.
  • ID number read from the document. The number comes from the captured ID, not the agent’s typing, which leaves far less room for human error and fraud.
  • Age and expiry checked upfront. Both are read from the scanned ID and checked before submission, so an expired or underage document is caught on the spot, not after rejection.
[SCREENSHOT: Before]
Before: [CAPTION]
[SCREENSHOT: After]
After: [CAPTION]

Figma · Before and after

See the real Sales App screens, before and after the redesign

Capture guides, ID read from the document, and upfront age and expiry checks.

Open in Figma

04

The shift: KYC becomes a standard

The process team in our division set out to standardise KYC across every digital channel that reaches customers. I joined those discussions and presented the Sales App findings as evidence of where the process was failing.

SELF-SERVICE

Channels customers use on their own. [e.g. MyDialog, web]

ASSISTED

Channels where an agent helps. Retail Hub Sales App, [OTHERS]

What the standard had to do

  1. 01

    An understandable journey

    Customers and agents know what is needed and why.

  2. 02

    Higher verification success

    Fewer applications rejected after submission.

  3. 03

    Regulatory alignment

    Every channel meets TRCSL rules the same way.

  4. 04

    Flexible per product

    Different criteria without a new form each time.

05

Phase 2: one module for every channel

In progress

I’m the designer of the module. The aim was a structure flexible enough for each product’s rules and simple enough to scale to every channel.

A

Common KYC levels as dynamic sections and subsections. Identity, address and billing proof are shared, so every channel asks them the same way.

B

Unique requirements appended per product. A product adds its own section after the core instead of forking the form.

C

The layout renders sections and fields from config. A new product is configuration, not a new screen.

SHARED CORE

Identity · NIC or licence
Address
Billing proof · if address differs

PER PRODUCT

[PRODUCT A] fields
[PRODUCT B] fields
Fintech · extended KYC

OUTPUT

One rendered form

In every self-service and assisted channel

The modular structure: a shared core, plus what each product adds.

Options I rejected

[REJECTED OPTION 1]

Why not: [REASON]

[REJECTED OPTION 2]

Why not: [REASON]

Plain language in extended KYC

Fintech products needed extra questions written in finance jargon. I rewrote each in plain words and kept the compliance meaning.

BEFORE

[ORIGINAL JARGON 1]

AFTER

[PLAIN REWRITE 1]

BEFORE

[ORIGINAL JARGON 2]

AFTER

[PLAIN REWRITE 2]
[SCREENSHOT: Self-service]
The module in a self-service channel.
[SCREENSHOT: Assisted]
The same module in an assisted channel, with a product section added.

06

Result

Phase 1 · Proposed, not shipped
  • Fixes proposed for the three causes behind 76% of rejections
  • Deprioritised before launch, a business decision outside my control
  • The findings went on to shape the company-wide KYC standard
Phase 2 · In progress
  • Findings fed the company-wide KYC standard
  • Module designed for all self-service and assisted channels
  • Design proposed. The next step is standardising the underlying systems so every channel can use it. Plus extending to fintech.

For Homey

Why this matters at Homey

UK conveyancing has the same shape of problem. Firms must verify ID and address before a sale can progress, and a mismatch means asking for more proof. That is the billing-proof rule here.

The approach transfers: start from the rejection data, fix capture where it fails, then build one verification core that every channel shares.

Next · Case study 02

Retailer loan: rewriting a bank’s language for the shop counter

← Back to home ↑ Back to top