Banking-as-a-Service: A disruptive force for good

Banking-as-a-Service (BaaS) comes in many various offerings, something that was not true back in 2014 when I first started talking about BaaS. Back then, I don’t believe anyone else was talking BaaS, let alone building propositions. However, fast forward a few years and BaaS is everywhere. It seems so many appearing un-related products and services now fall into the house that is BaaS. This makes things quite complicated as a technical leader within a bank, or harder still for a technical leader within an emerging challenger bank, neo bank or FinTech. Do you select BaaS? And if so, what are you selecting?

So, is BaaS something technical leaders should be looking at right across the finance industry? And if so, as a technical leader, what are our responsibilities back to the business we work for? BaaS has the potential to be highly disruptive, but unlike many “disruptive” technologies or models, BaaS doesn’t break the market, rather it enhances it, enriches it, reduces complexity, enables simpler working solutions, reduces operational costs (and other aspects such as liquidity and capital) while all the time delivering better customer experiences and outcomes. These are the very reasons why best-established banks and the FinTech challengers are looking at BaaS.

In this article I will look at some of the considerations we as technical leaders must consider when looking at BaaS solutions, ensuring the business that we work for, utilise this highly disruptive service in the right way for us.

The definition

First off, let’s agree on a definition of BaaS. The first issue is that BaaS providers seem to have different definitions. This is a tad frustrating, however, here is the definition I have been using since the back end of 2014.

“BaaS is the deconstruction of banking into individual granular services that can be subscribed to.”

I’m not often a purist, however, when it comes to “as-a-Service” definitions, I think we must be a little strict here. To best describe this, I often use “Office 365” as an example. To leverage Office capabilities, you simply subscribe to the services and products you want, pay for what you use and away you go. That’s what BaaS really should be. If you’re not able to “subscribe” to services, then I’m not sure you can be a true BaaS provider. Now, that’s not to say that solutions out there that I don’t consider to be true BaaS, in this pure fashion, shouldn’t be considered. No, they all have their merits, rather, as a technical leader, we just need to be mindful of exactly “how” the BaaS solution is delivered or executed.

I personally like to deconstruct banking into very granular services, and this is because banking has so many moving parts. Even simple workflows contain vast numbers of services, each one should be interchangeable to help me deliver a different outcome for my end customer. As a technical leader, I want the maximum flexibility from my suppliers, simply because I never want to have to be in a position where I select a supplier, trying to predict what the business will need to do next. I don’t want my selection of BaaS to become a limitation, rather it should always be an enabler to deliver the services the business needs.

Various BaaS offerings

Since there are so many banking services, there are now so many different types of BaaS solutions out there. Here is a list of some of the areas that are covered (I’ve stayed away from the more obscure).

• Pre-paid card and account services
• Credit cards and associated account services
• Clearing and Settlement (including agency banking)
• Core banking
• Card processing
• Lending
• Product management

Some providers remain highly focussed on their specific areas, while others look to offer more “complete” solutions, focussing on banking as a vertical. Each will appeal to the executive of an institution in different ways, however, as technical leaders we MUST ensure the business makes the right technology decisions, that is after all our duty.

Before we move on, I should also call out that we also have areas of BaaS that are so large, they are essentially seen as a subset of FinTech in their own right, and that’s:

• RegTech
• Compliance-as-a-Service

In the world of BaaS, I think these two areas are often overlooked, and yet they offer the same benefits to an organisation, if not more so when compared with the traditional BaaS offerings.

BaaS appeal

BaaS is appropriate for, and appeals to all types of financial institutions, from incumbents to new challengers, from neo banks to outright FinTech players, each one can leverage BaaS to build their propositions faster than ever before, and at an operational cost point drastically cheaper than previously dreamt of.

I often get asked, how do you know when to “buy, partner or build” and this is always something all technical leaders grapple with. BaaS makes things a little simpler, as it has the capability to turn banking into “features”, indeed some providers are really starting to deliver banking-as-a-feature. What this means is, I can concentrate on building only that which is unique to my product, unique to my offering, and treat banking as a feature within it. What we must remember is, building tech is not cheap and it doesn’t finish at the point of delivery. In fact, just 2 weeks’ worth of development costs are just the tip of the engineering iceberg. You must remember the costs associated with the built product, costs such as alerting and monitoring, patching and maintenance, re-engineering as underlying technology advances or just re-engineering so that you do not leave yourself with legacy software. If you can avoid building something that isn’t unique, then avoid it, buy or partner. I believe you should only build that which is unique to your proposition or is truly required to meet the unique demands of your proposition, to enable it if you will. BaaS therefore becomes a “go to” when I think about banking services or features, I want to bring to the market.

BaaS however shouldn’t be a driver, rather I believe it should be an enabler. What I mean by this is, BaaS capabilities shouldn’t drive your proposition, rather it should be an enabler of the propositions you want to build. To explain this, lets look at two very different examples. The first, BaaS of an established bank, the second for a new challenger looking to bring competition to the banking landscape.

BaaS focus

I am a strong believer that BaaS providers cannot do everything, and if they try, then the propositions that are built off the back of them, become all pretty much the same. As a technologist, I like the simplicity and the effectiveness of BaaS, and I also like to see it implemented in a “horizontal” fashion of focus, and not so much a “vertical”. As technologists we think of the “stack” as horizontal layers, banking in general and BaaS is no different. Since the number of services that make up “banking” are so wide and varied, BaaS providers need to focus on their specific areas, hence we see so many different types. As a CTO or a CIO who is buying BaaS, it’s worth remembering that flexibility is in the breadth of the solution or stack, not the number of layers it covers (the vertical height).  

The diagram above shows 4 main areas of coverage of BaaS. For maximum flexibility of the ultimate end customer propositions that are being built, each layer needs to be as wide as possible in terms of the breadth of services offered. For example, Payment Clearing & Settlement. In this layer, as a buying CTO / CIO, I will want to have all the payment systems covered and be able to operate across all of them in real-time, and since this is BaaS, on a subscription based model to a single API. As a buyer I may not purchase access to CHAPS or ICCC for example, however I know that if my proposition should change and grow, and require those, I can easily add that capability into my proposition. Payments Clearing & Settlement essentially become just another feature for my engineers. Banking-as-a-feature becomes a reality here.

As we move up the layers, we see different BaaS providers with different propositions. Again, as a technical leader I want to have maximum breadth of service offering so that as my proposition is used by customers, I can gain feedback, iterate and enhance my proposition. As I have said, you do not want to find that BaaS becomes a limitation of the proposition you provide, or the driver to a specific proposition. Breadth of service offering is therefore what makes BaaS an enabler.

As a CTO / CIO of a FinTech, Neo bank or new challenger, looking at that triangle I can potentially build out my entire proposition, with maximum flexibility with just a few BaaS providers integrated together. Never in banking has a CTO been able to deliver such varied and vast banking propositions with so few suppliers, so few moving parts nor been able to achieve these deliverables in such a short period of time.

BaaS appeal for an established bank

Established banks, especially those that are successful, have several issues to contend with when looking at BaaS. From a technology point of view the first is that the bank already has several systems. This number could vary from a handful to hundreds, which means the complexity of the bank, and its technology stack, could be quite simple, or more realistically highly complicated and rather legacy. BaaS solutions that we select therefore need to be highly granular, as no technical leader in their right mind would recommend a “big bang” approach at replacing current systems with new ones.

BaaS will appeal to an established bank because it can help migrate away from legacy systems. BaaS can simplify the banks systems and operational processes, improving performance and resilience while driving operational costs down. The exec within many established banks understand the operational savings that can be made from “aggregation” of services, payment systems and  core banking systems spring to mind.

Whatever the area of focus, as a technical leader we must ensure the following:

