 Hi everyone, my name is Atma and I'm the Founder and CEO of Lotus Pay. We are an aggregator for NACH Debit and I will explain what NACH Debit is. So we're going to talk about recurring payment collection methods. So this talk is focused on how businesses can collect recurring payments digitally in India. We'll cover what is NACH Debit, why you should use it, how it works, and how to design the subscription logic that underlies the actual payment collection, the recurring payment collection, how you can actually get started, and what the customers experience looks like. And also at the end we'll touch on how it compares to the other upcoming recurring payment collection method, which is UPI 2.0. So traditionally collecting recurring payments in India has been quite challenging through these existing methods. Paper-based NACH Debit, this is like a physical mandate. It looks like a check, it's 8 inches by 3 inches. It contains the customer's details and you need to take their signature. Once you've taken their signature, you send it to your bank, your bank sends it to the customer's bank. The customer's bank will verify the signature and activate the mandate. Then you start pulling money against it. So the logistics of this is quite expensive and cumbersome. And there's up to a 27% signature mismatch rate. So paper-based NACH Debit isn't great for most businesses. It's traditionally been used by the lending industry. Cards, cards are doing much better now. Payment aggregators have started to implement recurring payment methods on standing instructions on cards. But they're still expensive and also they have the challenge that cards do expire, they get lost, they get stolen. If it's not a standing instruction, if you keep asking the customer to pay, then you're also reminding them to cancel. So a true recurring payment method is one that never asks the customer to pay on a regular basis. There is an exception as I mentioned. Some large utilities like Airtel or electricity companies, they do deep integration with banks and they take standing instructions on card. Then there's payment gateways who are able to start doing standing instructions on credit cards. And the UPI is coming up for other push payment methods like wallets, UPI net banking methods. So push payment methods requires the customer to initiate the transaction. Whereas NACH Debit and UPI 2.0 truly are pool-based payment methods. The business is pulling the money out of the customer's account. So what is NACH Debit? It's a way to keep getting paid and it's easy, quick and secure. It's an NPCI payment system so most of you must be familiar with the National Payments Corporation of India. It's a private organization owned by the banks. It owns about half of the payment systems in India and all the payment systems are regulated of course. NACH Debit replaces ECS. So ECS has been around forever. NACH Debit replaces it in the last couple of years with the national clearing system. It basically means direct debit of a customer's bank account. It's been traditionally done on paper as I mentioned but now it's transitioning into an electronic mode. And there are about 30 or 33 banks today in fact who are live as e-mandates, as destination banks for e-mandates. And I'll explain what destination banks are. So the key features are that it's paperless. It is now paperless. There is still the paper method available but now there's the e-mandate method available. It's the cheapest by far recurring payment collection method. In fact I'd argue it's actually the cheapest payment method by far of recurring or non-recurring. It's very, very secure because it's a bank payment system. It doesn't require any aggregator as such but there are aggregators like us who do it. It's also great for customers because they just do a single initial authorization and that's it. That's their touch point. Then they forget about their recurring payment, recurring bills and you don't have to bother them. It's great for businesses because you can collect a variable amount or a fixed amount. You can do it regularly or irregularly. And right now what's available is e-sign mandate. So it requires a digital signature which is an ADAR e-sign created on the fly. I'll explain. But what's coming soon is another type of NACH debit e-mandate and it's called the API e-mandate which is initiated on the customer side by either validating through a debit card and PIN or through their net banking login. So this is coming soon. This is not ready yet but it's called the API based e-payment method. So what's available now is the e-sign based e-mandate. And it's good for businesses because you don't need to do a lot of security work especially if you're going through an aggregator. So it's not great in all scenarios. Let's cover why, when it's good and when it's not so good. It's great for high volume, small ticket payment collection. That's why it's been used by the lending industry traditionally. It can be used for any size but small ticket is particularly useful because of the ultra low cost. It's very, very secure because it's a banking payment system. It pulls payment so it doesn't require the customer to push a payment. It has legal standing. What this means is that it's an electronic payment system so it's covered under the Payment and Settlement Systems Act and it's also covered under the Negotiable Instruments Act because it's a customer authorizing a debit of their bank account and what that means is that under section 138 of that act the creditor, the business in this case, is afforded the legal protection which is afforded to checks for example. So if a customer defaults you have the right to initiate legal proceedings. So it has a legal protection in that sense. In that market you can use it with anyone because they just need a bank account. There's no smartphone required. It just requires a signature from the customer, either physical signature or electronic signature. Right now it works with ADAR so you can do it with consumers. Soon with the new API mandates it'll also work with corporates too. One business can collect payments from another business. It's not great if you need instant confirmation. But the ADAR eSign based mandates require some time for the destination bank to authorize the mandate and come back to you. It's not great for eCommerce because in eCommerce generally you require instant authorization. And it's not great for point of sale so if a customer is in a shop and they want a new recurring payment it's not really suitable for that. It's not great for push payments so it's not easy to initiate it from the customer's end. It's traditionally initiated from the business's end. And it's not suitable for offering the customer a variety of payment methods because there is only one payment method here. It's NACH debit. So there's no underlying payment method like for example in the Bar and Bill payment system that's a payment framework. It's not a payment system as such. It has underlying payment systems like UPI cards etc. So it only offers one way of actually taking a payment through the bank account. And it's not great if you need to extend credit. Like in a credit card the customer can pay their bill every month. They don't actually need cash to make the payment. Here you need clear funds in the customer's bank account. So direct debit has been a very popular payment method in Europe. In fact in Europe it's by far the most popular way for consumers to pay their bills. In the US credit cards have been more popular. That's the culture there. And in India we're seeing that now UPI is kicking off. So credit cards as a method for recurring payments haven't been so popular mainly because of the second factor authentication requirement. RBI has recently been relaxing that policy. But still it's challenging because credit card penetration is at the moment. Credit card penetration is at 4%. Debit card penetration is quite high but most consumers don't use debit cards for recurring payment. So NACH debit is based on three pillars. The customer needs to have a bank account obviously. Most customers have that. The customer needs to have either an Aadhar card. Now most people in India have that too. And they also need to have a... If they're doing API based E-mandates then they need to have net banking login or a debit card with the PIN. So here it's important to remember that the API based E-mandate is being authorized by the debit card and PIN. It's not using the actual debit card payment network like Visa, MasterCard or RUPE to actually take the payment. It's just an authorization method for the NACH debit E-mandate. And they need a mobile phone to receive the OTP especially if they're going through Aadhar e-sign. Now the great thing is that most customers have all of these like nearly everyone in India has these. And by the end of March everyone has to link these three things together. So the method that's available right now for NACH debit E-mandate is called Aadhar e-sign. Aadhar e-sign is simply a combination of Aadhar which is the unique identity an individual has together with e-sign which is operated by the CCA and it's a method for providing digital signatures which come through a chain of hierarchy authorized ultimately by the government who issues the license to the CCA, CCA issues license to an e-sign service provider, e-sign service provider issues licenses to corporate. So what is Aadhar e-sign? It's a temporary digital signature. It's an ad hoc digital signature. It's created on the fly. So it differs in that it doesn't require a customer to for example buy a digital signature certificate and store it on a USB. That's the kind of thing you can buy from say Imudra or Tata but it's not really required. It's generated on the fly. So here the customer needs to be an individual as I mentioned because it requires an Aadhar. Soon businesses can do it through the API based e-mandate. Customer needs to have an Aadhar. They need to have the mobile phone which is linked to the Aadhar because they need to receive an OTP on it. They need to have a bank account and the bank account should be with a live destination bank. There's some 30 banks. All the biggest banks are there except for a state bank. State bank is going to be live next month. So soon most of the customers in India will be covered under initiate debit mandates because they're banking with the banks that are already live. And the maximum size of a single debit can be one lakh on e-mandates, on paper based mandates. It's one crore but this one lakh should increase pretty soon. And the customer needs to have cleared funds in the bank account. What this means is that if the funds aren't in the account at the time of the debit, the debit will fail and you'll be informed and then you'll have to re-attempt the debit or find out some other way of collecting the payment amount. So if you want to do an ACH debit collection, this is what you need to do. You need to integrate with the bank on one side and you need to integrate with an e-sign service provider on the other side. And then you need to collect information from your customer and you need to go through a data security audit, a cert in audit. So cert in is kind of a government body which empanels various auditors and those auditors will audit you to check that the data security is up to the mark. So it's quite hard work. You need to do a lot of integrations. You need to build some subscription logic. You need to figure out how to create the mandates, how to authorize the mandates, then how to take the payments against that mandate and then you need to reconcile the amount that's coming against that mandate too. If you go through an aggregator, it's far simpler. There's just one integration required if you're the business. You integrate with your aggregator. The aggregator will receive the funds into their nodal account. A nodal account is like an escrow account. It's an account where clients' funds, your funds, are segregated from the aggregator's own operating activities and so the money coming in there is in the legal control of the bank. So this nodal account is owned by the bank. It's not open, owned by the aggregator. So the way this works is that you take your customer's details, you pass that mandate to your sponsor bank. The sponsor bank is your bank and then the sponsor bank will pass it through the NACH electronic system. It's called the mandate management system, MMS, to the destination bank, which is the customer's bank. The customer's bank validates the mandate and comes back as validated and the payment flows in this direction too. So the advantages of doing it through an aggregator is that you don't need to worry about all of this and here you can just focus on your single integration and the aggregators already done deep integration with the bank. They can intelligently route the mandates, they can negotiate better pricing with eSign providers and with banks and they have dedicated resources working on it and the funds are in safe custody because of the nodal account. So what does the destination bank do? So when a customer signs a mandate, they are saying that the contents of the mandate is correct, but that doesn't actually mean that they are the person who owns the bank account mentioned in the mandate. That has to be verified by the destination bank. So when the mandate reaches the destination bank, they have a validation engine provided by one of the eSign service providers. They check that the person who digitally signed the mandate is the same person who owns the bank account contained in the mandate. That's the validation process. That's how a mandate gets activated and therefore you can start taking funds against that mandate. To get all this started though, you need to have some underlying subscription logic. You need to have a billing system in place. You need to understand, okay, I have a plan against that plan. I need to invite a customer to be on that plan and then that link is called a subscription. So this subscription then has a mandate that mandate can be through UPI 2.0 or it can be through NACH debit. It can be through a standing instruction on cards. Then you need to have the underlying bank account from which you're pulling funds. So then once you have this mandate set up, you need to pull the funds. So that's the debit coming out of the customer's account. Then you need to map that to your bank account, the credit, and so you need the final object, which is your bank account. So all of these objects need to be coded in your billing software. It's quite complex to get this right. There are existing billing management systems which will do this for you and there's also aggregators that are getting into the space of subscription logic too. So payment aggregators are doing subscription logic. If you want to do this yourself, you need four things. You need a current account to be paid out to. You need the NACH debit product from your bank. It's a cash management service offered by the banks. Then you need to have a file transfer method in order to pass the e-mandates to your bank and to get the response files from your bank. And then you need to be banking with a live sponsor bank for e-mandates. Not all banks are actually live as both destination banks and sponsor banks, but many of them are. So the large banks are available as e-mandate sponsor banks. If you want to do it by an aggregator, you just simply need a current account to be paid out to. If you're going to do this yourself, you need a doc signer certificate. So a doc signer certificate is like a digital signature certificate, but it allows you at the corporate level, it resides on the server, it doesn't reside on a USB token, and at the corporate level, it allows you to sign documents, various documents, like a PDF or an XML. In this case, it's an XML. The ASP setup is also important because you need to get authorized by an e-sign service provider as an EKYC user agency or as an application service provider. So you need to have one of these two setups with your e-sign service provider. If you are an application service provider, there's a redirect to the e-sign service provider, which you'll come on to. If you're an EKYC user agency, this is called a KUA, this means you have a license from the UIDAI in order to carry out our authentication on your own server, then there's no redirect required. So you need to integrate with one of these e-sign providers. There's only five in the country. So these are the options available to you. As a couple of weeks ago, E-Mutra was suspended, so hopefully they'll come back online soon. But you need to get on board with one of these e-sign providers, either as a KUA, an EKYC user agency, or as an ASP, an application service provider. Here's the steps to actually getting started with an ACH debit. You need to prepare the mandate. So you need to source the customer's data and we'll mention what data you need from the customer. You need to create an authorization URL. So this is an HTML page where the customer can go and see their details and confirm that, yes, these are my details. This is my bank account, this is my other number, this is my name, and so on. The customer checks these details. So they check the details and they go through the e-sign process, which we'll come onto. Once they've done that, you have to prepare the raw E-mandate XML. That is a set of tags which contain all of the customer's data. You base 64 encode this string and you hash it using a hashing algorithm. That hash then goes into the request XML, which is separate to the mandate XML. That request XML, you send to the e-sign gateway and that's the integration that you should have done by now. It's important to remember here that you can actually ask the customer to enter their own details on this kind of confirmation page so that it could be like a form and then a confirmation page. This is a bit risky because customers can make mistakes. You need to get things pretty right. You need to get their, our number right, you need to get the bank account details correct. Otherwise, this whole part will be successful. They'll go through the e-sign process and then they'll finally find out after the destination bank has responded that there's some mistake, like say the account number was wrong. So it's best if you, as a process, you're collecting the data from your customer and you're just simply showing them a confirmation page where they carry out the e-sign. You have to take this raw mandate contents. It includes these details. So you need to have your sponsor bank details. You need to have your name, you need to have an ACH utility code which allows you to participate and if you have this utility code, you can use the aggregators utility code but then it's the aggregators name that will appear on the customer's bank statement. If you don't want that to happen, then you need to get your own utility code and a good aggregator can do this for you in a day or two and this code basically entitles you to participate. Therefore, it's your bank account, it's your name appearing on the customer's bank account statement and it's you that's afforded the legal protection, the section 138 protection that I mentioned earlier. Now, you also need the customer's bank account details. You need the IFSC code, account number, the account type, savings or current account and you need the start date and end date of the mandate. You need the frequency, whether it's monthly, weekly, whether it's ad hoc or quarterly and the amount. The amount can be a fixed amount or it can be a maximum amount under which you can, the limit within which you can debit. You need the customer's order number and there are two reference fields where you can enter your custom data like your customer ID number or your subscription reference number. The request XML contains the hash that I mentioned. It contains the algorithm type that was used to create that and it contains the authorization type. So in Adar eSign, there's two ways of doing Adar eSign, biometric or OTT. NACH debit only uses the OTT method and right now it's only pre-verified node and you need a response URL. So once the customer goes to the eSign gateway and signs, where is that customer going to come back to? So a URL for your website. You need to have your digital signature, the doc signer that you use to sign that mandate along with the certificate and you need to have the customer's order number. So the customer visits this page, they check their details, they click on Proceed and then they're redirected to the eSign service provider. This only happens if you are an ASP. If you're a KYC user agency, then you don't need to do the redirect. You can do this process on your own server. To get this license is a bit challenging right now. You need to go through a process with UIDAI and you have to pay quite a big fee. It's about 20 lakhs, bank guarantee, another 25 lakhs in annual cost. So most companies, most SMEs won't be able to do this. Many of the large companies have already done this for other reasons and therefore they can take advantage of this. The customer reads the resident consent. They're authorizing the creation of that temporary digital signature. They request an OTP. It comes on their mobile phone as an SMS and they punch that in and they hit submit and that confirms they get a confirmation that the eSign was successful and then they go back to your redirect URL. So in the back, that's at the front, but in the back this is what's happening. You're getting a response from your eSign gateway and you need to use that response to code up your final eMandate, the one that you're actually submitting to the bank. The final eMandate contains the raw mandate data. It contains the signed content. It contains the gateway's certificate and the gateway's signature. The signature contains the hash which verifies the content of the mandate. Once you've submitted this to your bank, so you do this via SFTP, your bank will check it. They'll validate that it conforms to the overall requirements of NACH with eMandates. They will upload it to the mandate management system. All the sponsor banks have integrated with the mandate management system of NACH. This is when your unique mandate reference number gets generated. At this point, all they're saying is that the mandate has been submitted. It's not that the mandate is live yet. The destination bank checks, then it reaches the destination bank. The destination bank then has two days to respond, either to say, yes, it's a valid mandate, or no, it's not. Then they can give the active or reject status. The sponsor bank gets that status back, and then they inform you about what their status is. Once the mandate is active, then you need to start pulling funds against that mandate. If you are going through an aggregator, that pulling of funds can be automated. For example, you're a gym that collects 5,000 rupees a month, but you know that on the fifth of each month we need to collect 5,000 rupees from this customer. Then you don't want to worry about, on the fourth of the month, I have to remember to send a debit file to pull the funds. If you're using an aggregator, they will hopefully build the subscription logic, which allows you to forget about that. If it's a fixed amount monthly, you don't need to worry about the automation part of it. If it's a variable amount, for example, say a mobile phone bill, which varies from month to month, then you as the business need to inform the bank or aggregator how much you want to debit each month. Once you submitted this bulk transaction file, the sponsor bank validates it, submits it, the destination bank will respond by the end of the day, and you will receive one single bulk payment. Suppose you submitted 100 debit requests in one batch file, and each one is for say, 1,000 rupees, and if they're all successful, at the end of the day, you'll get a single payment of 1,000,000 rupees into your bank account. Then you need to figure out how to reconcile that 1,000,000 rupees, a settlement, a payout amount, with the 100 debit requests that you sent. So this reconciliation process can be really complicated if you're doing it on your own. If you're doing it with an aggregator, then they will have built this into the subscription logic. So here are some of the advantages that we see when you're going through an aggregator. They will automate this billing process for you. They will have done the whole subscription logic. It will help you to improve your cash flow if you're using any kind of recurring payment methods that does not require a customer to authorize every subsequent payment. Remember what I said. If you're asking the customer to authorize a subsequent payment, a recurring payment, you're also reminding them to cancel. So it improves the cash flow. It reduces the churn. It also means that you don't have to keep chasing your customers for payment. Many businesses in India right now support people call their customers every month for payment. There's a real cost to that. You can integrate this with your existing workflow in your system. It improves the customer's experience because they just need to do a single initial authorization after which they can just forget about it. For you it's great pricing. It's much better pricing than any other payment system. So what are the use cases? If you are in the financial services industry, then you might want to collect recurring payments for SIPs or on the liability side, on the asset side, if you are a lender, for example, then you need to collect EMIs. So this is the best use case by far. In fact, 90% of NCH debit mandates are for the financial services industry. Slowly, though, it's being expanded into other industries. It's great for the technology industry to collect cash payments, for example, subscription payments, and their respective recurring payment collection requirements. How does this compare to the other payment system, like payment gateways? So if you go through a payment gateway, regardless of whether it's a push-based payment or a pool-based recurring payment, you need to pay some fees, which are generally going to be percentage-based fees, especially if it's a card, in fact, all the underlying payment systems offered by companies have a percentage-based fee. Say, if it's a debit card, it might be around 1%, credit cards will be 2% to 3%, UPI will be just under 1%, net banking payments will be just under 1%. So you're paying a percentage fee. It's a sliding scale. So if, for example, you're taking a thousand rupees, that 1% is 10 rupees, but if you're taking one lakh rupees, then it goes up according. So the point here is that NCH debit, it doesn't matter how big the payment is, if you pay a fixed fee, it's literally X rupees to greater mandate and Y rupees to take the debit. It doesn't matter how much, how big the debit is. And so there may be some other maintenance fees as well. So banks will charge you a setup fee to get started with NCH debit, and aggregators should not. NCH debit is by far the cheapest payment collection method for recurring payments. This is a simple kind of illustration. It's quite over-simplified. It uses kind of, you know, a little bit of internal analysis. But if you're trying to collect, say, 5,000 rupees from a customer on a recurring basis and you're doing it by cash, the true cost of that cash collection is actually quite high because you need to move the cash around. You need to keep reminding the customer to pay. You need to get your sales and support people to go and physically collect that cash. So the true cost of it is quite high. So this incorporates the labor cost, the logistics cost, the transportation cost and the lost interest and so on. So productivity loss. So if you're trying to understand the total cost to your business for doing something, for doing a recurring payment collection by various payment methods, this gives you an idea. Now, UPI fits in around the 150 mark just before NCH. UPI on version 2.0 with recurring payment mandates will still have this MDR concept. So it's still going to cost you a little bit more than NCH debit because it's still a percentage fee. The cheapest method by far will be NCH debit and if you're doing it on paper there's still the logistic cost. But if you're doing it on electronic mode through eSign or API based demand that is literally by far the cheapest recurring payment method body available. And remember, these other payment methods are push-paves payment methods. The customer has to push the money. NCH debit and UPI 2.0 are pull-based payment methods. This is a bit old. I didn't have time to update this. This is from June, but it gives you an idea of kind of the volumes in play in different payment systems. NCH debit is kind of in the middle of the pack. UPI I think it's grown significantly since June. It's probably around 100 million 100 million rupees 100 billion rupees mark. So it's still kind of it's probably just surpassed wallets. But you can see that this is a significant volume of recurring payments going this is not just for recurring payments. This is for all payments. But there's a significant volume of recurring payments going through other payment systems which could be consumed within true recurring payment systems. UPI 2.0 and NCH debit and card standing and stuff. So how do the two compare? NCH debit is a pull-based payment method. There is actually a way of doing it by push if it's the customer initiating the mandate. It's not such a popular way of doing it because the customer has to go and get that paper or that form and they have to push it on e-sign mandates other e-mandates it's always pull. You have to create the mandate. Whereas with UPI the customer can initiate UPI 2.0 the customer can initiate the mandate. You can say okay I voluntarily want to pay this business or this other UPI user X thousand rupees per month. The cost structure on NCH debit is a fixed fee. So it's an absolute fee. A rupee fee per mandate and a rupee fee per debit. Whereas with UPI it's a percentage fee. So it's going to be more expensive. NCH debit isn't great if you need instant confirmation. So it's going to require two days up to two days to actually authorize the mandate. That time period is actually coming down. A good aggregate can get it done for you in a day. And one day one business can get the actual debit. So you submit the debit request in the morning and by the evening you should get the funds come into the bank. That bank may take its own sweet time to pay you out but a good aggregator will pay you out the same day. On the other hand if you're using UPI and you're doing bulk collection bulk collection via UPI is actually a product offered by banks. You don't need to go through an aggregator but aggregator will have solved a lot of the tech problems for you. But if you're doing bulk collection via UPI there's two ways of doing it. One is that you're actually sending out individual UPI pull requests the customer pays you and you're getting literally thousands of debits coming to your account and you have to figure out how to reconcile those against your subscription logic. A better way would be to do it by bulk payment where you get one payment at the end of the day and then you can just reconcile that against the individual debit request. If you're trying to set this up you can do it through a bank or aggregator in both cases. But if you're doing it with NACH debit you need to have the eSign service if you're not going via an aggregator. So revocability is an important concept here. It's not the same as cancelling, right? Even a customer can cancel an NACH debit mandate or a UPI 2.0 mandate. Both can be cancelled by the customer. The difference is about revocability whether they're allowed to cancel the mandate whether legally they were meant to cancel the mandate. So technically an NACH debit mandate should not be cancelled by the customer unless they've taken the business's permission to cancel it. So if for example the business is a lender and they're taking an EMI payment against an outstanding debt then the customer has no right to cancel that mandate. They can but they have no right to do so. If they do that then that's a section 138 default. Whereas with UPI it can be cancelled by the mandate and it is revocable by the customer. And it is revocable by them. So it's not great for lending products. UPI 2.0 will not be a great legal will not afford great legal protection for lending businesses. The customer requires a bank account in both cases. They need a mobile phone in the case of NACH debit. In the case of UPI 2.0 they need a smart phone not just a mobile phone, they need a smart phone. They need to install a UPI app on it. So that penetration is much less than just simple mobile penetration. So with NACH debit you can receive the math at the bottom of the period. You can literally take money from anyone's bank account. Whereas with NACH debit it only works if that customer owns a smart phone and has a UPI app. And they created a VPA. So they need a VPA. That's the one thing you need from a customer E-mandate. From the NACH debit point of view you need to get their bank account details and their other numbers. If you go through an aggregator for NACH debit they will be able to provide you with dashboards and APIs that solve a lot of the subscription logic problem. If you don't want them to do the subscription logic part of it then you just need the E-mandate creation the pool money, the pool debit request the debit transaction request and you need to understand how to reconcile the payouts against the actual debit request. So you need an API or a dashboard to reconcile this and an aggregator should provide all three of these things. So if you want to get started with NACH debit if you want to do it yourself then you have to go via bank. So you have a current account with your bank you have to go to that URM and ask them for the cash management product known as NACH debit and then you need to do SFTP integration with your bank. This alone will take you hope it will take weeks but it will take months. You need a doc signer certificate from an e-sign authorized license you also need to do an e-sign integration and you need to undergo an audit from a certain impaneled auditor data security auditor. You need to create the mandate and figure out how to do that so you need to actually code that up then you need to build in your subscription logic to link that mandate creation with your billing system and subscription system and then you need to undergo NACH certification to be actually allowed to participate in the NACH system. If you do it by an aggregator you just need an API. So in summary NACH debit is great for recurring payments collection. It's cheaper, more secure and it has better reach than other payment systems. It has a different use cases compared to standing instructions on cars and UPI version 2.0 and you might want to consider using an aggregator. That's all I have for you. If you have any questions I'll be happy to answer them. Thank you very much.