In this meetup, the Investec team share an update with the Programmable Banking Community on what new systems have been put in place. They also do a product walk-through of save/publish code and discuss a few other features that are coming soon for programmable cards. Finally, they host a discussion around OAuth ID management and the potential of adding payments to the API in 2021.
Click here to download the presentation slide deck.
Transcript of the demo
Wayne [25:39]
This is the first big update we've done since launching programmable banking, so I think we are going to give you a bit of a feel for what's happening, and what's next down the line.
Wayne [25:56]
How's that for a picture of my team, you can see them all. We had a guy from Spotify a while back – one of their development people that work on their culture – and they had the most amazing quote that I was trying to find.
Wayne [26:16]
I've re-constructed it myself because I couldn't find the quote anywhere, but it is a quote from Aristotle that says, "The whole is more than the sum of its parts" – and in the context of what he was trying to explain is – you have a team, and you have five really good people in your team. They're not the same as five good people, because the team adds more value than the five people.
Wayne [26:35]
It's the sum of the interactions between those team members that is where the power of a team comes from, and I think that's what's relevant in the context of this product.
Wayne [26:44]
Five devs, randomly doing stuff on an API can't compare at all to the awesomeness that is in this community and the stuff that we've seen being generated out of it. I thought it was quite appropriate because this community has done some mind-blowing things.
Wayne [27:00]
Does that make sense, or was I just mumbling there like a mad thing? I thought it was cool.
Wayne [27:09]
What is new since we launched. Very quickly after we launched programmable banking, the card part of it everybody said, they want OpenAPIs, ironically. So, after all of that hard work with a card, there's a lot of good use cases around the card, but the big task was to launch the API, and we didn't anticipate having an OpenAPI that quickly. We put all our gear in line to just go and launch that OpenAPI.
Wayne [27:42]
If you're new to this community, you probably think it might have been there from the start, but it has only been there for six months or something. It hasn't been there from the start of this project, and we have done a lot of the work just getting it up and learning what it is to have an OpenAPI.
Wayne [27:58]
I like talking to clients about all these things and looking at all the stuff we could expose. There have been many bug fixes, especially on the programming banking editor part as it was something new – we didn't know what we were doing from the start so we had a lot of good feedback from the community on what would help the editor and that has now been updated.
Wayne [28:21]
I think it was really powerful because when we first got the editor it looked fine, but I think there have been some amazing enhancements that have come through based on actual use cases.
Wayne [28:32]
We added a date filter, and transaction dates next to the transaction endpoint. This was just so that you don't have to pull all your transactions every time. I think previously, it used to be a 30- 60- 90-day thing and if you were polling for [], this still makes more sense.
Wayne [28:50]
Initially, and we still know there's a problem with the transaction ID thing, but I can give you a bit of a spiel later about that in the what's next space.
Wayne [29:00]
We added the running balances on transactions, so you can see your actual balance going up, and we added to keep alive on the lambdas. Anybody that's done some of these things will realise that when those lambdas die, and you call it – it bypasses the two-second thing, so we had to make sure that the lambdas were staying alive constantly to let you stay within that two-second state.
Wayne [29:24]
Internally, which nobody saw, we migrated all our program banking infrastructure to Kubernetes and then, more recently, we had some blockers on the API for some user agents that weren't whitelisted. This sits on top of another system with a magical white list user agent, and we had to go and add some new ones because we didn't see all the stuff coming through, and you did all of that work. Then obviously the CORS. I don't know if anybody wants an explanation on that one.
Wayne [30:00]
If you're not Investec talking to the API, you need to enable CORS, and we've done that work recently.
Ben [30:09]
Maybe explain what CORS is for everyone?
Wayne [30:13]
CORS is cross-origin resource sharing, and basically what it means is if I have an API, and I'm trying to talk to the API and if my domain is not the same as the API one, it sort of thinks it's dodgy because it's a third party trying to access your domain. If I built wayne.com, as an API, and I built my website wayne.com, and it talks to my wayne.com API life's great, but if I start talking to peter.com, – peter. com would say, why is wayne.com talking to me.
Wayne [30:46]
What this allows is other domains like peter.com to use my API. It's a very dumb explanation, but it explains it.
Ben [30:58]
Most of us are going to go check out what wayne.com and peter.com look like.
Wayne [31:03]
They don't have domains – they don't exist.
Wayne [31:10]
Then we did lots of work with OneCart, and that was the first real business client that we onboarded, and we did some cool stuff.
Wayne [31:22]
That's been the journey for the last, six to nine months. Some of the challenges we encountered were that we quite a small team. I am not sure if you know, but it is me, Willem and Ernst – they're all on the call, and Devina, who was supposed to be here, but she moonlights as an RBA some days. It's not a big team, and we have to work within the confines of a bank.
Wayne [31:53]
We're also accountable for all the API gateways within the whole domestic group, so this is also part of the job. As much as we would just love to do this constantly, I think we have a big backlog, a small team and that's always going to be a challenge to get the right stuff prioritised in that environment. I'm sure that is a problem almost every IT team has on Earth right now, especially with COVID.
Wayne [32:18]
We have a dependency on others, for example, with the transaction ID. We rely on downstream systems to expose data files to expose that via gateways. If we want changes to some of these, packets, or the payloads, we have to go and beg, borrow, and steal downstream and get people to do changes so that we can do these things.
Wayne [32:39]
We’re not a holistic team that can change everything top to bottom, there are many different layers in the bank, and you have to work your way through it – through political manoeuvring.
Wayne [32:53]
When we launched the editor, for programmable banking, we found ourselves in a situation where it was quite hard to troubleshoot some of the stuff. We'd get errors, and we had to put in some added work to get better logging and include why it's important to troubleshoot some of these issues.
Wayne [33:11]
People would tell us the code isn't running, but I don't know why. That took a bit of time, especially in the beginning to just get us up to speed. I think we are semi-okay now. Next, I think Ernie, are you going to do a walkthrough on some of the stuff that's coming?
Ernst [33:33]
Yeah, just getting everything running then I will screen share.
Wayne [33:42]
Must I stop sharing?
Ernst [33:44]
Cool.
Imraan [33:46]
Wayne, while he's doing that, can you explain a little bit more about OneCart. I'm not sure why, but I don't understand what that was all about? Is it something that we can't use?
Wayne [33:57]
I'm not sure how much detail I can talk about?
Ben [34:02]
Michael did give a demo.
Ben [34:05]
Oh, yeah. OneCart is a company that if you don't want to go to the shop, you can get their app, and say go to Woolies and buy me my bread instead of you going to the shop. They are using this as a fraud prevention engine because people were buying things that weren't really on the list to some extent.
Ben [34:29]
They have a database that says, this guy is going to Woolies and is only going to buy bread for R30 on the programmable banking card, and when he swipes it does all the validations on it. It was a really good use case.
Imraan [34:42]
Okay, I think I must have missed that week when the demo was done. Thanks.
Ben [34:48]
Yeah, it was an interesting presentation from Michael. It wasn't so much a demo – more what they sold. I'll share the link with you afterwards.
Ernst [35:01]
Can everyone see my screen? Some of the changes that we are releasing soon will be a safe published change. It's been a long time coming, but I'll do a proper live demo, and hopefully, everything holds up.
Ernst [35:28]
You can now save and deploy your code separately. I'm just going to do a quick console log here to show you how it works. Whoops, hello world from the card, save that, deploy it, and if I simulate the transaction you can see there, obviously, you guys know this standard simulation, but what you can do now is change your code, just save it – it's not deployed to the card, simulate the transaction, and if it all works, it should look like it saves.
Wayne [36:29]
Maybe just for a second, while you're waiting - the problem we solving here and I don't know if everybody knows about this problem but from the start, when you wrote code, and you simulate, and you hit, it goes to production that simulated transaction because there's not a separation of concern between the code you're writing and the actual execution of this emulator.
Wayne [36:50]
This was important for us to start getting it right when you're debugging and testing your code to be able to simulate it without actually running it through the production system.
Ernst [37:00]
Yeah. Now you can see it is executing that code and not what's deployed to the card. We added the lead source code here, and you can then switch between the two. I've now switched back to the code that's actually on the card; it's a very simple way just to be able to test your code without actually deploying it to the card.
Ernst [37:31]
Then part two of the changes that are coming are the after-transaction change. You'll see there's a couple of additions to the after transaction now, you get to see the whole amount, and the currency code.
Ernst [37:49]
If you have a transaction that's in USD, you'll be able to see the USD and the ZAR values. That's the first change, the second change, we have now added this response status – a code and description. This is the response back from the card system, so you'll now be able to see what happened if the transaction was declined and the before-transaction. I will demo one now. If I make a change here, let's say that will return a false – simulate the transaction – I should have waited for it to save first.
Ernst [38:58]
There we go so authorisation is false there. If you go to the event logs, then after the transaction you can see, it's false, and it was rejected, so that's the response you get back from the card. Those are the two menu changes that are coming soon.
Imraan [39:22]
I have a question. Those response codes, do you have a list of the possible response codes that we could get?
Ernst [39:32]
We could get that for you. Those are the actual response codes on the card system.
Imraan [39:41]
Even if it's just ranging, like the 900s are errors or the 300s mean, this, or that, you know what I mean. Even if it ranges, it would be great and maybe just add that to the docs. That would be awesome.
Ernst [39:54]
Yeah, we can.
Audience member [39:56]
Instead of just returning a false, can you return a false and description, or is it just the false?
Ernst [40:06]
On the authorisation that will return a false.
Audience member [40:09]
No, no, the before-transaction when you are rejecting it can you say why you rejected it?
Ernst [40:21]
You will only see that in the after a transaction, the actual reason.
Wayne [40:26]
No. If you go to the main js Ernst – the question is, can you only return a true or false or can you expand it with the description so that you can when looking at the logs, track that.
Audience member [40:46]
For example, it's not enough or you over your limit or something, and you failed the validation whatever the reason is for the fail.
Wayne [41:00]
Essentially, our card system will only act on a true or false; that's the whole idea behind this is to tell the card system whether they should reject that transaction. You cannot expand it with a bit of meta.
Ernst [41:20]
However, if a transaction hits the card limit, you will see it in this list of response codes and descriptions.
Audience member [41:27]
Yeah, but that's the card. That's the physical card, right, not a customised limit that you've set up because it's a Woolies transaction, and you don't want to spend more than 50 bucks at Woolies.
Wayne [41:40]
Let me give you some context why that would be so strange and why we wouldn't do more in that return from the main .JS.
Wayne [41:48]
This routing engine plugs out of the card and does a call into AWS lambda, as you can see, this is part of our model. The only thing that affects our systems is that true or false, we wouldn't send anything else up and down, because then it opens up possibilities of you injecting a payload or doing something else.
Wayne [42:11]
We got a pass, some of the regulatory security problems in the group and I am saying that we will always return it to run a true or false and we won't ever let anything communicate outside of that lambda except the true/ false flag.
Audience member [42:24]
Okay, okay. Yeah, that's cool. Okay. I just saw that there was some sort of meta attached to it. Okay.
Ben [42:35]
I don't think anything stopped you from making a Google Sheet and publishing your own return reasons, for example.
Audience member [42:42]
Yeah, there are other ways around it. Yeah. Okay.
Ben [42:48]
Are these response codes not available publicly somewhere?
Ernst [42:54]
I don't know. I'll have to find out for you.
Ben [42:57]
I doubt it. Hardcore card system response codes.
Ernst [43:06]
We should be able to get the whole list that affects the actual card transaction. I see Adam asked a question on the simulations, are they closer to the actual card transactions. It's still a simulation at least now it responds to the code from your before transaction, and your after transaction.
Adam [43:37]
The question I'm asking is, can we now reasonably expect that if this works, if this behaves in a certain way in simulation, that it will be fine in production? One of the issues that we had was that things were working fine in simulation and then weird things were happening in production, code declines, and so on.
Ernst [43:58]
Yeah, it's there. It's probably as close as I can get it at the moment. It doesn't run through the card system itself. It does the same as the root engine that's running in production and simulating as close as, I can, currently.
Ben [44:21]
I think just to have some context as well, the simulator, is predicting a perfect world scenario if the world was beautiful, and the system acted perfectly, that would be the response you'd get. The reality is, and we've seen it with all the use cases, card systems are doing some strange things at times and behaving weirdly. That's very hard to predict, the complexity outside of that thing.
Adam [44:47]
That makes sense. That is perfectly fine. That wasn't the problem. The problem was that there were code issues. For example, they were in the guide, in the documentation and the simulation, was operating with certain responses, not responses, but they were raising certain events, and production was raising different events. As long as I can be reasonably sure that my code will behave correctly if it's running fine in simulation, I assume that the real world will have different things to offer, but I want to know that the code is reliable because I've tested it with the simulation.
Ernst [45:30]
The case that you're talking about, for example, was when it was triggering that after a decline. All of that has been stripped, and it's either the before-transaction and the after a transaction.
Adam [45:41]
Yeah, that was a big difference. Okay, great. Thanks.
Ernst [45:46]
Yeah, we've changed that.
Ernst [45:50]
Okay, cool.
Ben [45:55]
A question that came up in a welcome call the other day – is it possible to get on the OpenAPI statement, if it's a foreign currency transaction, It doesn't come through what the original transaction amount was. I know this isn't exactly programmable card, but it's more pertaining to the OpenAPI statement.
Wayne [46:17]
I think that money settles into your account in the currency of the account. If you have a proper bank account, and it's a ZAR account, the transactions would go in there, and, always, it's not like there's a makeup flag that says this came from a USD deposit. There's a process that happens before the money hits your account, which is this balance of payments process in South Africa, where the money goes into a queue where there's a process that happens, and it converts it from Dollar to Rand, and then the Rand lands in your account.
Wayne [46:44]
I am not sure on the EFT site, or with that type of payment if that's possible on the card, and I'm not sure if they keep that data on the transactions themselves. There are two systems involved here. You're not going to get perfect like for like between card and an EFT type of transaction, but we can look, maybe for a card, there might be a way.
Ben [47:08]
Yes specifically for card transactions and just to see that info again, on the statement, because it was a business that was going to do logging of transactions to a receipt bank storage thing, and they wanted to keep the difference between the original currency charged and the final amount.
Wayne [47:27]
The current API doesn't have it, but we can look at my before card transactions that can be available, but I'm not sure. Willem, have you seen this before?
Willem [47:34]
We get all the transactions from the same business API, so I guess what I'll do is a bit of an investigation around that and see whether there is something that they can do to provide us at current, but essentially, all transactions that happen against your account get fed through from the business API. If it's there, then happy to share it, or include it otherwise, yeah, it might be a difficult exercise.
Ben [48:07]
Yeah, we could also reverse engineer it using the card stuff. That's good.
Wayne [48:15]
Now that the currencies are in that core, you can build your little spreadsheet on the side as you say. Yeah, I don't know if that's useful. Okay.
Ben [48:26]
Cool. Are there any new, or more updates from your side?
Ernst [48:33]
I think it's just sharing the upcoming stuff and the stuff that we are currently busy with perhaps.
Ben [48:46]
My team was saying, does the amount charged to your account, and the amount that comes through in ZAR or goes off in ZAR is on the statement because this guy was showing me on his actual statement that he downloaded from Investec online, that he could see the USD amount and the ZAR amount so I don't know if that means it's possible, but it is on Investec online apparently as far as I can remember.
Wayne [49:16]
If it's on Investec online, then the chances of us getting access to that are fairly good.
Ben [49:23]
Okay, cool.
Wayne [49:24]
We are essentially consuming the same stack of business API from an OpenAPI perspective.
Willem [49:33]
Just to be transparent, it might be quite complicated that one, because when you go to the airport, you swipe and they say, do you want to do it in Rand, or do you want to do it in Dollar, but they asking which company is going to do the effects transaction so if you do ZAR it might go to Investec or it might get that conversion on our site, but if it's more upstream, I'm not sure if we'll always get it. I am not sure how that stuff works because somebody else is doing their forex there. That might be quite complicated.
Willem [50:02]
Okay, we'll have a look, nonetheless.
Wayne [50:04]
Yeah. Thanks. Okay. I've done lots of talking. William, do you want to take this one?
Willem [50:11]
It's fine. Something that we've been mentioning, fairly often in the recent meetups and essentially the big issue here is, once you've got OAuth creds, that's cool, but you cannot go and revoke them or regenerate them. That's the one limitation.
Willem [50:34]
The other limitation is when using those OAuth creds that we issued you when you use that to go and fetch a list of accounts currently, it will only return the accounts that are linked to your default, Investec online banking profile and that's obviously, quite limited.
Willem [50:34]
The stuff that we are currently busy working on is to mature that implementation and create an area within Investec online dedicated to OAuth credential management that will essentially allow you guys to, first of all, generate multiple OAuth credentials. You might want to have multiple or various credentials for various apps or integrations that you're building.
Willem [51:27]
From a consenting perspective, when requesting a new credential, you can select any of your Investec online profiles, and then any accounts within those profiles. That will essentially allow you to do structure that a lot better. That's also again, part of other integrations that we are busy with.
Willem [51:57]
We want to streamline that all together and create a proper place for that. I think the rest of the stuff is apart from the unique ID for transactions, as Wayne has mentioned, that is very much in play. However, we are very much dependent on other teams, but we are constantly pushing to get that done.
Willem [52:22]
I guess the consensus was or the main principle was always not to generate a fictitious transaction ID until such time where the actual downstream system would provide us with a proper transaction ID because that might render some of your implementations redundant or cause it to break.
Willem [52:45]
I think from a single codebase - I am jumping around, obviously not going in sequence here but in terms of a single codebase, and multiple cards, that is very much again, a feature that we saw with OneCart. You can imagine the OneCart implementation, having to apply the same code base to multiple cards might become a bit of a maintenance nightmare. What that entails is just having the ability to say, okay, cool, I've got this one piece of the code base, and just broadcast it to any or selected cards.
Willem [53:26]
The improved login was something that came to light out of our OneCart implementation, and the fact that the context has been persisted in the logs is quite limited. We are looking into expanding on that.
Willem [53:45]
Then the obvious elephant in the room here is the API documentation. Again, as I've mentioned, the documentation that you currently have is very much this stuff that was published an hour before going live with API. It's getting to a point where it's matured and will be published in a proper developer portal.
Willem [54:13]
Then I think it just talks to documentation in general. We are very much aware that our documentation is quite limited. There's a lot of work to be done there. That is something that we're going to be sorting out for you guys.
Willem [54:29]
The after-transaction features, I think that's the stuff that Ernie demo'ed tonight, chip in if I missed something there.
Ernst [54:40]
It's part two for that. One of the issues we've picked up on the OneCart implementation is occasionally they'd swipe a card and the point of sale times out, and it triggers a problem that I see in the programmable card logs.
Ernst [55:07]
We are looking at how we get those reversals so that you can check for that reversal in your code and then we're having a look at some of the other conditions of what happens on the card system versus your code that's executing. We're having a look at a couple of those kinds of things and seeing how we can incorporate those into the after the transaction so that you can cater for it in your code.
Willem [55:40]
Cool. Yeah. There's a need for developers like yourselves to have the ability to build an app for somebody that is not using programmable banking. The primary restriction there again is in the UK open banking context; you've got, the PS2 regulator that makes sure or that ensures that the apps consuming is valid and solid.
Willem [56:17]
The problem we've got in SA is if we had to allow any app on our platform, which would very much be regulated by us. We're trying to get our heads around, practically how we can make that happen in a safe and secure manner. That is worth investigating, and that is something that we want to give, we just are not 100% sure how we're going to regulate that.
Willem [56:46]
Then the big ask is always a payments API. Some of the stuff that we've been discussing recently from a technical perspective, we believe that if you had to expose an endpoint that would allow you to transfer or make a payment to an already pre-configured beneficiary, or make or initiate an inter-account transfer, let's say, for instance, every time you make a payment, or you buy something, you round the amount up to and you transfer the difference into, your prime saver account, we believe that the risk is mitigated.
Willem [57:34]
There's a lot of loops and stuff to jump through still in that regard, especially with our legal community, our info and cybersec community but those are the two things that we're going to, start prototyping and investigating so that we can take it to our legal community. Hopefully, if all goes well, we will get some buy-in on that, because we believe that shouldn't be too much of a risk.
Willem [58:06]
I think I've covered everything on the list. Is there another slide or is that it?
Wayne [58:22]
That's fine. Sorry, I'm fiddling here as my internet connection is unstable, it says.
Wayne [58:30]
I'm going to try and talk but if I blank out Willem just jump in and pretend this is normal. So one of the questions we've been pondering and we have seen the community build it out, but when you're doing calls outside of that editor to the outside world and then using any language you want to go and consume the before or after transaction and do stuff.
Wayne [58:52]
The question is that useful, or would it be more useful just to expose those events as webhooks and then let you do whatever you want with them? It would save us time trying to build you a Visual Studio, so that's just an open question. Is it valuable to have the editor inside Investec online or should we focus on just getting, not only those web books, but we’re also looking at potentially, the EFT webhooks exposed?
Audience member [59:23]
You'll get unanimous webhooks.
Willem [59:27]
Yep. Yeah. I also think something important to note or to know that the idea or the plan is not to replace the editor with webhooks. I guess you'll always have the editor. 90% of the use cases are keeping the code in that editor very, very lean, so essentially, the before-transaction thing just makes a call out to an external system that you maintain and manage.
Willem [1:00:01]
That's something also that came to light during one of our planning sessions recently, do we go in, evolve something that you might actually never use or do we just give you another piece of functionality where you can register various webhooks that triggers on those two events.
And yes, we've got our answer.
Wayne [1:00:28]
I see Byron did a poll for us, I'm sure the answer will be obvious, but that's fine.
Ben [1:00:36]
I think it's easy to say webhooks as well because we have an editor.
Wayne [1:00:39]
It might be as simple as just your default code is a call out into the webhook, and then we just go from there, then we don't have to build anything more inside.
Wayne [1:00:56]
My question to the community are there any features that you think would be valuable that you haven't seen in this presentation? We can chat through that.
Imraan [1:01:03]
Yeah. Wayne, I have a question might not be a feature request, because it seems like you guys are building on it. Earlier in the week, a friend of mine called me, he saw some of the blog posts that OfferZen was putting online and he looked at some of the Python API.
Imraan [1:01:20]
He's not part of the community, but he runs an accounting platform for lawyers, specifically targeted for lawyers. Currently, the lawyers have to download the CSV files, fixed files and import into his platform, so it's typically what an accounting system would do. He wanted to know and found out that about 13 to 15% of his clients are Investec clients. Could he use the API, the OpenAPI instead of his clients having to do this manually, can he just hook into it.
Imraan [1:01:58]
I told him it's not as easy as that, because he needs the OAuth details, and they'd have to enrol and all that kind of stuff so having the features that you're currently building like the OS identity management, or third-party management where do you think something like that would fit in, in a proper legal matter.
Wayne [1:02:18]
It's quite interesting. We had one of the community members build integration into Sage already.
Imraan [1:02:26]
That was me Wayne, but that's because I'm part of the community and I have access to it, but he doesn't. He is writing something completely different and is not part of the community, and his clients are not going to give him their secret keys, and client id's obviously, so we need to figure out what's the best way for somebody like him to utilise the OpenAPI.
Wayne [1:02:47]
That's exactly the point we had earlier, sorry, for my blonde moment there, okay.
Wayne [1:02:56]
That is exactly what William was explaining there – that third party apps – how do we get people to go through the three-legged OAuth steps that are not in the community because that's really what you want.
Wayne [1:03:06]
He's trying to go into the accounting software, and link it to an Investec account, then redirect them to the Investec login, enter a username and password, and create it and then share my data. We deliver it back to him with a key, and he is integrated into the API where he can apply for a bearer token and all of that stuff.
Wayne [1:03:30]
The issue we have there, and Willem spoke about it, but it's quite a hectic issue. How do we know that when people publish the third-party apps that are using our three-legged OAuth are not dodge, because it could be a nasty phishing attack if you think about it?
Wayne [1:03:45]
If you publish an app and say, talk to Investec – we redirect you to the Investec login page, but actually, it is not the Investec login page but some phishing site, and he puts in his credentials there, suddenly Investec is being held accountable for your app asking credentials to a 3rd party. We need to try and figure that one as well.
Imraan [1:04:06]
What if we didn't go with a third-party option, right now. Let's say you guys did the OAuth identity management, could he's client go to Investec online and create the OAuth credentials that have read-only access to an account. Then give those credentials to him to use on the OpenAPI. Will that be legal and safe?
Wayne [1:04:28]
I'm not sure it's legal or safe, because he's going to have to copy and paste it and email it to his buddy and that is not safe at all.
Adam [1:04:37]
Would it not be possible for you guys to do some level of vetting and produce a list of trusted or relatively trusted third parties. The moment somebody is trying to log in to get these credentials, they'll get a warning that says, Please make sure this is your responsibility – check that they are on the list.
Wayne [1:05:03]
100% Adam, that's the work we need to do, that terrifies the banking people, especially when you start talking about maybe opening it for payments one day, that just makes them freak out. It's something we want to do. We just need to do the work and get our compliance, legal, blah, blah, all of those people to look at that and if they are going to be happy with it.
Wayne [1:05:22]
We will need a vetted list from Investec saying we only trust these five apps, because we went to the creators of those five apps and we did some form of due diligence, what is their security like, and all of those things to be a third party thing.
Willem [1:05:37]
I don't know if you can hear me – I can hear you, but I've got a white frozen screen, but I'm leaving it alone. The way to get around that essentially is to onboard that third party application onto our OpenAPI platform, and through that process, we'll then obviously issue them a client ID and secret which they then have to present.
Willem [1:06:09]
To get user context, in that request, and essentially, the thinking at this stage is for the user to go on, to Investec online, and generate an API key for that integration. That third party will then identify themselves from a system point of view using the client ID secret, and then obviously, provide user context in the form of an API key that the actual user has generated from Investec online that we can maintain and revoke or whatever.
Willem [1:06:52]
At the same time letting those third parties into our world will be on us from a regulatory point of view, so in other words, we'll have to go through the due diligence in terms of how they're going to persist those API keys, whether it's in a secure manner and the rest. There's a lot of work and persuasion to be done in that regard.
Imraan [1:07:22]
Yeah, I think the safest route might be to get people who want to integrate to the API to register and get vetted. Then once you have that register list, only those people will be allowed. Then what you can do is as Investec assign those people an API key. They must still get credentials from the client, but they use their API key, so you know which provider is accessing the OpenAPI.
Willem [1:07:46]
Yeah, 100%. That allows us to track because that context will be included in our tracing logs and the rest so if there's an event, there will be sufficient data for us to track back and follow that incident.
Willem [1:08:07]
I think currently OpenAPI is read-only, and the fact that we don't expose any personally identifiable information, that helps us quite a bit, but this thing is going to evolve, and those types of interactions are going to become an admin nightmare.
Imraan [1:08:30]
Does that fall outside of the current feature set that you are building, or does it fall within the third-party area?
Willem [1:08:40]
The stuff that we are currently doing it's pretty much within the OAuth identity management part of the work that we're doing. It all fits together at the end of the day, so essentially, we are designing it in such a way that the same place where you are managing your keys, for your integrations is probably going to be the place where our clients will go to generate an API key for a third party.
Wayne [1:09:16]
Adam, just to answer your question about once of payments to unregistered beneficiaries, that's where the risk is for the bank – the biggest one. In the UK, they do a transactional second factor when you call the API and then do the payment out so we might have to think of something like that.
Wayne [1:09:32]
When somebody calls the API, we send an in-app to your phone, you hit accept, and then we pay it. That point is complicated. The beneficiary and [] we're hoping we can get over the line because at least you went into the website, you added it manually, and some checks and balances were leading to that call.
Ben [1:09:49]
I sound like a stuck record, but I'm quite a fan of this and that.
Ben [1:10:01]
I was just thinking, and you guys have heard me say this before if we can expose when I do something or send money somewhere, or you could just say action, I click the button, and it to posts my transactions somewhere, then third parties could register with this and that, and they could worry about the curation of third parties in the selection. Then we wouldn't have control over which connections are published so the third party would have to ask to have their connection published on the marketplace.
Willem [1:10:38]
Our approach is, and I can use the analogy when you boil a frog, you throw it in cold water, and you heat the water slightly you don't throw it straight into boiling water. What I want to do, and I think there's a lot of ways to get around this, but initially, we could allow you to facilitate an inter-account transaction for a maximum amount, or, the same beneficiaries. Then as we understand that, and as our legal community understands that, and become used to that, we can see, okay, cool, what's the next progression from there to make it a bit more useful, but at the end of the day, it's all about getting that, foundation in place and getting people used to it, and then levelling it up systematically.
Willem [1:11:32]
So just out of interest, I don't know if it's going to be useful for anybody, but the South African financial services contact authority, they've got a FinTech arm, and they're busy doing a document around open banking in South Africa. They are talking to banks around the requirements, and what that would mean, so it looks something like PS2 is coming. I'm just not sure if it's this century or not.
Wayne [1:12:01]
That would make our lives a lot easier because essentially, then at least there's, a regulatory technical standard that we can just implement, and everybody will be happy. At this point, we are flying solo.
Ben [1:12:18]
Yeah. Okay. Thanks, guys. I don't want to keep you all night. Appreciate the update, the sharing, awesome demo, thank you so much. Sometimes it's hard just to stop and celebrate because we are so consistent, at just running this meetup every week, people joining and you guys consistently working on these things.
Ben [1:12:41]
Sometimes I think people get excited about what's possible, but it's amazing that we're here at all and that we're still here so thanks so much for just putting in so much effort. It's amazing to see how much effort you guys put in compared to other banks, people I've worked with, and I won't mention names, not at Investec but other banks. So yeah, thanks, guys for making it possible and also to the community members who joined, especially the guys who come – it has been a long slog so thank you so much. Have a good evening, and we'll see you next week, hopefully.
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!