Napala Pratini is a growth & business strategy consultant to early-stage technology companies. Since concluding her graduate studies at Oxford, she has been enjoying the UK startup scene.
2019 is an exciting time to be a UK fintech, with record amounts of capital flowing into the industry.
But while Open Banking presents new opportunities, it also involves important choices. Accessing permissioned consumer financial data means tapping into banks’ digital infrastructure, and that requires an API. The choice facing fintechs and other third parties is whether to build the API themselves or purchase a solution.
As with any buy-or-build decision, there are multiple factors to consider. Here the three you should consider for Open Banking:
Cost 💸
Speed to market 🚀
Regulations (AISP vs. PISP) 👮
Cost.
Cost is tricky, as the absolute costs to buy and implement a solution are relatively straightforward, while the costs to build are always estimates until they are actually incurred.
That said, here’s a helpful way to estimate the cost of building your own APIs:
Determine the number of bank integrations you feel you’d need in order to deliver a minimum viable product (MVP) to your users. (In the UK, there are more than 300 banks.)
Figure that it will take a team of 5 engineers about 6 months to get your MVP up and running. This is based on the experience of Plaid engineers, who recently built out their own integrations.
Multiply the monthly salaries of those 5 engineers by 6 months—and be aware that maintaining the integrations will require ongoing staff support.
Figure that you will need one staffer working full-time to maintain every four bank integrations. But that varies widely by bank, based on things like volume of traffic and the complexity of the integration.
Of course, that doesn’t fully capture the costs, as building your own banking APIs requires additional staff support: support engineers, regulatory and compliance management, and periodic audits.
Perhaps the biggest cost associated with building your own banking APIs is the opportunity cost: the things your engineers can’t build because they’re focusing on bank integrations.
Ask yourself:
Would building these integrations in-house contribute to our competitive advantage?
Could we do it as well as or better than anyone in the marketplace?
Is building our own banking API worth the products and features we would be giving up?
Speed to market.
How soon can I be up and running?
It’s a primary question asked by many fintechs and other third parties looking to access permissioned consumer banking data. The reason? Time is money.
While you languish in regulatory limbo and wait for your engineers to finish building a framework for extracting consumer data, your competitors are busy gaining users and valuable experience.
There is little margin for error, and the stakes couldn’t be higher. Customers are understandably quite sensitive about the security of their financial data. If you experience a breach, it could mean the end of your company.
Building your own APIs can add months if not years to your ramp time. By contrast, purchasing an out-of-the-box solution can have you up and running in as little as one day. When you partner, you don’t just get the software, you also piggyback on banking and regulatory expertise that have been built up over months and years.
Ask yourself:
What is my target time to market?
Can I afford to sit on the sidelines while I finish building/wait for a license?
Can I be reasonably certain that consumer data will be safe in our hands?
Regulatory considerations (AISP vs PISP).
The beauty of Open Banking lies in the ease with which consumers can permission their data for fintechs and other third parties to access. But in order for third parties to be cleared for data access, they must first meet stringent regulatory requirements.
There are two kinds of service providers who need licenses under Open Banking. Which category you fall into—and which regulations you are subject to—very much depend on what you’re trying to do.
PISP 📮 If you aim to initiate payments, you’re a Payment Initiation Service Provider (PISP).
AISP 💼 If your goal is to access consumer banking data in order to display consolidated account information to a user, you’re an Account Information Service Provider (AISP).
To become a licensed AISP or PISP, you must apply with the FCA. It can take 3-6 months to get approved and requires demonstrating PSD2 compliance, as well as appropriate data privacy and security measures.
Of the two, a PISP license is the more difficult to obtain—but here’s the good news. Most companies don’t initiate payments and therefore don’t need one.
For those wishing to access consumer banking data for reasons other than initiating payments, more good news. In many cases, you don’t need your own AISP license. Rather, you can outsource that part of your business to a Third Party Provider (TPP), who would then be responsible for AISP regulatory obligations.
Some companies may even choose to build their own APIs in the long term—but work with a vendor in the near term to build out a lightweight, testable core product. That allows you to prototype, evaluate, and iterate while you are waiting for regulatory approval.
Ask yourself:
Am I an PISP or an AISP?—i.e. do I plan to initiate payments, or am I accessing consumer banking data for another reason?
Do I plan to build out a policy team and apply for my own license?
Could I outsource the account information services part of my business to a TPP who would then be responsible for those regulatory obligations?
In sum.
Whether you build or buy will depend on your goals, your product, your budget, and your timeline.
If speed to market is a key priority, you may lean towards buying a solution, as regulatory approval and build time will add at least a few months to your target ship date. On the other hand, if you believe your business model relies on managing your own bank APIs, then you may want to build those in-house.
The key question to ask is whether building banking APIs in-house will contribute to your competitive advantage. If not, you should strongly consider partnering so that you can devote your resources and engineering bandwidth to strategic priorities.
Napala Pratini is a growth & business strategy consultant to early-stage technology companies. Since concluding her graduate studies at Oxford, she has been enjoying the UK startup scene.
