We ran a hackathon with members of the Programmable Banking Community to see what exciting projects teams could build using the programmable banking tech in a short space of time.
In this demo, Renen Watermeyer walks us through his team's credit card transaction management system, which allows businesses to easily restrict and manage the use of Investec credit cards at specific merchants. This is done by creating sets of rules that allow or deny transactions in real time. For example, universities can make sure that funds are spent in bookshops, and transport businesses can allow their vehicles to be filled up at any garage. Check it out here!
Check out the repo here.
Transcript of the demo
Renen: (01:07)
So in my day job, we deal a lot with mobile money and with the management of financial transactions and so forth. So the gauntlet that Ben threw down was definitely interesting for us. We picked the goal of helping people to intelligently restrict and manage the use of Investec credit cards. There feels to me like there are two clear use cases with programmable banking. One is reporting. The other is inhibiting or shutting down transactions or controlling transaction flows. So in this case, we elected to emphasise controlling the flow of transactions – so allowing users to set rules around the transactions that go past. With that said, let me jump around at first. No, let's not jump around. Let's stick with the plan. You can all try this thing out. So there's the link there.
Ben: (03:04)
I'll share the link in the chat.
Renen: (03:07)
Yeah that's probably a good idea. Well, I'm going to hop around randomly anyway, because I can't remember what the hell we are doing. So the system allows you to set up credit cards or to link credit cards to the platform. And there's a series of incantations that you need to kind of follow for that, and then that allows you to create rule sets. So, you can have different rules that apply in different contexts and then it allows you to create rules at the bottom end that actually get grouped into the rule sets.
Renen: (03:37)
Now to back up slightly, let’s look at the use cases that kind of went through our heads as we built this thing. Creating a fleet management card, for example. So if you were a delivery company and you had thousands of vehicles drifting around and you wanted to allow your drivers to be able to fill up their cars at Caltex garages and Engen garages, but not BP garages, we want it to empower you to create a set of rules that allow that to happen. And in my case, the use case that I kept in my head as I did this was to restrict my teenage daughter's spending. So I want her to be able to buy stuff from Woolworths, but I don't want her to spend money at liquor stores. That's really what we were trying to get right. So there are a range of personal uses and a range of commercial uses, but really it comes down to being able to set up rules and link them back to it to credit cards.
Renen: (04:43)
Now there's the teenage example. You can see the rules there, and we'll look at this in detail in a second. There's a bunch of criteria you can set on the rules. So nothing's rocket science here. This is all kind of easily doable individually through the API. What this allows you to do is just to package a little more slickly, so you can do it more readily. The technology, which is, I suspect, what most of you guys care about. So there's three or four tiers to this thing, the card transactions and the requests that come from Investec to authorise or decline the transaction. That's an AWS Lambda running in Ruby. The link that takes you to the bit of code that does that. The website, which we will look at in two seconds, runs on Amplify. I've actually had to go check that we've stepped completely back from Amplify over the last few months, I've forgotten it even existed.
Renen: (05:49)
Amplify is very similar to Netlify – it's Amazon-based and slightly tighter to use, but the code is there. The website talks to another Lambda – actually it's the same Lambda, which does deals with authentication and all the reporting and all those sort of good things. And lastly, there's an RDS hosted MySQL database in the backend. And the script is there, if you want to think about that. All the code is obviously in that repo there. The process that kind of plays out is that the customer initiates a transaction, Investec makes the request to CardShark for authorisation, we assess the rules that relate to that transaction and approve or decline the transaction and Investec responds to the customer. And then after the session concludes, there’s a subsequent call from Investec with a notification as to what happened. And we then push that to a Web or Slack as is appropriate. Okay. That's the really intelligent link, as I said, it's in the email. So you can go try it out. We'll come back to next steps. Let's take a look at it.
Renen: (07:17)
Okay. So I've already logged in. It should say welcome to RSG on the screen. I've already authenticated. The authentication process just uses your email address to send you a one-time pin to log in with. It's really not that exciting. This is a progressive web app, I think. So it should run on a phone or run wherever. Here it's just running in the browser.
Renen: (07:41)
So I mentioned initially the concept of cards. So the first thing you have to do is add a card to the system. It's relatively straightforward. You need to provide the card number, the card holder name, and then there's a bunch of stuff you've got to do on Investec's side, which is documented here. This is also available through the program or banking interface on the Investec side. There's nothing kind of surprising there. All we're doing is telling Investec to call the card, but this configuration has to happen per card on Investec's side after the programmable banking has been enabled for you. If there was one single thing that would be helpful for Investec to kind of improve on, this would be it – to be able to integrate with cards and a dynamic API-driven manner would really transform this product.
Renen: (08:43)
Once you've got cards added, you can set up rules. In this case, you have rule sets that talk about that. The pocket money rules consist of the Woolworths ones, Pick n Pay ones, non-food retail ones etc. But in essence, you can use regexes to define what the rules apply to. For example, they're applied to Caltex, they do not apply BP, well, then these rules don't apply. You can set maximum/minimum values. You can say that it must happen in and out of the country, rands only or any currency. So basically all the data points that come at you through the API, you can hook rules around. There's a 'read me', which will help you understand what the hell's going on here, because frankly it's been a while for myself as well.
Renen: (09:42)
I think the most interesting thing for me though, is that you can use regexes as well as kind of straight up text, which makes it that much more flexible. You also don't have to have any rules. You can just set this thing up, connect a card to Investec, and then use that mechanism to push data to Slack or push records of the transactions to Slack on your side.
Renen: (10:10)
Yeah. I'm not going to demo it. There's a list of transactions. It'll reflect the transactions that have gone past, and you can see these are all the simulation ones. You can see whether they were allowed or not allowed. There are a few here that were not allowed. Ben loaded the one, set his rules up and found himself at PostNet or somewhere like that and couldn't work out why his transaction wasn't going through. So almost to my surprise, the platform actually does what it's roughly supposed to! Yeah. And that's pretty much it. So once it's hooked up, it just runs transparently in the background, filtering transactions, making sure that the right things happen on the right cards.
Renen: (10:56)
Our next big step is to commercialise this project. It's very interesting for us to relate a lot to what we're doing in our day jobs or what I'm doing in my day jobs. We're currently working with people at Payactiv in this country to deal with cash in and cash out. And this whole programmable credit card mechanism is very intriguing for us. The year has got off to a very busy start so this whole thought process is stalled, but it's definitely on our agenda to pick it up and make it actually do something kind of commercially useful. It certainly seems commercially usable, which is I guess the other big thought that I was kind of exploring as we did this. It seems to do what it's supposed to which makes it exciting.
Renen: (11:52)
Reactions, questions? Anybody out there?
Adam: (12:09)
The question I have is actually for both you and Ben, I'm very curious. That was very impressive. I mean, that looks really like a well thought out system. What exactly happened at PostNet? You say it was working as intended. It may have been surprising, but what was the intention? What were the rules that were being hit?
Ben: (12:35)
I can actually share my screen and show you my setup because that can segue nicely into my question.
Adam: (12:47)
And did you have to disable your programmable bank card in order to continue? Like with your transaction?
Ben: (12:52)
Yeah, I did.
Ben: (13:03)
So I had this rule set up called 'uber’. It was just a maximum value of R100. I must've been trying to spend more than R100, but yeah, it's quite cool. The whole depth of ability to set up rules here.
Adam: (13:23)
It's not a blanket rule of nothing more than R100.
Ben: (13:28)
Yeah. I was just testing it out. And then I went to PostNet to get a photo for my driver's license and then it was blocking me. But I don't know why every single time I play around with one of these... You can choose to allow cities and categories, pulling in all the regex code categories. So it makes setting up rules super, super slick. What I'm struggling with right now, Renen, is I actually got another Investec card because I lost my card, but it was actually just under the mat in my car. So I found it and I have two Investec cards which just makes programmable banking slightly more fun, but how do I see my cards here?
Renen: (14:21)
There, B Blaine, bottom left.
Ben: (14:23)
But that's just my account. Right?
Renen: (14:24)
That's the one you got.
Ben: (14:25)
So how do I see my individual card?
Renen: (14:27)
It's the card you've linked. I'm not sure that I'm clever enough to do that.
Ben: (14:37)
Do you know if it works for multiple cards or was it like account-wide?
Renen: (14:46)
It would be account-wide because you do send us a card number through, but I don't think we need that for the registration of this process. So I think Investec banking – if I remember correctly – works at this level from the API end of the equation, I think from this level when you get through, I think you can...
Ben: (15:12)
I know I have two cards, so yeah, that's quite an interesting situation, I guess.
Renen: (15:19)
Look at the sample code. The sample payload.
Ben: (15:25)
The simulation?
Renen: (15:28)
Yeah. So we're looking at the before transaction for this and I may be wrong, I don't think we get the card number, may well be wrong on that though. And I'd have to look back at the logs to check that out. I can see here though, give me a second...
Ben: (15:52)
Do you get the simulation code as well? Yeah you should.
Adam: (15:55)
Is the simulation code actually related to the code that comes through?
Renen: (15:59)
No, I can't see the card side of it here. I can't see the transactions logged on our side, I can see the transactions that have come through, but I can't see the backend detail.
Ben: (16:24)
Sorry, I didn't actually let you know that I was going to do a reverse demo on you.
Renen: (16:32)
No, no, it's fine. It's great. It helps!
Ben: (16:35)
Okay, look, it's not enabled. So that might be the problem. So let's try it again.
Ben: (16:43)
The code wasn't actually enabled on my card. Oh, this is getting complicated, but I've blocked this card. That's why it's failing. Just because it's sitting in my cupboard and if someone goes into my cupboard and finds it, then they can go buy stuff. Okay. So this one should go through.
Renen: (17:06)
See, I don't think we're getting any transactions, any data there which tells us which card it is.
Ben: (17:10)
Okay.
Renen: (17:10)
We must be getting something somewhere.
Ben: (17:12)
I've got a feeling that you're only logging real transactions there. Hey, there's my personal transaction.
Renen: (17:25)
And if you click on it, you'll be able to see why it failed. Click it. Wait a second.
Ben: (17:35)
Sometimes.
Renen: (17:41)
Okay, broken. Interestingly, mine is doing it, but that was just to show you, it's a very crappy report anyway, just showing you what rules applied were in effect for that transaction. It doesn't matter. This is what the requests look like that came in.
Ben: (17:56)
Yeah. All these got blocked. You can see, but then I very quickly turned it off and then I went on holiday.
Renen: (18:17)
I must say this has been an exciting little project and it's cool to build, do it and to know that we can do it. So yeah, we will build on this in time.
Ben: (18:28)
Can you share any more information about how you're thinking about commercialising this?
Renen: (18:34)
So the problem with commercialising it is completely embedded in the Investec ecosystem. You need Investec's blessing, engagement, support, cooperation to make it commercially viable. You could do one customer at a time, partnering with Investec on the customer or taking the customer to Investec, but to actually build a scalable Investec independent business, that's a lot trickier.
Renen: (19:03)
So at some point we will find a business case for it and take that to Investec. We would also like to, and I spoke to Ben about at the end of last year, but we simply haven't had time this year to actually get close to the Investec, to talk to them about their aspirations, and understand how we could turn this into something kind of powerful and useful for Investec. It doesn't make sense for everybody to rebuild the stuff when we have something useful.
Nick: (19:40)
Because you're talking about commercialising it and making it better, I’m wondering if Investec said yes to everything, would you make it more for individual people or for a company or more commercial use?
Renen: (20:02)
So I think that’s obvious and it feels that the most kind of compelling use case, if you have Investec’s buy-in, would be to add this to the business card. So if you get business cards, it's kind of thrown into the mix and it's part of the deal. But then the model would be a fee-per-transaction or a fee-per-month usage or whatever. You need to build a model around that. But that would give you the biggest amount of scale with the most reach. Failing that, our customers do these kinds of things but generally in a slightly different context. So at some point we will find a customer where this will be useful and we will roll out the role of functionality to that customer on a kind of piecemeal basis. Much less exciting. If Investec got on board, we would have to take something to market with them. And then you can really build it into the product.
Nick: (21:05)
Oh, that's actually pretty cool. Yeah. Because as soon as Investec can actually bring out that section where they have multiple cards linked up to the API, then that will really just explode. You know what you guys have.
Renen: (21:17)
As I said, the challenge is to make the card allocation dynamic. Like if you have to call your Investec banker and ask them to help you link a card, and then you have to go through the process. However much that the app spoon feeds you, my mother will not be able to pull it off.
Ben: (21:38)
You mean not having to add the code to your card on Investec online?
Renen: (21:45)
Correct. Yeah, yeah.
Renen: (21:48)
It's been pointed out to me that there's some serious security problems there. So one has to think about that process, but it's solvable. I mean, it's been solved in Europe, so people will solve it here as well.
Ben: (21:59)
Well it's quite interesting that when you get businesses who want to give people cards to go buy stuff at specific retailers. Specifically businesses that give people cash loans. They want to lock it down to groceries or things that are good for people. They obviously don't want to loan people money to go buy alcohol for instance, but people do that. So, if they can lock it down, they can kind of give you much better cash back on those kinds of things. So those could be really nice management businesses.
Renen: (22:34)
Absolutely. So you're welcome to refer those people to me then. Very happy to do it.
Ben: (22:42)
I definitely think whether we want to or not, we're going to have to figure out what this business partner network thing is because what Investec wanted is something along the lines of Microsoft's interoperability something board, and they basically brought a lot of businesses online or onboard to toll like Microsoft internally, and decide what to do to make their products work better together. So hopefully this year we will take it to the next level and get businesses on board who want programmable things but don't necessarily have the expertise. And then we'll have guys like yourself in the community who are able to help them out. And then that hopefully will be a feedback loop for Investec on what they should be doing from the platform.
Renen: (23:31)
Yeah, I think that works in all directions. It'll drive this program for Investec and make it real for them. It also makes it real for the community if there are opportunities that are kind of hemorrhaging out of it, then everybody can be happy. I mean, so far I've got a T-shirt, check it.
Get involved in the Programmable Banking Community
If you have questions or just want to say hi to the Programmable Banking Community leaders, you can pop us a mail and either Ben or Nick will get back to you.
If you want to see more from what the community has been up to, you can: