Mobile-only Atom Bank enables straight through processing with MuleSoft
- Summary:
-
CTO Damon Roberts explains how Atom Bank is using MuleSoft at the core of its business to enable touch-free mortgage processing.
CTO Damon Roberts was speaking today at API platform vendor MuleSoft’s annual user event in London this week, where he described how the use of the APIs as a form of middleware have allowed the bank to implement straight through processing of mortgage applications - one of the most complicated tasks in retail banking.
Roberts explained how Atom Bank is differentiating itself in the hard to penetrate financial market. He said:
Atom is about the customer. UK retail banks are not transparent and they’re not fair. And we want to be different. Everything about what we do is about the customer. We are top of the table in savings rates. We are top of the table in mortgage rates. We believe what we are doing is different, everything is on the app. That’s my bank. I can open a savings account, I can transfer money out, I can look at my mortgage offer, everything is on the app.
We are the first fully licensed digital only bank. We don’t have any branches and we’re never going to. We don’t even have an internet site.
Roberts explained how Atom began back in January 2014, with just three people in a room who decided that they wanted to start a digital bank. He described this as a “big ambition”, given that doing anything in a bank is difficult - and that starting with a blank piece of paper was both a “blessing and a curse” because of the choices you have to make relating to architecture.
By April 2016 Atom had a full banking licence, which is an incredibly quick timescale given the limited resources available. And because of this, Atom demanded a technology stack that didn’t require intensive use of internal resources. Roberts said:
Everything was buy over build. Unless it gave us competitive advantage. So, right at the beginning, the app was the thing that differentiated us, it’s very different from a UK retail banking app - although it does all the same stuff.
At that time we didn’t think that middleware would be the differentiator, so we bought a solution. So everything else integrates into our middleware and then integration becomes a challenge - because we are buying components and we are bolting them all together.
Changing tack
Atom Bank built its savings product with “another supplier”, a middleware solution that proved challenging from an integration perspective, and then later built its mortgages product with MuleSoft sitting at the core. Roberts described MuleSoft as sitting at the core, with legs going out to other applications - but everything comes through MuleSoft. He said:
There is no point to point connectivity at all.
Atom Bank soon realised that MuleSoft’s API approach was superior. Roberts added:
The first piece in terms of our journey - we built savings with another supplier, but we built mortgages with MuleSoft. Mortgages is the most complex product you can have [in retail banking].
The team is very small, they built all the APIs with a handful of developers. And for a significantly smaller amount of money than our incumbent supplier was going to charge us to do the same thing. And the important thing was is that we own the intellectual capital.
We have the flexibility to do what we want and we are in control. And that has marked our savings deployment from our mortgages deployment, because middleware was never a problem with our mortgages deployment.
The end result
Roberts was quite passionate about the ease of dealing with MuleSoft as a vendor - he described them as helpful and said that the architecture was simple. He added that MuleSoft helped Atom Bank ‘mobile and become self-sufficient’. Roberts said:
I’ve worked in a lot of big banks and the architecture is a nightmare. Our whole thing is an integration challenge. And if the middleware isn’t part of that and you’re in control it makes it easy.
Roberts said that if you own the middleware, you can pick any best of breed component you want and plug it all together, with MuleSoft sitting at the core. He said:
We have integrated best of breed for auto conveyancing, but because we own the APIs, we can do that. We are in control. We don’t mind which vendor we pick, as long as they can publish their technical specs and data contracts with us, we are good to go.
And what this has enabled is a touch-free experience for mortgage applications, something Roberts said is very complicated to do. He added:
Our mortgage process is actually straight through processing - auto conveyancing, auto valuation, auto credit scoring. A human being shouldn’t have to touch it because the systems do all the work.
We have one of the first platforms that’s truly straight through processing in the market. I’ve tried to do that in a number of other banks and the architecture gets in the way. We were lucky because we could make the middleware part of the parcel of that.
The numbers
Comparing Atom’s saving product - which used the “other supplier” - and mortgages, using MuleSoft, Roberts said that the difference in capability and out comes was incredible. Atom Bank is now going to replace what it is currently using for savings with MuleSoft.
Speaking to the benefits, he said:
We will deploy half the number of APIs that our current solution has, so from 80 to 40. We will not have any device specific SDKs, because we don’t need them. And we will do that in probably half the time.
Remember, this is a 24/7 bank. We have no branches. The only way to get to us is through the app. So if you had to take the service out for upgrades [it’s a problem]. It was taking us up to 90 minutes to upgrade the server software for middleware. It’s a couple minutes per API and we do them one at a time. So 90 minutes, to two minutes is a pretty impressive number.
We were also struggling to be on a monthly release cycle for our API developments. For a simple API, to design, build and test it, even if it’s going a bit slowly, [with MuleSoft] it’s a day. You’ve gone from a month to a day. For a complex one, that goes across multiple systems, typically the development cycle for that would be under two weeks. If you think about the cadence of delivery we have, where we are looking for at least a monthly release of the app, new functionality every single month - if we can do the API development in under two weeks, we can actually do it quicker than every month. That’s fantastic, we weren’t able to do that before.
And then there’s the speed of product delivery itself. Roberts added:
Obviously we had to do proof of concepts. However, mortgages, remember the most complex product, from sprint zero to handing it over to UAT for test, having system tested it, was two months. Clearly by reducing the number of APIs you make the job smaller and two months is impressive. That’s straight from proof of concept all the way through to delivery. That was not the same case for savings.
That tells a significant story for me in terms of the business benefit in terms of the technology choice we have made.