1. Services provided by the BaaS provider are granular enough that they can be rolled into our systems in bite-sized chunks
2. We can clearly assess integration points and the impact on the current systems (this includes any operational impact)
3. Payments flow is clear, including data residency
4. We can understand how the BaaS providers scale their services
5. Are there other services provided that could be leveraged to reduce operational costs and simplify the technology stack further?
6. How interoperable can the service be, how granular are the services provided
7. Does the BaaS provider have a “rich” vein of services ensuring the bank isn’t restricted by BaaS when looking to evolve services provided to customers in the future?
8. Can a clear plan be put together, collaboratively, to migrate small parts of the old system to the new BaaS system?
9. How flexible can the BaaS be with regards to access to raw data and reporting

Established banks in recent years have looked to BaaS to help build out new customer propositions quickly, getting them into the market quickly and iteratively improving them. The challenge here is to ensure that technical decisions made, including the choice of when and where to use BaaS, do not simply solve the immediate ask, rather they are able to solve the immediate ask, but also evolve as the product offering does based on customer demands. All too often, technical decisions are made and partners are selected that end up restricting the products capabilities and therefore sees the initiative and product struggle. Alternatively, we see banks investing in technology and then trying to find new ways to monetise that investment, I often hear the term “sweat the asset”, which can lead to the wrong technology being used for a specific customer outcome, which ultimately limits that outcome or doesn’t really do the trick.

BaaS appeal for a new challenger

If you are thinking of building a new challenger bank, then in my opinion, you have to leverage BaaS, after all, why would you overlay operational and development costs into your business that simply do not need to be there, they aren’t helping you design and build out your proposition. BaaS reduces the barrier to entry in terms of capital and operational costs. That’s a starting point you cannot get away from. The funding you have raised for the new bank can go on the things that matter, building your proposition and market presence. BaaS will also help you get that proposition to market with unprecedented velocity, saving your investors’ money and getting you to revenues in a shorter period of time. There are even providers that allow you to leverage their regulatory licensing to speed up the process further.

However, things aren’t as simple as selecting a BaaS provider and away you go. As a technical leader in such a new challenger, the key here is to ensure that the business has a known strategic path to follow. This is in terms of the type of propositions you want to build, but also the technology you are to leverage to deliver those propositions. As I have said before, select BaaS wisely. You want to have maximum flexibility from your BaaS, so that you can iterate and grow with your business, not find yourself locked and restricted. As a CTO / CIO at a new challenger, I would be looking at selecting probably numerous BaaS providers, a provider rich in capabilities across each of the horizontal layers of my stack. I can then focus on a specific vertical niche, bring that to market and broaden my proposition as and when I need to.

Disruption

BaaS is disruptive to the financial services marketplace because of the very fact that it can be an enabler. Enablers drive new and innovative products and services, enablers help deliver better customer experiences and outcomes, enablers ensure greater diversity of financial products and enablers ensure greater competition in the marketplace. BaaS is therefore a highly disruptive technology within the financial services sector that is for the good of banks, FinTech’s and the end customer.

When we look at technology stacks of banks in the future, most of the offering will be coming from the cloud and this cloud native “as-a-Service” type offerings. This future is inevitable, as technical leaders, we need to ensure we educate the executive of its numerous benefits, not just those of cost, but of technology simplicity, agility to respond quickly, iterate products to meet customer demands and feedback.

But for any financial service provider, we have to think of what I call regulatory headwinds, when we think of the operational costs associated with security, availability and performance, these are all costs that are going up and up, driven by customer demands for real-time anytime, but also by those of the regulator. When we look at these costs rising, as a CTO / CIO we have to understand that we need to keep our operational costs down, we cannot go investing in 3 active:active:active datacentres to help tackle High Availability, we have to leverage the cloud. We cannot afford the luxury of building everything, we must look at partnering. BaaS enables us as technical leaders to become “FinTech plumbers”, plumbing together solutions that help solve our regulatory headwinds, help ensure we drive our operational cost base down while at the same time, maximising the type of products we can build and bring to market, quickly. Our focus and engineering efforts go on “what makes us and our products and services unique”, our efforts go on adding value to the bottom line of the business we work for.