KYC system - [0%]

Designing a Robust KYC System for Investigation, Trust, and Scale

Over my four years at Plumter, KYC evolved from a relatively simple review process into a much deeper investigation of businesses, people, relationships, and risk. This case study shows how the review experience evolved alongside that complexity.

Founding Product Designer
Plumter2022 to Present
TransactionVolume Supported
$3.7B+
CountriesSent to
60+
TransactionsProcessed
70,000+

TL;DR

The Challenge

As Plumter grew, KYC became more complex. New partner and regulatory requirements, misleading business information, sanctions risk, and deeper verification needs meant Compliance could no longer rely on a simple approval flow.

What I Did

I evolved KYC into a structured investigation system, introducing shared compliance checklists, conflict detection, inline verification, consolidated declinations, and a more scalable review workspace.

Impact

  • Built KYC infrastructure that supported Plumter as the platform scaled to $3.7B+ in total transaction volume, with $2.06B processed across 67,159 transactions in 2025.
  • Reduced reliance on senior Compliance knowledge by turning recurring review steps into a shared, enforceable checklist.
  • Made reviewer onboarding faster and more consistent, allowing new Compliance hires to get up to speed with far less guidance than before.
  • Improved investigation quality by surfacing relationships across businesses and bringing verification closer to the information being reviewed.
  • Reduced repeated correction cycles by allowing reviewers to consolidate multiple issues before communicating them to the business.
  • Created a foundation for AI assisted KYC review, using the same structured review process to support a parallel AI co reviewer workflow.

The problem

Plumter's early KYC review flow was built for a much simpler process, where new businesses submitted their information and documents, and Compliance reviewed them for approval. As Plumter grew, both the amount of information we needed and the depth of verification increased.

Several things were changing at once:

  • New payment partners required deeper business information before they were comfortable processing transactions.
  • Regulatory requirements in Nigeria expanded, introducing additional information and checks into onboarding.
  • Submitted information could not always be trusted at face value. We encountered businesses whose stated activities or details did not match what we could independently verify.
  • New risk patterns emerged through real payment failures. In some cases, partner rejected payments led us to investigate further and uncover sanctions risks involving business directors.

Checks such as deeper business verification and sanctions screening had not been part of Plumter's earliest KYC workflow. They became necessary as the product encountered more complex businesses, requirements and risk scenarios.

Plumter's early KYC review, before deeper verification and investigation became necessary.

Evolving the KYC review system

To support this growing complexity, I evolved the KYC review experience from a simple modal into a more structured, layered review system.

Instead of treating KYC as one large approval decision, I broke the submission into parts that reviewers could inspect, verify and act on individually while still understanding the business as a whole. Business details, documents, directors and shareholders all remained accessible alongside the tools needed to investigate them.

The system evolved to support:

  • Deeper document and business verification
  • Individual review of directors, shareholders and KYC items
  • Checks for conflicts and relationships across businesses
  • Verification actions within the review workflow
  • Multiple issues and follow ups within a single submission

This gave Compliance a more systematic way to move through increasingly complex submissions without losing the context needed to make a final decision.

KYC review evolved into a layered side panel, giving reviewers more room to inspect each part of a submission and open deeper context when needed.

Encoding compliance knowledge into the workflow

As KYC became more detailed, much of what reviewers needed to know still lived in documentation, conversations, and the experience of senior Compliance team members. Newer reviewers frequently relied on the Head of Compliance for guidance before approving businesses.

I introduced a shared KYC review checklist, turning those recurring checks into a structured part of the review workflow.

The checklist was designed to work as both a shared source of truth and an approval control:

  • Reviewers followed the same required checks before approving a business.
  • KYC could not be approved until every checklist item was completed.
  • Only authorised reviewers could update the checklist, allowing the process to evolve as requirements changed.
  • Updates applied to the whole team, reducing reliance on knowledge being passed from person to person.
The shared compliance checklist turned recurring KYC checks into a required part of the approval workflow.

What changed

Shortly after launch, a new Compliance reviewer replaced the team member responsible for most daily KYC reviews. Unlike the lengthy training and repeated guidance their predecessor required, they were able to follow the checklist and get up to speed with little additional support.

What previously depended on years of accumulated team knowledge had become a process the product could preserve and distribute.

We deliberately introduced the model in KYC first, where lower volume and slower review cycles made it less disruptive to test. Its success has since made the same approach something we want to extend into Payment Review.

