Simon Lyons of obconnect talks to Andy Warren. Andy spent many years as the CTO of Open Banking at a top six bank. Here he expands on the tech side of the open banking world we rarely hear about. How to scale bank compliance software so that millions of people can use it every day.
Simon:
There are lots of opinions on the subject of Open Banking. There are lots of people who talk about it. There are very, very few people who can talk about it with authority – about how it actually works, how you make it work, and how you make big banks and big organisations get the benefits from it. One of them is with me today. Andy Warren, thank you very, very much for joining us.
Andy:
My pleasure. Good to be here, Simon. Good to see you.
Simon:
And we’re very, very privileged today to be able to ask you completely unbridled questions, and perhaps challenge a few things as well – obviously without naming names. But we’re going to jump right in and have a conversation about Open Banking. Andy, we’ve had some big revelations this year – eBay, Amazon – the names are bandied all over the place. They’ve suddenly taking up Pay by Bank, they’ve suddenly done that. You were working at a major bank when some of those big participants first arrived. Did that change the pressure on the stack? Did you suddenly find yourselves having to perform at a completely different level when a name like that came through the door?
Andy:
Apple was a very late joiner to the ecosystem. We’d been in production for a long time before Apple became a participant at the bank I was working at – so by the time they came along, we’d already learned a lot of the hard lessons. The harder journey was in the early stages, perhaps after six months of going live back in 2018, when you really started to see production volume and fintechs building a business around Open Banking data. And it was all data to start with – you know, the Pay by Bank, PISP offering really didn’t take effect for the first couple of years.
So trying to harden the stack around what was new technology end to end in a bank – it wasn’t just the front-end connection layer out to the Open Banking directory or out to the fintechs. So much of the bank’s technology was built, tested, and industrialised with Open Banking. That was the container stack, the API platforms, all of the security layer, the connectivity, the fraud element. There was a huge amount of new technology that needed to be industrialised. I think, in most banks, it was a real test.
So the first year was challenging, at least – response times, availability, SLAs that came with that. I think when we first went live years ago with my previous employer, we were averaging something like two-and-a-half-second response times, so we had a huge amount of work to do to really chip away and improve upon that.
Simon:
When you did it, though, you start out on this journey as well – do you sit there and look at the market? I mean, you obviously would have had a massive team of people working on it. Do you look at it and say, “Well, there’s no chance of us going outside to build this with somebody – we’ve got to do it ourselves”? Because you’re really starting from something that’s never been done before. It doesn’t exist before, does it – the open API with the consent model on it as well? What do you do? How do you make that decision?
Andy:
Back then, there weren’t really many providers in the market that could help you—not with a full stack. Some of the IDP providers – the bigger names, Forgerock, Ping – they had certain elements that could help, but nobody really was in the market at that point in time with a fully compliant solution.
If you look at when the specifications were published, and then the timeframe to stand up a full production-compliant environment back in 2018, there was a very small window between having those specifications and then having to mobilise to build.
Trying to build something of that scale back then in a bank – whose whole ethos before that moment had been to keep customer data within the perimeter of the bank, keep all payment solutions heavily secure and inside the organisation – there was never really a culture of trying to expose this type of data or to make payment systems available externally.
So it was a real game-changing moment. And there wasn’t really an option apart from a custom build at that point in time. There wasn’t a product in the market that you could go to, or a supplier that had something end-to-end that you could buy and adopt.
Simon:
That’s fascinating. So the nine – basically the mandated nine – it was almost a forced decision, saying, “Right, you’ve got to build this – there isn’t anything in the market – you go and do it.”
So I’ve got to ask the question – it’s probably not one that will get through it – how many people did you have working on it? And by the way, governance, project people, risk people – if you were to put a number on it now, how many would you say?
Andy:
At its peak, we had a very significant number of people involved – if you count the full programme, including governance, risk, and all the supporting functions, you’re easily talking over a hundred.
Simon:
My God, that’s a lot of people. That’s a lot of time as well. And that was everything, top to bottom, all the way out. Bloody hell – that’s absolutely staggering.
Andy:
It probably impacted many others too. The core dedicated engineering team was substantial – it gives you a real sense of the scale of what was actually involved in standing this up from scratch.
But, to my point earlier, you weren’t just building an external connectivity layer and a consent journey. You were industrialising technology that had only really been tested at pilot stage in its infancy back in 2017.
Banks at that point in time didn’t have mature private cloud, public cloud, or container platforms. They didn’t have API platform technologies that had been tested and industrialised at scale. Some of the technology protocols that came with Open Banking were new. It was the first time that we really had to build a lot of that type of technology.
Simon:
Yeah, Open Banking did for the API world what Covid did for the video call, I think. It sort of dragged everything up to where it needed to be. It’s quite an amazing thing – really interesting.
You’ve worked across organisations at different stages of their technology journey. Some banks have quite modern platforms underneath them; others are still carrying a lot of legacy. Does that make a material difference when you’re trying to stand up something like Open Banking? Did having a more modern core give you an advantage – or is the complexity there regardless?
Andy:
The next-generation build was a very different experience – and part of that was because we were working on a more modern stack. But also, the ecosystem itself had matured enormously between 2018 and when we came to build the next generation.
Open Banking, by the time we moved into public cloud with that next-gen build, had become a lot more commoditised in its nature. There were organisations in the market, like obconnect, that we obviously engaged with to help us on that journey – people who’d really been through it, who’d built stacks for banks and then built fintechs, standalone companies to serve ASPSPs or build out fintech platforms.
So by 2021, you’d had three years of live production volumes. You had successful businesses starting to really emerge out of Open Banking. The technology – and a lot of the suppliers – had really caught up. Even big organisations and API platform providers back in the day weren’t fully compliant with Open Banking solutions. They weren’t ready for a January 2018 go-live.
So when it came to building a next-gen environment, by that point in time you had quite a mature ecosystem and a widely understood set of protocols underpinning it, and reaching compliance was a lot more straightforward. You had people who understood end-to-end what that looked like.
Simon:
It’s really funny because you’ve got a unique position. We hear people saying, “This is what people do with Open Banking.” Whereas you’ve actually seen the volume of people that connect to the back end.
One of the biggest things for me at the start – it wasn’t a surprise that accountancy and bookkeeping were such high-volume use cases for AIS. Now we look at it, the legacy connections have gone from the banks – they’re all using Open Banking.
If you talk to accountancy platforms – the biggest advisors to small businesses are accountants – and if your bank isn’t connected to Open Banking, you’ve got a problem, because it makes their life easier as well.
Then Apple comes along, and if we ignore Pay by Bank for the moment, and then look at the mortgage industry as well – was it exponential growth in the use of data from ASPSPs, or was it a nice, steady curve? Or was it spiking? I’m really interested in adoption and how it happens.
Andy:
In the early days, we started small – it was slow growth. I think the first year in 2018 was slow growth across the whole ecosystem. There were probably no more than five to ten TPPs in the market that had proper production systems in place.
The tipping point probably came around 18 months after going live, when you started to see spikes – certain fintechs really starting to ramp up volume. The performance and resilience of some stacks did suffer because there was a tendency for some fintechs to batch process calls into a stack, creating spikes.
You’d look at your logs in the morning and see spikes at 2 a.m. or 6 a.m., for example. You could actually see the calling patterns of TPPs, where they’d send hundreds of thousands of connection requests your way. And there was nothing in the scheme to stop that.
Over time, that became less of a problem – calling patterns changed, and things matured in the market. The operating guidelines from OBIE started to enforce better usage policies. Most banks developed better operating models for their APIs.
And that was one of the key benefits Open Banking brought. Before Open Banking, APIs were just seen as plumbing – just system connections. They weren’t considered a product. They weren’t designed for massive industrial reuse.
Now, you’ve got one API with hundreds of TPPs consuming from an industry standard. That was game-changing. APIs became products, and usability and developer experience became critical.
If you look at the success of fintechs like Plaid, they invested heavily in developer experience – and you can see the results. They’ve captured developers through ease of onboarding, transparent pricing, and accessibility.
Developer experience wasn’t really a thing in banking before Open Banking. It became far more relevant after 2018 – 2019.
Simon:
I’ve always been a fan of the standards of Open Banking. If you’ve got a compliance exercise, you can fail – but if you’ve got standards, you can’t fail because you have to meet them.
Standards have driven standardised behaviour – that’s hugely valuable.
Let me play devil’s advocate for a moment. Looking back, what would you have done differently from day one?
Andy:
I think everyone was doing their best. Hindsight is a wonderful thing. At the end of any long-term project, you reflect and think about what could have gone better.
It was a difficult phase. The pressure from OBIE and the CMA to meet original implementation dates was intense – especially because AIS and PIS were treated equally.
Account data and payments are very different technology systems with different complexities.
If we could have done anything differently, it would have been to focus on one of those first – probably AIS. Payments didn’t gain traction for the first couple of years.
If we’d started with a smaller subset of data and focused on making AIS successful first, we could have concentrated the engineering effort and been more stable on day one.
When you try to build too much at once in a distributed architecture, it becomes incredibly complex to stabilise.
I’m a big believer in starting with the thinnest possible slice of end-to-end functionality – a “steel thread” through the stack – to define and test integration standards before scaling.
Because you weren’t just building Open Banking APIs – you were building an entire stack from core banking systems through to customer experience and external APIs. That’s a huge integration challenge.
Simon:
It’s a really interesting viewpoint you’ve got as well, because when you think about it, you often isolate one part of the job – you know, we need to get compliance done for the APIs – but actually there’s a chain all the way up to user experience, all the way up to terms and conditions for the customer.
The bit that always gets me is – I’m not a super technical person, but I’ll give it a go – the microservices that Open Banking relies on, and the APIs to the backend systems as well. How on earth do you make sure that they are of a standard to keep up with what you need? And was it a difficult challenge to ensure they performed at the right level?
Andy:
I think the first time any big organisation adopts a microservices architecture and a distributed architecture, resilience and performance are difficult to get right. You learn as you go through that journey.
If you start too big – with hundreds of microservices and complex interconnectivity – the latency created by decisions around security and service separation becomes significant.
In public cloud, you might have namespace separation in a container platform. There’s always a trade-off between security, resilience, and performance. The more friction you introduce, the more latency you create.
You learn those lessons as you go. Building security from the outset is essential – you shouldn’t just design security at the perimeter. But these are lessons learned through experience.
When we moved to the next-generation build, we were in a more privileged position. We had learned those lessons – particularly around network latency, avoiding overly chatty architectures, and designing the right level of service granularity and throughput to meet SLAs and response times from day one.
Simon:
It’s really interesting because nobody ever notices a service that never goes down. We often use Google or YouTube – not because of their architecture – but because they work every single time.
We have zero tolerance for failure in banking. You can retry a card payment at Tesco, but if your banking app doesn’t work, it’s a big problem.
Thinking about the future – Andy, you’ve built this at a serious scale inside a major financial institution. I personally think that by 2026 or 2027, Open Banking won’t just be regulatory – it’ll be customer-driven.
Customers will expect to be in Apple Wallet. Small businesses will expect seamless bookkeeping.
So, the question is: can smaller banks realistically build what you built, or has the market moved to a point where the smart move is to rely on specialists?
Andy:
The buy-versus-build argument exists in every technology decision. My view has always been: build your custom intellectual property. Anything that isn’t your IP – why invest in building it?
Especially in a commoditised technology like Open Banking, which also has a very expensive run model. It requires ongoing maintenance – connectivity to other banks, fintechs, sometimes hundreds of connections.
It’s not just expensive to build – it’s an expensive long term investment to run this type of operation
The technology framework, security policies, trust framework, directory connectivity – building and maintaining all of that is a significant operational burden.
I wouldn’t consider that core IP for a bank and not something a bank would want to invest in building themselves.
Today, engaging with a specialist provider like obconnect to manage that complexity and take that pain away is a far more practical and cost-effective approach.
That said, there are elements that are a bank’s IP – customer data, consent management, and customer experience. Designing trust-led customer journeys is critical.
But connectivity to directories and external participants – that’s not where a bank should focus its investment.
Open Banking is not just about compliance. Decision-makers need to be clear about what they’re trying to achieve.
If it’s purely compliance, then outsourcing makes complete sense.
If it’s strategic – if they want to reshape how they integrate with partners and deliver services – then that should influence their architectural decisions.
And finally, from an architectural perspective, if done correctly, Open Banking can be a true game changer in any organisation.
It can make technology estates more interoperable, scalable, and future-ready – whether that’s for AI or new integration models.
If you treat Open Banking not as a compliance project but as a modernisation lever, it becomes incredibly powerful.
