Weekly Updates

Summary

1. Batch v6.2 ramp has been increased to 30%.
2. Collect IQ version 2 for collection is live for some fraction of users.
3. AARR follow up from TS is done. AARR rolled out to a few more filters.
4. MNRL based rules in rule engine are live
5. Yellow chat message data now available for analytics. Congratulate Nikhil U for his first major project.
6. Digio version upgrade is live

Batch v6.2 ramp has been increased to 30%

Batch v6.2 is the successor model of batch v6.1. Quick notes

1. v6 was the first deep learning model for approvals
2. v6.1 corrected the training methodology
3. v6.2 incorporated approval age as a parameter in training

Collect IQ developments

Two changes have gone live last week

Firstly, so far calling started on D8. Now, calling starts on D6.

Secondly, so far digital communication for collection (SMS, push, email, whatsapp, IVR, flash) was rule driven. Now we have made it model driven. And we are now live with this for 30% of the users in the DPD21-30 journey.

This is a deep RL model. This is the first time we are using a deep RL model at Simpl.

AARR followup from TS is done

Quick recap - AARR (accrued amount payment required) - is a new concept we have introduced as a replacement to blocking. For a long time we had filters that block the users - blocked users can no longer transact with us. Then, beginning early 2025, many of the filters were put on "unblock on repayment" i.e. if the user repaid us back, then this was a signal enough that we should unblock the user. (Note that for some filters, even repayment is not a strong enough signal). Building on this functionality, we have now built AARR which has following functionality. When AARR is enabled then the user cannot do a transaction with Simpl. However, once they repay back their existing bill then they will be able to transact again. Now, we don't call these users as blocked - rather we say that they have AARR enabled.

Ok, so what's the big deal? Both with earlier "unblock on repayment" setup and current AARR enable and disable, user needs to repay the bill for their approval call to succeed. Differences are two fold. Firstly, on most merchants, user can repay the bill on the merchant app itself - their eligibility does not fail - they are taken to the repayment page. Secondly, since they are not blocked - nowhere in App, CRM etc will there be a mention that they are blocked. This will avoid confusion - that comes from seeing the number of blocks some which are unblock on repayments.

Coming to the work done this week, earlier AARR worked only with linked users. An AARR enabled user, could go through repayment on merchant page only if they were linked. Now, if they were not linked, then they are asked to link, and once linked, they are taken to repayment page. This was Chirag's last go-live project. We appreciate the efforts that he did even in the last week of his employment at Simpl (for now - he will come back after some quarters!) After this - a total of 4 filters are now using AARR.

Manish and others in T&S team have pointed that there still two user experience to be resolved. Both our app homepage and repayment page say that bill is due by so and so date. So, there is incoherence - if bill is not due currently then why is Simpl asking for it right now?

MNRL based rules in rule engine

Rule engine runs in real time and allocates PCL to users. Approval age based on MNRL data is now available to rule engine, and we have implemented rules that incorporate this.

After incorporation of the rules, the latency of rule engine increased. The team worked to bring it down quickly. I believe there is a lot of scope to do bring the rule engine latency drastically down (avg 40-50ms to like 20-30ms).

Yellow messenger data is now available in databricks

Following are the relevant tables:

Congrats to Nikhil Unavekar for his first project completion!

Digio version upgrade is live

Once we were done with android 35 last week, we have now upgrade digio version in our android app. This will help reduce digio related crashes and reduce support tickets.

Ensemble based approval model did not yield results

We (Vivek Bhardwaj specifically) spent around 2 weeks trying to have ensemble model - an ensemble of tree based batch v5 and DL based batch v6 - outperform our current approval model. We did not succeed. I still feel there has to be opportunity here. We look at this again once we have tried transformers for approval model.

Repeat Pi3 delinquency is not a concern

In the last week's update, I reported that Repeat PI3 delinquency has risen significantly in last few months, and now it is above PL repeat delinquency. It was an incorrect observation. Thanks Harsha for looking into it. Repeat Pi3 delinq has indeed increased in last few months, but not significantly, and it remains below PL repeat delinquency.

Here are the revised DPD30 repeat numbers.

So, Pi3 repeat delinq is better than PL repeat delinq.

Login related improvements

Some login related improvements went live, but I did not spend time understand exactly what was done. Connect with Melron for details. Here is the relevant doc. Login success rates are on the upward path - perhaps hitting all time best on August 12. Thanks to all those who work on this and looking forward for more progress here.

How credit limits work

Harsha wrote a doc on how credit limits works. Read it here.

Svelte migration

Svelte migration has been very much delayed due to various reasons. Raksha says it will go live Aug 18.

Increased costs due to increased number of approval calls

Krishna estimates that we are paying around $100 per day across all our systems. With time it will increase as the cost seeps into our training and inferencing pipelines.

Increase is all explained by juspay calling us multiple times for zepto. They call us twice for PL and twice for Pi3. Once when user is early in checkout journey and other later. Himanshu had some idea for optimisation. He will talk to juspay.

SELECT SUBSTR(bucket_id, 6) AS date, 

COUNT(CASE WHEN merchant_name = 'Zepto.' THEN 1 END) AS zepto,
COUNT(CASE WHEN merchant_name = 'Swiggy' THEN 1 END) AS swiggy,
COUNT(CASE WHEN merchant_name = 'Meesho' THEN 1 END) AS meesho,
COUNT(CASE WHEN merchant_name = 'Zomato' THEN 1 END) AS zomato,
COUNT(CASE WHEN merchant_name = 'blinkit' THEN 1 END) AS blinkit,
COUNT(CASE WHEN merchant_name = 'Apollo Pharmacy' THEN 1 END) AS apollo_pharmacy,
COUNT(CASE WHEN merchant_name = 'Astrotalk' THEN 1 END) AS astrotalk,
COUNT(CASE WHEN merchant_name = 'bigbasket' THEN 1 END) AS bigbasket,
COUNT(CASE WHEN merchant_name NOT IN ('Zepto.', 'Swiggy', 'Meesho', 'Zomato', 'blinkit', 'Apollo Pharmacy', 'Astrotalk', 'bigbasket') THEN 1 END) AS others

FROM public.user_approval_events 
WHERE event_name IN (
    'ZeroClickTransactionEligibilityFailedEvent',
    'UserApprovedEvent',
    'UserApprovalFailedEvent',
    'ZeroClickTransactionEligibilitySuccessEvent')
AND bucket_id >= 'date_2025_06_01'
GROUP BY 1
ORDER BY 1

Vijay and Chirag's last day

Last Thursday was Vijay and Chirag's last day at Simpl. They had contributed immensely to Simpl's technology. We wish them all the best.