FRSLABS

Fraud Risk and Security (#KYC) – Knowledge Series #33 - DigiLocker integration made simple with Atlas Dashboard. DigiLocker is a service provided by the Indian Government, allowing issuing authorities to directly issue identity documents such as Aadhaar, PAN, Driving License, and Registration Certificates into a Users DigiLocker account. As a business, you can use DigiLocker to accept and verify documents provided through DigiLocker, a safe and secure way to verify and authenticate original documents. This will cut down on synthetic and identity fraud and have an irrefutable proof of government approved and government backed KYC. If you begin the integration, you will soon find that it is not that straightforward. There are a lot of steps (APIs), not least the signing up as a partner with DigiLocker. We have made the integration so simple enough that you can go from start to finish in about 5 minutes without having to go through a complex onboarding process. You can integrate DigiLocker into your web or mobile app via a single API or SDK. Or skip code completely using our no‑code Atlas dashboard. Simply log into Atlas Dashboard, design a simple Aadhaar Flow using our flow builder, test with free credits, then go live using the same dashboard or integrate a single API or SDK to go live. With millions of verifications each month, we scale with your needs. Here’s a step by step guide for DigiLocker integration: https://lnkd.in/gQ5wjFU5 #DigiLocker #DigitalKYC #Integration #Developers #Compliance #NoCode

The future of identity is never going to be the same again. No amount of smart technology is going to cut it against AI in the hands of bad actors. #identity #KYC #digitalindia #VKYC

Our time with #CISOs and #DPOs on the topic of DPDPA has increased exponentially (and it’s heartening to see their commitment, even if they remain hesitant to go all out in the absence of a clear Govt mandate). While much of our discussions revolves around managing #consents, #policies, #breaches etc, we feel they are misdirected or perhaps even misinformed on how to go about DPDPA. The first, the hardest, and perhaps the least understood step is discovery. While much is being covered under the umbrella of gap assessments, in our reading, we found them to be theory heavy, and often stop short of providing practical guidance (I wouldn’t blame the legal experts and consultants on this). The law does not say much about how discovery should be done, so most experts are blissfully unaware of how it is actually done, or worse still make an assumption that it has to be done in a certain way (despite never having done it themselves). However, without a sound discovery strategy, every other compliance effort risks becoming just academic. You will soon fall into the trap of holding on to a giant excel sheet to fill in. In my deep and sometimes difficult conversations with Fiduciaries, I have understood that DPOs feel that they have a fair idea of what systems they have and what data they collect. However, in reality, even a small POC reveals that data isn't always neatly labelled, it’s scattered across files, DMS, emails, databases, backups, images etc. Some are impossible to access (proprietary third-party tools deployed on-premises) and some they never knew they had or shared. Also, unlike a consent notice, discovery doesn't produce an immediate ‘sugar rush’ to readily appreciate the value of a tool. Discovery is a marathon and takes a while to establish secure connections, discuss the boundaries of scanning, configure custom patterns (other than what is available out of the box), lay down the infra for meeting the minimum throughputs needed for a comprehensive ‘full’ scan. And often full scans reveal gaps, mistakes, and security issues to be confronted head on. Yet, without this step being fully comprehended, organisations are flying blind. For instance, you cannot apply retention policies without knowing how data is linked across your systems. You cannot fulfil data principal’s rights if you cannot locate every system that hold them and process them. And you certainly cannot demonstrate compliance just by showing a giant excel sheet filled half-heartedly by system owners. It sounds zen, but when we deployed our Atlas Discovery tool over our own servers and endpoints to identify and categorise data, it blew away our prior beliefs of our own systems. We feel discovery is an amazing discipline in itself and the foundation upon which meaningful privacy, security, and compliance can be built. If you’re on your #DPDPA journey and wondering where to begin, you have now been informed. #DataPrivacy #Compliance #DataDiscovery #PrivacyMatters #Atlas

Introducing Unified KYC. Whether you are a large Bank or a small investment advisor, KYC and AML is fundamental to your growth. KYC must be done exactly the way regulators want it, and when regulations change, so do your workflows, disrupting every aspect of your business. Non-compliance is not an option. Regulations arrive from multiple regulators, at multiple times of the year, growing in scale and complexity each passing year. Buried in these regulations are voluminous details to interpret and implement, often at short timescales, to remain compliant. Keeping up with the regulations is a challenge, pushing you back from exciting new innovations to take your business forward. Therefore, you need a platform that adapts to new regulations, that remains flexible to build new flows, allow you to experiment with AB testing, that can provide a single and uniform onboarding experience across all your products and all your channels. This has been in the works for a while at the lab (from 2018 with Atlas 1.0) but relaunching again with our modern Atlas 3 (which is a beautifully designed dashboard with Identity Management and Privacy Management integrated into one). If you are interested, please do give me a shout and I would be more than happy to organise a demo and walkthrough of the platform and how you can instantly unify the entire KYC experience and save tons of development time, technical debt, and money across all of your products. #ATLAS #KYC #PRIVACY #DASHBAORD #BANKS #INSURANCE #TELCOS #NBFC 

What happens when the custodians of privacy themselves are not following the rules in letter and spirit? What hope do we have for data principals who continues to be overlooked, with nothing essentially changing behind the scenes except for a new disclaimer. Here’s the story. There was an announcement of a #privacy conference. The organisers' noble motive is to bring people together to talk about privacy and, in the process, perhaps ensure an equitable arrangement for themselves (perfectly fine). The real trouble I had when I went to sign up was the glaring lack of understanding of the #DPDPA law. So, lets dive in. 1)   Firstly, the consent cannot just be a disclaimer with vague details – for e.g. “... in accordance with our standard procedures”. This doesn’t mean much and goes against the grain of DPDPA that the consent must be presented and understood independently. 2)   The organisers then want your name, email, phone, LinkedIn, organisation name and designation. While name, company and email are essential to providing conference details, the phone number and LinkedIn seems excess (and they are all mandatory). Let’s dive into the privacy link and there are more surprises. 3)   The collection of information goes even further: name, phone, address, job title, industry, company, credit/debit card information and if you are a speaker, volunteer or a sponsor then more data. Just by looking at the list above, you can figure out excess data is being collected without attaching a valid purpose or legal basis to it. 4)   Hurrah! in one section, they do mention #PurposeLimitation and #DataMinimisation so that gives me some hope that the law has been read, albeit not put into practice. 5)   The use of personal information starts with “we may” which in itself lacks bite as they themselves are not sure how they are going to be processing my data. Most of the purposes seem alright to me as that’s what one would expect attending a conference – to be informed of logistics and any changes and comply with local bylaws. However, there was one about personalized event experience and recommendations which got my attention and no way to untick it (it is imposed). 6)   And then comes the shocker - #disclosure of personal information. It’s a free for all data sharing with very little control for me to change it. 7)   The #retention clause goes even further. Usually, the data is needed only up to the point of attending the conference and a fixed duration can be kept before deletion (or take consent to keep it longer). But this is what they have provided – “The retention period for different types of data is defined based on the applicable legal and business requirements”. 8)   Great that they have provided a contact to exercise my rights but misses crucial rights like #ROPA, #DPAR etc 9) Thankfully they had an Agree or Disagree button and I promptly clicked #Disagree. And for sure I am not going to be on their invite list 😊 Comments welcome.

The Ministry of Electronics and Information Technology (MeitY), through the NeGD, released a comprehensive Business Requirement Document (BRD) for a model Consent Management System Essentially it is a "Guideline for the development and deployment of a system" and not part of Rules or mandatory to be implemented at this stage. Though it does lay clear emphasis on the nature of consent as primarily laid down in DPDPA - Granular & Purpose Specific, Clear and Affirmative It outlines a full lifecycle—from collection to withdrawal—with built-in mechanisms for: - User dashboards - Cookie management - Notifications - Grievance redressal - Immutable logging - Meta Data - Data Retention, Consent Expiry - CMS User Role mechanism - Audit Trails The document does not cover the Right to Nominate as a Data Principal Right under DPDPA, which should also be looked to be incorporated in developing a Consent Management System. There are further questions which are left unanswered however as the industry starts implementing the regulation best practices shall emerge. It was an interesting discussion today covering practical challenges in the implementation of CMS across various sectors and whether Indian business are ready for implementation of DPDPA. Thanks to my co-panelists and participants for the interactive session and to Shankar P and Gaurav Mehta for sharing their views as platform service providers.

Fraud Risk and Security (#KYC) – Knowledge Series #32 RBI is certainly tightening the digital lending landscape to protect borrowers and ensure responsible innovation in the sector. RBI published the Reserve Bank of India (Digital Lending) Directions on 08 May 2025 which tackles key risks such as: misuse of data, excessive third-party involvement, mis-selling, high interest rates, and shady recovery tactics. The rules are applicable to all banks, NBFCs, co-op banks, and financial institutions doing digital lending on their own or in partnership with FinTechs. Most rules are live now. Platform-level rules (para 6 & 17) kick in later this year. There are some clauses specific to Explicit Consent, KYC norms, purpose limitation, and data storage which are highlighted here. KYC accountability stays with the Regulated Entities (RE). Loan Service Providers (LSP) may collect data, but REs are solely responsible for verification. (Note that this is implied from RBI’s KYC Master Directions, not explicitly stated in the 2025 Directions) KYC must follow RBI’s 2016 Master Directions (updated most recently in May 2025) – including Aadhaar Offline, V-CIP, and Digilocker. No watered-down checks. (Standard RBI compliance, not repeated in 2025 Directions) Mic, camera, location access by the Digital Lending Apps (DLA) is allowed only if needed for KYC, and only after getting explicit, purpose-limited, and revocable consent. Refer Clause 12 (i) LSPs must not access contacts, call logs, contact lists, media files, telephony functions, or other personal data – no matter the justification (fraud scoring, profiling, etc.). Refer Clause 12 (i) All KYC and onboarding data must be stored exclusively in India. If processed offshore, it must be deleted and brought back within 24 hours. Refer Clause 13(iv) All Digital Lending Apps (DLA) of both Regulated Entities and Lending Service Providers must be reported and registered on a centralised RBI-maintained CIMS platform. Refer Clause 17 In line with the emerging DPDPA, Borrowers must be given clear options to deny or revoke consent, limit data sharing with third parties, limit data retention, and request deletion of their personal data. Refer Clause 12(ii) Personal data of borrowers can only be shared with third parties after obtaining their explicit consent, unless the sharing is required by law. Refer Clause 12(iv) Exciting engineering and craftsmanship to get life done. Brought to life by your friends at frslabs. Learn more about our Atlas Unified KYC that adheres to the new master directive including #DPDPA compliant consent layer (no-code and single API integration): https://lnkd.in/gPSf9p_i #DigitalLending #RBIRegulations #KYCCompliance #DataPrivacy #FintechIndia #ConsentBasedLending #LendingCompliance #LSP #DLAs #FinancialInclusion #ResponsibleLending #CustomerProtection #NBFC #BankingReform #RBI2025

📢 The #DPDPA introduced the concept #ConsentManager, who acts as a single point of contact to enable a #DataPrincipal to give, manage, review and withdraw her #consent for #personaldata processing. Recently, the Ministry of Electronics and Information Technology (MeitY) released a Business Requirement Document for a Consent Management System (CMS) under the Digital Personal Data Protection (DPDP) Act, 2023. 🎯 We are discussing these requirements and guidelines in FDPPI #Jnaanavardhini. Discussions led by Bhuvana Anand, Deepti Bhatia, Gaurav Mehta, Shankar P and Vijayashankar Nagarajarao. All are invited. 📅 June 18, 2025 🕖 7 PM IST 📌 On Zoom ID 828 3381 5757 pw jvs2025 Ramesh Venkataraman| Nagendra Javagal| Bondaiah Adepu| M.Ashok Kini| Manju TC| Subbarayudu Tallapragada| Ramesh Kauta| Suresh B.

DPDPA violation and what might transpire – A small example of how our personal data might be circulating without our knowledge. Context: I received a call last week from a general insurance company asking if I wanted to renew insurance for my old Maruti 800. I hadn’t shopped around or requested any quotes, so let’s assume I raise a complaint with their DPO or escalate this to the DPB. Details: I’ve never contacted this insurer before, nor had any relationship with them. They were unaware I had already renewed, so it’s unlikely my current provider shared the data. They contacted me via phone, WhatsApp, and email -- clearly, they had my complete personal details. So who might have shared my data? Analysis: The original car dealer in Bengaluru had all my info -- name, address, phone, email. They arranged the first insurance, but I switched later and they had no issues. The dealer did follow up on servicing, but never on insurance -- until perhaps now. It is possible the dealer switched insurance partners and shared all historical customer data with the new provider. Other possibilities: Parivahan holds vehicle and insurance info, but if checked, it would show I had renewed (obviously they hadnt checked before calling me). Service center: I have left the car at two places over 7 years. Insurance papers are in the glove box, someone could have picked up the info and passed it to an agent. Law enforcement officer? Unlikely, no accidents, 3 parking tickets, and were paid online so no chance of leakage there. Most likely source? The original car dealer (highest probability). They had complete data, and perhaps they shared it with multiple insurance companies or change partners and shared historic data with them. That might also explain why the caller didn’t know my policy was renewed. Now the bigger question. Should the insurance company that contacted me be penalised under DPDPA for using my data without consent or legitimate purpose? Should the trail lead back to the entity that shared data without my consent (likely the car dealer) and be penalised as well? Will DPOs investigate complaints to this depth -- or stop at surface-level actions -- "regret the inconvenience ..." ?? What’s your take on how enforcement will play out under DPDPA? Will the Data Protection Board be convinced if I share these details for imposing fines? Will fiduciaries be innocent until proven guilty by citizens? #DPDPA

Fraud Risk and Security (#KYC) – Knowledge Series #31 The Supreme Court of India, in its judgment dated 30 April 2025, has emphasized the equal and accessible inclusion of persons with disabilities (PwDs) in obtaining financial services. The Court has directed all regulated entities to ensure that the Digital KYC process is fully accessible to persons with disabilities, in line with the rights granted under the Rights of Persons with Disabilities Act, 2016. SEBI has a circular and FAQ in this regard. Please find below a summary of what you need to do as a regulated entity. Firstly, allow persons with disabilities (PwDs) to open accounts in their own name, digitally or in person, just like any other individual. Recognize Guardianship Legally - When a guardian is needed, accept a Guardianship Certificate issued by a Local Authority. Allow Guardian Signatures Where Needed - If the person with disability is unable to sign, allow the guardian to sign on their behalf for opening the account. Comply with Dual KYC - Ensure both the guardian and the person with disability comply with KYC requirements when applicable. Enable Online/Digital KYC with Accessibility Standards - Extend digital KYC services to PwDs offering additional assistance during video KYC on request (for example accommodating a guardian or providing support for sign languages or reading out loud features). Offer Practical Liveness Checks - If the person cannot blink or move their eyes, use alternative checks such as: Head nods, Facial expressions, Showing OTP on screen. Note: It is not clear how a PwD will be able to read out an OTP on the screen. Perhaps it may be interpreted as displaying the OTP to the Agent on screen. Accept Thumb Impressions Digitally - Allow e-signed thumb impressions as valid signatures in online KYC, ensuring inclusivity for those unable to provide conventional signatures. Note: This again poses multiple challenges as the digital signatures offered in India are not PwD friendly and will require the help of a guardian to complete the step (for e.g. entering Aadhaar/OTP for digitally signing a document). Capture Disability Type Respectfully - Capture the disability information and percentage of disability during digital KYC, only if necessary and with proper consent and respect for privacy. Leverage Central KYC Registry - Accept pre-existing KYC records from the Central KYC Registry upon receiving proper consent from the client. Review Accessibility-Related Rejections - The Principal Officer shall review the automated KYC application rejections in cases where accessibility-related challenges prevent successful verification and approve them on a case-to-case basis. Are you are looking to make your KYC process more inclusive for your customers, let us help: https://lnkd.in/gPRx9EE3 #DigitalInclusion #AccessibleBanking #PwDRights #AtlasKYC #SEBI #FinTech #RegulatedEntities