Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Presentations Open Banking - Tales from the Frontier

Open Banking - Tales from the Frontier



Anca Zaharia and Jason Maude focus on the successes and pitfalls Starling Bank encountered in building Open Banking. They cover topics such as the OAuth security flow, the permissions-controlled API, obtaining permissions for third party actions, and verifying payees between banks.


Anca Zaharia currently enjoys the challenge of developing risk and compliance systems for Starling Bank. Jason Maude works at Starling Bank as one of their lead engineers and host of the Starling podcast.

About the conference

Software is changing the world. QCon empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.


Maude: Anca [Zaharia] and I are both parts of the engineering team at Starling, and today we're going to talk to you about our "Tales From The Frontier," the lessons we've learned about open banking.

What is Open Banking?

Open banking often gets used as a bit of a catch-all term. When we were preparing this talk, I went online and tried to look up a succinct definition of open banking and couldn't really find one, so I made up my own definition, which is shown on screen here. Open banking is both a piece of legislation specifying particular APIs that have to be used, it mandates that certain of the bigger incumbent banks must provide this.

I want to talk today is about Starlings journey with open banking and that's not so much specifically about the legislation of open banking, but more about the philosophy, the general philosophy of open banking. That philosophy is about data, customer's data and how banks manage it. If you think about money, banks hold money for customers in trust, so people come along to a bank and they deposit their money with the bank and the bank can use that money in aggregate along with everyone else's money to make money themselves by lending it out, by investing it and so on, but ultimately, the money that a customer has invested, put in the bank, deposited in the bank, is their money. If they want to come on along and take it out, remove it from the bank and take it elsewhere, do something with it, then they can do and should be able to do that.

Open banking as a philosophy is that the same thing should be true of data, that banks do not own customer's data, they hold that data in trust and they should be able to profit from it in aggregate by being able to do things like work out, use it to detect where there are higher rates of fraud and so on and prevent that from happening. Ultimately, the data belongs to the customer and the customer should be able to take that data and share it with who they like.

Who Are Starling Bank

Who here has heard of Starling Bank? I'm going to hope everyone, most people. Starling Bank, we like to describe ourselves as a textile top with a banking license, we are almost 100% cloud based mobile only bank. Mobile only means that to get a bank account you get your mobile phone, you download the app onto your mobile phone, you apply for a bank account through the mobile app, and you do all of your banking interaction through that mobile app and it gives you all of the features that you would expect from a UK bank and some more that we think are quite innovative.

One thing crucially for this talk that we started out with, that we did from the beginning was we opened up a public API, we provided a public API and developed a platform for people who wanted to connect to their bank account programmatically, design their own apps to connect to their own bank account.

The general philosophy is that anything that you can do through the app, you should be able to do through the API and that's not universally true, but for the most part that is true. Anything that you can do through the mobile app to your Starling Bank account, you can also do through the API as well. This allows individuals to come along and connect up their bank accounts to their own code and allows them to develop their own apps so that they can interact with their bank accounts in their own way.

This is great, we've also extended that principle to the Starling Bank market place where we connect up to various providers of mortgages and investments and pensions and so on, providers of these other financial services and allow people to securely share their banking data with those third parties, connect up their Starling Bank account to a third party somewhere providing another service who need some data and to share that data between the two in a secure manner and not to share all their banking data, not to just allow the third party to come in and screen scrape what they like, but to share very specifically specific pieces of data.

The question is- that sounds all very nice and simple- what have we learned along the way developing this? What have we, you know, encountered? What are the problems we've encountered and overcome? What are the things that we've anticipated and headed off? What if you want to develop a public API for specifically a financial platform, what are the sort of things that you should do?

We're going to go through some of the lessons we have learned on this and here's where Anca [Zaharia] is going to come in and take you through the first lesson about our OAuth 2.

Understand Oauth 2

Zaharia: About two years ago when we first started thinking about implementing our public KPIs, the first thing we had to think about was how to secure them, so our first part of call was OAuth 2.

We had a look at the security standard and we considered the implications and we decided to implement it ourselves to secure our APIs. I'm sure that many people in this room already know what OAuth 2 is, but I'm going to explain it a little bit just to get everyone on the same page, and then I'm going to go through how the flow looks like from one of our partner's point of view with them trying to get access to a Starling customers' data.

What is OAuth 2? It is a open standard which empowers third parties to get access to a user's data without the user having to repeatedly hand over their credentials. Typically, it has four actors and on the right side, you can see the user in teal color, that guy is the resource owner and the guy that owns the data. On the left side, in light blue, you have the client, the third party trying to get access to the user's data and in between there's going to be one or two servers, the auth server, which will expose some sort of interface so that the client can I request permission to the user's data, and then the resource server will be serving the data.

In Starling's case, the user will be the Starling customer and the client will be one of our partners, so let's say one of our partners in the marketplace, and then in between you will have the Starling servers. Before I go on, I just want to make clear, I'm not a security expert, so what I'm going to say, it's not necessarily 100% accurate and I've actually left out quite a few details just to keep this brief. I just wanted to be able to assess the level of difficulty involved in implementing OAuth 2 if you want to secure your APIs with it.

That being said, let's start. I'm going to need you to imagine that you have two apps installed on your phone. You are a Starling customer, you have the Starling app installed, and you also have a partner app. They have quite the simple app, it just displays your balance with several banks you might have accounts with and one of them being Starling because you are a Starling customer. In order to display your balance with Starling, they will need to request your permission to do that, so typically, you'll click some buttons somewhere in the partner app and what happens is you'll get redirected to the Starling auth web app. The partner will have to provide their client ID, which they have set up with Starling before signing up to the marketplace, so that we can identify them.

What happens next is auth web app will generate a QR code for them. This QR Code will have their identity embedded and also what sort of permissions they are asking for. In this case, they are asking to see your balance and that will seamlessly get sent to the Starling app via another redirect and you as a Starling customer will have to login and review the permissions, so it will open on a specific permissions screen. You will see some details about the partner and what sort of permissions they are asking for and if you're happy with that, then you will authorize.

At that point, an auth code will get generated by the Starling API. That auth code is basically a link between the partner and the Starling customers, so it says that the partner is allowed to get access to the Starling customer's balance data in this case. They don't have it yet, a few more things need to happen, the auth web app will be polling for some sort of yay or nay from our server. If the customer has authorized, then they will get the auth code and they will redirect it back to the partner app via redirect URI again that they have set up with us beforehand.

That's how they get ahold of the auth code. You might think, okay, so now they have access to the data, right? It's not quite that simple, they still need to do a second step, which involves one of the partners' servers, so it needs to be a server to server communication this time. A partner API needs to call the Starling API and they need to provide not only the auth code, but also their credentials, so a client ID and also a client secret. This is important, so they need to identify themselves and we need to make sure that it's them who's calling our API not someone else. If everything goes well, then the Starling will send them back an access token and all they need to do now is use the access token to query the balance public API, the way they do that is they just stick it in the authorization header of the request.

This is an example of one of our partners in the marketplace and they are called Wealthify, they are an investments and savings tool. On the top of the screen, the second screen, you can see requesting permissions from the Starling customers, so they want to see some information about the customer and also their savings goals data, which makes sense because they are a savings and investment tool. What makes this a bit more special is you can see on the bottom, the third screen, Starling Bank is also asking for some permissions from Wealthify, so typically, the Starling customer will also be a Wealthify customer. In this case, we want to be able to display their balance in the marketplace, so we need to request some permissions from Wealthify as well. This is what we call the two-way auth flow, so what I explained before was just one way, the partner asking for some data from Starling and then the other way will be Starling asking for permissions to see Wealthify data and it's exactly the same thing but reversed.