Authorised reviewers could update the checklist as requirements changed, keeping the team aligned around a single shared review process.

Identifying cross business identity conflicts

Compliance started seeing cases where the same director appeared across multiple businesses. The problem was that reviewers could only catch this if they happened to remember seeing that person before. As the number of businesses grew, relying on memory was no longer realistic.

I introduced conflict detection to automatically surface potential matches during KYC review. Rather than matching on names alone, which could produce too many false positives, the system compared stronger personally identifiable information such as:

  • Government ID numbers
  • Email addresses
  • Phone numbers

When a match was found, reviewers could see which other businesses the person was connected to and investigate the relationship before making a decision.

Shared identity signals helped Compliance spot relationships across businesses without relying on reviewer memory.

Bringing verification into the review flow

Some KYC checks originally required reviewers to leave the review flow or use a separate page. That created unnecessary context switching because identity and document verification needed to happen while the reviewer still had the submitted information in view.

I redesigned these checks to happen inline within the KYC review experience. Reviewers could trigger checks such as BVN or identity verification directly beside the relevant information, inspect the result, and continue reviewing without losing their place.

Inline verification kept checks and review context together, reducing the need to leave the KYC workflow.

Reducing repeated KYC correction cycles

KYC submissions often had multiple issues across different parts of the review. A business might submit the wrong document, provide unclear ownership details, or have a director who required further clarification.

Previously, those issues could be handled one at a time, which meant a business might fix one problem, resubmit, and only then discover there was another issue to resolve.

I introduced declination logging, allowing reviewers to record issues as they found them without immediately sending each one back to the business.

Declination moved closer to the point of investigation, allowing reviewers to log issues against individual KYC items as they found them.

What changed

With issues now logged against individual KYC items, the main Decline action no longer needed to sit at the top of the review panel. I moved it into the Declination Log, where reviewers could review everything they had flagged before sending a single structured response. This separated identifying issues from communicating them, making feedback more complete and reducing repeated correction cycles.

Logged issues were collected in one place, where reviewers could review the full set before sending a single structured declination.

Evolving the review workspace

As KYC continued to grow, the side panel eventually reached its limits. Checklists, conflicts, verification, declinations, and other review tools were all competing for space around the same submission. I evolved the experience into a full review workspace, keeping the business information as the stable source of truth while giving deeper review tools their own space alongside it.

KYC evolved from a constrained side panel into a full review workspace, giving deeper review tools room to grow without losing the core business context.

Designing the AI review model

The new workspace also created room for the next layer we were exploring: AI assisted KYC review. Because the human review process was now much more structured, we had a clearer framework for what AI should look for and how its findings should be presented.

Our initial idea was more automated. AI would review submissions in the background so that when Compliance logged in, each KYC could already have a summary, risk signals, and score waiting for them.

Privacy changed that approach, and we decided against sending sensitive customer information to commercial models and instead explored self hosted open source models. This gave us greater control over customer data, but introduced slower inference and less capable models.

AI runs in parallel with the human review, allowing Compliance to continue investigating while the model prepares a second review in the background.

Parallel human and AI review

That constraint changed the interaction model, so instead of making reviewers wait, I designed the experience around parallel review. Compliance manually triggers the AI check, continues the human investigation while it runs, and returns once the result is ready to compare findings. The check is deliberately manual rather than automatic, helping us avoid unnecessary computational cost while the experience is still being validated.

Once complete, the AI review surfaces a structured summary, risk signals, and supporting checks for the reviewer to compare against their own findings.

Outcome

The biggest shift was moving KYC from checking what a business submitted to helping Compliance build confidence in whether the business, the people behind it, and the information they provided could be trusted.

Over four years, KYC evolved from a simple approval flow into a structured investigation system for understanding businesses, people, relationships, and risk.

The new experience gave Compliance a more consistent way to review submissions, surface hidden relationships, run verification checks in context, consolidate issues before declining, and work from a shared process rather than relying on individual memory.

One of the clearest signs that the system was working came from the compliance checklist. When a new reviewer joined after the previous day to day reviewer left, she was able to get up to speed with little additional guidance because the approval process was already encoded into the product. We are now extending that same model to additional reviewers and exploring how it can support Payment Review as well.

The KYC system also became the foundation for our next phase of review tooling, including AI assisted investigation built around the same structured process while keeping human reviewers responsible for the final decision.