Not just screens. System, behavior, and outcomes
AstraPay

Designing a KYB Fast Track for 15,000 Merchants

An AstraPay partnership brought a roughly 15K SRC merchant cohort into KYB while the same Operations team, about three reviewers, continued handling BAU. The CMO asked Ops and Product to smooth the onboarding path. Instead of rebuilding KYB, I proposed a bounded fast-track model that reused referral-code infrastructure, moved clear cases to one-page single-pass review, and routed exceptions to deeper review. We validated the path on a whitelisted SRC sample, trained reviewers, then rolled it out over roughly 3–5 months.

Role: Product DesignerKYBMerchant OnboardingOperations DesignInternal ToolsRisk & Fraud
Context

15K SRC merchants landed on an Ops team that still had BAU to run

The project came from an AstraPay partnership. The CMO asked Operations and Product to smooth the SRC onboarding path because roughly 15K merchants needed to move through KYB without stopping BAU work.

The Operations team handling the workload was only about three reviewers. The existing UI had four review steps. A verifier checked merchant data and documents, then an approver reviewed the case again before the final decision.

With a rollout of roughly 3–5 months, the problem was no longer how quickly one screen could be clicked. I needed to remove repeated work from clear cases without opening a faster route to merchants who were not eligible.

At this volume, click speed was not the main problem. Every clear case was paying for the same review depth.
Capacity problem

SRC alone created a large target workload before BAU was counted

The rollout numbers show the scale the same team needed to absorb. The daily figure below is a capacity model, not measured throughput.

15Ktarget cohortSRC merchants in the partnership program
3–5 morollout windowrough duration of the program rollout
~3Ops reviewersthe same team continued handling BAU KYB
~45–80/daymodeled required capacitySRC only, if 15K is spread evenly across 3–5 months at about 22 workdays per month
Design decision

I moved control from every case to eligibility and exceptions

I proposed reusing the referral code, one-page review, Instant Approve, the exception queue, and removing the second approver for eligible clear cases. We worked through each change with Product, Ops, Tech, and the control functions to make sure it was feasible.

Standard KYB

Four UI steps, then verifier and approver

Every merchant moved through sequential review. Even after verification, a clear case still continued to a second approver.

Reasonable for general traffic, expensive when partnership volume arrives on top of BAU.
Fast-track cohort

One review for clear cases, deeper review for exceptions

Merchants from the validated cohort entered a one-page review. Clear cases could finish with Instant Approve. Cases with issues moved to secondary review.

The same data and documents were still checked. What changed was when a second review was actually needed.
Routing model

The fast track started with eligibility, not with the Approve button

SRC merchants had already been screened by the aggregator. Inside AstraPay, the existing referral code and backend validation were reused so only the approved cohort entered the fast-track queue.

Entry
KYB submitted

The merchant sends data and documents through the same core KYB.

Eligibility gate
Valid SRC referral code?

Backend validation ties the submission to the approved, pre-screened aggregator cohort.

Default
Standard KYB

Merchants outside the cohort keep the verifier and approver flow.

Eligible
Fast-track queue

Eligible submissions enter the dedicated review path.

Operations
One-page first review

Core data and documents are scanned on one continuous page.

Decision
Data and documents clear?

The reviewer separates clear cases from exceptions.

Clear case
Instant Approve

An eligible clear case finishes without a second approver.

Exception
Secondary review

Cases with issues still receive deeper review.

Resolution
Remarks and corrective action

Operations records the right reason or corrective action before the next decision.

Flow connections

  • submitted to eligible
  • eligible to standard, No
  • eligible to fastqueue, Yes
  • fastqueue to firstreview
  • firstreview to clear
  • clear to approve, Clear
  • clear to secondary, Issue
  • secondary to resolution

Merchants outside the cohort stayed on standard KYB with verifier and approver. Fast track was not a manual option available to everyone.

Review interface

The UI became simpler after the control model changed

These three artifacts show the changes reviewers actually felt. The existing flow gives the baseline, one-page review removes navigation, and Instant Approve closes a clear case in the first pass.

Clear cases still moved through several stages

Reviewers moved across steps and cases that were already clear still continued to the second approver.

Original KYB flow with multiple review stages
The starting point before fast track.
Validation and control

Removing the second approver only made sense because the cohort and fallback were bounded

SRC merchants had already been screened by the aggregator before entering the program. AstraPay then bounded the fast track again through the existing referral code validated by the backend. Regular merchants could not opt themselves into the faster path.

The control-model change was reviewed together with Operations, Fraud, Risk, and Compliance. The goal was not to remove review. It was to avoid repeating the same second review for clear cases from a known source while keeping a deeper path for exceptions.

Before wider rollout, we whitelisted a sample of SRC merchants to test the fast-track path against the operational SLA. Reviewers were also trained on the one-page review, Instant Approve, and exception handling before the cohort expanded.

The faster path was never open to everyone. Speed depended on a known source, validated eligibility, and a fallback when a case needed deeper inspection.
Rollout

The fast track supported the ~15K program without turning core KYB into a rebuild

The rollout ran for roughly 3–5 months while the same Operations team continued handling BAU KYB. I only use outcomes I can still verify from the project record, so I do not attach an approval-rate or fraud-rate uplift to this case.

15Ktarget SRC cohortthe partnership scope the KYB operation needed to absorb
3–5 morolloutwider rollout after sample whitelisting and reviewer training
1 passeligible clear caseno second approver after the first review
No rebuildcore KYBthe change stayed in existing routing, review UI, and operational workflow
What I took forward

The reusable idea was not Instant Approve. It was moving control to the right place.

Instant Approve was the most visible change, but the leverage came from cohort gating and exception routing. We did not make all KYB looser. We made review depth follow the risk context.

If mass onboarding becomes recurring work, I would not keep extending referral codes. I would productize eligibility, sampling, audit trails, review time, exception rate, and rework monitoring so the trade-off between throughput and control can be measured.

A healthy fast track is not just fewer steps. It knows who can move quickly and when a case needs deeper review.