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, Adam Fisher shares how he built a bridge solution that enables a single point of contact for approval, determination and secure transaction forwarding to other APIs using the AWS Cloud Development Kit (AWS CDK). Check it out here!
Click here to download Adam’s presentation slide deck.
You can find his his dev guide for working with AWS CDK in Typescript on GitHub here, and his command centre bridge GitLab repo here.
Transcript of the demo
Adam [00:12]
My name is Adam Fisher. I’m currently working for a company called Industrial MicroController Applikationen. I’m translating. It’s a German marine tech company.
Adam [00:30]
I have a wide ranging history, everything from mainframes to fixed-wing combat aircraft. I’ve touched a lot of things. I don’t think I actually introduced myself to the group. My specialisation is not specialising. I touch all sorts of new things. My main intention when signing up for the programmable bank cards was actually to find a way to connect it to crypto.
Adam [01:05]
But seeing as I need EFT access for that – open EFT. I decided to do something a little more community-focused in the meanwhile, and what I’ve seen immediately is that there are a lot of interesting command centre projects. But there are only two seconds to run approval logic, and lots of things to do. And lots of interesting projects that you guys have demoed, already.
Adam [01:30]
What I’m providing here is a secure method of approving transactions with multiple data sources and destinations. This is the basic architecture, one API gateway, lots of lambda functions, and SQS on the left side there and DynamoDBs. The intention was to be as serverless as possible, which I went for scalability, performance, and cost.
Adam [02:02]
But also, I would like this to be easily maintainable and deployable, by any of you. I’m currently running on a dev stack. But the intention is that anybody can set up their own stacks, quite simply. And what I mentioned earlier, is that I was actually hoping to demonstrate a CDK deployment. But, as of this morning, CDK started doing weird things. I’m not going to do that live.
Adam [02:37]
Okay, let’s go to the actual demo.
Adam [02:48]
I’m not going to demonstrate logging in, registering. It’s the same mechanism. All you need is an email address. Mobile hasn’t been implemented yet. You’ll get an OTP, and you will then verify with that OTP, which once you’ve authenticated, will give you a token. My JWT token is already set up there. In fact, it’s for half an hour, so it’ll be fine.
Adam [03:22]
The interesting things to do – first let’s just list cards and make sure that I don’t have any set up for this. Good, I deleted my card. Let’s add a new card. You can put in any card number, it’ll only take the last six digits if it’s longer than six. And, it will make sure that each user doesn’t reuse either a card number or a card name. Here, I have my card ID and my API key, I’m just going to set up postman to use those for everything.
Adam [04:09]
Of course, clicking fails. There are a few things that are protected by JWT token. Then, there’s a whole lot of functionality that’s protected by API key and card ID only. When you integrate this into your Investec programmable bank card, you only need to set up the card ID and the API key, and you’ll be able to manage those requests.
Adam [05:00]
If you have any other sources that are going to update things like your limits, your card limits and pre-authorisations, those things will be able to interact with this bridge via card ID and API key as well. There’re very few things that you really need to have the JWT token for, that’s in particular for adding cards and reviewing cards.
Adam [05:26]
And then, we have to set up the forwards. Here, you’ll see there aren’t any forwards set up. And now what a forward is, it’s the details for any API endpoint with its headers so that the transactions can be forwarded to those addresses. As an example, I have on a completely separate stack – I have an endpoint that just accepts data, whatever we send it.
Adam [05:56]
I’m going to set that up as a forward. As you can see here, you set the URL, choose whatever random headers we want and click send. This is now updating the card with those effective credentials. One thing is that from a security point of view, the users cannot be traced back from cards in as far as the data scheme is concerned, and any credentials that you put in here are all going to be in ASS256 encrypted with the API key.
Adam [06:34]
At rest, there is no secure data stored by the system. And that includes when you add a card. The API key, I don’t store the API key. I only store the hash of the API key and the card ID. If you don’t record the API key when you create the card and you lose it, you’ll have to reset, you’ll have to renew the API key and delete your forwards.
Adam [07:13]
Now, just to verify. Now we have these forward set. There we go.
Adam [07:21]
I can view these because I have the API key that I’ve sent to this endpoint. It’s predicted with JWT and the API key in this case. And now I’ve got the forward set. Now, I’m going to set the limits that I want. At present, there aren’t any limits set on the card. If I click on approve, everything will just be approved.
Adam [07:45]
I’m going to set a transaction limit, which is simply a limit for each transaction. Here, it’s R50. And then you can set a daily limit, in this case, I’ve put R250. And, those are now, my regular card limits. Which can be updated at any time, they’re set. They’re tracked separately from the amount of money that’s spent on the card. For those, well, in this case, for daily usage, I’ve set those limits.
Adam [08:19]
And now if I click ‘approve’, we’ll see I’m going to try and approve – or this obviously could just be the whole transaction sent from the programmable bank card – if I try and approve this now, then it will fail, and it will fail because the transaction limit is lower than the amount that you’re charging. Let’s add a pre-authorisation. In this case, I’m going extreme. Wow, that was silly. I didn’t actually, no wait this is next month if I’m not mistaken. This should work. I’ve set this pre-authorisation.
Adam [09:04]
And now, if we’re trying to prove again, it will go through. Now, this is just approval. The approval will not update any of your limits, including your pre-authorisation. That will only happen when you relay a completed transaction. Let’s relay a completed transaction.
Adam [09:36]
I forgot to show what happens in the background. This is the endpoint that I set the forwards to, and here we can see the approval. And here we can see the completed transaction. Again, this payload is whatever you send it and it’ll be forwarded to wherever it needs to go. And it’s done in a separate process.
Adam [10:06]
So, it doesn’t take time from the approval. And the last thing to show if there wasn’t anything more, a failed transaction will also be sent through. And then there’s an approval warm-up because the approval takes anywhere for the first call between one and a half to three seconds, which is obviously too long. But once it’s warmed up, it takes anywhere between 6 to 800 to 1.5 seconds.
Adam [10:43]
That should be fine. There we go. There’s the failed transaction.
Adam [10:55]
That is the technical part of the demo. I don’t think I’ve missed anything.
Adam [11:04]
Challenges encountered, as I wrote, lockdown with a four-year-old. I’ve been working on this for a couple of months. But in reality, it’s only been a couple of hours a week. The AWS CDK learning curve is very steep. This is my first time working with cloud concepts.
Adam [11:23]
Aside from having to learn all the nitty-gritties of AWS and figuring out CDK the hard way, because the documentation is all over the place, I also had to translate my initial strategies and revise a lot of the things that I was doing because they didn’t really make sense for cloud. But here’s the get involved slide.
Adam [11:50]
This is my contact card, please anybody feel free to contact me via any of these routes. And, there are two projects that I’ve been working on for the last couple of months. The first one was actually writing a dev guide for working with AWS CDK in Typescript.
Adam [12:11]
If you’re looking to get into that, that’s a good place to start to get familiar with how everything works. And then I’ve been translating back and forth between that and the command centre bridge because I’m using the same concept. And I am looking for you guys to get involved because I’m really hoping that you guys will be using this.
Adam [12:33]
The other thing is completely unrelated and a shameless plug. I’m busy adapting Shakespeare sonnets into a graphic novel, and I would be grateful if you guys would take a look and maybe even contribute.
Adam [12:51]
Next steps. Scheduling warm-up calls that should be easy. That’s part one of improving the approval performance. Step two is trying to improve the approval performance by other means. I would like to add unit testing and make sure that everything works well before deploying to CDK.
Adam [13:11]
Although I am using the stacks in a way that I have a prod to test – maybe a bit of overkill in a dev environment. I would like to include a simple web interface, although as you’ve seen, everything is designed to be working with other solutions. I’m not sure how necessary that is, except for the basic setup.
Adam [13:37]
The pre-authorisation at the moment takes the closest pre-authorisation that’s viable. But I would like to lock it to category and vendor as well and add more interesting card limits. At the moment it works with daily and monthly but I would like to add weekly as well, but I have only implemented the daily and monthly today.
Adam [14:04]
That’s why that’s not done yet. I’d like to use a pretty URL, which is just another thing that I need to figure out with CDK. I would like for the transaction forwarding object mapping to be able to have the user provide a map for the data that comes from the programmable bank system, so that it can be reformatted, depending on where it’s being forwarded to. And then finally, because I really don’t think it’s that important, maybe you disagree, but optional login passwords, in addition to just the second-factor authentication, and that’s it.
Adam Fisher is an experienced analyst, architect and polyglot developer who is thoroughly obsessed with bringing Shakespeare's Sonnets into the 21st century. He enjoys adapting to new contexts and paradigms and takes pride in being "constructively lazy". He is currently on contract with iMCA GmbH, a marine transport engineering company, and has worked on a wide range of technologies from HR to advertising, mainframes to avionics.
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, pop me a mail.