 Welcome to today's session of digital lending watchtower at Casper's consumer we are organizing a series of events focusing on digital lending and as part of that in today's session we will look at the release of a citizen's report on the Baruch financial technical glitch which led to consensless loan provisioning. The summary of the issue was in November 2011 the whistleblower report accused Baruch financial inclusion limited and microfinance subsidiary of Indus in bank of evergreening loans to subvert the NPA numbers. The bank responded to it admitting to having issued 84,000 loans without consent of consumers and cited a technical glitch which prevented OTP consent to be bypassed and it also said that the said glitch was rectified in two days. It appointed an external auditor to verify the velocity of claim of the whistleblower. This is a draft of a citizen's report on the same issue investigating into the matter from publicly available artificial catch to document the case and present the findings. We also make a series of recommendation to various stakeholders to handle such situations in future and predict consumers from systemic failures. A brief overview of what is a consent scam so as the digitization journey of India has progressed in a very rapid manner the same has also enabled consumer harms in an increasing pace. While the killer use case of Chandran Nathar mobile was to enhance credit to underserved population and be an enabler for financial inclusion. There has also been consumer harms in the area of digital credit arising out of various practices of digital financial service providers and these get overshadowed and reported until the issue blows up big. And even within the harms of digital financial services there are a variety of harms and most often data privacy, data leaks, credit profiling, algorithmic scoring get extra attention and get widely discussed whereas harms out of consent design in systems do not get sufficient attention. We kind of define consent scams as those where consumers of financial services get shortchanged to lack of proper consent mechanisms in the processes adopted by digital financial service providers either willfully or due to technical glitches. India has been witnessing a series of these consent scams by various digital financial providers where consent of the individual has been like violated both either in letter or in spirit. Some of the examples are the Airtel payments bank subsidy diversion fraud where bank accounts were opened without the knowledge of the person. There are other examples of dumping a loan for attending free sample coaching classes in a coaching institute and being asked to share an OTP where the OTP was actually a loan for joining the course even though the student was completely unaware of the fact that they are signing up for a loan. And a similar practice also transcended online with few ed techs making the same practice where they provide tablets with course content and then essentially dump a loan with leaving the users having no choice but to pay the loan. And this aggressive marketing practices followed by an intake firm by use was also highlighted in parliament although it was happening for quite some time now. The latest to join this list of consent scam is Bharat Financial Inclusion as I mentioned admitted to having dispersed 84,000 loans in May 2021 without proper customer consent. And an interesting fact to note here is Bharat Financial also happens to be the first microfinance player to have completely digitized operations through other based authentication and provide a digital credit service as early as 2017. And Bharat Financial Service was that's why SKS Microfinance Limited which also has a history in the microfinance crisis in India which happened early 20 things. So the objective of this report essentially is to kind of bring the wireless of these consent scams and to note that there has been very little regulatory action around this issue and often there's not even an acknowledgement of this issue. And in this particular case specifically that media reports suggest that the Reserve Bank of India, the regulator monitoring the microfinance industry was aware of the issue as early as September 2021 full two months before the whistleblower report came out. There hasn't been any official statement from the Banking Regulator on the matter. And even in cases where the acknowledgement of the consent scam happens like the case of Airtel Piemons Bank subsidy scam where one provider was penalized and people got their money back. But there was no systemic analysis that was conducted on why that issue happened and the payment system operator which ran the Aadhaar payment bridge was not penalized and there was no remedying the system design problem of the Aadhaar mapper diverting the subsidy to the last linked bank account of the Aadhaar number. And what that made is the subsidy diversions are still happening to people who are without recourse and running to post trying to get their subsidy. So the objective of this report is essentially to kind of document this entire technical glitch and see what are the systemic design issues that have led to this particular consent scam and put the facts in public domain using a poison analysis of publicly available information and documents and make recommendations to various stakeholders surrounding issues of consent design particularly in the context of digital lending. So first we look into the facts that got reported under the Bharat financial inclusion technical glitch. The chronology of events as reported by the whistleblower claim article in the economic times is below. So on 15th of September the non-executive chairman of BFIL Mr. MR Rao he sends a resignation letter to the board of Anderson Bank raising issues that RBI has been made aware of 80,000 loans being given in May 2021. And there was the same article also notes that subsequently an outside whistleblower wrote to the RBI on October 14th and followed by two letters by internal whistleblowers who are senior employees of the same firm which were sent to independent actors and RBI officials all citing the same issue of evergreening and procedural lapses in governance of extending loan contracts and accounting practices. So it was evident that the RBI was actually aware of this issue as early as like September 15th but there was no public statement or notification to not necessarily the public but at least those who have been impacted by this particular glitch and even as of now RBI has not released a statement in this regard. The Anderson Bank on the next day of the whistleblower article gave a clarification and said that the allegations are grossly inaccurate in business and dismissed the governance and evergreening issues and said that it gave additional loan to longer tenure for people who are stressed by COVID to repay their debts only after they cleared their existing areas and with their view consent. And it also said that all loans are following a weekly BPMN model and the defaults are getting automatically recorded on the system and in such case the possibility of evergreening is invisible and having said that it contradicted itself in the subsequent statement where it actually made an admission of having dispersed 84,000 loans without customer consent getting recorded at the time of disbursement and this they said was due to a technical glitch and it was highlighted by feed staff within two days and was rectified expeditiously. It still doesn't say how long this issue existed. What we know is that sometime in May 2021 84,000 loans were disbursed owing to a glitch which lasted for at least more than two days and then came out and said that of the 84,000 only 26,073 clients were active with a loan outstanding of 34 crores and that was just 0.12% of its overall loan portfolio. And in a subsequent interaction with analyst Hemindra Khasari the Anderson Bank clarified that the loan dispersal systems are into and digital and without panel intervention and because of an upgrade that happened the biometric verification if it fails an OTP is sent to customer mobile which is then treated for consent. However on 21st May on account of a bug in the system the OTP stage also got bypassed which essentially meant that loans were dispersed without any consent and when they clarified this there was no mention from the bank as to what it did to those 84,000 people and how it handled the auto-consentant loan and what was the fix that was done and what were like the reasons where consumers even informed of this matter in the first place and in the absence of such information one is supposed to presume that almost everyone impacted by the glitch actually paid the price of having a loan that got auto-renewed without consent and having to pay more. And on 3rd of December they appointed an external auditor from Deloitte to review divisive blower allegations. There was also a good amount of corporate politics and how this impacted the stock markets. The stock fell 10% after the day of divisive blower report came out which led to a loss of $1.3 billion in shareholder value and the timing of this whistleblower report was also very curious was that it happened two days after another rival microfinance institutions, Bandaranspur P announced hiring of hiring the top management executives of Barak Financial and the Barak Financial executives later in November actually filed their resignation letters and the innocent bank made a regulatory notification that their resignations are being considered. These coupled with the fact that the resignation of MRLow in September 15th and RDA's knowledge of this matter prior to that itself indicates that a lot of people knew of this issue but just came out because of some corporate politics at play besides the actual issue of consentless loan provisioning. So on the scope of investigation our methodology was to gather as much evidence as possible that's available in public domain and analyze and reconstruct the events that led to this glitch and then try and see if we can arrive at some conclusions on what exactly happened. Since we don't have access to any private information that's sensitive or access to servers, we cannot conclude anything completely as we don't have such material evidences and those are available only to people who have access to the infrastructure. The external auditors obviously would have that access. So we've listed down our data sources on what all will be considered for analysis and specifically we did technical analysis using MOB SF which is a security testing framework for mobile applications and we performed static analysis of all the apps that were available for that were used by the agents to kind of see and gather some insight. So on the way we went about this investigation was to kind of start with identifying the app which the agents used and this was done by searching Barrett Financial Inclusion and developer on kudos and OSINT application mobile application repository which hosts application binaries of millions of Android applications. So we then got the name of the app and the package ID. So beefing some perk was the name of the app that was used by agents with the package ID com dot beefill dot member status and when we searched the same app on Google Play Store we got an auto suggest with multiple versions being listed in the auto suggest and when we further kind of filled in the search text we got a list of versions of these apps that were at least once available in the Play Store and were searched by many many people because this the auto suggest on the Google Play Store comes up when a large number of people search for the same text and these are supposedly what the agents have searched and Barrett Financial by the way has roughly around 20,000 agents who service the microfinance clients that they have. So a list of versions of these apps were available in Play Store but the Google Play itself did not have this app. This app was probably removed soon after the incident or at a later date and it's no longer publicly available but we were able to source the app binaries from kudos and we were also able to verify that these had Barrett Financial's app signing certificate so the authenticity of the APK files can be recently ascertained to be original and they have been archived for our analysis and these are the checks and one thing that we noted down was when each of these versions of these apps got uploaded on to kudos and these are apps were also targeted against specific instances so three of these apps were targeted against the user acceptance test environment so these are probably test files that the developers and the testing team of the Barrett Financial were using to test the app and then there were three other protection build of these apps which were also available and another stat that we looked at was the other authentication slash EKYC statistics so UIDI publishes daily stats of authentication and EKYC on its dashboard in addition to like overall ecosystem level statistics they also publish specific individual entities number of authentications performed and number of EKYC's performed along with various authentication factors like fingerprint diaries and so on so other dashboard stats was is an archival tool that runs daily and archival copy of published statistics so we wrote a script to filter down the data of all the authentication data of innocent bank in the month of May 2021 when the incident supposedly happened there are a few interesting data points here but we could not like kind of include and I'll come to the analysis part of this data in a bit there was also publicly available documents of COVID passes of agents of who were employed with Barrett Financial for them to commute during the lockdown situations and this indicated like there were 19,300 agents in all who were servicing activities across the country in April 2020 and though we don't have any other further data but for an internal investigation a map and a time graph of all the 84,000 consensus loans could give a geographic example spread of these loans and they could kind of hint if there were specific concentrations in one region or any set of agents to kind of allude to the fact that it was a coordinated mall practice or indeed a glitch in which case the data would kind of be random and since we don't have access to information this particular information we just note this down as a corroborate the data point which the auditors who will have access can add to their report to add confidence to their finding finding it one way or the other that it's a glitch or it's a coordinated mall practice and these were the data sources so we had like apps from Kudus other authentication stats the Google Play search suggestions and the Barrett Financial agent database and the findings were largely focused around first trying to locate the version of the app and the date of incident so the analysts called with Hemindra Hazali noted that the glitch happened on 21st May 2021 and incidentally the one protection build of the app with version 1.3.8 was uploaded to Kudus on May 15th and there is also presence of search terms 1.37, 1.39 in Google Play auto suggests and both these kind of give us a lead to kind of look into 1.38 and 1.41 in analyzing what these apps are and the other authentication and the KYC statistics although we've got the data for the entire month data is unreliable for a few reasons and one of it is the unreliability of the other dashboard as many days in the data point both including in May 21 the incident have zero authentication transactions and this gets kind of tricky with the same day having zero authentic authentication transactions but showing few thousand EKYC transactions and it's a fact that EKYC cannot happen without an authentication so there is a generic problem of trusting the data in the dashboard that is there while it might be largely correct that we probably don't know the process in which the data gets updated and hence can't click treat that as a full data and the other thing in itself is that the innocent bad mission which said that if the biometric authentication failed then the OTP was used and in this case given that OTP got bypassed because of the glitch and analysis of the app kind of reveals that the OTP that is mentioned here is not actually like the other OTP it is the OTP of the Barrett Financial app itself and further for renewal of loans there was no fresh EKYC that was being performed and these are because they are existing customers of Barrett Financial the other reason is the UIDA numbers for Barrett Innocent Bank is not specific for Barrett Financial but it's also could be used by other services in the bank so but having said these there are like sharp dips on several days and we still don't know when the incident exactly happened we have an analyst called Transdirt which is happened on 21st May but we don't know how long it lasted and there are several days in the data where EKYC numbers have shown but have dipped severely and coupled with the fact that those same days had zero authentication transaction and this is a cost of concern there needs to be some clarity on this data anomaly and lastly we came to the technical analysis of the Android app in itself so what we first learned was that Sahaita loan was a special type of loan that was offered to get additional credit after offsetting the past use for the previous loan and if there was a consent bypass technically the agents can auto mark these without even the presence of the person because there would not be an OTP sent and there would also not be an OTP verification in the process so the process of issuing fresh loans to accounts that have outstanding use can kind of be done without the knowledge of the account holder so this is the basic premise of Sahaita loan and when we saw the list of apps version 1.2.8 was the first version to have Sahaita loan being referred and these are typically zero disbursement loans where there is no disbursement meant for the borrower it's always that the past use are offset and a new loan is sanctioned and new loan is basically paid back to the same bank for the past loans so in such scenarios we've also seen that Sahaita loans often come with only OTP based consent and biometric consent is needed only if there was an actual disbursement so only the amount of the Sahaita loan exceeds the past loans and there was to be a fresh disbursement made only then the biometric consent kind of caught kicked in otherwise it's an OTP consent and unlike other authenticated biometric consent where transaction is recorded on the UIDA side the OTP consent is against an OTP server run by Park Financial that sends a 4-digit OTP so this is not the same as other OTP and we also analyzed the various versions of the app and they had something called as a dynamic URL service which basically when the app is opened communicates to this particular server and gets various URLs that the app needs to communicate to and one can see that in these particular two versions of 138 and 141 there was a change in the backend server that the app was referring to and we don't know if this was causing the glitch or if this was a fix for the glitch that happened because we don't know on the day when the incident happened which version was used both the app version as well as the backend service version and since we don't have access to the backend code we cannot kind of ascertain if the change was actually due to a bug because suddenly the versions change from 1.51 to 1.25 usually versions don't reduce people upgrade not downgrade so we don't know if this was due to if this was actually a fix or if this was a malpractice that was done and which actually led to the issue and we don't know because we don't have access to that backend code but another point to note is that there was not major differences between 138 and 141 particularly those codes relating to OTP handling and hence mostly if something was fixed it was probably fixed in the server side and not on the app side and what we also did was the app on all the versions did not have a chance where you could skip entering an OTP so if OTP validation bypass happened it happened in a scenario where an OTP prompt was prompted but there was no OTP sent and the agent could kind of key in any number and and then that would kind of allow the OTP to validate basically without sending an OTP it kind of does validation on whatever the value that the agent keys in and this kind of gives in room for the malpractice training but again we cannot ascertain this because we don't have data on the backend code so the the other interesting point is that the apps also indicate that there was a development process and apps were specifically marked as UIT and production which meant that there was a there was a process in place where anything that moves to protection before it moves to protection undergoes user acceptance testing and if this is true then it raises the serious concerns on how such a basic key feature was not tested in the user acceptance test phase particularly when an upgrade happens and how this was kind of like caught only in the production after these 84,000 loans were actually issued. There are some limitations to our analysis and these are like depending on the data so so the kudos was helpful in kind of narrowing down the app name and having multiple versions of app but again we cannot conclude anything because we do not have all the versions of the apps we only have six versions of the app with us and we don't know on which on the day when the incident happened which was the version that was in line use. Then the other dashboard data as I mentioned that though we have UIDA authentication activity for a month we can't kind of conclude because firstly the UIDA mode of authentication was not used for this Sahayata kind of loans where it was just an OTP consent that was local and then the Play Store Search Solution data was again showing different versions that was helpful but again inclusive on which version because we don't know which version was used on the specific day. On MobSF technical analysis we did kind of inspect the reverse binaries to understand the execution flow. We understand that there is no special logic to kind of bypass OTP on at least on the client side which means that even when a glitch had happened it was basically that any random OTP got validated as an OTP which meant that the agent could kind of perform transactions even without the user because there was no OTP sent in first place and any number would have been accepted as an OTP. But this doesn't say whether it was a willful issue or a technical bug which led to this situation. And the agent data again though could give geographical spread of the agents and possibly the 84,000 loans we can't kind of conclude anything and can only be used for adding additional corroboration. So in summary that we had listed all the available evidence that was there in the public domain and noted down specific areas of investigation. But the citizen report will wait for the external auditors to actually file the official report and we'll kind of be scrutinizing what that report says and how it says so but the evidence, the methodology that it produces. So while the evidence that we have in public domain currently is insufficient to arrive at an end conclusion, the entire episode has thrown up an important oversight issue in relation to customer consent and digital lending. Transparency notice are key expectations from the regulator. So when this whole episode got flagged to regulator as early as September 2021, the expectation is that the regulators would inform the impacted consumers and make provisions for them. And we need this transparency in the audit reports as well to strengthen consumer protection and trust. So we list down a set of recommendations for various agencies. So one is first for the RBI to publish standard operating procedures when it receives these kind of technical glitches or concerns which directly impact specific consumers. So in this case, as high as 84,000 consumers were impacted. So there has to be a specific process through which the regulator actually communicates at least with those who have been impacted, if not the general public, regulatory silence affects consumers trust. Extending the publication of application checksum referred in the digital payment security controls directions for payment apps to all banking apps and lending apps that are used by consumers as well as agents. So what this would allow is to let us kind of see which versions of apps were actually in use on a specific day and so on, which would kind of really help in collaborating any such investigations. Make the external audit report publicly available. We hope that the Deloitte report will be made publicly available with extensive detail on the evidence and methodology that they have used to arrive at whatever the assertions that they may expect, whether it's a technical glitch or it was a willful malpractice. And another recommendation to the UIDI is to publish detailed correct UIDI authentication in the EKYC data, which is which is actually a high frequency indicator of the activity that's happening around particularly agar-based consent for the biometrics and a portee in a machine readable format. So we could kind of use this as a high frequency indicator to detect anomalies in consent practices. In a larger sense, analyze the OTP abuse scenario, particularly with respect to customer consent in cases such as digital lending and revisit the role of OTP in consent itself. And last but not least, for investigations that are linked to ADAR, since UIDI logs are retained only for six months as per the Supreme Court judgment and only in AUA retains the logs for longer duration. And in case of banks, since the banks of themselves, the UIS attempts to kind of proving any other related malpractices harder as time passes by. So this is a recommendation for UIDI to kind of fast back any such investigation as soon as it comes to know of them. And I've listed references for this report and put out some credits. Shout out to Anish for making the artwork for the digital lending watchtower and Nemo for providing some critical infrastructure to source control the reverse code and making it available easier to analyze the difference between various versions of these ads. And I'll be making this repository also available publicly after sanitizing that for any secrets that are there. And digital lending watchtower is a place to keep track of digital lending space in India and have ongoing conversations about digital lending primarily from the lens of consumer protection. We've had a consumer protection panel last month. We released this report and I must say that this is a draft report that we have released and we'll wait for the audit, external audit report if it's being made publicly available. We'll also try and reach out to a few more people to see if they had some thoughts on this and then we'll release a final report and send a copy of these to regulators as well as the government. Having said that, I have come to the last page of the report and thanks for watching and if you have any questions please type it on the YouTube chat. Thank you and share the link to the report. If there are no questions, thanks for joining in and we'll see you next month on another session of digital lending watchtower project. Please preview drop by telegram channel p.me staffs, classes consumers for conversations or check out our other videos. Thank you.