You can imagine there are some requests which are a little bit more sensitive, for example, making payments. For those, we require our partners to sign the requests, those kinds of requests need to be signed with the private public key pair and this is for additional security. I just want to sum up this, if you're thinking about securing your APIs with those two, you need to understand the standard and even if you don't implement it yourself, if you go for a third-party solution, you should still understand the standard because it's your customers' data we're talking about and you don't want to get the integration wrong.

Just as a story, a random thing we've learned while we were implementing OAuth 2, it sounds obvious right now, but it turns out it's a very good idea to archive or delete expired access tokens. We have quite a few partners and they integrate with quite a few of our customers and so the access tokens will tend to pile up because they expire quite quickly. You don't want to end up in a situation where you have over few millions of access tokens in your database, nobody's going to use them because they are expired. It’s something to keep in mind in case you're thinking about that. With that, I'm going to hand over to Jason [Maude] who is going to talk about idempotent requests.

You Can’t Always Connect

Maude: You've set up your connection either from your own developed app to your own account or you've set up your connection between the bank and the partner application. The first thing I would say to consider here, once you've started getting things set up, the first thing after that is what happens when something goes wrong because something will go wrong, you will lose connectivity between the two things and if you consider this upfront, then you can head it off at the pass.

If you have your two fingers coming in and they miss each other, what happens? If your request doesn't get where it's going or there isn't a response, the response doesn't come back from the request you've made, what do you do? How do you tackle that? This is something that you shouldn't just consider when it starts going wrong in production, you should consider it upfront and you should discuss it upfront, the both parties in the connection should discuss it in the first place. because this is particularly important for finance.

In finance we want to make sure that we are reliable, we want to make sure that we are processing all of our requests in the correct manner. If the customer wants to make a payment, then it is important that that payment is made and it is important that that payment is made only once. In some respects, it doesn't really matter if a tweet goes missing, if we're thinking about the social media context, but if a payment goes missing, that is much more serious.

What shouldn't happen is the other thing that this picture indicates, which is finger pointing. One of the worst things to hear when you're trying to set up any sort of integration with a third party and the customer who's trying to use that integration to share data between their bank and this third party can't connect for some reason or is getting error codes, what you don't want to hear is the other third party going, "Well, it all looks fine on our end." Great, fantastic, it all looks fine on your end, but the customer obviously can't connect, so I urge you, if you're in the situation, expunge the phrase, "it all looks fine on our end" from your vocabulary. Concentrate on what the customer's seeing, the customer is seeing a misconnection here, it's not a case of working out whose fault it is so much as fixing the problem and working together to fix the problem. That's a less a software technical point and more a people point and as always, people are more complicated than software.

Losing Requests

Let's consider the two different failure modes you can have when connecting and broadly speaking, they fall into two categories, losing the request and losing the response. You try and make a request from the partner API to the Starling API and the request goes missing, or the request gets there but Starling response and the response gets lost. How do you cope with these two failure modes? We've implemented an architecture at Starling that deals with these sort of failures when they happen in between - I call them microliths, somewhere between microservices and monoliths- our different systems, when they're trying to contact each other, they all have failure protection against these two losing the requests, losing the response things built in.

That's reasonably easy when you're in control of the architecture and it's all, you know, in your control, but when you're trying to deal with a situation where you're controlling half of the equation and someone else is controlling the other half, it can be much more difficult to make sure that a lost request or a lost response is handled correctly. We call this sort of architecture DITTO architecture, DITTO standing for do idempotent things to others. I'll come back to idempotency and what it means in this context in a minute.

Generally speaking, the idea behind DITTO architecture is that the system, and by the system here we mean both the partner API and the Starling API, or the developer app and the Starling API, must ensure that everything from the user, everything that a user sends to them, every instruction is processed at least once and at most once. The reason I emphasize at least once and at most once is so that we get both of the failure modes rather than just saying once. At least once, which is what happens when you lose the request and at most once, which is what happens when you lose the response, so let's go through both of those now.

