OfferZen’s recent Programmable Banking Community hackathon turned up some inspiring projects built using programmable banking tech. Five of the teams got together with OfferZen and Investec afterwards to share their solutions to a specific banking problem. Here, Amanda Mosena, Devendran Naidoo and Ockert Pretorius of CSTech unpack their solution, Card Guard, which democratises programmable banking through a web interface, helping non-technical account holders to set up their own rules for their bank cards quickly.
The solution helps non-technical Investec clients to create and configure their own rules, using a simple and easy to manage web interface. Providing a greater level of control over where and how they want to transact.
Transcript of the demo
The problem
Amanda Mosena (46:18)
Good evening, everybody. I will be walking you through what our solution is and what our problem statement is. So, programmable banking was initially built for developers, which meant excluding other communities. Our mission was to change that narrative, which is why we are introducing Card Guard. So, what is Card Guard? Card Guard is the user interface that brings the rules engine to the masses, via programmable banking. It empowers non-technical users to apply [card] transaction rules through programmable banking. Currently, we are focusing on one objective, and that is to decline a credit transaction if it doesn't meet the defined criteria or rule. How does it work? Card Guard allows you to enable and disable card transactions on your card, based on rules you create without having to write code. You can create rules for transaction types, transaction amount, transaction categories, transaction currencies, etc. I will be handing over to Ockert, who will walk you through the technical details of our solution.
The solution
Ockert Pretorius (48:04)
So, I'm just talking about our high-level architecture. We've got an API talking to the Investec service. The Investec service only has a listener. It's a webhook that calls our API, and it just tells it yes or no. Again, the rules get ported to the API via Angular front-end. And the data sits on our Cosmos database. At the moment, when the user registers, they'll get the card secret from the Investec site. They'll add a secret to the profile and [for] future login. I just didn't have time to do anything fancy there. And then they can kind of add to their heart's content. I don't know if you guys want to see it in action.
How they did it
Ockert (50:09)
Okay, so I’m using Devendran’s account for this. Okay, just waiting for that login, waiting for the API service to spin up. We did use Azure Functions, which is a codeless-type solution. Okay, let's go to rules. Add new rule. Okay, next thing, currency code needs to contain ZAR. Save it. Okay, maybe merchant’s city does not contain Brakpan. Save. This gets fed to the API. And whenever a swipe happens, these rules get validated against the amount. And then the card will turn return a true or false. […] So that's the basic gist of it. Any questions about the architecture or the site? Cool.
Amanda (51:24)
I think we'll hand over to Devendran, who will actually walk us through a live scenario of setting up a rule. And seeing what happens after that rule has been applied, by shopping online.
Nick Benson (52:04)
Is Devendran …? Is his audio working? I don't think his audio is working. Or maybe it's just muted. Amanda?
Amanda (52:26]
I can talk while you're creating a rule; I'll just keep an eye out. Okay, so how this work is, you go to Rules. You can create … Well, first, [he’s] disabling the rule that was created before by Ockert. And he's going to create a new rule for a transaction amount that has the value greater than one Rand. Our values are currently in cents. I think for future we'll look at changing that to higher value. So now he's saved the rule, he's going to Takealot to do shopping to buy a Vodacom voucher for two Rand. The 100 cents is actually one Rand. So, let's see what happens. He’s going to select the card he’s configured to make the payment.
Nick (54:07)
It’s still authenticating.
Amanda (54:09)
Yeah Obviously, it’s still authenticating. And we'll see what happens on the next screen.
Amanda (54:21)
Okay, [it] takes a while. All right. As you can see, he tried to make a purchase of two Rands. But the amount that he configured was for … he didn't want transactions that were above one Rand, which is why the two Rand has been declined. I think, Devendran, if you can show us the next test case, where you can disable this one Rand and transaction amount and show us one which will allow you to actually make a purchase Okay, he's updated that to 300 cents, which is three Rands. And he's going to make a payment. And he will go through the same process of authenticating, and he will actually show us what it looks like. Okay, 60 seconds. Let's give it a few more minutes.
Nick (55:26)
I really love that you guys are using an actual shop. Very cool.
Amanda (55:47)
Yay. Cool. So, as you can see, this is the rule that we built. To handle just that card-decline transaction. Obviously, we have quite a few future features that we want to incorporate […]. We've got an initial suggested rule template that, in future we would like to incorporate into our solution; we would like to be able to perform our analytics on […] your card, on all the rules that you've performed against your card. And we've got a list of Investec-suggested blacklist entries which we’d also like to incorporate into this. And this will help you when you want to make certain payments or when you're shopping. If these people have been flagged, it will be something that […] the app can automatically tell you that you're making a risky payment or a risky purchase. Cool. And […] let me just share quickly, we do have a Q&A section on our website, well not a Q&A section, we do have – do you want to share for me, Devendran? – we have a frequently asked section on our website where you can find additional details if you've got any questions. But we'll be taking additional questions in this section also.
Questions from the community
Nick (57:27)
That's cool. When are you shipping it?
Amanda (57”30)
[Laughter] As soon as possible? We've demonstrated that you can actually start building your rules against lots of prototypes that we've done.
Nick (57:44)
Thank you. Any questions from the community? Jared? Ben, any questions from yourself? Are you good, mate?
Ben Blaine (58:05)
You put me on the spot there! What do you guys want to be […] adding to this app? I guess that's one question. The other question would be, what kind of users do you have in mind? Like your first segment of users? Are those things you've thought about?
Amanda (58:26)
Ockert, do you want to answer that?
Ockert (58:38)
Sorry, I didn’t catch that.
Ben (58:40)
Have you had any thoughts about what you would want to add to this app? Or how you would want to extend it? And have you had any thoughts around a segment of users that could be a good segment for early adopters or an interesting segment?
Ockert (58:56)
At the moment, our initial idea was for everyone with an account should have access to this. [We need] to market it in some kind of way. Maybe discuss it with Investec. […] If we can maybe hook into them. Maybe we can have a look at that. Otherwise, maybe like Google ads or something to get people to come in and join us. But there's a lot of things we can do with this, because essentially, it's that hook sitting inside the API. We can stop and start a lot of things from there.
Amanda (59:41)
And obviously, our target audience for this solution is anybody really. You don't really have to [have a] technical solution. Because, you know, we write the code behind it. All you have to do is use a GUI to just configure. So, I think you know [indistinct] people will be a great start for us to get started. Also, to test and see, what are the frequently asked things or what are the frequently configured rules. And then we can add these to our suggested template based on what gets configured frequently.
Ben (1:00:21)
Cool! Makes sense. Really well done.
Ockert (1:01:04)
We did talk about doing templates like Amanda said. There are some basic rules, you can add, like your card can be used between 12 and six in the morning; [or] a card can't be used for outside of South Africa unless it's during this time. So, there are some templates and things we could do. It will just give us easy wins for whoever signs up for us.
Michael Louis (1:01:35)
When you start rolling this out, what do you think the revenue model will look like? Do you think you'll pay per user per card? Or do you think you'll take a percentage of transactions that are executed?
Devendran Naidoo (1:01:50)
Can you guys hear me? Yes? Sorry about that. Yeah, we haven't given much thought about the actual revenue model. The initial aim is to get it to as many people who can benefit from it now. I think, later on, we'll try to figure out how to monetise it. But for now, if it can help people Yeah, I think that's the real win.
Get involved in the Programmable Banking Community
If you have questions or just want to say hi to the Programmable Banking Community core team, you can pop us a mail and we will get back to you.
If you want to see more from what the community has been up to, you can: