API Management in Financial Services: Build or Buy?

This question only arises when a bank has both the financial resources and the internal IT knowledge required.

There is no definitive answer. Financial institutions are diverse and have different requirements and resources. Building your own API solution means that you own your intellectual property, which can be useful in the long term. But buying also has certain advantages that would ease worries and lessen the burden.

What follows is an analysis of factors to consider, as well as some examples of successful builds and buys.

1. Objectives

What are your business objectives? What is your vision?

Are you aiming to comply with regulations? Do you want to streamline application development? Are you focused on improving your internal IT processes?

With different goals come different requirements.

2. Cost

Calculating the cost of digital transformation can be as arduous as the task itself. When building in-house, you can only make an estimate of the final cost. Much depends on how many developers you already have, how well-versed they are in the art of building open APIs, and how much of their time you are willing to contribute to your API initiative. If you build without having appropriate internal knowledge and capabilities, you can expect costs to soar above your initial budget estimate.

But there’s not much guessing involved in buying. You’ll get a price, you accept, decline or haggle, and you usually pay fewer upfront costs. There are of course additional other costs to take into consideration. If you buy, how much will maintenance and support cost? What if you need to change providers? Is there vendor lock-in?

Building could be more adequate for those who have an existing tech base and the right internal capabilities.

Buying promises the least upfront costs, but watch out for hidden fees and use vendors that prioritise transparency.

3. Speed-to-market

This is more crucial in regions that have adopted open banking regulation. Timelines tend to be inaccurate when building in-house, especially when exploring an unbeaten path, but building doesn’t necessarily mean building from scratch. Open source software has slowly been gaining trust in the financial services sector. Developers often turn to Github and borrow hundreds of lines of code to leapfrog hours of unnecessary coding.

Needless to say, open source comes with its own notable advantages and disadvantages.

IT providers, on the other hand, have already implemented open banking a number of times with other clients. Their battle-tested technologies are usually ready to be integrated with your core banking systems and you can get the more complicated processes, such as consent flows, running in record time.

But be wary of unexpected delays even with IT providers. If delays do happen, they will most likely be out of your control.

When buying, keep a sharp eye out for proof of rapid time-to-market and avoid vague propositions.

When building, leverage open source code to accelerate development.

4. Functionality

What functionality do you need to reach your business goals?

More advanced institutions may find that available Open Banking or API Management solutions don’t fully deliver their vision. In this case, as the proprietary code of most acquired software cannot be modified, the only apparent solution is to build from scratch. But features take third place when time and money are on the table. If the budget doesn’t allow it, you’ll have to resort to buying. And here, when buying, you may have to sacrifice features that you had your eyes on.

Remember: your primary interest is to find secure and convenient ways to facilitate API design & monetisation. You can afford to sacrifice the extra functionality if the solution allows you to build your own features later on.

Build it if you need specific functionality that you can’t find with reliable providers.

Buy it if the solution already has the main functionality you need and it provides flexibility for adding features in the near future.

5. Opportunity cost

Opportunity cost is “the forgone benefit that would have been derived by an option not chosen”.

Consider the time your engineers and developers dedicate to open banking and how much time that takes away from the primary business. These are opportunity costs. To avoid missing these innovation opportunities, financial institutions would do well to grow their technical teams.

6. Know-how

For a successful and lucrative open banking strategy, you need employees who understand the business side of open banking APIs.

These experts will collaborate with the IT team to help them design for monetisation.

If you build, these experts will have to either come as new talent, or as external consultants.

If you buy, the know-how is already present in your provider’s team. However, this becomes less useful if the provider intends to keep the knowledge to himself.

Build

Pros

• Prioritise adding features that are in line with business objectives;
• Build it to work with the rest of your stack;
• Avoid depending on external services;
• Own what you build so you can sell to other organisations;
• Reutilise open-source code with permissive licences (Apache or MIT) or less permissive licences (AGPL) to fast-track development.

Cons

• Difficult to estimate costs
• Uncertain timeline
• Uncertain outcome
• Requires more resources, planning, expertise and effort
• Risk of retracing steps halfway
• Requires hiring new talent/expanding development team

Buy

Pros