If you were making requests, especially if you're doing this in a financial context from your app to another API somewhere, you've got to make sure that if the request gets lost, that you do something, don't just do fire and forget. Don't just say, "Oh, if I've made that request, it must have been processed." Maybe it hasn't, maybe the thing that you contacted went down, maybe it didn't return you a 200, okay, everything's fine. Maybe it returned to you a 404, I have no idea what you're talking about, a 500, something exploded, it returned to you an error or returned to you nothing at all.

You've got to make sure that if that happens, that you have some way of getting out of it, you have some way of replaying a request saying, "Okay, this request didn't work the first time. Let's try it again." You've also got to make sure that you don't just go request-request, conduct a DOS attack on the other side, you've got to have some sort of a way of tackling that. You've got to make sure that you have kept in mind the fact that this could fail or return a bad response and what do you do in that case.

You could also lose responses, so you could have a request come in, the response goes back, but the response gets lost. If the side making the request is playing by these rules, it should make the request again and then what are you going to do? This is where at most once an idempotency comes in. In this context, what I mean by idempotency is that if the request is made twice, it has exactly the same effect as if you made the request once or indeed, if you made the request three times, four times, five times, it has exactly the same effect. Basically, what this means is you make the request and then the other side has to check if the request has already been made and processed, has to make sure that the request is "Have I processed this request? Yes, I have. I've already processed this request." Don't throw an error. Return 200, okay, the request was processed and just keep returning that every time that individual request is made.

Some key lessons here, some key important things that you have to consider when trying to make sure that this happens. Firstly, we talked about deleting of tokens earlier, you can delete your tokens, but don't delete them straight away. Don't go, "I've received the request. Ok, I'm going to process the request and delete the token. Done.", because the request might come through again. Obviously you have to put some expiry on your tokens, you can't just make them live forever, but make sure that there is a sensible window that you account for this possibility of failure and replay of the request. You also need to give every request a UID, a unique id that uniquely identifies that individual request. Don't rely on the amount of the money and the payment or what have you or the date or time that it's being made, those aren't reliable enough. You need to give every single request a UID and on the requesting side, you need to store those UIDs and make sure that when you're replaying an individual request, you replay it with exactly the same UID. On the response side, you need to store the UID and you need to say ”Go and check whether I've already processed this request and if I have, then don't do anything, just respond, 200, ok. Thank you, I have processed that request. “

The other thing I would say about these UIDs is don't use domain UIDs, by that I mean if you're processing payments, if you've associated a UID with the payment, don't use that UID, again, for the request, don't leak your domain UIDs, which you might use for internal controls like this out into the outside world. Keep them separate and make sure that you have specific request UIDs, which are the UIDs that you can pass between the partner and yourself.

We've said all of this up, but how do we know it's working? This is where we're going to start to talk about testing.

Make Testing Easy

Zaharia: We ticked a few boxes, you now understand OAuth 2 and you're hopefully able to make an informed decision on whether you want to implement it yourself or not. Also, you've learned that you should design your API so that any request is idempotent and you've also let your partners know that they can safely retry any failed request as many times as they need to, but what about this testing? How do you make sure that your partners can easily test their integrations with your APIs without them having to guess what's happening behind your systems?

One way we've done this is we've made it easy for developers to access their Starling Bank account data from production as a developer, and this is actually my own production Starling account. You can see some details about myself, some transactions I've made. But this is not the Starling up a, this is actually a screenshot from a web app running on local host.

How have I done that? It turns out it's not that difficult, all you need to do is set up an account on our developer portal website. This is a website which provides you with documentation on our public KPIs, but also it allows you to administer access to your production Starling account as a developer. What I've done is I logged into the developer portal, I generated a QR code for myself, remember the QR Code I explained about before, then I also have a Starling Bank account, I just opened the Starling app and scanned the QR code and I gave myself permission to my own data. I had an access token which I could also access from the developer portal website and I could use that token in the same way I explained before to query our public APIs. Just a word of caution here, this is meant for personal access, so you can't access multiple accounts this way, just your own Starling account and also, you can't do things like payments because that's a little bit too much. Apart from that you can just test whatever's happening behind the scenes.

