Open banking: Should I build or partner?

Since the introduction of the revised Payment Services Directive (PSD2) and Open Banking in 2018, the payments sector in the UK and EU has exploded. Every day you read about a new, innovative product aimed at making life easier for consumers. But while new payments regulation presents new opportunities for businesses, it also involves important choices.

One important choice being: should you build or partner on your open banking initiatives? Accessing consumer financial data means tapping into a financial institution’s digital infrastructure, and that requires an Application Programme Interface (API). The choice facing fintechs is whether to build the API themselves, partner with a third party provider (TPP), or partner with a technical service provider (TSP) who builds the APIs for them.

Since 2019, Plaid has been authorised by the Financial Conduct Authority (FCA) under the Payment Service Regulations 2017 [Firm Reference Number: 804718] for the provision of  Account Information Services (AIS) and Payment Initiation Services (PIS) in the UK and EU. We’ve learned a lot during this time and wanted to share a few insights on what firms should consider before entering the open banking market.

Our learnings can be broken down into three main categories:

• Regulations

• Cost

• Speed to market

Regulations

The beauty of open banking lies in the ease in which consumers can allow fintechs and other third parties to access their personal payment account data; however, before third parties are cleared for account access and data use, they must meet stringent regulatory requirements.

Under PSD2, your business activity determines your regulatory requirements. The two open banking categories under PSD2 are:

1. Payment Initiation Service Provider (PISP): If you aim to initiate payments, you will need to be authorised as a PISP.

2. Account Information Service Provider (AISP): If you aim to access consumer payment account data in order to display consolidated account information to a user, you need to be authorised or registered as an AISP.

To become a licensed AISP or PISP, you must apply to the FCA in the UK or the local National Competent Authority in another EU member state. It can take 3-6 months to get approved and requires demonstrating PSD2 compliance, to include appropriate data privacy and IT.

The good news for those wishing to provide AIS only–in some cases, you won’t need your own AISP license. If you are using account information for internal purposes and not reprovisioning it, you do not need to be regulated. However, if you are planning on reprovisioning the account information you still may not need a license. Rather, you can become the agent of an authorised TPP that holds an AISP license, who would then be the principal responsible for AISP regulatory obligations.

Becoming an agent of an authorised TPP allows firms to quickly launch their product into the market and provide AIS, without needing to become authorised in their own right beforehand, allowing them to concentrate on what they do best.

Since October 2019, we’ve worked with our agents to enable them to quickly and cost-effectively enter the open banking market and begin gaining exposure and customers. We look forward to working with more agents in the coming months.

Questions to consider:

• Do I need to be licensed as a PISP, AISP, or both?

• Do I plan to build out a compliance team and apply for my own license?

• Could I become the agent of an authorised TPP instead?

Cost

The cost to build and maintain an integration varies by institution based on their mix of legacy issues, product niches, and resource requirements. The one major cost implication for every firm; however, is regulatory. There is a huge cost difference for a firm that needs to be regulated versus a firm that does not.

Let’s examine other costs. Under PSD2, firms can either become an authorised or registered TPP and build connections to financial institutions APIs, become an agent of an authorised or registered TPP that can build the connections for you or partner with a technical service provider. Each option has different cost implications.

If you decide to build your own APIs, consider the following:

1. API integration. In the UK, there are more than 345 banks and building societies. While the CMA9 are required to use the same Open Banking APIs, those banks represent only a fraction of the total number of financial institutions that you would likely have to integrate with.

2. Build time and costs. It took our team of engineers about six months to get our open banking APIs up and running in the UK and EU. During that time, we were paying salaries and planning for ongoing staff support.

3. Ongoing costs. Finishing the API integrations is only half the battle. APIs require ongoing review and maintenance, so you’ll need a team of engineers to constantly maintain your APIs.

Conversely, if you decide to partner with an authorised or registered TPP and become an agent or partner with a TSP consider the following:

1. TPP cost structure. Some TPPs charge based on the number of integrations you require. The more integrations, the higher the cost.

2. Maintenance. Because TPPs manage APIs, you won’t have to worry about maintaining APIs or resourcing those roles within your company. Everything is outsourced to the TPP.

3. Improvements. If you build integrations directly, you won’t benefit from larger-scale improvements made to the APIs by your TPP partner. This could include things like bug fixes and improvements to categorisation.

Of course, this only summarises the cost of APIs. No matter which route you take, you will need to consider staffing requirements such as support engineers, regulatory and compliance management, and relationship management.

Questions to consider:

• Would building API integrations in-house contribute to our competitive advantage?

• Could we do it as well as or better than an authorised TPP in the marketplace?

• Does the TPP already have connections with the banks we want?

• Is building our own banking API worth the products and features we would be giving up?

Speed to market

A key question to consider before deciding whether to build or partner is how quickly can we launch?

This is always a consideration when creating a new product or service. But open banking presents the additional barrier of getting access to consumers payment account data. No matter which route you take to access data–building your own APIs or partnering with a TPP–you will still need permission from the local regulator if you are carrying out open banking activities of AIS and PIS. As already discussed, becoming registered or authorised in your own right is a lengthy process; however, the agent model offers a speedier route to market if you wish to provide AIS.

Building your own APIs will add months, if not years, to your ramp time. By contrast, purchasing an out-of-the-box solution from a TPP can have you up-and-running in a fraction of the time. And when you partner with a TPP, you don’t just get the software, you also piggyback on your partner’s invaluable engineering, banking and regulatory expertise.

Some further questions to consider:

• What is our target time to market?

• Would we benefit by  becoming an agent of an authorised TPP? Can we afford to sit on the sidelines while waiting to become authorised in our own right?

In summary

Whether you build or partner will depend on your goals, your product, your budget, and your timeline. The first step in deciding which route to take should always be to consider your regulatory position, as whether or not you need to be  regulated will strongly influence your decision.

Beyond that, if speed to market is a priority, you may lean towards partnering with an authorised TPP, as regulatory approval and build time will add several months to your target ship date, as well as significant costs. On the other hand, if you believe your business model relies on managing your own bank APIs, then you will likely want to build those yourself.

If you’re curious about Open Banking initiatives, reach out to Plaid to see how we can help.