Every week, we run a meetup for the Investec Programmable Banking community. Developers demo cool projects they've been working on and everyone has the chance to ask questions. If you've been wondering where programmable banking is at, here's your sneak peek!
In this demo, Lishen Ramsudh discusses the tool he’s been working on to streamline business operations and open up product possibilities through the use of a temporary store of value. The temporary store of value and automation of certain operations opens up a different trust relationship with a process being the custodian instead of hoping that a transaction is upheld.
The technology he’s used for this build include C#, DotNet Core 3.1, Postgres, Redis and Xamarin Forms. He’ll eventually work towards including Docker, AWS ECS Fargate and API Gateway as well as AWS Aurora.
Click here to download Lishen’s presentation slide deck.
Check out the repo here.
Transcript of the demo
Lishen [00:00]
The correct words to use to describe it is what I call open-sourcing Escrow. This is me, Lishen Ramsudh, and in my normal day-to-day job, I do foreign exchange work at Absa. My normal work is using the DotNet framework, etc., etc. C# type of stuff. Very Microsoft stack.
Lishen [00:25]
This particular presentation is what I call the Wallets presentation. I'm trying to streamline business operations, and the whole idea behind this is to put as much automation and fewer steps in place where there could be human intervention.
Lishen [00:43]
As I said, it is an open source Escrow, which is allowing for a trust relationship to be built within the application and with the system being the custodian of a transaction. Banks, other banks, and stuff have Escrow services, so this is open-sourcing it where every single system that uses this would use or expand on Investec being an Escrow provider.
Lishen [01:14]
The system that I eventually built is DotNet Core, using Postgres and Redis. It's a small little app that I made. I went into Docker and Fargate on AWS but the demo that I have doesn't actually have that. It was more in the beginning but I will take you through the architecture.
Lishen [01:37]
I use quotes because I'm a fundamental believer that physical properties, actual physics concepts, are always going to be something that we need to strive to understand. It helped me a lot here because this started off as a big project and I broke it down into small little pieces.
Lishen [01:59]
What I'm going to showcase to you is basically a small piece of a whole bunch of use cases. If you could use this in any one of these use cases, one being Escrow type using open sourcing Escrow if you want to do department budgeting, as an example.
Lishen [02:19]
Let's say you're an organisation, and you have multiple little departments. You do your budgeting, and if you need to manage your money, this is an easy way for you to see how much money is available in each department because you basically put it out into all of these wallets at the beginning. Then as time goes on, they can actually transfer between themselves, but all under one bank account so it's not like you have to get multiple bank accounts to get this working.
Lishen [02:45]
Then the last one I thought about is something that it could be used for as tender processing. Let's say you have a tender for iron ore for a road, or whatever the case might be, and there's a whole bunch of procedures that need to happen. Controlling the money is what I believe is important because that prevents fraud and all sorts of other things from happening.
Lishen [03:06]
Controlling the money by having the Escrow type stuff baked into the system is actually what I believe will stop the fraud, I'm hoping. These are a couple of use cases that I thought about and how it works.
Lishen [03:25]
As I said before, with the quote, I focused on individually scalable and very small services, and because they're so small, they are easy to update, very focused, normal, solid principles. You know – single responsibility stuff. The bank service is actually the thing that's tied to Investec and how I envision this thing being used is that it will be scheduled and it will run every 30 minutes or an hour, or whatever the case may be.
Lishen [03:56]
How it works is that someone registers a wallet, you get an easy equity style registration number, you deposit money into this number, the bank service runs, picks up the deposit and checks the description – being the number – and then it associates the deposit with the wallet.
Lishen [04:15]
The bank service then caches stuff in from the previous run so that it can always know what the latest transactions are – and I'm assuming future iterations of the account service with Investec would probably have searching parameters or something. Maybe it's there, but I haven't really used it properly.
Lishen [04:36]
So that's the payment reference part and how it allocates funds.
Lishen [04:41]
I envision the architecture being a cloud-based architecture for scalability. These pieces over here are back-end for front-ends because I have a mobile app and I have a website, and I have these clients and users using it, where clients would actually be the ones registering wallets for something.
Lishen [05:06]
One of the use cases is, let's say you want to reverse the internet browsing thing where you search for stuff from Takealot, for example. Here, you could say, I'm going to search for cheese, actually, and I'm willing to pay 500 bucks for the special kind of cheese. That's the amount that I put in the wallet, someone goes and finds it for me, it goes in the community and somewhere down the line, someone finds it, it gets sent to me, you can have a third party, pick it up whatever the case might be and then the money gets transferred.
Lishen [05:38]
So the people who actually put money in would be the clients, the people that go in and exchange the goods, I assume, would be users and, in essence, they would all just create wallets, and the wallets are then stored in an Aurora database, in this case.
Lishen [05:53]
In this particular setup that I have, it's a private SubNet. Everything is housed within a secure private environment. However, I found that if I wanted to use the complete isolation, which is VPC endpoints, they actually get quite expensive, because you have to add so many. You also need ipv6, which was a question that I asked in one of the Slack channels as well – can I access the Investec API using ipv6?
Lishen [06:26]
I opted for a NAT gateway because it's just one NAT gateway, but it's split across so it's two NAT gateways and that loaded the cost. Anyway, going to the demo, I recorded it before, and it's got my voice so I'm going to mute myself for a few minutes and you guys can listen to this. It's showcasing on a local machine, just the wallets API, the bank's API, and it's talking to the Investec API. Okay, so I will mute myself and press play.
Lishen [07:04]
In my wallet's application, the alpha phase there's three components: the SDK, the bank service and the wallet service. The SDK is, of course, the thing that talks to Investec. There were a couple that had already been created but I found that out after I created mine, and that was actually good to find out later, but at least I incorporated quite a few things from some of the others, but I think we should contribute to those
Lishen [07:33]
Then there's bank service, which syncs all the bank transactions into the wallet and the wallet service is the manager of the wallet. All right. Let me give you an overview of what it is. If I go to my Postgres database, I have a pre-loaded wallet, with the reference number of the wallet. I have deleted all the transactions as part of the demo, so there are no transactions. Then, my Redis cache is basically a cache that I use to make sure that the bank service is keeping track of the previous run and it keeps three keys.
Lishen [08:19]
The one key is a hash of the entire transaction payload for the run. The second key is a hash of the last transaction ordered by date. The last transaction that had tried to sync or update or track and the third key is the date of the last transaction that it did.
Lishen [08:44]
Alright, so I fired up my API. This is the wallet API that is linked to this database and what I'm going to do first is I'm going to show you the transactions that are inside this account. This is the transaction that I'm looking for, and there are quite a few transactions that are inside this account.
Lishen [09:07]
I did a deposit a couple of days ago, into the account, and I use the wallet ID as the reference, similar to how you would do with EZ equities, for example. This is just to give you an idea of what's in the Investec account. Alright, so what we're gonna do here - my wallet service is running, and I'm going to start up my app. I just made a small little app to showcase the wallet service. It just takes a little while to start.
Lishen [09:51]
If we go to the wallet, it talks to the wallet service and this app is baked in with this reference number which is the same reference number that I deposited to, and it shows you zero as it should because there's nothing in the associated transaction associated with the wallet yet.
Lishen [10:12]
Next thing I'm going to do is I'm going to start up my bank service, which is now going to sync transactions and what it does, it looks through all the descriptions and checks the description against the wallet service. It actually talks to this wallet service, and checks the description and says, does this wallet exist, okay, cool, it exists so now it's going to credit the wallet, and then after the run, it updates all the hashes that I spoke about.
Lishen [10:41]
If I refresh the screen, you should see the 50 bucks, which is the exact amount that I was hoping to find. That is my demo done, but I need to do a few things quickly to run through to check if the transactions are saved in the database. In this wallet, wallet ID one has a transaction on it for 50 bucks, and my hash is updated as well, which indicates the hash has run.
Lishen [11:15]
The idea behind this is that all of these components, this wallet component or bank service component can be containerised and placed or can run inside a Docker container. You can schedule this one, but they work in tandem.
Lishen [11:32]
Everything is open source, and everything's ready to use. I will be recording myself again as it's actually quite dry. Anyway. Okay, as I was saying, everything's open source. Everything's ready to rock and roll there, and I'm making changes to put it into Docker.
Lishen [11:58]
Challenges that I encountered. Well, I've never used any of this stuff before.
Lishen [12:04]
I use the DotNet framework for my day-to-day, I use MSSQL, but I never use containers, because there's no need for us to use it as we are migrating at the moment. I pushed for all of the new stacks, and I managed to convince business to allow us to migrate.
Lishen [12:24]
All this stuff was a huge learning curve for me. The one thing that I decided to keep in common because there are so many different technologies is to keep the language the same, at least. I've done other languages before but keeping the language, the same meant that it was easier for me to get up to speed quicker with all this stuff.
Lishen [12:40]
The other complicated thing that the demo didn't showcase was the cloud infrastructure. The cloud infrastructure was the ECS setup that I did, and the iterations were a bit tough to understand how all the things fit together.
Lishen [13:00]
The next steps for me now like in that architecture diagram, is there's a whole bunch of other services and I'm going to create a DotNet new template to go and create all the remaining pieces. This is part of a much larger project. However, open sourcing Escrow as a service, or Escrow components, is the piece that this is about and I feel that maybe other teams, people, whoever wants to – businesses – whatever, whoever wants to use this can end up using Investec's Escrow, so to speak.
Lishen [13:41]
For me personally, this is part of a much larger project that does use temporary store value. Then I must configure the build pipelines, automate all of that up, clean up the code. I'm going to investigate event sourcing, and the last bit is to put this all on DockerHub so that anybody can just pull the image and start using it or put it in your environment variables with your Investec credentials.
Lishen [14:09]
If you guys want to get involved, that's my email address. Everything on GitHub.
Lishen [14:15]
The reason for the AI solution was actually such a long time ago, but it's a small little side thing that I used to play with ideas and I am putting everything in there. Great. I think that's it for me. Any questions from anyone?
Wayne [14:46]
I have a question for you. It's very cool. If somebody wants their money out of the wallet, do they just let you know, and you do a payment back to wherever they paid you from, like a database with their bank accounts in and just paid them out?
Lishen [15:00]
That's pretty much how I see this working, but when the payments API is set up, then I will automate the payment. But for now, what's happening is that, on the weekend, or a Sunday you get the list of everybody that wants the payments out, and I could do it manually.
Ben [15:28]
There are some interesting comments here as well like hooking it up with freelancing services so that you can prove that you have funds for freelancers before they start working on projects. Byron, you mentioned that this is similar, or do you feel it is similar to Ethereum? I was quite interested in what aspects do you think are similar to Ethereum?
Byron [15:56]
Um, yeah, most specifically, the Ethereum smart contracts. I think this might be potentially at least slightly broader, but from a smart contract perspective, that's what it can be built to. It is great stuff. You can have somebody deposit funds, and it's that separation that I think, was the most important piece of information.
Byron [16:23]
I was also waiting for what Wayne asked if, at the end, does it get paid out into a bank account? Because if you're going to do that sort of manual step, then Ethereum, the smart contract, can essentially be the same thing because we can also have a manual thing, but that's if I understand it correctly.
Lishen [16:42]
The idea is there's a whole bunch of use cases where for example, you'll have money in, and you'll want to split that money across multiple wallets. Let's say there's a whole bunch of people in the chain that were involved as part of this transaction, right. For example, I put in a R3000 bounty for cheese, and five people share it, and the last person actually has the cheese.
Lishen [17:07]
Everybody in that sharing chain would want a piece to that bounty because they were part of it, you know what I mean. It's basically sharing that amongst all of them, so the idea is from me putting the bounty into the cheese wallet, and transferring that from one wallet to a whole bunch of them – it's a wallet to wallet transfer, so there are no real inter-account changes.
Lishen [17:28]
It's only when those people decide, hey, listen, I want my money now, and then they say, pay me my money – here's my bank account details – that's when the payment actually takes place.
Byron [17:41]
Okay. I understand it, but it still seems really similar minus the infrastructure in the background
Lishen [17:53]
It could be, I just need to read up on the Ethereum a little bit more to understand the contract part of it.
Audience member [17:58]
One of the main differences I see with what he's got there is, Byron, is that Ethereum, the smart contracts, has to be that you're buying. You have to buy Ethereum. He said he works with normal money with standard flat currency. Within the Ethereum contract, you have to actually buy Ethereum and Ethereum gets transferred to the other person, which they then have to convert into a local currency.
Audience member [18:27]
You obviously take that risk that Ethereum could go up or down, depending on the volatility of it, so him working without that volatility could be better, depending on the situation and the environment.
Byron [18:40]
Yeah, that's definitely a good point although token prices can be locked, you've got stable tokens and things like that, it doesn't have to necessarily if it's going to be its own smart contract, it will be a token on its own, you can lock that to a certain currency. But yeah, I see what you're saying.
Audience member [19:11]
I would say that the gas fees would be the biggest hurdle there, which this solution would be better for.
Audience member [19:18]
Yeah especially if it's small amounts, like R50 or 100 bucks, the gas fees are gonna eat through that quite quickly.
Byron [19:26]
Don't get me wrong, I'm not saying Ethereum is the better one or whatever the case is. It's more just the idea so that I can understand it correctly and liken it to.
Audience member [19:38]
Ya, understand, okay, cool. Thank you.
Wayne [19:42]
The money, the wallet part of the regulations that are payments, you might run into some stuff. If you keep it in a closed-loop network between product distributors, sellers and buyers, I think that might actually be a very valuable thing but doing it for the public would be a bit tricky and, that's probably why Ethereum works better because they work outside of the banking sector.
Audience member [20:05]
If you start, you're basically starting your own bank, you're making deposits into every account, and you're making payments to third parties, I think you have to think of this thing, almost as a closed loop and if people join with some regulation, then you can transfer that value between them and guarantee the transaction that way. It's very cool.
Lishen [20:24]
Thank you. Yeah, that's exactly it. I am definitely not trying to create a bank because I've found out how much it actually cost. If you run a banking level type thing, the cost is R250 million, minimum. It's crazy, just the legal part of it, but it is definitely not that – this is very close looped.
Audience member [20:50]
Mentioning the legal part of it I recently bought a house and I noticed there was a hell of a lot of red tape around funds held in Escrow by the lawyers, specifically for the purchase. They had red tape around what they had to do with the interest, what kind of interest was supposed to be charged, what they can do with the money and how soon they have to pay it out. How do you envision handling that kind of legal hurdle for a system like this or is that entirely based on whatever person is currently using it for?
Lishen [21:18]
How I envision this working is the interest is based on whatever the interest is on the account. Let's say it was an Investec account, so the idea is that the wallets with the largest proportion, the interest comes in, and it gets distributed proportionally, according to the total wallet amount. It's definitely going to be based on that, but I have no idea about any of the other legal pieces at the moment, which is why it's something that I'm going to probably run into and then have to deal with when it comes up. I'm hoping that for the first purpose, it's like paying for a service, so I am paying for a service, and the payment gets paid to the people that provide the service. That's how I'm looking at this thing working with the wallets being an intermediary store value. I'm hoping that that's the case, but we'll see what happens. The other reason why open source is if everybody does it, the middle might have to change.
Ben [22:30]
I really love the use case if you buy something on Gumtree, you show them that you've got the money in Escrow and then a courier like Uber person or pickup person or whoever goes and picks up the goods, and they activate something on their side to release the funds to the buyer.
Lishen [23:04]
And then one of the other things that I mentioned, I don't know whether you guys picked it up but in a single organisation or individual case, where you basically have a low budget at the start of the month, you draw out all your money, you put your grocery monies in an envelope marked groceries, and all your electricity money goes in an envelope marked electricity, and when you pay for electricity, you take money out of that envelope, except doing it in a somewhat less barbaric way. It is something that could be managed with a card especially if you integrated with the payments approval API so before you book you check whether there's still money in the envelope, and if there isn't enough you decline the transaction and if there is then the transaction was successful, and you deduct it from the appropriate wallet.
Lishen works as a Technical Team Lead for iOCO in Cape Town, and is currently outsourced to Absa CIB Digital, working in the Markets space. He works a lot on pet projects in his spare time with an aim to learn more and build systems that people find useful.
Get involved in the Programmable Banking Community
If you’re not part of our community yet, sign up and join the fun. You can also see more of the demos from our meetups on our YouTube channel here.
For those of you in the community, check out our GitLab to see more of the awesome projects members of our community are working on. You can also sign up for challenges, where you can help find solutions for real life problems.
For more information, get in touch!