KalPay

The situation

KalPay runs BNPL and device financing under regulatory supervision. Every approval passed through a manual queue, whatever the risk of the application, so throughput was capped by the number of reviewers.

The review criteria existed, but they lived in the reviewers rather than in a written policy. Nothing could be automated, audited or scaled until they were written down.

The constraint we found

The question was whether the reviewers applied their criteria consistently enough to write down. The diagnostic established that they did. The work was specified tightly enough to encode, and the queue was holding back decisions that did not need a person.

Had the criteria varied from reviewer to reviewer, automating them would have scaled the inconsistency. Because they held, the build could start from a policy rather than from a guess.

What we considered and set aside

What was built

1. 01

   Lending console

   Returns most decisions without a person in the queue.

2. 02

   Written referral criteria

   The reviewers' judgment recorded as policy and applied the same way every time.

3. 03

   Manual review by exception

   A reviewer sees only the cases the policy refers to them.

4. 04

   Document verification in the flow

   Verification positioned as a gate rather than a step an agent could reorder, so an application cannot advance in an ambiguous state.

5. 05

   Admin and risk tooling

   Configuration, thresholds and audit trail in one place, so a policy change is a setting rather than a retraining exercise.

What made the difference

Testing the criteria before automating them. Encoding a consistent policy lifted the limit that headcount had placed on throughput. Encoding an inconsistent one would only have automated the inconsistency.