That's cool and everything. But what if you want more, what if you're this ambitious developer that is dreaming of having hundreds of thousands of customers and you want to load test your application just see how it behaves with many customers. To do that, we provide you with the sandbox environment, which is a separate environment from production where you can generate Starling customers. This are screenshots from the developer portal, in the same place as before you can see in your account, you're able to generate sandbox customers and you also are able to simulate various types of transactions for them, so you can simulate past payments or car transactions or even direct debits.

Speaking of direct debits, I have another funny story from about two years ago when we had the hackathon. People were implementing direct debits at the time and I don't know how much you know about the direct debits here, but to get direct debit information, you need to talk to banks and banks talks to you only via files. Jason here was our human direct debit simulator, he was handing out files to the hackathon participants so that they can test their implementation. Jason [Maude] survived, he jumped back in time and he's here today to talk to you about our permissions model and how we evolved ours.

Work on Your Permissions Model

Maude: You've understood OAuth 2 and you've implemented this, you've coped with various failure modes that could happen in your connection between the partner app and the Starling API, or your own developed app and the Starling API, and you've tested it, tested it using simulations that allow you to simulate all aspects of the other side of the equation.

All that we've been talking to up till now has been about the Starling Bank connecting to a partner, or similar, or a developer. There is actually a third entity in this equation, which is the customer and this is where we bring the customer into it. The customer wants to give permission to a third party thing like Wealthify or Habito, for example, to connect and take some of their banking data from their bank account and use it in that other third party app. The question is, how do we make sure that we have given appropriate permissions and have an appropriate security model between those two and that the customer knows what permissions they're granting and has given informed consent to do that?

This is where I'm going to say, you need to iterate on your permissions model. This was version one of our permissions model and it was based on tiers, various different tiers of permissions. You could grant the ability to read your financial data, or read your personal data, or write your financial data, so the idea was there would be these overlapping tiers which would stack on top of each other.

This was designed from the point of view of the customer, we need to be able to give the customer easy way of understanding what they are giving permission to. We will say, if you grant tier one, you grant the permission to read financial data and tier two read personal data and financial data and they all had a big banner headlines that made it easy to understand what the customer was granting access to, but there were some problems with this. Personal data is quite sensitive, so originally, we had that as tier two and tier three contained tier two and then we realized, "Well, hang on a minute, just because someone can write financial data by canceling a direct debit doesn't mean they should have access to my name and address," for example.

We segregated tier two off and then we realized that that still didn't make sense. You have the ability to read my personal data just because you want to make payments, that doesn't necessarily make sense. Although this tiered structure might've made sense from the customer's point of view, it didn't really make sense from a security point of view. We were ending up giving out permissions that people didn't really need or use and giving a third party permissions to your bank account that they don't really use is not a very good security model. Although this might have made sense from explaining and getting informed consent from a customer's point of view, it didn't make sense as a secure way of connecting a bank account to a third party user of the data of that bank account.

We moved on to another permissions model and here we basically split it up, we split it up into loads of different individual permissions and we basically worked on a yes/no model. We said, yes, you can have that permission, but no, you can't have this permission and so on, so we could go through and give each third party application only the permissions that it would actually be using. We could review that on a case by case basis and go "Well, they want this permission, not that permission. Do we want to allow that? Yes or no".

Brilliant, but now we come back to the problem with the customer, how do we give the customer a nice easy way of saying these are the permissions you're giving out without making it look like the iTunes terms and conditions, just a giant wall of text that everyone scrolls through and goes, "Yes, I have read that. Continue." No, you haven't read it, you haven't understand it, it's not informed consent.

