 Hello everyone. Thank you for joining us here. I am Srikant, part of CASTUS consumer. Welcome to the first of the webinar series that we have planned on all things payments and fintech. For those who are new to CASTUS consumer, for those who are new to CASTUS consumer, we are a consumer collective who are interested in tracking all things digital payments to increase awareness, understand technology, produce consume data around represents consumers in the policy of digital payments ecosystem, twice consumer perspectives and concerns the goal of moving towards a fair CASTUS society. You could read more about our work on our website www.castusconsumer.in. Some housekeeping comments before we get started. Please use the Q&A on this room if you are on Zoom or post your questions in the YouTube chat. We will get them answered towards the end of the talk. So today's webinar will look into the IFSC toolkit by ReserPay and we will discuss how developers can make use of this IFSC data using the API the toolkit provides. We have Nemo, Alice, Abe Rana, maintainer of the open source project behind the ifsc.reserpay.com. To talk more about it, I will handle it over to Nemo. Hello, everyone. I'm Nemo. I do take into clarity things at ReserPay. Today I'm going to be talking about the ReserPay IFSC toolkit, but in general about IFSC codes and how they work, what's the history behind it, and the various kind of internal things that you may not usually get to hear about or understand just from a consumer perspective. As users, you've used IFSC codes for making payments to add a beneficiary or by making a UPI payment even, but how does that actually work and what's the underlying text behind it and what does it get after it etc. I'll go through all of those things. The starting point is the IFSC toolkit that you released four years ago. This is the page as it looks then and that as it almost looks now. We pushed the blog post out telling why we built it, but the primary use case is the addition of IFSC codes. So before we start, since this is all about IFSC, what does IFSC stand for? The obvious answer would be it's a banking code, so Indian financial, something, something, C4 codes. As it turns out, there's another IFSC code. There's another abbreviation for IFSC that RBI has published recently, creating something called an International Financial Services Centre. RBI is trying to create a special economic zone of some kind, which basically provides incentives to financial companies and banking companies to set up their presence within India and support international finance in general. That's also an IFSC. But yeah, today we're not going to be talking about that kind of IFSC. We're going to be sticking to the Indian Financial System Code. Can I switch it to full screen? I think the green line is because of room, but I think that's fine. You can manage. So we're going to be talking about the Indian Financial System Code, which is basically the IFSC code as you know it, or this is how exactly we identify banking branches in India. So we're going to be splitting this talk in roughly three parts. First, I'm going to be talking about the project, what it does, what it's about, how we maintain it. Second part is going to be about addresses in the background in terms of what all goes behind the scenes, how are they maintained, what are the RBI do, what's the role of the NPCI and so on. And third is going to be future scope collaboration ideas in terms of how we can in general build better APIs, build better open collaboration systems in India. Okay. So some metrics we've been doing this for four years, first release on insect 2016. It was an internal project before that. We have had 64 releases, 64 plus releases since our 72 hashtags. Multiple languages, 7,000 lines of codes. Not a lot of it is actually code. A lot of it is just data. And the primary use case for the entire tool creators data, having an open public data set that supports validation that lets you know whether an ICC is live or not. One of the things that I'm most proud of is starting from the number of releases, number 2016 release. I started adding little photos of cute animals as a release to make the internet a cuter place. And as a consequence, if you go ahead and search for an ICC code today on Google image search, these are the kind of photos that show up. And as a consequence of this, I can present to you now the ICC wall of cuteness, which is all the cute animal pics that we'll show up if you search for ICC codes on Google image search. If the slide's long behind, please let me know. Okay. So coming back to the CS side of things, what is the toolkit? The primary part of the toolkit is an API that is served publicly at ICC.RacerBeta.com. The primary use case for the API as of now is validating ICC codes. So if you're building a service which requires a user to type in an ICC code, and you want to fetch in details or we want to validate, you can use this. There's a data set to the toolkit, which is published as a release. It's a moving data set, which means every release is generated from scratch. On top of this, this data set is present in multiple formats. The data set includes all the things that you would expect from knowing an ICC and getting more users about it. But on top of just consuming and providing ICC codes, you also provide data around banks in general. On top of the data set, there is an SDK, which lets you do all of these things via code. So you can validate your ICC codes. You can make requests to the API. You can do offline bank checks. You can get additional information about a specific bank and so on, all of this in code. And all of these SDKs are available in multiple languages. There are a few folks that support additional languages. We are trying to update them. So yes, that's the data. What's the family source? One of the guiding principles behind making this was finding out the official sources and ensuring that all of those are directly used as this. If you search for ICC codes in India, you will get a lot of third party sources on the internet. But none of them actually document where the upstream data is coming from when it is getting updated and so on. So one of the use cases and one of the guiding principles was to ensure that everything that we are using should be a public data set. That's easily available. And making sure that the rest of the pool is open so you can reproduce the same results. So the family data source is the RBI website, which provides an Excel sheet for two data source, which is the NEST and the RTTS data sets. Both of them include details about various branches of India. Both of these includes details about each and every branch within India of multiple banks, all the banks that are registered with the RBI. There are any of the details and all the RTTS details. Any of the RTTS just as you may, I'm sure, everyone knows the difference. But in general, if you're trying to make higher amount transactions, you have to switch from any RTTS to RTTS, which has different limits. NPCA also publishes a checklist that we consume on the primary source as the all live ACH member banks list, which is the NCH member banks list of all the member banks in the NCH network. This list includes a lot of details about various banks, such as their primary access code, which is important for certain use cases. NPCA also publishes a list of all the UPI live member banks, which is basically the list that you see when you open any UPI app and you try to add a new bank account. There's also a list of NBI end codes, which we'll get to later on, which was published in the INB of visual guidelines 1.7. These are the primary data sources we use. But we're also open to using other data sets. So, for example, if a bank has a specific data set, for example, the SBI website has its own list of you can go to the SBI website and type in a few details about the bank branch and get more details about it back in return. And it turns out that some of the details mismatch against what is published on the RBA website. And because it's the only state website, those details are sometimes more accurate than what's present in the RBA site. And as such, we try to do an amalgamation of seeing which is the better data set on such basis. So, yeah, in any other sources, we use RBA circular in terms of RBA publisher circular saying, hey, this bank is now calling that and that, or some of the banks are being merged, some banks are being shut down. Any procedural guidelines that we show from RBA in terms of RBA being shut off on a few banks or any other public sources on the LPC website itself. And a few specific RBA circular that's become RBA. So, yeah, what's the data? Once we consume all these data from different sources, the idea is to publish a singular data source you can use as the source of truth for any of the use cases that you have. So, this is a list of all the files that we include every release. On the primary, the first one is the Bankster JSON site, which is a list of all banks in India, primarily based on the NPCI-ACH list. But we try to add in additional things as well. So, for example, the UPI support over here is published on a different page and re-merge all the statistics. This is how it looks like. For example, for the SBIN bank, we know where the bank code is. We know we get a bank type. I'll get to details on this later. We get a primary IMPS accessee. So, in case you want to know what the accessee for the primary bank branch is, usually the head office branch. This is provided. The MICF code, similarly, again, for the primary bank branch. The IN, which you may also have heard of as the BIN number for a bank. This is the first six digits of the primary issuer number for the bank. So, a bank may have registered multiple INs. Since these are coming from NPCI, these are the UPI INs, usually. Whether or not the bank supports other payment system. So, that's a true work flag. A few other flags. And, finally, whether or not the bank is available on UPI or not. So, this file itself gives you a lot of data corresponding to all the banks that you're aware of. Currently, 1,400-ish banks, saying what all is supported on a bank, what kind of bank it is, and so on. Finally, the next file is a BI bank file, which provides various details about all the bank branches of a specific bank. This is basically the data that we actually publish on the final API. So, if you were to open fse.databank.com. This is the response that you basically get from here to here. It tells you what the bank name is, what the FSC code is, what the branch is, because you're referring to a specific branch, what's the address, if you have a contact number for it, and what all, whether it supports INPS, RTGS, and ESD, and whether we have an IMSC or code for the branch. I'll get to more details later on what all we does what. But it gives you, basically, it just shows what all are supported on a specific branch, what are details. So, this API also supports, of course, in case you're using making a front-end only app, you can actually just make a direct request from the browser to this end point and get the details and pre-fill these for your customers, for example. This is what we do, for example, when a merchant shows up on our dashboard and they fill in the details saying, hey, this is my FSC code, and we pre-fill all these details, the branch address, etc. And, for example, if you have certain limitations saying, if you're pushing out your transactions or if you're pushing out your remittances to these specific and branch-wide IMSC or FDGS, or any FD, then you can disable-enable quantities. You can say, you're giving me an FSC code, but that doesn't support any FD. I'm going to make a transfer on an FD as such. Just as a match, please provide me a different FSC code. We publish a single list of all the FSC codes. So this will be basically a link, huge JSON file with all the FSC, no FSC codes. We publish the FSC.cse file. This is a single CSE file containing all the things. All the fields are basically the same as for here. So all of the things on the left over here become headers. And this is a fairly large CSE file. The use case for this family becomes, because there are three different data sets that we try to cover. We are covering NSD, RDGS, as well as IAMPS payments. And having a single unified CSE file makes it much more easier for anyone to consume things. We publish a single FSC.json file. This is the one that is the primarily used for validations of all FSC codes. So if you have ADCC as the branch, it provides you a list of all the possible branch codes that are supported. In this case, we support ADCC 0.0.0.0.1 to ADCC 0.0.0.16, which is this list. All of these are valid FSC codes. FSCs in general follow a standard format. So we go with four characters of the bank code, which are all alphabetical, followed by 1.0, which is itself as of now, followed by six alphanumeric digits. There are actually some places on the internet where you will find, you know, you try to enter an FSC code and they do not take an alphanumeric value as the last six, but it's not as for the standard in general. FSC codes as well as account numbers within India everywhere should support alphanumeric values. We also publish a bank names.json file, which is basically a manually human curated list of all bank names. This is very helpful when you have a UI to build and you want to show a user a list of banks. And in our system, for example, when there are empty users everywhere, you have a specific format to code and you want to showcase a list of bank names. This is what we use. And we ensure that the list is as human readable as possible. So even though we take in data sets from multiple sources, where they may have confusing names, or where they may have redundant names, for example, you may often see Chamba, Urban Cooperative Bank, Parma, Chamba, or you may see places where cooperatives spell multiple ways and so on. So we have a single curated list, which makes sure that all the bank names are written down in the same manner so it's easy to consume. The API itself, once again, and this is how it responds, similar to how it's shown if you send a request to our database, it will give you all the details including branch, center, district, state address. Some of the details are not available for all SSC codes and that's just a consequence of merging different data sets. So we either put an NA for those cases. In some cases, we won't have, for example, the app might see a code and so on. But yeah, that's just how it is. This is how it usually works. You don't need to understand code, but in general, we support the same things across multiple languages. So if you want to validate an app's SQL, the important thing about this check is it happens offline and it is a much more better check than what you may have seen in other places. For example, if you try to validate an app's SQL, and I've seen Regix, you try to do this by taking the first two characters and saying, hey, are the first four characters alphabetical and if the fifth character is zero, then yes, they mark it as a valid SSC. But unfortunately, that's not true because SSC codes get retired, they may have blanks. Just having a four-character valid code does not ensure that SSC will desalate. For example, ATM00001 is a valid SSC, but ATM002 is not. Two is now, I think, but five is not, for example. So it differs. So with this check, however, on the other hand, make sure that the SSC code is actually valid as per the latest data set that you have currently installed locally. So I have a question from someone asking, yes, this is an open source dataset. All of this is there. If you go to ffc.razepay.com, you should be able to get all the links. So we also support things like getting a bank name from a specific bank code. So if you do, I'll get a name for PUNB, all these happen offline. We also support constants, which is, if you work in FinTech, it makes things much, much more easier for you because you're talking to specific banks very often and makes things much more easier in general, having a constant to refer to a specific bank across your entire code base. And if you want to get details on the certain habits offline, you can get details of a specific bank and see all the things. So if you want to get the SSC code for a javascript bank in general, there's a way to do that. Finally, you can also do all the internet lookups. The lookup of course happens for the internet, makes a request to ffc.razepay.com, gets back all the details that you would want. And again, all of this is supported over multiple languages. So you can do a validation and load. You can fetch details from the internet, have constants and load. And similarly, thanks for Ruby, etc. We also support, and there's a support matrix currently, what all features are supported across the SDKs. So there's some different level of supports, but the primary use cases, which are validation and the API client, can you validate it with an SSC code? And can you fetch details given on SSCs or get things like contact or address of a branch? Those are primary use cases we try to support across every SDK. This is a chart I made a while back, not highly accurate, plus minus 5, 10%-ish. But in general, this is the code chart in terms of the number of SSC codes on this across every release, broken down by release date. But in general, it's a slowly rising chart. I think we have crossed $255,000 now, but depends on what RBI is doing on a month-to-month basis. These releases happen usually monthly from the RBI. That is when we try to do more releases. We try to follow the RBI guidelines, and whenever RBI pushes a release, we push out a new release as well. So, plan learnings. When we started this project, we had a few ideas in terms of where we wanted this project to go. The first was having a polyglot single-drepo, which is basically the idea of ensuring how can we have a primary data source as well as SDKs for all the different languages in a single repository. We've managed to do that. The second was about having an open data superfast public API. BAP is actually very, very fast. It's one of the things that we don't have to worry about maintaining much. It consumes very few resources, and it runs on top of just memory database. It's been really fast and easy and nice. The third was a scapegoat application for random tests, because the SSE API as a source doesn't act stateless for us, which means you can actually play around a lot with it internally, in terms of using it for additional testing or getting it to a different cluster and things like that. This is how our polyglot thing, for example, shows up in practice. The source directly has files from LXS, Node, PHP, lots of JSON files that are used across all languages, things from Ruby and so on. Try to ensure that every single code base exists within the same repository, instead of having different repositories for different languages, makes releases much more easier. There were a lot of unplanned learning as well. This is where I'm going to be talking about how the SSE works in the background, what are the different principles that are involved, what are the different entities that are involved. These are things that I was not expecting to learn. When V10 started doing syntax back in 2015, V10, we were all new to the syntax field, and these are the things that we learned along the way. The first is there are actually too many banks in India. Our current bank manager JSON file holds 1400 plus new banks. If you add additional banks from various other sources, which are currently not on the file, it adds up easily to 2500 plus banks within India. Not all banks are completely recognized by the RBI. It doesn't have a concept. If you want to do a bank in any way in India, you do have to register with the RBI, but not everything is recognized by the RBI with a four-letter code. I'll get into more details soon. But if you add up all the banks, it adds up to a lot. We have different years of banks within the country. On top of the usually banks that you heard of, there are district cooperative banks, state cooperative banks. We have foreign banks that can do banks in India and so on. It adds up a lot. RBI is actually trying to do a lot of things in this regard. They're trying to shutter down a lot of small, cooperative banks, which were not being profitable. They're trying to shut down rural regional banks, which are called as ROBs, and trying to merge them together into a single PSP and so on. This is something that I'm also seeing evolving as how to manage the access codes for the crop as these banks change. There are 11 different kinds of banks in India, which is a lot. This is what you'll get if you click the ACH list from the LPCA website. We have DCCBs, which are lots of different kinds of cooperative banks, district cooperative banks, urban cooperative banks, state urban cooperative banks, district cooperative banks, and the payment banks, you may have heard a lot in the news, things like ATMAs, repayments, and so on. We also have local leader banks and small finance banks. Finally, you have foreign banks, which can be entities that are registered outside India, but want to operate as a bank within India for reasons. 11 different kinds of banks. Finally, you have public sector banks, which are the entities like PNB, SBA, etc. Regional rule banks are the small banks, which RBA started out actually as an experiment in the 70s on the idea that it could make banking much more cheaper and easier for the rural economy of India. The experiment has recently, I believe there was a report which basically said ROBs are much harder to be profitable, and running an ROB becomes very, very hard for RBA to sustain in general. So, as such, they're trying to shut it down in much within PSPs, which are actually doing a much better job of supporting rural banking in India. So, on other learnings, RBA doesn't have much idea what it's doing. This is an easy example. There are two different quotes for Indian Post Payments Bank. Both of them from different sources. Both of them are correct. Both of them are valid. Only one of them has an RCC assigned under it, but both of them are technically IPOS and IPBB. Both are Indian Post Payments Bank. So, if you look up either of them, you get the same response. Very often, you'll see this happen with the cooperative banks as well. So, the way four letter quotes work within the RBA system is RBA is supposed to give you all the four letter quotes. And usually though, if you're a small bank that is not actually connected to the RBA in many ways, you get a four letter quote that's in X. And if the bank actually updates the old record remains, and that results in different contracting quotes for the same banks. Now, you may have assumed by that, you know, AJUX, okay, that's a cooperative bank, small cooperative bank not connected, can't really have that's the general principle you usually go with, because it's not connected to a small bank. It won't have any accuracy quotes. As it turns out, there are actually banks, for example, the Chartered Psychiatry Bank in the Amita, that has the RCC code over the bank code that starts CSBX, but it's directly supported on the IAMPS network. It's not listed by the RBA. So, RBA does not know of the presence of this specific IAMCC code, but it's a valid IAMCC code that only supports IAMPS. So, my mental model changed at this point, okay, maybe banks with ending with X can have an IAMPS, but not RBI mandated things. But as it turns out, there are other banks where this also does not hold up. So, it's more of a thumb rule saying, if you have a bank code that ends in an X, it doesn't have connectivity. But in the case of QEX, which is the KBHANA bank, it has connectivity across RTGS, IAMPS, and AST with an IAMCC code that actually starts with an X. So, RBI doesn't act like, RBI has a thumb rule of thoughts, but it doesn't always necessarily follow it. The other learning which I had was that the NPCA doesn't actually come under the RTN. There's a huge judgment around it last year. The case was taken up by the CIC, which is the Competition Commission of India, and CCI. Around whether or not the NPCA comes in under the public body or not, you can go and read the link judgment. But the code has ruled that, as of yet, NPCA doesn't come under the RTN, which means if you're looking to get certain specific data sets from the NPCA, the right way to do that currently is to actually approve the public authority for the NPCA, which is the RBI or the minister of finance, which is what I've been trying to do, filing an RTN via the RBI to get data sets, which are kind of not public yet. The other learning was around MICA codes. The IFC data set, when we first released it in 2016, didn't actually support MICA codes. I see if you're not aware of it as the magnetic and character recognition code, and this is a nine-digit code that's printed on all your checks, and it's printed with a magnetic ink, which makes it much more easier for automated systems to recognize and pass the check. Other for IFCs, the first four characters immediately give you the bank code, but in this case, because a check clearinghouse works in a different manner. The check clearinghouse works more location-wise than a bankwise, so you'll have a check clearinghouse being run which will cater to different banks within the same city, which is why the first digits are much more city-dependent. Then you go to the bank, then you go to the branch. It was a decent system while it was built to IFCs, but it doesn't hold out because the number of branches and the number of banks are much more limited. But as it turns out, MICR is still being used for various different reasons. But yeah, we have had issues in this, and then people have showed up and said, hey, this is the MICR code, and it's not showing up, blah, blah. Can you fix it? And it turns out people still use it. Next, we have the IVN codes, which are the international standards for how banking codes next work. IVN, in general, the format that is followed is two characters of a nice code for a country. So in our case, for example, it'll just be IN on this check digit, which can be used for validation on an easy basis saying whether or not the number that you've given is correct or not, followed by an account number. That's the standard format that an IVN code has. There was a committee that was formed a while back by the Ministry of Finance to decide how IVN codes within India will work. They looked at a lot of different options. For example, whether we should allow alphanumeric code account numbers, what's the minimum maximum account number length we should permit should we allow the bank codes to be alphanumeric or not, et cetera. And I've linked it over here, but it's a very good read in terms of what's the actual coverage of how account numbers and bank codes in India look like. And ultimately, they fall back to the maximum, which is having support for 18 digits in the account number. And keeping those digits of alphanumeric, because there's a lot of account numbers in India that are alphanumeric in nature, not just normal. So this is the official IVN number structure in India. So if you want to have IVN number, which may be required for routing internationally, in some cases, this is what you can follow. You can take the bank code, which you already know from your FSC, remove the zero, put in the list of your route numbers, and you pad it with zeroes to make it get to 18 digits. The next thing I found out was bank mergers. Bank mergers have been happening quite frequently since I started this. We had multiple banks being merged to SPI. We had multiple banks being merged within PNB. There's also client mergers that don't show up in the normal use, where an RRB will be shut down and be merged to another RRB. I believe this has happened in Dalangana, where as well as Bihar, where the Dukshin, Madhyam, Mud, and the South Dukshin East, there are three different rural regional banks within Bihar and all of those were merged to make a single bank and so on. But you don't usually get to hear about these and how to handle this becomes important as you see a tranche of FSCs becoming invalid and new FSCs showing up. So it becomes interesting. And each bank mergers has to be handled differently. It basically depends on finding out the right source and the right reaching out to the right people and saying, hey, are these FSCs going to become invalid? Are these going to remain valid? In the case of SPI, which is the most famous example, SPI said we will support inverter and base transactions for one month. But the FSC codes still remain valid for a short time. But after that, you need to switch out all to the correct types of things. Daming banks is hard. They're just in the 1400-ish list of named banks that I maintain. There are 20 different ways to write cooperative or cooperative without a dash and lots of different other ways. You'll have different ways of writing the word district in different formats of Zilla in general. The Hindi translation for cooperative becomes and there are different ways of spelling out. And this is fairly problematic because the primary use case is to showcase a list of all the banks to customers. So in case you have a list of bank codes that you want to show where you use it and then seeing different ways of cooperative being spelled or different variations of Zilla doesn't look nice. It makes for a very inconsistent UX experience. So I ended up writing guidelines on how to keep bank names consistent, which basically says you don't want private limited at the end of every bank name and so on. The guidelines are just guidelines, but they ensure that all the bank names are consistent within the data sets that we release. These are the original guiding principles that we had while doing releases. Make sure that the data set is current, which means if an FSC is no longer valid, it should no longer be in the data set. This ensures that if you have an FSC today and it's marked as valid and you're valid today, there's a very high chance that if you make an inbound or an outbound transaction from that FSC code, it should work. The second is keep a list of banks comprehensive and included banks. This is something we realized midway, I believe. We didn't use to support all banks and then we realized there's still a lot of places that, for example, ING Weissher Bank, which has merged to Kotak a while back, it still shows up in a lot of places, both internally, externally, while we're dealing with partners and so on. It makes it much more easier to still have that on our list. Third was only use official upstream sources or make sure that we're directly talking. They're not picking up, for example, some random FSC website on the internet. They're picking up data sets from either the banks themselves or from RBI and TCI and other official sources. This is what I found out about the FSC issuance process. The way it works is when you register as a bank within the RBI network, RBI issues you a four-letter bank code. The four-letter code ends in an X for banks that are not connected to the RBI payment settlement systems. This happens usually via FMS. In case you're not connected to it, which is the case for small digital banks, recent banks, your assigned four-letter code will end in an X. There's an interconnect system between various banks in India called FMS, developed and built by RDBT, which is basically the technology ring of RBI. Using FMS, basically, different banks in the country can push out a release, push out an update to the RBI, and then RBI collects all of this and publishes the final data sets into their website. Independently of this entire process, banks can inform in BCI of each and every FSC they have via LSS, which is the next financial switch. They have different other mechanisms for different sources. For example, with UBI, UBI it only has this registration thing happening for each and every bank when you get onboard, you have to provide your handle, and the list of handles is present over a metadata call and so on. But basically, each bank can inform in BCI, independently of whatever RBI has issued them about each and every FSC they support, and issuance within each and every branch code, which is to say that given a four-letter code, everything that happens underneath any FSC that starts with those four letters is basically owned by the bank, which means only the bank is responsible for whether or not it's valid or not, or whether or not it supports IMPS or any of the and so on. Having this system there is, you know, the RBI issuance process is independent of the NPCI submission process. Makes for interesting mix because you'll have cases where an FSC code can have IMPS enabled on it because that is what the bank has submitted to NPCI, but that FSC code is not known at all by RBI because that was never submitted to RBI in general, and it makes for like a disconnect, and sometimes you'll have the same branch with multiple FSC codes, and the bank may declare it as a headquarter branch back at IMPS, which is what they have submitted to RBI, versus they'll have the same branch submitted with a different FSC code under any FSC and so on, fairly common. There are also lots and lots of different codes, which are just FSC. Different FSC codes exist for NPS and NSD. They're usually the same, and again, for some of the cases, they will be the same, but in some cases, they may be different, and depends entirely on the bank because the bank owns it. Amicia codes, as I mentioned, are what gets printed on the checks, and they form by a city bank branch code, three digits each, or numeric. Then you have the SIFT, which you may also have seen as being referred to as the NBAC codes. They are the international inbound transfer codes under the SIFT network, so if you're doing international wide transfers, this is what your bank, outside the India, will usually ask for your SIFT code. Then you have the IN codes, which is the standardized way of referring to bank codes. They may or may not be the same as SIFT code depending on your bank. Then you have the NBIN codes, which is the National Bank Identification. These are basically four digits numeric codes that NPCA came up with timely because of how NPS was built. The way NPS works is everything within NPS tries to be as numeric as possible in order to ensure the roots of NPS, which are to ensure wide-based payments. Doing all of those is much more easy to see everything as a digit. Unfortunately, the actual existing SAC codes all have SIFT numeric, which makes it much more harder to be used within mobile phones, which is why we have NBIN codes, just four-digit numeric codes for every bank within India. The NBIN codes get consumed within NMIDs, which you may have seen while trying to make NPS transfers. That, again, has this own format where they try to make up NBIN with a mobile account selector, which gives you the final actual seven-digit NMID. There are lots of different ways of referring to a bank branch of pointing out an account number within India. I also don't have lots of idea about what I'm doing. I've learned a lot of things as I went along. For example, the NBIN format was something which you had been trying to decode for a long time. I've had a lot of attempts trying to collate with the remember the digit codes that you saw on MICO codes. I tried to ensure that they were matching in some way or form, but it turns out they don't. I've tried a lot of different things over time. Some of them worked out, some of them have not, but I learned a lot. NPC also doesn't have much idea what it's doing. There are a lot of UPI handles, for example, that are actually currently unknown. In the sense, the issuing bank behind these handles is unknown. As you go to the UPI NPC website, there are two different places where they have a list of all the banks that support UPI, which is what we consume, and then they have a list of all the known handles against total banks from these handles. For some of the handles, there's no known issuing bank. Most famously is the case with UPI because the email is a separate app. It's not running partnership with any bank, which makes some of the bouncing consequences tricky. For example, what happens to the MDR where you're making a payment over at the UPI handles? Who is the issuing bank and what happens to the issuing bank MDR in such cases? RBA doesn't care much about data sanity. The Excel sheets that RBA uploads regularly have encoding issues, lots of defending coding issues, family F8 issues. We try to accommodate for a few of them, but not all. I'm hoping RBA fixes those in there. A lot of Excel sheets that they publish are also broke. They'll have duplicate entries. They'll have headers showing up in the middle. They'll have access codes that are much longer, missing commas, and so on. They're also fairly broken. People do occasionally show up and say, hey, please fix this. This is an encoding issue, but the point is I don't want to make accommodation for too much of what RBA is doing because then it becomes much more harder to maintain downstream. If the data set is accessed by saying, hey, this is what we take from the RBA and this is what we publish, it makes things much more simpler and easier. So the usual advice I give is to please reach out to the RBA and fix the data sets. The only change that I know of that has happened on the RBA website is they've started putting this desk name over which didn't exist till mid-2019 at the bottom of the Excel sheets saying the data is compiled by the member banks. The RBA also built out a new tool where they let you search for a specific ISSC. Unfortunately, if you go through the whole show and find an ISSC, RBA disclaims and says the data is exploited without any warranties of any time. So there's that. I've been trying to report all these issues with the RBA, but I have had this really long, long thread going years at this point when I try to get them to fix out the data sets, but it's hard to get RBA to work sometimes. And next blocks, which you may have heard about recently, most famously from the Yes Bank case where RBA decided to push out saying, hey, any of the conversations within Yes Bank are being disallowed from such and such time and date. But these happen slightly more often than just the Yes Bank case. There are other banks as well. This is actually a snippet, not from the Yes Bank, a circular, but a different circular, which resulted in a FSC code of any of the transferbies being blocked for such different banks. Since then, I believe the blocks have been lifted. But yeah, these are kind of things that I also have to worry about and take care of while making releases. Getting to a sublet branch for a little bit. This is a simple FSC code, 11 characters. You can assume this is an HDSC code because it starts with an HDSC, but it's not. If you make a request to fsc.data.com slash the FSC code, you get the bank name as Solarboard for Solarbone Cooperative Bank and the bank code is SSLX. This is one of the most interesting learnings that I've had over time, which is that given an FSC code, you can't currently tell which bank is actually behind the FSC code easily. This is, for example, the two different sources that we've figured out for a sublet identification. A sublet branch is basically a branch run by a small bank, basically a branch that is posing to be a small bank within the RBI or the MPC networks. In this case, the entire Solarboard Social Urban Cooperative Bank exists within a single SSC code. If you are an account holder within the bank, you basically have this SSC code perspective of which branch of this bank you are in. There are two different sources we use. MPC, ICH list, which I mentioned previously, documents each and every primary SSC of each and every bank. And this lets us know, for example, in the case of Solarboard Social Bank, that their FSC code is HDFC0 SSUCB. And that lets us know, hey, this is the FSC code for the sublet bank. There are also exit sheets. And the RBI that publishes the RBI also occasionally have a bank name in the branch name field. And this increases the list number of banks which have a sublet by a huge margin. These are not published directly. There are lots of cases where the banks may not even have a full character code. So it becomes much harder to roll it as well. But this brings up the number of banks within India by a lot, for example. And yeah, talking about the pick a bit, it's fairly simple and boring. We have a scraper that runs within Ruby slash cache. We have a release notes generator script, which generates release notes, etc. There's some previous release to tell us what the additional FSC codes that have been released or what are the FSC codes that have been discontinued. There's also a patch manager that can fix issues by fix. I mean, we can pass a specific FSC or specific banks to just allow things like any FTC, for example, this how we support the FTC blocks. If you want to try it out, this is a simple full line code. You can clone the entire thing, go to the scraper, install the dependencies and run the scraper. Once the scraper runs out, you'll have the directory, which will have all the corresponding data sets in JSON format that you can actually check out and consume. This is how the patches usually look like. For example, the patch that I mentioned earlier, which shut off any FTC for six different banks. This is how it looks like. You can patch a specific bank and say, hey, any FTC for these specific branches is no longer permitted. Similarly, we maintain views, a patch for maintaining on the UPI live member list. We patch the dataset to say UPI supported for these specific or all of these banks. There's a lot of tests that I've written over time to ensure things remain consistent. A lot of testing happens between languages. Because we have a cross-language framework to ensure things are the same between all the different SDKs they are using. We have tests that are basically JSON files, and we run the same exact same tests across all the different languages. We also measure coverage between languages to say that all the constants that are defined in PHP should also exist and do this in this case. Similar things for node and so on. We also have the API. The API is also a main open source. The API exists in a separate repo by itself because we try to commit all the dataset in the repository itself. There's a fairly large repo as a result, so croning it may take time. The use case for committing all the data within the repo is to ensure we have a clean desk. The desk can be used later on for actual use cases if you want to do analysis in terms of branches moving or branch contacts being changed, etc. It makes it much more easier to do this. It has a multi-stage talk about users' rubies in order to actually serve all the requests. Fairly simple code, but highly performant. I've been running it for easily on very little resources for a long time now. I want to talk a bit about the future scope of what all we've been trying to do in the future for the tooltip. One of the things is supporting test codes. Test codes are tricky because they're entirely on the bank. So every bank may have its own standard. For example, HDSE has a common single test code across all their branches. While SPI has for like one to five percent of the branches, they have a test code which is vastly different. It doesn't follow any format at all. AAPS membership sheet is another thing we're trying to figure out. See if we can return APS true, false for every bank and you should be able to do these checks with the code. Next is trying to figure out all the sublet branches, even the undeclared ones. So the declared branches are what shows up, for example, in the NPCILS. The undeclared ones are which are hidden behind some excel sheet somewhere which says the bank branch name is actually some specific urban cooperative bank. They need to go through all the assist sheets that RBA publishes, go through all the branch names and the branch addresses to actually figure out that even though it starts with an HDSE, it's not an HDSE bank branch. So they document all the banks, even the undeclared slash dead ones. There's a lot of data on this in PDF format published on the RBA website. But unfortunately, not all the banks, even though they're documented in different places, they don't necessarily have a full character code, which makes things slightly more different and difficult because you don't have a consistent official way to refer to a specific bank. Support for more languages. I think there's a fork for Python. We're trying to add support for Go. Improve the API for use cases, such as free tech search, or for example, if you have a pin code, can you find out all the list of banks with that pin code or all the branches within that pin code and so on? Add support for hotline bank logos and images. They already, for example, entries that they have a list of how are they data set for this. But they're looking to see if they can publish this and make this much more easily consumable. So for example, even if you're making the payments across different places, as there's an easy standardized way to have a bank logo being presentable, it makes things easier for other companies. This is how, for example, these special outlets work. This is just a small subset of what it looks like. There are 1,500-ish plus bank branches that are basically SDSC-0, something-something, but it happens to be a different bank. And as you can see, spellings of co-operators once again differ, spelling-focus-hikari again differ, and so on. So the RBI, if you go to the RBI's official list, you can get some of these things out there. They may have a declared bank name for Shankara Mohit Bhatul-Sikari Bank, for example, and that shows up in our list just below the surface. But the problem with this is, again, there's no given 4-character code for the bank, so we don't have a single easy way to actually refer to this bank within our code, and it makes things much more difficult. But yeah, that's all I have. The slides are over there, the first link, and if you want to see the source of the slides that's there as well, the tool that itself is a label that asks you to see.recipe.com, so you'd like to take a look, links to the documentation, etc. over here, and yeah, that's it. Let's take a look at questions now. Yeah, so I guess there was one question by Kiran asking, if you'd like to hear more about how IFSC itself works, and there was also another question by Grace on the event page, which asked about if I had made a payment to an incorrect bank account, is there a way to report the transaction? I think primarily, both of these questions kind of confused the IFSC with the NEFD, which is the payment system, whereas IFSC is like a routing code, so a rough analogy of sorts is like IFSC is like a DNS, which routes any payment instruction across different various payment networks, and say for example, if you've made an incorrect payment, or if you want to report a transaction, you need to report as per the payment systems operating guidelines, and IFSC itself is like just the underlying routing code structures. Nimo, you want to add something on that? Yeah, mostly this, Advaita, just to answer how does Grace up here handle this? It depends entirely on once again on whether it's what kind of payment it is, if it's a critical transaction, we can have a reversal would like to answer. In case you have a credit card payment, we can ensure we can push out as a fund back to the source, but in case of an NEFD transaction, we can, for example, decide, hey, since the bank supports an IMPS transaction, we can actually do it as a fund wire IMPS to this bank account and make it much more faster in general. So it depends entirely on what the actual instrument was used for the payment. IFSC in general, once again, it's like in DNS, it's just a way to tell us where the bank account itself is, and which bank owns this bank account. So it's kind of orthogonal. We have one more question. We do cross-border payments. Okay, sorry. From the question on cross-border payments to Indian bank accounts, some banks for an IM, UPI or IMPS are not eligible to receive cross-border payments. Is there any data set available where you can figure out who can and can't get these transactions? This is something I mentioned in the future scope of things. We're trying to, for example, integrate these sort of bank codes within the accessee data set. And the idea is, you know, you provide an FSC code, which is the place where your customer has a bank account, and you can get back a FSCode in return. If you get a FSCode in return, you have a reasonable guarantee that you can actually make a transaction within the bank account internationally. But in case you don't get a FSCode, you either need to figure out whether there's FSCode or data set doesn't have it, or you can assume that, okay, because there's no FSCode, we can't easily make a transaction. So yeah, there are some ways, but the FSC to FSCode mapping is not easily accessible. For example, SBA publishes the list you need to figure out from the addresses of the specific bank in the FSC list and the address of the specific bank in the SBIs list and collate them together and see if it still makes sense. There was one more question on YouTube around asking if, is there any government restriction on using this data, like commercial use, etc. asked by, I mean, when you am on YouTube? So, I just answered the reading on the thing, but basically, the reading says, do you consider this data to be in public domain? All the data sets are published by LBI as such and a public domain. And as such, I believe it's easy and accessible to use for everyone. I don't see any issues with anyone using this, but Zephezi has released all of the code within the MIT license as well. So the license for all the code is under MIT, and the data sets are in public domain. That's our current stance. Nimo, you're on mute. Oh, sorry. I'll repeat my answer. So on the question of license, right, our current stance has been that all the code within our repository, which is the code that fetches it, code that gives the data sets and the code that publishes and the code that serves the API, for example, or that is under MIT license, the data sets themselves are currently believed to be under public domain. So we publish them as such. So I don't see any use case issues that you may have of using this data within commercial or non-commercial users. And there is one more question from Advait. Nimo, you're on mute. Yeah, I'm just reading through that question. I'm not 100% sure what it means. Neither RBI or not, and if you have an updated method for fresh or old FSE. So the way, yeah, the way it works is on the SFMS network, every month, the bank will push out a new list saying, hey, this is the list of all the FSEs we have. And it's up to us as a consumer of that list to ensure that the old things get removed. So what we do is treat every data set as fresh in Excel, which means we can do it just from the previous release to the new release and say, hey, these FSEs have been removed versus these FSE codes have been added. How they duplicate FSEs for different banks reconciled from the regulator side. And this, for example, this handled on a case by case basis once again, for example, for the SBA mergers that happened, as we have published out a list within their own website saying this is on the left is the old FSEs on the right is the new FSE codes. And they've been doing that mostly for each and every new merger that has happened over time. But other banks may not follow it. For example, BNB mergers, there's no such list available. So and what happens ultimately is that the old, in the old, for example, whichever one's got mergers to BNB, the FSEs will keep getting published for some time and then they will stop getting published to the list. And then you have to assume that, hey, they're now getting published under the PUNB namespace. So it goes on a case by case basis. And the reconcilation is, I believe, entirely up to the bank. I think the RBA steps in for cases like KS Bank, where they want to ensure that things don't break, but usually it's taken care of by the machine banks. Okay, Zainab had posted why bank doesn't have liability or intervention powers in terms of a long transaction. How does this arbitration works? For IFSE, IMPS and UPI transactions. I think just to clear it out, IFSE is the routing code structure. So IFSE is not a payment system. Because IMPS and UPI are payment systems, but banks do not have intervention powers because they operate on a network where the transactions are instantly settled. So they have to actually go through a formal process of the dispute resolution against the network, which is NPCI in this case, and this whole process takes a while. And typically, in fact, in a recent report, RBA has decided it takes up to 47 days for a dispute to get resolved through an ombudsman. So that's the average dispute resolution time that we know of. But I think we should kind of dig in more, because there are different kinds of disputes and different levels of issues, both technical, non-technical, operational. And I think we should probably do maybe a small session on this sometime later. And are there any more questions? Are we getting too close? There are no questions open on the Zoom. Let me see if there are questions on the YouTube. There is none. Okay. I think we'll formally close this session then. Thank you for attending today's event. We have an upcoming session on May 30th by Kanchan Kumar, co-founder and CEO of Remitter, who will be speaking on AML, Intermittences, Data Flows and Privacy. Please visit the event page on haskeek.com.com. And respond to the RSVP. We're also planning to come up with a study circle where we'll go deep dive into individual payment systems and narrow topics where we'll read through and get to understand specific areas in a classroom setup. And please let us know your feedback on this session on the comment section of the event page or ping any of us. Do let us know what are the topics and talks you would like to hear. If you would like to talk about anything on payments, do let us know. And you can join our Telegram group for any FinTech chatter. We are at t.me slash cast consumer. And there's a poll that's run. And there's a poll that is in progress now. Was this session useful? Was this event format participatory? And yeah, if you have more comments on this particular topic, you can go to the event page and comment on the comment section, anything on IFSE or branches that you want to ping Nemo Moore to hear about it. Yep. Thank you. Thanks everyone.