Designing KYC: a bachata feat. Growth and Compliance💃
Growth wants easy KYC for more adoption. Compliance wants tough KYC for less fraud. Who leads, who follows?
Welcome to another issue of PMF: Perspectives, Markets & Frameworks 🌈, where we endeavour to shed light on the intricacies of product management and delve into the unique aspects of India's market landscape.
If you’re not a subscriber yet, subscribe now (like 70+ PMs, founders and builders already have) and get notified whenever we publish a behind-the-scenes story of building great products.
This article is an expansion of a small section of another article. Here’s a TLDR of the linked article:
In October 2021, FloBiz launched Smart Collect – a powerful reconciliation tool for Indian SMEs within its accounting SaaS product myBillBook.
For those of you aware of Razorpay’s Smart Collect, this was a similar product, but with a GTM tailored for non-tech savvy Indian SMEs and deeply integrated within myBillBook.
For those who aren’t, myBillBook’s Smart Collect provided merchants with automatic payment reconciliation by serving as a tech-enabled middleman between merchants and their customers.
The linked article talks about the research behind launching this product, the product + design + tech choices made and the success we saw. One part of being a payments middleman was conducting thorough KYC of merchants, while ensuring that adoption didn’t suffer greatly.
That’s what this article focuses on.
Disclaimer: This is a story from 2021-22, so it may not fit well in today’s regulatory environment.
Table of Contents
Why did Smart Collect need KYC?
Imagine a fraudster collecting money from unsuspecting victims.
He needs to share a QR code with his victims to which they will send money. But in case of a Cyber Crime investigation, he won’t want his bank account to be known to and blocked by authorities.
A cunning fraudster could use myBillBook’s QR code to collect money from victims. By putting myBillBook’s QR code as an intermediary, the fraudster could significantly slow down the investigation, as the police would first have to be convinced of myBillBook’s innocence.
The fraudster could use an unsuspecting friend’s account to collect the victim’s money from myBillBook. The friend could be under the impression that he’s helping out someone with bank account-related issues. But in the event of a Cyber Crime investigation, the friend would get implicated.
If we didn’t confirm that the merchant himself was the owner of the bank account, we potentially would have opened the floodgates for hundreds of friends (more formally called mules) to get entrapped and thousands of victims to be defrauded by cunning fraudsters. Apart from this, it was important for us to complete KYC of merchants, since in the event of a Cyber Crime investigation, we were required to submit PAN or Aadhaar details of the suspected merchant to the cops, so that they could block all bank accounts linked to the PAN immediately and minimise further damage.
Not just fraud, a mule could be enabling money laundering as well (which in simpler terms means erasing the origin of illicit money by layering it under a web of transactions). Money laundering is a serious offence. In February 2024, Paytm Payments Bank was instructed by the RBI to cease all deposits, bringing their operations to a grinding halt due to insufficient KYC practices and signs of large-scale money laundering.
Similar to Payment Gateways like Razorpay and Cashfree, Smart Collect (SC) needed to validate the bank account to which we settled the merchant’s collections, and to confirm that the merchant was the owner of the bank account on official records. So we defined KYC as an umbrella term for:
Verifying the validity of the merchant’s bank account
Verifying the ownership of the merchant’s bank account
While we built our KYC journey in-house in 2021, today, you don’t need to. KYC-as-a-Service vendors like HyperVerge and Bureau can do this heavy lifting for you, ensuring that you spend more time on delivering your core value proposition to your customers.
Learning from fintech giants
While we evaluated from first principles what our KYC process should look like, we also studied other fintech players to understand how easy or tough their KYC was.
Paytm for Business and PhonePe for Business had the easiest KYC, which involved:
Entering bank account details
Entering PAN
Ensuring that the name on PAN matched with the bank account holder's name
Google Pay for Business had the toughest KYC, which involved:
Entering bank account details
Submitting a photo of PAN
Submitting an address proof
Ensuring that the name on both these documents matched with the bank account holder's name
Making a live video call when present inside the shop
This disparity in ease of KYC was intriguing, which we attributed to 2 things:
Google Pay for Business had little to no offline adoption workforce in 2021, compared to PhonePe for Business and Paytm for Business whose massive P2M UPI transaction share was due to their widespread offline adoption workforce. Since field agents evaluated shops before pitching merchants to use a PhonePe or Paytm QR, their product team could confidently eliminate the need for extensive proof.
The level of strictness in KYC in fintechs in 2021, was influenced more by growth-hungry product teams than risk-averse compliance teams.
Interestingly, both Paytm for Business and PhonePe for Business called this process as ‘Verify your Identity’, to call out that their KYC wasn’t as arduous as KYC normally is. We borrowed this copy from them.
Like what you’ve read so far? Subscribe (for free!), and we’ll stay in touch
KYC v1: Let’s build a smooth yet robust KYC
How we thought about it
Based on our understanding of myBillBook merchants and after surveying other fintech apps, we recognised that a KYC process:
can be cumbersome and long
requires merchants to trust you
is full of friction
Solution to Problem #1: Know your merchant
myBillBook is an accounting app, whose GTM is tailored to find merchants who struggle with traditional accounting practices. We saw hardly any users post onboarding who didn’t have a genuine business. So it made sense to build a light-touch KYC, without asking for any documents, photos or videos. Given that we had decided to roll out SC conservatively to our merchants, we could re-visit this decision if early signals raised alarm.
KYC vendors like Karza provide APIs to fetch the name of the individual or company registered under identity documents like PAN, Aadhaar, Driver’s License, etc, requiring only the ID number, not even a copy of the document.
💡 We chose PAN and GSTIN as options for users to prove their identity, for these reasons:
GSTIN: Merchants who were GST Registered and carried out GST-compliant accounting on myBillBook had already added their GSTIN on myBillBook. These merchants wouldn’t have to enter any extra information.
PAN: For non-GST merchants, we had to choose between PAN and Aadhaar. We chose PAN for 2 reasons:
PAN verification APIs provided a simpler UX than Aadhaar verification APIs, while having similar penetration among merchants. PAN verification simply required users to enter their PAN, whereas Aadhaar verification required users to enter their Aadhaar number and DigiLocker pin (which we were sure many merchants won’t remember).
We could save integration time by using the same API to verify both PAN and GSTIN, since 3rd - 12th characters of GSTIN are the company’s or individual’s PAN (this turned out to be a mistake in hindsight, which we’ve discussed in detail in minor improvements)
With these 2 options, we were confident that we would cover majority of our merchant audience, and provide a simple and short KYC experience.
Solution to Problem #2: Win trust
India’s micro and small business owners were truly introduced to the internet only after Jio’s launch in 2016. Over the years, they slowly learnt to use YouTube and Instagram, but even by the launch of myBillBook in 2020, the internet had yet to become a mainstay of their business. Their trust in an online software’s ability to store their accounting data securely was nascent, further compounded by the fact that traditional accounting softwares like Tally had been completely on-device. In myBillBook’s pre-PMF days, we discovered that repeatedly reassuring users that their data while online, was stored securely with us, helped address this concern and improved adoption. So for each screen of the KYC journey of SC, we reminded merchants of our ISO 27001 certification and that our app was 100% secure.
Solution to Problem #3: Reduce friction
We wanted to minimise Time-to-Value as much as we could while staying compliant. We believed that merchants should experience the aha moment of auto-reconciling payments before we asked them to put in effort for KYC.
So we allowed merchants to enable SC and collect payments in their Virtual Accounts (VA) even if they hadn’t verified their bank account or KYC. Once they verified their bank account, we would immediately settle the collected amount to it.
How we built it
Given that we needed to know the merchant’s bank account and confirm its ownership, we built a 2-part KYC process:
Verify your bank account
Verify your identity (KYC)
Part #1: Verify your bank account
Q. How do you know if the 11-14 digit account number that the merchant has entered is correct?
A. You send them some money
We used Karza’s ‘Bank Account Verification API’ (commonly called ‘Penny Drop API’) to send ₹1 to the merchant’s bank account. If the transaction was successful, the bank account number was correct and we could settle the merchant’s payments to it.
💡 To reduce scope in the first version, we didn’t support verifying and settling to multiple bank accounts. Our database stored only the last verified bank account of the merchant. This meant that merchants could verify 2 different bank accounts back to back and earn a rupee for every verification. To counter this, we added a limit beyond which a merchant couldn’t verify his bank account. This introduced some unexpected Customer Support tickets, which we’ve talked about in interesting episodes about India.
Today, you don’t need to add ₹1 to your Customer Acquisition Cost (CAC) for penny drop, just to verify bank accounts. Payment API vendors like Karza and Decentro offer penniless verification, where you don’t need to send any money to a bank account for verification.
After bank verification, we could build our KYC journey in 2 ways:
Nudge the merchant to complete KYC right away so that he can complete KYC all at once
Nudge the merchant to try SC first, till he settles up to a cumulative settlement threshold, after which he would have to complete his KYC
Our merchants hadn’t seen a payment construct like SC before, so it was important to let them get a taste, before we asked more of them. We chose option #2 and set the Cumulative Settlement Threshold at ₹50K, since we were more concerned with adoption early on, than fraud.
We made ‘Start Collecting Payments’ the primary CTA and let the next step of KYC show as a ghost button.
As merchants used SC and their cumulative settlement reached 75% of ₹50K, we reminded them to complete their KYC.
If merchants crossed ₹50K without completing their KYC, we informed them with a realtime Push Notification (PN) and a native banner that their money was stuck due to pending KYC 🚫.
Part #2: Verify your Identity (KYC)
To verify that the bank account was actually owned by the merchant, we required 2 pieces of information:
Name of the bank account holder – when making an IMPS payout (in our case, the penny drop transaction), banks revealed the account holder’s name in the API response
Document to identify the merchant – we fetched the merchant’s name from their PAN or GSTIN
💡 We matched these 2 names using a ‘Name Similarity API’ from Karza, instead of a vanilla string comparison, because:
bank account holder names contained prefixes like Mr or Ms in some cases, which aren’t present in names on PAN
bank account holder names contained the middle name as a single character in some cases, which doesn’t happen in names on PAN
bank account holder names in the Penny Drop API response got truncated to 20 characters, while names fetched from the PAN API had no such restriction
The Name Similarity API provided a similarity score as an output, which we learnt from Karza has different thresholds for individuals and companies. To be considered a match,
individuals must score > 0.65
companies must score > 0.85
In keeping with our focus on adoption, we relaxed these to 0.6 and 0.8. In cases of mismatch, we showed both names to merchants, so that they understood if the bank account or the PAN/GSTIN were the cause of mismatch.
No system is perfect, definitely not in its first version. For all cases where our KYC fell short, we empowered our operations team to step in. You can read about it in a later section titled Empowering KYC Operations.
While striving for high adoption and easy communication to merchants, we designed a complex flow for developers to implement. A big thanks to them for aligning with our commitment to good UX!
Metrics
📈 Within a month of launch, we saw 60% bank verification and 14% KYC verification among accounting power users who enabled the feature. This early success was endearing, given the unprecedented construct (for our merchants) and the complicated nature of the product.
KYC v2: UPI-powered smoother yet robust KYC
We saw 70% merchants drop at the bank verification screen, which meant more merchants could have enabled SC, which could have accelerated TPV growth. After speaking to merchants, we identified that not remembering bank account number was a common culprit. On the other hand, UPI IDs were much easier to remember and could be used for settling payments.
💡 Settling via UPI presented the inherent restriction that payments with amounts > ₹1L couldn’t be settled. Most PSPs also placed restrictions on daily payment counts. Thankfully, our payment partner Hypto’s Axis Bank powered-VA didn’t have a daily payment count restriction.
With this opportunity (and shortcoming) in sight, we enabled merchants to penny drop to and settle to their UPI IDs.
This made the first step of KYC easier, while adding another step to full KYC:
A merchant verifying only his UPI ID could collect up to ₹5K (lifetime) – we reduced our cumulative settlement threshold from ₹50K to ₹5K when fraud volume picked up. You can find a detailed article on our anti-fraud efforts here.
A merchant verifying his identify could collect up to ₹1L in a single payment
If he received or wished to received a payment higher than ₹1L, he would have to verify his bank account
Metrics
📈 We found that introducing UPI-powered KYC led to a 17% increase in settlement account verification, and an 8% increase in monthly transacting merchants.
We even experimented with making UPI the default verification option, but found that it worsened verification by 10% – probably due to distributors and wholesalers with payment amounts > 1L thinking that SC wasn’t meant for them.
Would you have built KYC differently? Let us know!
Empowering KYC Operations
For v1, our ethos was shipping beats perfection. This meant that we had to set up operations processes for cases that we hadn’t built for:
Merchants whose KYC and bank account couldn’t meet Name Similarity API’s thresholds (eg. missing middle name, different order of first and last name)
Merchants who changed the name on their PAN, but Karza’s API didn’t have the updated name
or cases we hadn’t foreseen:
Merchants using banks that did not support IMPS (eg. small co-operative banks like Vasai Janata Sahakari Bank, which aren’t part of this list on NPCI’s website), and thus couldn’t complete penny drop verification
Some banks responded to Karza’s Penny Drop API with their bank’s name, instead of the bank account holder’s name
We solved for this in 2 ways:
Reactively: Letting users reach out to Customer Support (CS) when they couldn’t verify their bank account or complete KYC
Proactively: Calling users with unsettled payments due to pending bank verification or KYC – we found that allowing users to enable SC with little friction led merchants to not recognise the impact of the change on their business. Virtual Account (VA) details and QR codes showed on their invoices and some customers paid as much as 87K to SC VAs instead of their regular bank accounts, which merchants had failed to notice. We acted before this led to confusion between the merchant and customer, and resentment towards myBillBook.
To enable manual KYC verification, we collected KYC documents like Aadhaar, Gumasta and bank proofs like bank statements or passbook photos and maintained these in an Airtable database, to analyse and prioritise if verification of any of these documents needed to be implemented on the product urgently.
CS agents could see unverified KYC details of merchants on an internal tool and approve or reject their KYC using the extra documents that merchants provided.
Interesting episodes about India
Manually reviewing multiple cases of failed KYC allowed us to learn new and interesting things about merchants, and how they did business and navigated their way through compliance in India. Sharing some interesting episodes:
#1: One and the Same certificate
If you have slightly differing names (all your own, of course) on important identity documents, instead of going through the pain of getting them corrected, you can get a One and the Same certificate from the Government.
#2: Too young for PAN, not young enough for business
A young 16 year old, helping his father run a roadside dhaba in Chattisgarh couldn’t complete his KYC, since he didn’t have a PAN. Between him and his father, he was tech savvy-er and set up a myBillBook and SC account himself on hearing about rewards for collections via SC. Given that it’s common to not apply for a PAN till one gets a bank account, he hadn’t applied for a PAN yet. We used his Aadhaar to process his KYC and let him resume his endeavours.
#3: Settling to multiple bank accounts
Some merchants in India maintain multiple bank accounts for business. These merchants had to change their settlement bank account on SC to ensure that they could still collect in different bank accounts. This meant that they had to re-verify their bank accounts each time. These users would get blocked due to our penny drop limits and have to contact Customer Support to bail them out.
📈 Thanks to the widespread penetration of PAN and GSTIN and reliable APIs from Karza, the volume of manually reviewed KYC hovered at a meagre 1.5 – 2% of all new KYC attempts.
Some minor improvements
#1: Masking bank verification error messages
Karza sent us error messages for bank verification, just as the bank had sent to them. In the first version of Smart Collect, we showed these error messages to merchants without any change. Some of them were clearly impossible to decipher for a layman.
📈 We masked Karza’s errors with more actionable and familiar terms and saw a 13% increase in bank verification.
In case, you’re struggling with a similar problem, you can find a list of bank error messages and what they mean in Giveaways.
#2: Using GST API to fetch company name
For sole proprietorships (which are a large majority of myBillBook merchants), PAN fetched from within GSTIN was the sole proprietor’s PAN. So when we compared his name with the bank account holder’s name, it failed in cases where the bank account was in the company’s name.
Using Karza’s GST API instead of PAN API, we could fetch both the Trade Name and Legal Name of the company.
A quick explainer on trade and legal names for proprietorships:
Trade name – merchant’s name
Legal name – registered entity name
When these merchants added their settlement bank accounts, we weren’t sure if they had added a current account (in their company’s name) or a savings account (in their name). So we checked both trade name and legal name.
📈 This resolved 70% of early KYC failures
#3: Validating IFSC code
💡 Did you know that you can make IMPS payouts successfully even if you enter the wrong IFSC code?
We didn’t and here’s how we found out: when we verified bank accounts via penny drop, we couldn’t check if the IFSC code was correct. This is because IMPS transactions (like our penny drop) only checked the first 4 characters of IFSC. But RTGS and NEFT didn’t have this luxury.
We encountered 3 failed transactions per day where their amount (> ₹5L) had required them to be sent via RTGS/NEFT and the merchant had entered the wrong IFSC code. Understandably, failed transactions of this quantum were scary for us as well as the merchant. We integrated Hypto’s IFSC API to validate IFSC codes and show corresponding branch names to merchants during bank verification, which resolved the issue.
Looking at our work under today’s regulatory lens
If you remember the disclaimer at the beginning of this issue, our work on Smart Collect happened in 2021-22, a relatively unconstrained regulatory period. Today (9th May 2024), we see a starkly different regulatory environment. Sharing some of the things we did, that aren’t possible today:
#1: Designing KYC without approval from Payment Aggregator (PA)
Today, products like Smart Collect need to onboard their customers onto their PA (Hypto in our case) for serving as a middleman. All KYC requirements mandated by the PA would apply to Smart Collect merchants, with little say of our own. Our design choices like requiring no documents and asking for only PAN or GSTIN won’t fly today.
#2: Optimising Time-to-Value by tiering KYC
PAs won’t allow our merchants to use Smart Collect, if the merchant’s KYC hasn’t been completed at the PA’s end. So our meticulously designed tiered KYC won’t be possible today.
There’s a silver lining to this though — any fraud that happens over Smart Collect, would be handled by the PA. We had to spend a lot of time, effort and money on building our own robust anti-fraud engine and operational process.
Giveaways
Here’s a list of bank error responses, what they mean and copies for your customer.
If you think this’ll be useful to a fellow PM, founder or builder, share it with them!
Thanks for sticking till the end!
Don't miss out on the next parts of this series! Subscribe now to continue exploring the intricacies of:
From Zero to Hero: A Payment Product's 100x Journey (part 1 of this article)
Fighting Payment Frauds as a Fintech Startup 🕵️ (part 3 of this article)
How to design a Rewards Program (part 4 of this article)
Nice read, but I notice a lot of KYC workarounds which happens while you are growing. However, when you become too big, such cracks become too wide to not notice for the auditors/regulators/partner banks. It is incumbent on firms to fix them as they scale and yes retrospectively as well in cases