We need to find a way that allows us to do both of these things. The permissions requesting screen you will see when you sign up for Starling looks a bit like this. What's good about this is that first of all we've got those high-level bullet points saying you're giving access to your financial information and transactions and your personal information. If someone just wants to get a quick overview of what they're doing, what they're sharing, when they share their banking data with this third party application, they will be able to do so. We've also provided the detail though, we've also provided the in-depth blow by blow account of what the detail is.

The reason we've done that is because some people like just the big picture and they just want the big picture, they don't want anything else, but some people really want to dig down into it. When you say you my personal information, what exactly do you mean? You have to be able to cope with both of these cases, you have to be able to cope with both types of people who will complain if one way of showing the data or the other is removed.

The overall lesson here is that one of the reasons you've got to work on an iterate over your permissions model a lot when you're trying to set up something like this is that you've got to make sure that you cater for multiple different types of customers who want multiple different ways of seeing information in order to give informed consent and you need a security model that works in the technical sense when you're trying to connect yourself up to this other API. Now that we've set everything up and we've got permission, we're going to talk about ongoing monitoring.

Monitor Your -API

Zaharia: We are a bank, we need to provide 24/7 service to our customers, if there's a problem, we need to find it quickly and solve it quickly, not because we are required to do so by the regulator.

You can imagine we've put together over time a quite an extensive monitoring and observability stack and here's how it looks like right now. On the bottom we have ELK, Elasticsearch, Logstash, and Kibana for log parsing, searching and filtering. If there's a problem, we need to send out alerts, so Prometheus alert manager will do that. We also have the Elastalert for the same kind of thing, parsing elastic search logs, and then Pagerduty, which is our tool that we use to manage incidents. As a metrics tool, we use Prometheus which gathers metrics from our services and also sends out alerts. The data behind Prometheus is pulled by Grafana which basically builds pretty dashboards for us to look at. On the top, you have Instana, which gives us a broader overview of our microservices, so it's a distributed tracing tool, you can trace a request from server A to server B to server C and also have a look at what's happening in the database.

That's nice, we have monitoring for our core banking product, but you might wonder, why would you want to do that for a public APIs? Why is this relevant for public APIs and what are the challenges that you might encounter when doing monitoring for them? I'm going to give two examples which are specific to public APIs.

One of them is this one, this is a dashboard of one of our partners public API rate goal. What makes the public APIs different from our core product is in our core product, we have a mobile app, so a specific flow that the customer goes through in the app. We know how many customers we have, so we can kind of expect a specific load to our services, but with public APIs, you don't get to have that, so in this particular case, one of our partners decided to send out a burst of requests to our services. Thanks to this dashboard, we were able to quickly identify them and take some measures. We were monitoring specifically, so we knew exactly which partner this was and we were monitoring every endpoint that we expose.

The second example is the one I talked about before. If you remember in the beginning, I was talking about deleting your access tokens if you don't need them anymore. This is how it all started, how we spotted we had the problem with the access tokens, we were monitoring specifically for the token refresh latency and we spotted that some of the requests had a much higher latency then others. We were able to investigate further and realized the problem was in the database.

These are examples of why you would want to monitor your public APIs, but if you listened to Ben's talk before about Google's microservices, you also learned that you probably should try not to have dashboard explosion and don't track too many things. In this case, we were looking at very simple SRIs, so this made perfect sense for us and it actually got us out of trouble in these particular scenarios and I highly recommend you do the same if you want to implement public APIs. That being said, I'm going to hand over to Jason [Maude] again who's going to talk about the future and some other stuff for you guys.

The Future

Maude: There are a few things about what we're going to do in the future with this sort of open banking software that we have developed. First up is a thing that we call the open integration platform, this is something that we're going through a tryout hoping to trial, which is a halfway house. We've got on the one hand the ability for developers to connect up their own developed apps to their own bank accounts. We've also got marketplace partners with whom we are willing because we have done a lot of due diligence with them to share customer data with and allow them to take customer data on board with informed consent from the customer.

