 Hi, I'm Srikanth, I'm part of cashless consumer and a volunteer initiative trying to figure out the payment systems and also in the process see how we can ensure consumer rights are protected. So the talk is on UPI and beyond how tech communities can help consumer in cashless world. So first part I'll focus briefly on UPI, some of the work some of us did in figuring out UPI and in the later part I'll talk why as a initiative or a community need to focus on cashless systems beyond UPI as well. So first we'll talk around, we'll try to understand what is UPI. So quick 20 second thing is like UPI you install an app and you install a PSP app, you register, you get a created payment address and then link it to your bank account, have a pin for that and then start transacting. It's that simple from a consumer perspective. So but why is it so special and we'll also see what is the significance of being and there's also UPI is by far the developer friendly system that's out there. There's also some of the technical specifications that are out there. So we'll see how UPI deep linking specifications work and we also generated, we created a small hack to create a QR code generator. We'll see that and with UPI there's also the other thing like every bank and every payment service provider is putting out apps. So currently there are 38 odd apps on the Android store. So how do you actually as a consumer differentiate between these apps and install what's best for you and some of us have also been interacting with the India stack and the UPI folks. We've kind of reported some of the issues. We'll go through some of them and beyond that we'll see like what else are than UPI and the whole question of why this cashless consumer or why we should or volunteers should kind of be aware of these payment systems and work towards it. We have four broad areas of work. So one is awareness. So both in teaching people how to get digital, what are the basics. So most of us in this room would know how to go digital and be cashless, but there's especially after demand decision a lot of people had issues in boarding to these cashless systems. So how do we solve that? And then there is technical aspects. So we study these payment systems and we can also there's also opportunities for communities and individual developers to develop assisted tech for these payment systems. And we'll also we are also focusing on data and policy aspects of cashless. We'll see some of the things that we need to do in order to protect consumer rights. Okay, so before like I start so this is a UPI in the other payment modes. So you have traditional paper based transaction modes. So you had a pair and pay you had cash, checks, DDs, they're paper based, fully interoperable, they're privacy friendly. They're probably low cost to the consumer, but even that cost is hidden. So the Water Committee report says that any transaction should have the transaction cost, the cost that is incurred during the process of transacting value from payer to pay should be transparent. And most of these, the policy recommendations kind of view that there's high cost of cash, but to the consumer, it's always low, but it's also hidden. And settlement is instant in case of cash and for checks and DDs, it takes six days. And okay, so then there is there are other digital mechanisms where you can transfer by cards, net banking, wallets. These are digital by design, but they are built on proprietary or non standard interfaces. Since it's very fragmented, there is a little or no interoperability. Some of these systems talk to some of the other systems like cards, we'll talk to wallets, but some wallets won't be talking to net banking and things like that. So the interoperability is limited. It's, it's semi privacy friendly if you consider the fact that your bank would not know what you are actually spending on the wallet. And your wallet doesn't know which bank you're banking with or which what's your account number in case if you use net banking, there is a slightly higher cost to the consumer. That again is also hidden. So there is this whole notion of MDR much in this count rate, which gets passed on and then there's convenience fees, service taxes. So there's slightly higher cost to transaction as against cash. And settlement is mostly instant or in few hours. When so we'll come out to UPI how this differs. So you have a so UPI is digital by design, but it operates using this open API standards. So where standards are defined between how communication takes place between A and B. So it could be between pair and PSP or PSP and banks, everything is through APIs. And these specifications are out in public. This is more data friendly. So it collects lot more data in a structured form. So a lot of these entities would actually collect a lot more data than what they collect in the other digital interfaces. It has a lower monetary cost. So as in the previous talks, we saw like the switching cost is 50 paisa and that's being absorbed. So it has a lower monetary cost, but it has a high rights cost, which is again hidden. So I say high rights cost because there are issues around privacy, data protection. And it's not just for consumer. The rights is also so the with the PSPs and banks warring it. These are right now. So banks are also losing some of their proprietary rights that they held on the customer to newer payment service providers. Moving on to the settlement factor, it's instant. So UPI transaction takes a few seconds to settle. Okay. So I'm trying to put out the definition of UPI what it is. So there has been some talk that UPI is a protocol and UPI is a standard. Whereas in my view, UPI is a centralized platform, mobile based, built on top of the IMP infrastructure run by NPCI. The open API standards are out in public. I'm not going to go in detail into this, but I mean, I'm not going to detail because it's not there out for everybody to develop only banks and partners can develop. So I have no interest in going through that, but just to broadly summarize each request that you're making is an XML call. You generate an XML and send your PSP or PSP generates another XML and sends to bank. And this process goes on through the multiple hops. So while it's not open fully, some of us can still participate and contribute in development of UPI. So we'll see like how UPI is still not mobile banking. So UPI only solves the payment portion of it and UPI separates UI from back end. So which means that you can install any PSP apps UI and you could use any other banks and it also separates payments from banking. So this was one of the first recommendations of the water report that says that payments should be separated from the function of central banking. That was speaking from more from a regulatory perspective. UPI kind of operationalizes that even before that's the report has been accepted. So then there's also a talk that UPI is privacy friendly. You could create virtual private payment addresses. So you don't need to share your account number and all you just need is a virtual payment address to transact. But there are again questions. So is it like really privacy friendly? We'll discuss more on the UPI buff in the afternoon. And another point I want to touch upon is UPI is there on mobile right now, but should it be also there on the desktop and web? So the way it's there right now on the desktop and web is through the payment service providers. So say through Razapay or some other payment service partner, they integrate with the UPI layers, but should you actually have a native PSP capabilities on the desktop and mobile web as well? And we'll also see what Beam is and the significance of Beam. So Beam is yet another UPI app, but what's so special about it, except the fact that the Prime Minister launched it. So if you consider payments as a sector, they're trying to imagine payments and develop digital payments through innovation and private participation. Just like how they did with the highways. We had national highways for far too long, but 15 years back when the national highways authority kind of formed and they had this PPP model, they formed a set of ways how they built the highways, right? And then you had the concept of tolls. So UPI in my view is a told multi-lane highway built for vehicles of every size. So you could have PSPs which offer wide variety of functionalities and features both to customers, merchant, online intermediaries. So any PSP can offer these wide set of features just like how you have some eight lane highways, some two lane highways, right? So there'll be some big fat PSPs. There'll be some tiny PSPs offering various services, but these are all private PSPs and commercial bank run PSPs. So Beam in that sense is more like a parallel service road, which is like free of any toll. I mean, I'm hoping that it will be free of any toll. And let's say unlike say the other PSPs, NPCI won't sell out the data that's going through Beam. Beam is also minimal in design and its features sets are restricted to the basic functionalities of UPI. So it's the, and it's by choice because NPCI again can't actually have its own app while the other banks are also having their own app, right? So because that creates a conflict of interest. I mean, already there is a the platform, the creator is also acting as a platform player, right? So that's, that might be unfair for the other platform players. So that's why they have lower transaction limits as against like 20,000 per day as against one lakh on your any other UPI app. You pay, Beam is also supported over ESSD. So we'll touch upon this deep linking specifications. So as Rahul was mentioning in the earlier talk, so they're doing one click to FA, right? So what does one click to FA means? So you have a deep link concept in UPI, which lets you create a link payment link. And if you click that link, it will open up an intent handler on your mobile device. And that would directly prepopulate the values of the payment onto the screen. All the user needs to do is just to enter a pin and authorize the transaction, right? So the deep link specification is out there. And so a deep link looks like something like this. So it's a custom URI scheme. I say UPI pay, pay account is logic at access bank and pay name and then transaction note and then amount. I mean, there are also the entire specification talks about a huge set of parameters, including merchant integration and a whole lot of other features that could be used for including for online micro payments. But so this is exactly the minimal representation of a UPI deep link. If you put this link, if you generate this link and create a QR code out of it, all the UPI apps which have a scanner in them can scan this link and it will raise UPI intent and that would open up a list of apps that the user has. And that would open up the authorization screen. So all the user needs to do is either scan and pay or click or pay, click and pay, right? We'll see. So we built a QR code generator here. So all you need just need to do is since the specification is out, all you just need to do is enter your name and VPA and say create QR code. So this creates a QR code. This wins can't would make a payment. And so one of these things since the specification was open, it's very easy to build such kind of hacks. So this was purely done on JavaScript mainly to factor in privacy reasons. So I don't collect any of the VPA. If you enter on that page, that gets rendered on your own browser. And the one thing that I also did try out is try localization over here. So when it comes to digital payments, the apps are slowly would be realizing that if you don't localize, you can't scale in India. So beyond the first 100 million users who are English by education, if you want to scale beyond that, you need to go local. And the I use this wiki media jQuery it in plugin, which helps localize. So it's something like you just choose the language, and it changes. Right? So this essentially the localization has to be a key factor. If you're a developer, if you're a product startup, which is entering into paymentscape landscape, you should consider localization. And there are enough technological support that is available, some of which is maturing. And but that's important if you want to scale. So we'll also see briefly on UPI comparison metrics. So as I was telling, there's a lot of apps, right? So there are some 30 apps, 38 apps that are there. So how do we differentiate these apps, right? So there are common set of features that are available across the apps. And there are also some niche features, right? Say for things like example, like multiple VPA, right? Some of the apps allow multiple VPS. Some of the apps don't allow multiple VPS. One of the unique factor I figured out in this whole exercise of installing some 15, 20 apps on my phone and figuring out what all each PSP does is that Punjab National Bank, I think they have a feature called as one time and time bound VPS. So this is more like you create something like your one time credit card, virtual card, so you just create for some transaction and then it gets destroyed, right? So they have something similar on the UPI front where you create a virtual payment address that's only used for one time, right? So there are a lot of these factors are creates possibilities of having each player having their own small little space where they can be having their own USP's in their product. So which is why it's important to actually have the comparison metrics, right? So a user can actually know that this is my requirement. I'll choose this app instead of just going on. So some of the narrative around the UPI apps has been like the app with the best UX would win. I mean, UX is just not one of the key factor, but UX is not the only factor, right? So there are many differentiators among these apps and our initiative is to actually understand these and see what are these differentiators and how can a customer know before choosing an app, right? So right now we just have this some crazy Excel sheet. We should probably move on to something like a cool dashboard where you can do a price compare something similar to how you have a smart, my smart price for e-commerce, right? So you compare different e-commerce sites with the prices of a commodity, right? So you should be able to compare different apps. All of them are UPI apps, but on different feature sets using a dashboard and you could arrive at your own app, right? So some of this we also extracted data from the App Store, right? So the Play Store gives you a lot of data. So I used an API of Play Store to get these data, like what these apps actually have. And they have, so they are the primary intention was to get the permission footprint, right? So each of these apps can have various permissions, but there are also a lot, a lot other data like Play Store rating summary. All these things can actually help you compare apps across different parameters and not just UX, right? So the other thing that's important to know about these apps is you can actually, if you study these apps, you can know what technologies these apps are based out, what are the third party or open source libraries these use. And this could be not just as an academic activity, this could also be used as a security indicator, right? So if a particular app uses a particular technology and if that particular technology has a zero-day exploit, and if your PSP is sleeping for three months, you shouldn't be using that app because you are vulnerable to security issues, right? So aside from all the other comparison metrics, right? So imagine as a developer, you can measure the technical debt of a payment app which you want to use. And you might be totally comfortable even in using an app which has only basic features, but it's probably technically update, right? And when all things are same, we can probably do the WIM versus EMACS thing, right? So then I'll move on to UPI platform bugs, right? So UPI was launched in August. So it's still a child in terms of the maturity, right? So there are a lot of things, the rough edges are still being worked out. So we are trying to set up a common bug tracker for the UPI security issues and issues that users are facing up because these are some of the things that a large number of users would face and if not reported at the right forum, that forum where, say, the NPCI developers actually look up, then there's a chance that this that could lead to a risk, right? So some of the issues that we reported are in the earlier stages of the UPI app world, so there is no interoperable QR code. So apps were having their own little QR code which kind of destroyed the original intention of UPI to be like a seamless interoperable world, right? Because the purpose of QR code is to actually have a common QR code which they put out a deep linking specification, but then apps went ahead and created their own little QR code and supported only that. And there was also an SBI onboarded UPI, there is Mastro, users were unable to set their debit card, M-PINs, so that was documented. And we also documented a lot of UPI specification violations. So UPI specifications is pretty deep in what the requirement of any UPI PSP app should be, right? But not all apps have actually complied with all those things. So in, for example, even the QR code handling, right? There are 10 different apps which behave in 10 different ways, defeating the purpose of the standard, right? So we've kind of documented those and currently NPCI is planning on certifying these apps. So the certification should actually take care of these inconsistencies and the user experience on the specifications should be in line with what UPI actually says, right? And the, from a consumer point of view, like the other big worry is there is no documented dispute resolution procedures, both say between PSPs and banks, which is what is playing out with phone pay and ICICI. And in between a customer and a PSP or a customer in a bank, right? So I've had two of my UPI transactions fail and I did raise the dispute in their UPI app. Some of these, like I did get response from all the PSPs, but the other PSPs I never got a response back. But I did get my money after a week, right? So, but it's still, it's not good. Like if I actually, the potential of this is I can actually transact up to one lakh in UPI, right? So if what if that one lakh transaction goes out for a week and I lose out on the interest, right? So, and there's no proper dispute resolution procedures that are set up yet. Maybe once the water recommendations get accepted mainstream and there's a proper regulator, I think things could improve. Okay, so that is around UPI. And I think for UPI related specific questions, there is a BOF there in the afternoon. So we will have discuss A to Z of UPI and we'll be happy to answer any questions that you have on UPI with whatever I know. So, but cashless consumer is not just about UPI, right? So UPI is only one of the payment instruments, right? So there is the internet banking. And some of one of the questions in the audience was like, is there a competitor to UPI, right? M visa kind of comes close, although it's not very direct competitor, but M visa is probably something that shares some amount of UPI features in it. And then there is this Adara enabled payment system. That's an entire giant payment system in itself and could also even potentially swallow UPI when it's getting launched full fledged, right? And then there's wallets and then the old cards industry. So we need to work on seeing like how these different payment systems work and from a consumer perspective like what how these are and how consumer friendly these are and getting to know these systems and is important. And as Malika was telling in the previous talk, now NAFT and RTGS might also open up, meaning like there could be prior participation and it could be more developer friendly. And there are also systemic payments like automated clearing houses. They may also open up in future, maybe like say at least five to 10 years. It's important for us as consumers to understand these systems, which we use in one way or the other, right? So ECS goes through NASH, right? But what do we know about those things? There are already tons of information that's available out there. Our endeavor is to just kind of academically learn these things and then see how it can be made better for the consumers, right? We're also interested in learning about blockchain and Bitcoin related or any emerging payment technology trends, right? Which and then inform that to consumers so that consumers are aware of these systems, both their pros and cons, and they decide upon what they prefer to be the best, right? So you can't just say that no, stop using wallets use UPI, right? You have to actually tell what all the merits and demerits of each and let the consumer decide for himself, right? And we're also some of us are fanboys of open source and open data. So we can also look out areas where free and open source software can exist inside this payment technology ecosystem, right? So why? So most probably these systems payment technologies are being designed either by payment ecosystem companies or the banking companies and consumers probably coming towards is probably not factored much in the design of the systems. Like nobody asked before putting the OTP in place, like would you like an OTP? Nobody asked you as a consumer, right? It's mostly the regulators and banking system providers. They come in and say that no, now we need to identify transactions. So we put in OTP without asking the consumer. So how can we put together consumer perspectives in the design of payment systems itself so that like we don't need to go through the pain of having a system that's not convenient to us, right? And also consumer protection in cash as well because aside from the consumer protection that's out there already in the economy, cash is actually opens a new box of firms including like privacy data protection and it could lead to situations where people owning this data could price you differently, right? So we've seen that in the case of say Uber or dynamic pricing in one way can be termed as offers in the Uber world, it could be termed as surge pricing. So how do you actually fight surge pricing on your groceries, right? And the other intention is to simplify the technical complexities behind these systems. So a lot of these systems, they do have a fair amount of complexities in them and those complexities are there for a reason, right? Be it security or regulations or whatever. But those need to be simplified for the user and say that this is what this was intention and this is why it is like this, right? And also the choices with complete information. I say complete information because each payment ecosystem provider will say like I'm the best, like they won't say what they are not best at, right? So we have to kind of have a platform where we neutrally analyze and put information at one place and let the consumer decide, right? So how do you choose between hundred different payment systems of apps and of varying size and features? So as I said, like there and then there is also the opportunity to building and participating in the design of payment systems. So more specifically on the participation, we've seen like there is now an ability where someone like me who's not outside is an average consumer can actually report issues to people who develop UPI, right? So this is probably not very fairly simple in say the cards world or the net banking world. All I could do is probably have access only to the bank, right? Now I actually have access to the developers of these systems, right? So I can also participate in the design. As a consumer, I can participate in the design of these systems. And with free and open source software, we could also potentially build these systems. If payments is just a function of building technology for switching, then there could also be a chance that we could build a payment solution for ourselves, right? So I think no dollar will talk something around that area. But so there is a chance of building and participating in designs of systems, right? And the other thing is organize consumers as a block and impact policymaking. So typically the other players in the system of policymaking are actually an organized block, right? Be it a payment system providers or startups or developers or banks. So they are all having an organized block and representation in policymaking, right? That is consumers need to actually have that organization to actually have a say in the policymaking, right? So let us the other aspect. So the four aspects, awareness, tech, data and policy. So on the awareness, particularly on the demonetization during the time, we had onboarding kits for customers. There's also need for ethical cashless evangelism. So to people who are new to this cashless, how do you actually tell them that these are pros and cons of cashless before actually just installing them an app and asking them to go cashless, right? There's also need for merchant kids educating people on basic security practices and all these things have to also be available in their own languages because beyond the 100 million, people won't understand these. And in order to contribute to the systems and policies, knowledge of these systems is actually key. So that is why like one of the projects is to kind of understand what UPI is in greater level of detail, right? So study payment technology APIs, study the security designs of these systems. There's an interesting UFL study on mobile apps and banking apps. And they kind of studied in detail about the encryption technologies and things like that, right? But are we doing the same thing for our apps that we use today, right? Some of us know technology and can we try and do that and see like ensure that this technology that is being built around our safe and secure, right? Decompiled payment apps. I think a lot of people have already started doing it. Nemo has done decompiled beam and pay PTM. And we can actually get interesting information when we decompile these apps, right? And give feedback to developers of these systems, right? So know your app. So I said from just knowing the app metadata, so there are some things that you can actually know in the app metadata, right? So there are things like what I call as app vintage, right? When was the app last updated, right? So there are apps which have been updated, which have never been updated since the UPI launched launched in August, right? So it's been like four months that the app never got any app update at all. Like can you afford such an app to be your payment? Can you trust such an app? Because in this day and age where security issues do prop up time and again, can you afford apps like that? So app metadata can actually give you a lot of these data as well and which will again be helpful in doing a comparison between apps, right? And terms of service decoders. So we all signed up email, Facebook and all bypassing these terms of service. But when it comes to payment apps, they literally deal with your money and there are these crazy terms like saying irrevocably and unconditionally allow access to any third party, all the information in its position, right? So there is a nice website called TOSDR that does decode this TOS into common English Parallels, but they primarily do it for the Google, Facebook and all the websites. But probably we need to do it for our own payment apps that are there right now and we've been using, right? So using tech, we can generate more open data tool sets, visualizations and develop fast layers inside the platform ecosystem. So fast also brings in like security, transparency and accountability by default because things are open. And we'll also briefly talk about can communities run their own payment systems in the UPI buff. Like the community can community run PSP can actually value things that a commercial PSP need not, right? And it also helps in avoiding platform and device colonization. So till the time the systems are actually truly open, like we have UPI which is following open API standards, but they are not truly open because meaning they won't allow you and me to actually build for UPI beyond the level. But till the time that is there, we should probably be still understanding these systems trying to build fast layers or tools wherever we can. And some of the examples could be like payment generator, link generators, QR code generators, API wrappers and shared boiler plates, right? And so the other aspect that we also are keen about is data, right? So cashless is also less about money and more about data. So how do you measure data footprints of each of these apps and systems? And moving on to the privacy and data protection issues. So what are the different data ethics? Can somebody actually price you out based on your own data? Right? So how do you ensure consumer protection in that scenario where they have they intensely create the information asymmetry by design, right? So there's also another area where we can generate open data about the system. So much of these spreadsheets that I have shared are all data that's out there in open, which is there for anybody to use, right? You can generate data about these apps and payment systems. And there's also need to seek open data from these players, right? So just like how try today has a detailed data on the mobile speeds, internet speeds, QoS levels, the similar things can also be done for payment system providers. Like you can actually have ask these regulators, stats on dispute resolution, QoS levels, uptime and performance and things like that, right? And you can also help visualize this data and see like help in data driven policymaking, right? On policy, there's also need to decode the policy proceedings, right? So there's this water report. So much of the mainstream media has largely not covered this in full detail. But then there is a need for us if we want to be, if you're developers or if you're interested citizens involving in policymaking, we need to know, have the information about these policy recommendations, right? And sometimes these policy documents are too hard. Like they are literally like your insurance policy documents, there's too much of legalese and jargons and things like that. So how do we break that down to consumers? So like organize pieces of information around policy. And so we've also collected all the public, listed all the feedback that was sent. So CIS and IFMR had sent, I tried putting around my head and reading through these 200 pages and came up with five page feedback, which is probably very naive because I'm neither a legal person nor a policy person. But still, if we can enable more and more people to actually give feedback on the policy proceedings, right? So help them help more people participate in the actual governance and policy things. And this, if we do that, those will all just by default will be focusing towards consumer protection, right? So about us, we are volunteers interested in open source, open data and privacy. All our work is freely licensed under FOSS or Creative Commons. You can join us. And we do have a lot of things to work out. So this is, although I know we shouldn't be making hiring pitches, I'm not technically not a startup or a company. I'm just a volunteer initiative. So I'm actually calling out people who can help with this. So if you're interested in knowing more, feel free to reach out and Q&A. Thank you. Thank you very much, Srikanth. We have time for about five minutes or so of questions and answers before we head to lunch. So anybody who has questions for Srikanth? Yeah, ma'am. This is second. Somebody get the mic. So pitching again, like there is a UPI specific boff in the afternoon. So if you have any questions on UPI, you can feel free to ask there. Okay, Srikanth, could you just repeat the question for the benefit of those? Okay, so the question was how would UPI work across borders for international payments if that can, it's a right summarization, right? So UPI in its technical specification also has actually factors in currency. So theoretically, if the central bank or another payment company or let's say there is NPC of Sri Lanka, right? If they also implement the same UPI and their banks also form the same, use the same infrastructure, theoretically, there could also, your UPI could also act as cross border payments. But I think those require a lot of implementation because, and also between agreements between the countries and countries and their banking institutions, right? Do you, this is a question regarding BIM. Yeah. Do you think the banks knew that BIM was being developed? That's a good question. So while the UPI specification actually talked about something like a common app being developed, probably the demonetization paced it out too soon, like it was launched too fast. But I think something like BIM was always on the cards. But there's also this thing like NPC also talks about opening that layer to individual developers as well. So potentially tomorrow you and I can also write our own beams. So that has also been documented in the UPI vision document or things like that. So banks probably did know, but probably they didn't know that they would come too soon. Anybody else? Yeah, we have a question here. We can't for a good presentation. This is Abhishek here from Preachers. So recently I think Amitabh Khan made a statement that I think by 2020, all these debit cards and ATMs will be redundant. And I think it will be all fingerprint based payments. So recently I think ICIC, IDFC and SBA had done some pilot around AEPS based payments. So did you do some study around that? Yes. So that's on the cards. So since again, as I mentioned on the side, since the bandwidth is limited, I stuck around to UPI. But increasingly there is a chance that AEPS can actually swallow UPI. But there is also a chance that they both could still coexist where AEPS would still be used for identity based transactions. Maybe your person being present would be driven through AEPS. Person not present would be still driven through UPI. So there are things like that, but those things are still being worked out. AEPS itself is still maturing and much of the information is still not out there. And with whatever this we've done through UPI is possible because the apps are already out there and there is tons of material on UPI out there. But that same is not true for ADAR. And this is also the other thing that ADAR is still exclusionary. I don't have ADAR. I can't study ADAR more in detail as I don't have ADAR. Whereas there is no barriers for that in UPI. We have a question right at the back there. And then we'll come to it. Hi, I'm Dinesh. You mentioned that there should be a lot of open-source software which should be part of this. But two things. One is what is the current state of the open-source software? And also looking at the perspective of security, is it good or what's your take on that? I think the answer on the security is probably easy. We've probably been used to use open-source operating systems itself for two decades or three decades right now. So I think open-source brings in more eyes so it's more secure. And those arguments are fairly mature enough. On the current state, on these systems which are coming up newly, there are no open-source softwares right? But there are other systems like Nootaller is one. There might be other systems that could potentially come up in open-source software which will also target the same audience. And then there is the whole Bitcoin world which is completely open-source. It's a world in itself. I am not going into that. Yeah, the man in the red shirt. Hi, my name is Venki. Quick question I think is a follow-up from the one for international transfers. UPI, is it integrated with Swift? I think in your example you mentioned the bank would need to implement the UPI infrastructure and stuff, right? Wouldn't it be easier to kind of get out to Swift or one of the existing networks in that case? It could be. But that's again more of a business or a commercial decision to be taken by NPCI and things like that, right? And that's not probably where we have a say, right? It's up to the institution that operates this. And maybe like if Waterloo report comes enforced fully truly and it encourages competition, maybe Swift itself might come to India and operate something similar to UPI and offer international capabilities as well. But those are more of commercial and trade agreements later things, right? Yeah, we had a question of here. Yeah, this does work here, here, my uncle. Yeah, then that would be good. Hey, Shirkan. This is my uncle from Luma Queen. I remember we were speaking earlier about semi-private nature of UPI and you were telling me that there are some concerns on privacy and security of these transactions because a user identity is not completely exposed to the banking system. Is that correct? What is the way forward for it? And have you received any more clarity on this? Okay. So this UPI or the VPA is being truly private is still a sort of myth because banks still know the underlying payment addresses. So they actually know the account number. So I think Rahul was explaining that in this talk where banks can still know the actual account numbers through which the transfers are being made. So it's still not fully private in that world. And there is also another risk more specifically on the citizen front if you consider privacy. The risk is that your UPI is tied to your bank account and your bank account is tied to your Aadhaar identity. So and all these entities, all these pieces of data lie with NPCI. So from a user perspective or a citizen perspective that creates gives you a privacy risk, right? Hi, this is Sandeep from Easter Egg. I just wanted to know if you guys are working on anything related to blockchain or Bitcoins from an open source standpoint. Also, what's your take on the POC that was conducted by RBI and NPCI where they did a transaction on a blockchain? So I have not done anything on blockchain or Bitcoin. So on the POC, it's true that banks are actually now interested in developing blockchain capabilities. And even Water Report talks about RBI, central bank issued cryptocurrencies, right? So but that's probably still a decade away. And but when that comes, it probably would help fix some of these privacy concerns. But we still need to know how that's getting implemented and what exactly because blockchain by default does not offer you privacy, right? Okay, we'll have one last question for the before we break. Yeah, hello. Hi, this is Sarabhair. I'm product designer at Razor Pay. So UPI basically relies on for transaction UPI relies on VPAs. But there is no sort of restriction that what you pay one can get. And it's very easy for someone to spoof. As an official person say someone can be like ptm at the rate ypl ypl and they can be trying to like do fraud transactions. So any thoughts on how to stop it or regulate it? So the easier way is that people no longer actually manually type these addresses, right? So that's either people use the QR code way to get the address or people click on links. And increasingly, that's going to be the digital way, right? Because if you start entering, there is even a possibility of even a typo or things like that. But if I'm running my ptm site, I would probably give the official VPA hard coded into that. But I agree, there's still a possibility of ID spoofing and things like that. What if somebody does a man in the middle attack and changes the address and things like that? But that's a larger security issue, I think. But maybe a verified handles kind of solution is also possible, but those things have to be evolved. Like UPI still not matured that enough. Okay. Thank you, Srikanth. I think we had a very entertaining session on how UPI works for the consumer. So we'll now break for lunch, I think. And we shall reconvene here at 145. And we'll have the next session starting then. Thank you.