PL Delinquency
PL NU delinq
Table below shows D20 NU delinquency for PL monthwise.
PL TPV and DAU have been roughly constant for past few months while Pi3 TPV and DAU have been increasing.
We increased NU user intake significantly in March - using lines which call D30/D75 lines (also sometimes called "Vivek lines"). These lines have higehr delinquency as well as higher retention. So far, their combined R / S (revenue by spend) has been worse than other lines (i.e. delinquency has outweighed retention). However, (a) We believe retention effect will come into play later (b) We have used approval age and MNRL data to improve delinquency of these lines. We believe NU delinquency will go down in coming months.
There is a sharp uptick in the month of May (though for June things are better till D18). We need a bit of deepdive to debug this increase.
Since D30 numbers are like 7%, we are doing well in Pi3 NU delinquency.
RU delinq in Pi3 is lower than PL delinq in equivalent time, so we are doing fine here.
This is the new exciting feature that has got launched this week. Let's take some time to understand this.
We have filters which block some users, and we know that our blocking has lot of false positives. Many of the blocked users have an amount pending with us and they pay that amount back. One of the areas we have worked on in early 2025 is to determine that for many filters, a repayment of pending is a strong enough signal that we should not have blocked the user to begin with. For some filters though, we have determined that even repayment is not a strong enough signal to unblock the user.
Once we determined that some users deserve getting unblocked on repayment, we started to do that systematically.
But then we realized - if we know we are going to unblock them on repayment, should we block them to begin with? We decided that we will not block such users. Rather on their eligibility call, we send the response as "payment required" - i.e. we tell the user - you are not blocked - you just need to clear your dues now and then continue using Simpl. Now we have implemented this. AFS can return a "AARR" response and if that response is returned then TS sends "repayment needed" or "linking needed" response to the merchant (depending on merchant configuration).
Following are some of the benefits of this construct.
Sometime in June, UPPCL - Uttar Pradesh Power Corporation Limited - changed the names of their billers. There were some 5 billers catering to different regions of UP and they all were merged to one biller. As a result our autopay billbox electricity bill transactions started failing. Users could not transactions manually either.
We have now fixed the problem. It needed an app change - to show the new biller, also a DB change to migrate existing billers to the new biller. We have lost some 1-2 cr of TPV because of the problem. I believe that in future for such outages we should fix them at war level. This time around though we decide to prioritise pay list than fixing this problem.
When we fetch SMS, we first filter out personal messages. So far we relied on the fact that transactional messages, the headers are of the form "JM-HDFCBK". However, lately the SMS headers were changed to be of the form "JM-HDFCBK-S". This led our app to reject transactional messages. Now we have fixed this bug. Also, by moving this filtering from app proper code to JS, we have ensured that were a similar problem to happen in the future it won't required an app rollout.
We were slow to recognize this problem. However, once recgonized we fixed in next 1-2 days, working over the weekend. Thanks to all those who worked on this.
Zepto Pi3 is giving us around 18L of TPV per day.
Does not seem to impact 1.3 cr daily PL TPV -
Two weeks ago we went live with GoKwik. So, now all the merchants using GoKwik can start using Simpl PL or Pi3 with the click of a button. We have so far onboarded 120 cr monthly GMV worth of merchants.
We are getting like 3 lakh TPV every day from gokwik merchants. These merchants are expected to scale rapidly. They indeed seem to be growing at least in number, lately:
Saravanan fixed two improvement to iOS - first was the bitcode removal (which was causing hiccups in integration) and second is to add simulator support to SDK
Autopay rollout has been increased from 5% to 20%. No problems have been encountered
Someone in devops worked to reduce our cloudwatch costs - I remember by realizing that some alarms can be availed in free tier rather than paid tier. That's neat 100 dollars a day. Whoever you are - pls drop me a slack message!
Awesome progress for the week. Let's keep firing!