The question is what happens if a developer develops something, develops it out and they think, "Hey, this would be very good for lots of people to use.", but they can't go through the whole due diligence process, which is very long, complicated. It's just a little widget that they think is going to be useful to lots of people and don't just want to keep it from themselves. At the moment, we've got no way of running that individual piece of code, so we're going to try and develop something which allows that piece of code to be run and for customers to use that widget to connect up to their Starling Bank accounts but that doesn't involve giving out personal access tokens for your bank account to that particular developer. Starling Bank will run the code that the developer has developed in our own servers and customers can use it from there. We're still working out the details, very rough sketch unaware but that's the sort of problem that we're trying to solve.

The other one is about sharing identity. Up till now we've been talking a lot about sharing of your financial data, sharing of your card transactions or your direct debit transactions or the ability to make payments. Another thing that most banks have to do, in fact, all banks have to do is they have to perform a lot of due diligence on an individual when that individual signs up and that's data that we've got about the customer. By this same principle, we should be able to -with informed consent from the customer- share that KYC, that data that we've done to verify that the customer is who they say they are with another third party so that that third party doesn't have to go through the same set of "please provide your identification, please provide your name and address" and type it all in here. You can just go log in with Starling effectively and have that data transferred and that will hopefully make onboarding to other third party financial apps much easier, that's another thing we're considering.

There are some key takeaways from this talk, key lessons that we've learnt. First up, make sure you understand OAuth, make sure you understand the security principles behind how you are keeping the transfer of data from yourself to a third party app secure. Second of all, consider that you can't always connect. You will lose requests, you will lose responses, and make sure you know how to tackle that. Third up, make testing easy, make sure that anyone trying to connect your app can simulate your app and indeed the environment, the universe that it's connecting to so they can simulate outside things like card transactions, direct debits without having to get me to type out a file for them. Fourth, iterate and work on your permissions model, your first try isn't going to work. You need to make sure that you are able to get informed consent and you need to iterate on how you're getting that informed consent with the customer whilst having also a model that provides security for the connection between you and the third party. Fifth, once you've got all this stuff set up, monitor it, put monitoring on and put a sensible amount of monitoring on. Do not monitor and alert on everything, work out what is important and monitor on those things. If you do all that, then you should be able to connect up your API to another API with ease and share this financial data securely.

Check out the "Starling Developer Podcast" as well if you want more data on this. Thank you very much.

Questions and Answers

Moderator: Thanks very much. We've got a bit of time for questions. If you've got questions for Jason [Maude] or Anca [Zaharia], please. Wow, really? Ok, I'll run around.

Participant 1:Thanks for your talk. How did you migrate your permission model when you went to the different iterations, because you changed it, how did you migrate it for the existing customers?

Maude: Luckily, we hadn't done much in the way of setting up our permissions model first time round basically. There hadn't been many active connections, many active integrations, so we haven't as yet had to work out how to migrate the permissions model. We set it up and we very quickly went and deprecated it and turned it down. I think the only people that were affected were developers who connected up their own app and had to give themselves permission to connect their own app up. At some point, we will probably have to change our permission model again, and then we'll come back next year perhaps and tell you how we managed to migrate our permissions model from one to the other.

Participant 2: Just a question about when you said about the future for authentication to kind of accept also the confirmation of requests for connection to yours. Was it from your side or the third party side because on the OAuth, there was a step when the app is basically trying to access your API and you're requesting from a user to practically login again, we're on the third party's app. Would that then be considered that you accept the authentication that they did on the third party side to go through?

Maude: I'm imagining that in terms of this two-way OAuth, if you're sharing KYC data, that you will do this at the very start of you signing up with the third party app. There won't be much in terms of the two-way flow to accept on the other side because it's literally just Starling Bank wants to access your account which has no data in it yet because you haven't input anything because you are trying to send all your data across from Starling as it were, so I don't think there'll be much there to share.