• Cut time-to-market considerably;
• There are lower upfront costs;
• Battle-tested solutions mean more certain outcomes;
• Start designing immediately for commercialisation for a better chance of gaining ROI;
• Allows you to concentrate on the main business instead of maintenance and support;
• Leverage extensive expertise;
• Uncovers unexpected opportunities.

Cons

• Proprietary software can lead to vendor lock-in;
• Risk of hidden costs;
• You have to rely on the vendor to add new features;
• Vendors may not have 360° knowledge about your regional requirements;
• You may need to rely on external servers;
• Using a commonly-used software may hinder competitive advantage;
• May not integrate with important tools and code in your stack.

As noted above, each option has positive and negative qualities.

Luckily, these options can be complementary. For example, there are organisations that make flexible solutions that allow you to tweak the code and add the functionality you need. This type of hybrid solution eliminates some negative aspects of build, such as uncertainty of outcome and the possibility of higher costs, while enabling customisation of the code and addition of important features at will.

But disadvantages remain, depending on the provider. For example, it may be difficult to integrate the solution with your stack even if you customise the code, and you might still have to rely on external servers.

Successful Buy – Royal Bank of Canada

Name: Royal Bank of Canada
Aim: Increase engagement in partner channels and drive low-cost innovation
Implementation time: 4 months
Provider: Apigee

Successful Build – Asia Commercial Bank

Name: Asia Commercial Bank
Aim: To lay the groundwork for Open Banking in Vietnam and to set an example as the first commercial bank to implement Open Banking in the region.
Implementation time: 8 Months

Aware of the difficulty in building in-house, TESOBE talked to the ACB team to gather greater detail.

Detailed implementation time: The ACB team started planning in December 2018 and began implementation in January 2019. They officially launched the developer portal in August 2019, and they have invited pilot integrations from multiple partners ever since.

Why did they build in-house? Talking to the team, we found out that they initially collaborated with a vendor to develop the first MVP. Despite the vendor’s expertise and technology, which were perfect for the job, they lacked full understanding of Vietnamese regulations and therefore didn’t know which innovations were absolutely necessary.

Taking this into consideration and seeing how customised most successful banking platforms were (like HSBC and Citibank), they decided to re-build the platform themselves.

Challenges:

According to IT Team Lead at ACB, Dzung Nguyen Thien, the biggest challenge was dividing the team into two major groups:

• One group tasked with researching the open banking/open API market and learning about other successful products;
• The other group tasked with exploiting this information internally and combining it with the core banking system in order to offer the best services and integration.

“It was an arduous process with a significant learning curve for the small development team we have. But it turned out to be a great chance for us to learn both the business and technology that ACB needs to be “open” to the Vietnamese market.” – Dzung Nguyen Thien,  IT Team Lead at ACB.

Hybrid Model – HSBC

Name: HSBC
Aim: Create new models to support engagement with developers, as part of the group’s effort towards achieving Smart Banking
Implementation time: 6 months
Provider: TESOBE / Open Bank Project

• Consider your resources

What does your cash flow forecast say? It may be uncertain in these times, but there will no doubt be an indicator that suggests how much you can spend on a project.

Resources include manpower. How large is your IT team? How busy are they with current projects? Do you have other projects in mind for the next year?

Map your resources and you may find the answer.

• Determine your goals

Are you complying with regulation? Or are you trying to monetise your APIs?

Once this is clarified, you can start to consider what you need in your ideal solution. Which features are indispensable and which are nice-to-haves?

Some journeys can become more complex than others and can be daunting for banks with limited technical capabilities.

• Compare solutions thinking in the long term

This may seem like an obvious one. The solution you choose now may not be the solution you need in a year. By now, you should have a roadmap and should know your strategic direction. You know where you want to be.

Will the solution that can satisfy your needs now still satisfy them later on?

Especially if you’re complying with regulation, it takes some time to consider all of the requirements.

Regulatory APIs require more than just importing an OpenAPI file. There’s OAuth2, OIDC and the FAPI/PKCE flow to take care of, eIDAS certificates, consent flows and screens, Strong Customer Authentication… the works!

And so, we recommend taking your time to learn about open banking and determine if you’re in the right position to build or to buy. Don’t rush into your transformation journey without taking all aspects of open banking into careful consideration.

Remember: slow and steady wins the race. In this way, you don’t risk speeding down the wrong road and having to retrace your steps.

Want a more personalised recommendation? Contact us for a hand in assessing your situation.