Context
15,000 merchants turned a normal review flow into a capacity problem
AstraPay partnered with an aggregator managing an SRC retail network. Roughly 15,000 merchants needed KYB before activating QRIS, Indonesia’s standardized QR payment system, and using QR soundboxes.
The existing flow used four review steps. A verifier checked merchant information and documents, then an approver reviewed the decision again before final approval.
With about three Operations reviewers and a 2–3-month onboarding target, small repeated actions became a capacity problem. I focused on which work truly needed to happen for every merchant and which work should only happen when a case had an issue.
The problem was not making reviewers click faster. It was removing work that did not need to happen on every merchant.
Workload
Scale made repeated work the main problem
These four constraints shaped what I kept in the review and what I moved out of the happy path.
Artifact explorer
Inspect the artifacts behind the fast track
The existing flow, delivery constraint, review layout, and Instant Approve show what I preserved and what I changed.
Review still moved through several stages
Reviewers navigated across steps and clear cases still continued to an approver.
Routing model
The fast track only existed for an eligible cohort
The speed came from routing. A validated referral code determined whether a merchant entered the fast-track queue. Clear cases could finish in one review, while issues moved to secondary review.
Entry
KYB submittedThe merchant sends the same core data and documents.
Gate
Valid referral code and eligible cohort?Backend validation checks the merchant source before fast-track routing.
Default
Standard KYBMerchants outside the cohort keep the verifier and approver flow.
Eligible
Fast-track queueEligible aggregator merchants enter the dedicated review path.
Ops
Single-page first reviewOperations scans merchant data and documents on one continuous page.
Decision
Data and documents clear?The reviewer separates clear cases from exceptions.
Clear case
Instant ApproveA clear case finishes without a second approver.
Exception
Secondary reviewCases with issues are isolated for deeper inspection.
Resolution
Remarks and corrective actionOperations records the right reason before reject or send-back handling.
Flow connections
- kyb-submitted to eligibility-gate
- eligibility-gate to standard-kyb, No
- eligibility-gate to fast-track-queue, Yes
- fast-track-queue to single-page-review
- single-page-review to clear-case
- clear-case to instant-approve, Clear
- clear-case to secondary-review, Issue
- secondary-review to remarks-action
This diagram summarizes the routing and review logic for the aggregator cohort. Merchants outside the cohort remain in standard KYB.
Review flow
The biggest saving came from repeated review work
The information being checked stayed largely the same. I changed how reviewers reached it and when a second review was actually needed.
Existing flow
Four steps and two review layers
Operations moved through several sections in sequence. After verification, a clear case still continued to an approver.
Reasonable at normal volume, expensive when repeated thousands of times.Fast track
One page for a clear case
The required information was available on one page. An eligible clear case could finish after the first review.
A second review remained available when the case actually needed more attention.Eligibility
The referral code became a gate, not a manual shortcut
The existing KYB form already used a referral code to identify merchant acquisition sources. Because the timeline did not support a major database change, I reused that field as the entry point for fast-track eligibility.
Operations issued a dedicated code to the aggregator, and the backend validated it before routing merchants into the fast-track queue. Regular merchants could not simply opt into the faster path through the form.
This kept the technical change small while creating a clear boundary. Access to the code also had to stay controlled because the fast track depended on a known merchant source.
Who can enter the fast track is part of the design. Without a trustworthy gate, removing the second review only moves risk upstream.
Review decision
Clear cases and exceptions stopped competing for the same attention
The first pass was optimized for throughput. Work that required more reasoning was separated so reviewers could return to it with the right context.
Clear case
One pass, then Instant Approve
The reviewer scans merchant data and documents on one page. If everything is valid, the case finishes without a second approver.
Reject and Instant Approve were visually separated to reduce accidental clicks during repetitive review.Exception
Issues move to secondary review
A problematic case is not immediately finalized as rejected. It enters a secondary list where Operations can inspect the issue and write the right rejection reason or corrective action.
Detailed remarks no longer slow the first pass for clear cases.Risk and fraud
Removing one review layer was only defensible because the cohort was bounded
Instant Approve meant that a clear case no longer passed through a second approver. That removed one manual control, so the decision could not be justified by efficiency alone.
I worked with Fraud to review document risks, misuse of the fast-track route, and fallback handling. Access remained limited to merchants with a validated referral code, while cases with issues still received deeper secondary review.
No fraud or material documentation issues were reported for this cohort during rollout. I treat that as an operational observation, not proof that the same model is automatically safe for every merchant or aggregator.
The control model changed from ‘review every case twice’ to ‘gate the cohort, then investigate exceptions deeply.’
Outcome
Roughly 15,000 merchants were processed inside the planned window
Routing and review changes were enough for this cohort without a major rebuild of core KYB.
After rollout
If this pattern repeats, the fast track should become a capability
This solution was deliberately built for one aggregator and one delivery window. Reusing a referral code was sensible under those constraints, but it is not the right foundation if high-volume onboarding becomes recurring work.
The next step should be a dedicated bulk-KYB capability with explicit eligibility management, review queues, risk rules, sampling, audit trails, and operational monitoring.
I would also measure median review time, exception rate, and rework rate by cohort. That would make future decisions about single-pass review and additional controls evidence-based rather than assumption-based.
A one-off fast track solves delivery pressure. Repeated use should become a product capability that can be measured and audited.