Participant 3: I'm interested in the identity sharing in the KYC particularly from the legal angle. If there's a failure of KYC, I suppose my question is who goes to prison?

Maude: This is future, this is an idea that we think is technically possible and should be possible and convenient, but there are questions, you're right, to sort out there if you onboard a terrorist, who is at fault for onboarding the terrorist. Unfortunately, we can't just adopt the engineering question of if there is no faults, we'll just have a retrospective and it'll all be fine. Yes, lawyers don't like that answer, so I'm afraid I don't have an answer for you, that's something that we still have to work out on the legal side about where responsibility lies. I think this will end up only being from trusted third parties that you might have need to have some sort of government certification, I'm hand waving pie in the sky at the moment.

Participant 4: You have mentioned that you can help troubleshoot connect you to user on your side or on client side, but let's say you mentioned that client sends request, that his request has not been sent from his network and you don't see that request as it see it within your network, how would you help me as a client to troubleshoot this?

Maude: Essentially, it's the sort of standard things you're going through when you're debugging. Imagine two of your systems within your own architecture have decided that they can't connect to each other. You basically have to ask yourself if this side is sending the request properly. Is it sending it to the right place? Is there any response coming from here? Does it even know? Is there any logging? You're doing the same sort of debugging you'd be doing when two of your services were trying and failing to connect to each other, but you're doing it between two different people, sets of people in two different offices, and that is trickier, because you're having to be on the phone phoning each other up. It's the same sort of process and you are asking the same sort of questions. What I'm going for is that that isn't specifically a software problem, that's a problem of people in different offices communicating with each other, so that's more of a human problem.

Participant 5: It seems like you have your own way of doing OAuth with the two-way OAuth. Have you considered using things like OpenID Connect? That seems to be able to solve some of the same problems that you have with the partners that need to call you.

Zaharia: We are thinking about implementing some of the things with OpenID Connect, that's now in future implementation. I'm not that familiar with it, but I know it allows you to send over some information about the Starling customer, so the guy that is giving out permission. What actually happens is a partner ask for permission, but what they get back is just the access token and no information about the other party, so information like when the access was given or what their name is. That's useful thing and I actually asked one of our developers about this and they said that's something we're going to be implementing next.

Participant 6: Thank you for the presentation, very interesting. I have a question about OAuth 2 flow. You have presented the authorization code flow. Is it also for mobile applications, native mobile applications that you use this all through?

Zaharia: Yes. This is actually the case, yes.

Participant 6: Because insecurity has turned out, nowadays we talk more about Proof Key of Exchange OAuth to flow, which is more adapted to native apps.

Zaharia: I know what you're talking about. This is the PKCE thing. I know what that is, it basically means that I think some malicious app might set up a redirect URI on your phone, which is the same as the redirect URI of the partner, but let's remember we have other clients secret that needs to be sent over on the next step, so that's an additional security measure. What we are thinking about as another step is us actually signing these kind of requests, so in that way, there's no way someone can actually intercept. They could, but they couldn't do nothing with it basically because they wouldn't have the public private key pair.

Participant 7: Thank you. I believe you're also a comm provider for open banking directory?

Maude: I don't believe we are at the moment, no.

Participant 7: If that's the case, I believe that the user experience for the developer experience is going to be very different, because of the security model, the engagement with you, and no way to test?

Maude: There is the open banking catch-all term, we're talking about the philosophy here on our journey on implementing it. We haven't implemented, the strict open banking APIs specified by legislation of open banking yet and all of what goes on with that but I think that we will do that at some point in the near future and all of what is said here, all of the principles and lessons we have learned apply equally to implementing the APIs as specified by that legislation as well.


See more presentations with transcripts


Recorded at:

Jun 02, 2019