Context
The repeat rejection reasons could be caught before verification
KYB approval was falling while submission volume was also weakening. I did not want to improve approval by adding another mandatory step that made the flow harder to finish.
I started with rejection data and quick interviews with several merchants who had been rejected. The three most common problems were mismatches between business information and the storefront photo, product photo, or business name.
Some cases came from guidance that was missed or misunderstood. Others genuinely needed checking because the uploaded image or business name did not clearly represent the business being registered.
The goal was to catch likely mismatches earlier without letting AI decide whether a merchant should be approved or rejected.
Outcome
Targeted mismatches fell without a visible submission tradeoff
These numbers come from the period after launch and are treated as production evidence rather than a controlled experiment.
Evidence
The early evidence pointed to a specific class of problems
I used these three views to decide what should be checked, where the check belonged in the flow, and how model findings should become product logic.
Approval was already moving in the wrong direction
The decline mattered more because submission volume was weakening during the same period.
Intervention
Better guidance helped, but it still could not inspect a submission
The interviews showed that guidance needed work. The rejection data also showed cases where the actual submission needed to be checked before it was sent.
Guidance improvement
Make the existing guide easier to find
Useful when a merchant does not know what a valid photo should look like. The guide still cannot tell whether the uploaded image matches the business being registered.
Lower effort, but limited coverage.AI-assisted pre-check
Check likely mismatches while the merchant can still fix them
Use the business information and photos already available in Step 1 to show a warning before the application reaches verification.
AstraPay already had Llama available through Vertex AI, which made this a more practical option to ship quickly.Try the pre-check flowSystem behavior
AI sits before submission, not at the final decision
This flow separates the responsibilities of the merchant, product layer, Vertex AI, and verification.
MerchantProvides the input and decides whether a finding needs correction.
KYB productControls when the pre-check runs and how findings are presented.
Vertex AIChecks the mismatch conditions defined for the pre-check.
VerificationKeeps ownership of the final KYB decision.
Input
Enter business information and upload photosBusiness name, category, storefront photo, and product photo already exist in the KYB flow.
Product
Run the pre-checkThe product layer sends the relevant inputs before the merchant submits.
AI
Check targeted mismatchesThe model looks for likely inconsistencies across the business information and photos.
Rule
Map findings to product rulesTechnical output becomes stable conditions and merchant-facing feedback.
Decision
Is there a finding that needs review?A warning only appears when a defined condition needs the merchant's attention.
Choice
Fix the input or continueThe merchant can correct the flagged input or continue when they believe the submission is already right.
Submit
Submit KYBThe application enters the normal verification process.
Human review
Review and make the final decisionThe AI pre-check does not replace verification.
Flow connections
- merchant-input to product-precheck
- product-precheck to ai-check
- ai-check to product-map
- product-map to finding-decision
- finding-decision to merchant-review, warning
- finding-decision to product-submit, no warning
- merchant-review to product-submit, fix or continue
- product-submit to verification-final
AI only provides a finding before submission. Verification still decides whether the merchant is approved or rejected.
Decision logic
The model can stay specific while the merchant message stays simple
The same photo problem can be described in several ways by the model. The product needs one stable instruction that a merchant can act on.
Model finding
Keep the detail for product logic
The model might describe a dark image, an interior-only photo, an unclear storefront, or a storefront that is not visible.
This detail is useful for mapping, evaluation, and debugging.Merchant message
Show one clear correction
Those findings can map to one instruction asking the merchant to adjust the storefront photo according to the guide.
The merchant only needs to know what to fix.Interactive prototype
Try the AI-assisted pre-check
The warning is assistive. A merchant can fix the flagged input or continue when they believe the submission is already correct.
TRY THE FLOW01 / 06
Use the existing KYB inputsBusiness informationBusiness name, category, storefront photo, and product photo are already available in this step.
Product guardrails
AI was deliberately kept as an assistive layer
The first release kept the decision boundary clear while the quality of the findings still needed monitoring.
Prompt and output
Prompt design became a contract between the model and the product
I worked with the developer on the prompt, condition definitions, and output structure. The response needed to be predictable enough for the product layer to map it to the right message and next action.
Prompt detail only helped when it improved a decision the product could use. Output that was too open-ended made the mapping harder to maintain and made incorrect findings harder to evaluate.
The model produces a finding. The product still decides how that finding changes the merchant experience.
Reading the result
The strongest evidence sits in the rejection reasons the pre-check directly targeted
After launch, the three targeted mismatch remarks fell by 22–90%. Approval also improved by around 7%, while submission volume remained relatively stable.
The movement in targeted remarks is closest to the mechanism of the pre-check because those are the conditions it directly inspects. I treat the approval improvement as directional post-launch evidence rather than causal proof from a controlled experiment.
The strongest link is with the targeted rejection reasons, not a claim that the entire approval improvement came from the AI pre-check.
Next iteration
I would expand the model's role only after measuring its errors more closely
The next step is a stronger evaluation set that makes false positives and false negatives visible for each condition. That gives the team a better basis for comparing models and deciding which warnings are reliable enough to become firmer.
For more specialized visual checks, I would also compare the LLM with computer vision or a hybrid approach. Not every image problem needs to be handled by one model.