2024 was an eventful year. I joined Simpl in early 2022 and so I have seen nearly 3 full years at Simpl. Every year is unique, but 2024 was certainly the most eventful year in all these 3 years. If we execute right 2025 and beyond, we might look back at 2024 as the pivotal year in Simpl's journey.
Let's have a look back at 2024, and in fact, let's look at the evolution of Simpl as I view it. We will first talk about metrics, looking at how they evolved in 2024 and also how they have evolved over the years. Then will talk about significant engineering and DS outputs in 2024. We will also reflect on some miscellaneous matters towards the end.
Let's see how PL TPV (Just PL, not Pi3) has evolved over the years.
The summary that I take from the above chart is - During 2021 and 2022 there was good growth. During 2023 there was moderate growth, and 2024 is largely flat.
To have a reasonable comparison, let's compare yearly TPVs.
| Year | PL TPV | YoY Growth |
|---|---|---|
| 2016 | 4.93 crore | - |
| 2017 | 29.81 crore | 505% |
| 2018 | 160.38 crore | 438% |
| 2019 | 269.41 crore | 68% |
| 2020 | 290.95 crore | 8% |
| 2021 | 1,094.64 crore | 276% |
| 2022 | 3,734.54 crore | 241% |
| 2023 | 5,481.79 crore | 47% |
| 2024 | 6,801.10 crore | 24% |
So, 2024 is the weakest year barring 2020 - covid year. But hey, despite all the upheavals, it is still at 24% year on year growth.
Next, let's consider the Pi3 TPV over the years.
Note that for the PL graph, the y axis was in crores, while for Pi3, it is lakhs.
Here is the short story of Pi3. It was launched in June 2021. I think some US/Europe based PL providers were doing variants of Pi3 so we guessed it is probably a good idea. There is a 99 page tech spec by Shreyas. It grew steadily till early 2023 to around 40 lakh TPV a day. By then, management decided to double down on Tachyon - and that Pi3 will be bundled with Tachyon. Development of core Pi3 got deprioritised - it was one of the features with Tachyon. So, Pi3 contracted and had a stable TPV around 25L a day. In May 2024 Tachyon was gone and Pi3 was back again as a product. We built SIKA by Sep/Oct 2024 and Pi3 TPV has been growing rapidly since then.
Here is a commentary on the number in the above chart.
On the repeat side, till late 2022, there were no filters - repeat users were never denied transactions, nor were they ever blocked. RU delinquency was coming down by itself. Note that RU delinq has a tendency to come down over time if hold incoming NU rate constant then more tenured users constitute an ever larger fraction of TPV, bringing RU delinq down.
From Jan 2022 to Sep 2022, delinquency increased steadily from 5% to 6% and Russ declared that something needs to be done urgently. Then within a period of a few weeks 100K+ repeat users were blocked. From that point we continuously worked on systematically reducing repeat delinquency. We are currently at lowest ever repeat delinquency.
During the first half of the year, half the team was working on Tachyon. Magento integration, shopify new integration, couponing module, resolving order issues, RTO module, early settlements, EMI are some of the significant projects from that era that I can recall. A lot of hard work by a lot of people. Thank you all.
This was the most all encompassing project that we have accomplished. Instead of two due dates in a month, due dates will be distributed all over the month, enabling lowered borrowing requirements for Simpl. All the teams were involved in the project. Congratulations to everyone for excellent team work. We accomplished this project within the promised timeline with one main hiccup - around 70L lost due to late application of late fines.
We implemented Simpl Select - which is the premium membership of users. It is open to the best of our users. They pay a monthly membership fee which unlocks a host of benefits - free billbox access, priority support and in coming times - 30 day billing cycle and maybe more. As of now there are 60K select users giving us INR 35L monthly membership fee. Plan is to expand select to more users in coming months and expand the benefits.
Once Pi3 was unbundled from Tachyon we decided to build SIKA so that merchants don't have to do separate integrations for PL and Pi3. We delivered SIKA. While merchant facing APIs were fixed, first we implemented only Pi3 for SIKA so as to unlock merchants. Towards the end of the year we delivered PL on SIKA. We also write a SIKA adapter for razorpay.
OTM is a feature from NPCI, supported by banks. When a user sets up an OTM for Rs X,then Rs X are blocked in user's account for some entity. The entity can pull the money when it wants. OTM has been used in IPO subscribing usecase. That usecase for Simpl IPO is several years in the future, but for now we used it in a different way. A user who has been blocked can unblock themselves by setting up OTM. This allows us to earn effectively riskless TPV from these users. Similarly during onboarding an otherwise unapproved user can get a credit line from us if they are willing to set up OTM.
Lately we have faced the problems with canceling of OTMs - the bank APIs for OTM cancellation don't work properly. So, if for some reason a user reaches out to us to get their OTM cancelled and we are with that (because they don't have pending Simpl bill), then we are not able to honor that, and that is a problem. Due to that we have currently disabled OTM except for OTM renewals for existing OTM users.
So far we have got a total of ~9.7cr of TPV from OTM lines
Linking establishes that, at the time of a transaction, the user indeed is the owner of the relvant phone number on whom transaction is being done. Currently we have two dominant methods of linking. The first is OTP. On the linking page, user enters the OTP sent via SMS and thus establishes that he is indeed the owner of the phone number. The second linking method is inapp swipe (or mswipe), where the user swipes on Simpl app. Since user is logged in to the app from a certain phone number, use again establishes that he is the owner of the phone number. Third way of linking is turbo linking - where we set a cookie in user's browser at the time of repayment (and store it in our database) and read this cookie at the linking time. If link time cookie matches with the cookie stored in the database for that phone number it establishes user credentials.
Good thing about turbo linking is that it is simultaneously less friction full (since user does not need to enter OTP or swipe), as well as more secure. Unfortunately, for the merchants who want to use it need to have some android app packages (chrome custom tab) so it does not work out of the box. This is currently live on redbus only.
We integrated Karix for SMS and email and Telspiel for SMS.
Our margins are very sensitive to delinquency and as we focused on unit economics and profitability, there was renewed vigor on reducing delinquency.
Users can set up spend limits lower than their credit limit to help them in budgeting.
This feature leads to lower TPV but decreases delinquency and is explainable.
So far, for users who are soft blocked, eligibility response was negative, now we return the response as "linking needed", and when the users want to link, we prod them to pay the bill.
Worked with zomato to have a checksum in linking call to avoid the different devices using same phone number without linking and enabling ATOs.
We developed the pipeline to analyse SMS data to derive relevant information from SMS. We called it PACE - payback capacity estimation.
DTM was moved from CRM team to DE team but there were some dependencies on CRM components that continued. They were removed this year.
We migrated flink pipelines from standalone clusters to EKS, which helps in reliability as well as reducing cost.
We improved the model inferencing system significantly whose details Somil has covered in this blog article. Notably we moved from gunicorn to tensorflow/serving which in which we can tasks can share model code and event loop is able to serve requests concurrently.
At the beginning of 2024 our goal was to deprecate redshift in 2024. Due to priority change in May we could not focus on this goal much. Still a lot of workloads moved from redshift to databricks - analytics reports, risk reports, approval model, credit upgrade - all run on databricks now.
Our ability to track costs at a granular level has been developed and that has led us to recognize offending workloads quickly.
Bill generation was migrated to UEP, resulting in vastly reduced bill generation times. We could also thus change cycle cut off time fromm 9:30 PM to 12 midnight.
We worked to solve login related problems. Earlier, on any login error a generic message was shown in the UI. Now, we show specific error why login failed - SMS auto read problem vs down time on vendor side vs 2 device login limit etc. This has helped reduce support tickets due to login problems.
Mobile team has worked to systematically resolve various app crashes. We have started tracking number of crashes
and have worked to eliminate app crashes. Following graph illustrates the progress we have made over time.
Once we start measuring something we can work to optimise that.
Modularized AFS system so that it is easy to extend it. AFS team needs to write complicated multi step filters to catch complicated patterns and needs to intervene at several places - pre linking, post linking, eligibility and charge call. Good architecture here enables to create powerful filters to counter MO (modus operandi of the fraudsters). In particular, we introduced "Actions" in fraud filters and orchestrator.
We also did several performance enhancments - moved fraud filters from flask to fastapi (AsyncPython), eliminated multiple dynamo calls and did some innovative work to reduce kafka lags.
We used to have some NU delinquency and RU delinquency goals - quarter over quarter we tried to improve on these goals. Overall burn was not being tracked. Then, in May, this natural progression was changed, and we started having portfolio delinquency level goals to meet which we constricted NU levels to around 1000 users a day. Soon after that the concept of "payback period" has been operationalised. We want to take in new users only to the level that their payback period is small enough (we aim for 9 months).
Early this year we started working on batch v6 approval model. It was initially called SACred Model - something like "Sequence of Approval Call" (not sure what "red" expanded to) - but the name never caught on outside the DS team. Underwriting team has been less successful in generating flashy names for their projects. Finally, sinces previous model was batch v5, they called it batch v6. It started rolling out 2nd half of this year and by December the rollout has been complete.
In general - PD (probability of default) generated by approval models has proven to be good initial measure of the goodness of users. It is good to take a minute back and see how approval models have evolved.
| Model | Time launched | Description |
|---|---|---|
| v1 | Prehistory | Assigned MCLs. Main features were number of merchants, device model & manufacturers, time of activity. PD generated for user, merchant pair. |
| v2 (challenger model / RF model) | 2020 | Assigned MCLs. PD generated for a user. Focused on merchant attributes - ticket size etc, rather than merchant itself, to reduce data sparsity. Focus was to increase approval rates. |
| v3 | 2021 perhaps | Similar to v2, but assigned GCLs. |
| RF v4 | 2022 | Better sessioning of approval calls, reducing delinquency. |
| Batch v5 | 2023 | Moved away from top 72 merchant paradigm. Better imputation of null data. Focus on device change. Focus on reducing delinquency, keeping approval rate constant. AUC = 0.58 |
| Batch v6 | 2024 | First deep learning model for approvals. Increases approval rate with decreased delinquency. AUC = 0.63 |
As Pi3 becomes a growth vehicle for the company, we have understanding how to orient our risk measures to make them suitable for Pi3. As a starter, some users (UNT, ANT as well as repeat), are being assigned some MCLs beyond the (potentially 0) GCL that they have. Since MDR of Pi3 is usually higher and delinquency is lower (due to users pay 1/3 amount upfront), we can take larger risk on the users.
| v1 - Early 2023 | Handled 2-8 cycle users |
| v2 - Aug 2023 | There was core selmore and 2 more models - 1 for 2-15 cycle users and another for 16+ cycle users. SSC score was used in conjunction with selmore score. Better features. |
| v3 - May 2024 | Early detection, optimal binning, better merchant embedding, migration to databricks |
| v4 - Oct 2024 | Stacked LSTM, includes DPD90 as target, faster training. |
| Nov 2024 - LTV aware blocking | Blocking threshold for high LTV users is higher. |
| v1 model - May 2023 | 10% traffic given to the collection model. Model called riskiest users first and so the early collection was poorer. Main features - call connects, weighted max delay, credit util |
| Later 2023 | Model rollout increased to 100% gradually |
| v2 model - Nov 2023 | More features around txn and delay. 6bps impact on DPD90 |
| v3 model - Oct 2024 | Features around block status. 3bps impact on DPD30 |
Other projects in collection area:
This is a new area that we started this year. It has two major components
2024 was a good year for controlling fraud - there were no major flareups of 2nd party and 3rd party frauds. This is as opposed to 2023 when there were two major fraud episodes - in March and then in December. Over time we have built several weapons in our fraud controlling arsenal and we were able to deploy relevant filters fast whenever fraud happened to increase. We have several ideas in the pipeline too.
Here is a bit of history for everybody. For the longest time, from 2018 to 2023, we tackled only first party fraud. We had filters based on requests coming from the same IP, or address in charge call being suspicious. At this time, AFS (anti fraud service) was integrated with rest of the system in two ways:
Sometime during 2023, AFS started getting called on eligibility call too. This was a major milestone since latency requirements on eligibility calls are much more strict than in charge calls. Then, AFS started getting called pre linking and post linking also. All through 2024, AFS team has made creative use of all these calls to counter the modus operandi of fraudsters.
On the product front, several innovations have taken place over the past 2+ years. This year, we continued to improve "mswipe", and several filters which are derivatives of mswipe. Mswipe has proven to be a very important way to control fraud - 2FA means we have a way to better authenticate the user and thus we don't need to block the user.
For 2nd/3rd party frauds, note that big fraud has not recurred after Dec 2023.
1st party fraud has vanished since May, when we went very tight on new user approvals.
I see anti fraud as an iterative game - we and the fraudsters. Fraudsters find out an MO (modus operandi) of committing fraud. That then is a challenge to us. We then try to counter their MO such that collateral damage is minimal. Clearly we cannot stop all transactions - so we have to find a pattern which mostly catches fraudsters. This, then, is a challenge to fraudsters. We challenge them to find out what pattern we are using to isolate them - it is on them to better impersonate a genuine user. Given them sufficient time and they get back to us and throw a new challenge at us.
Our objective is to raise the cost of committing fraud to high enough levels that they go away.
Project Canopus was a bright spot in H2 execution. So far we have recovered we have recovered 32cr+ at investment of around 4cr. When the project began, here is what various people estimated about how much money could be recovered.
Many of the learnings from this project have been incorporated in regular collections. Gopal gave a talk on this topic.
Starting May, we started on a significant effort on cost optimisation.
Here is how costs have been trending over past several months
| Mar'24 | Apr'24 | May'24 | June'24 | July'24 | Aug'24 | Sep'24 | Oct'24 | Nov'24 | |
|---|---|---|---|---|---|---|---|---|---|
| Total (INR, crore) | 5.65 | 4.65 | 3.88 | 3.19 | 2.94 | 2.24 | 2.15 | 2.18 | 2.08 |
| Category | Mar | Apr | May | June | July | Aug | Sep | Oct |
|---|---|---|---|---|---|---|---|---|
| AWS | 247.11 | 231.63 | 193.80 | 162.81 | 137.86 | 109.14 | 104.25 | 111.60 |
| COMM | 119.95 | 60.74 | 44.72 | 44.19 | 55.27 | 18.32 | 34.55 | 34.45 |
| ORG | 37.83 | 34.28 | 29.70 | 28.22 | 27.19 | 23.76 | 19.95 | 17.75 |
| GROWTH | 18.60 | 18.22 | 20.42 | 20.42 | 15.25 | 15.25 | 15.25 | 15.25 |
| DATABRICKS | 8.95 | 8.95 | 19.48 | 25.24 | 23.15 | 27.28 | 11.69 | 11.69 |
| RISK | 87.33 | 72.48 | 47.78 | 11.80 | 11.63 | 11.00 | 10.74 | 10.79 |
| SUPPORT | 10.77 | 8.23 | 7.15 | 7.00 | 6.44 | 6.99 | 6.50 | 6.79 |
| TECH-DEV | 18.73 | 16.58 | 16.36 | 13.57 | 11.18 | 10.22 | 9.83 | 7.99 |
| TECH-MISC | 15.51 | 15.71 | 11.24 | 6.41 | 6.21 | 2.64 | 2.69 | 2.89 |
| TOTAL | 564.78 | 466.83 | 390.65 | 319.65 | 294.18 | 224.61 | 215.45 | 219.20 |