PISPs and AISPs handle customer consent needed to access Open Banking data. This means each AISP and PISP clearly explain to the end-user what data will be accessed, for how long, and who it will be shared with. This digital consent journey also forms the basis of data processing for AISPs and PISPs under GDPR
If you’re active in the banking services industry, you’ve probably kept a close eye on FinTech in recent years. Its rise has given us game-changing products like affordable money transfer services, borderless bank accounts, and peer-to-peer lending platforms, to name but a few. It’s also given us open banking—the industry’s latest development—which is sure to have a big impact on companies and consumers alike in the near future. Today’s mission for the Mooncascade team is to present a number of open banking examples to introduce you to the technology and it’s possibilities.
What is open banking?
Open banking is the practice of sharing financial data, securely and with user consent, to third-party payment and banking service providers. Though it’s been around since 2016 in the UK, open banking was introduced across Europe with the revised Payment Services Directive (PSD2), a 2018 E.U. directive that added third-party payment service providers to the legal framework for banking services.
Giving third-party providers access to financial data means we’ll be seeing an exciting range of open banking examples and tools in the near future. It also means we’ll be seeing plenty of big opportunities for those who build them. In fact, there are quite a few early adopters already out there. But this shift won’t come without its fair share of risks and challenges. To find out why open banking matters, how it works, and what to look for before diving in, read on.
Why open banking?
Open banking was established with the end-user in mind. The idea is to open banks to competition and improve the services they offer by creating new opportunities around financial data. Though open banking is made possible by legislation, its real promise lies in application programming interfaces, or APIs, which banks now have to share with licensed third-party service providers. In short, bank APIs provide programmatic access to all of their customers’ financial data. And with the passing of PSD2, any licensed company can now access them. This data is only shared with user consent, of course.
The first of many open banking examples and possibilities that we want to present today is this: If you’re building a financial services product, this is exciting for a few reasons. First of all, APIs allow you to avoid screen scraping processes, which are slow to use and expensive to maintain. APIs are also more secure, as they don’t require users to provide their banking credentials to anyone, but have the bank share information directly with your service. More broadly, these APIs mean that third-party companies no longer have to go through banks to get a complete picture of their users’ financial data via proprietary APIs – and that opens up even more open banking examples and possibilities. With a license and user consent, you can now access this kind of information directly, making it easier than ever to target, optimize, and innovate on the financial services you offer.
Open banking examples for B2B markets: AISP vs. PISP.
Now that we’ve covered the basics, let’s have a look at what you need to get started and join this world of open banking examples and possibilities yourself. The first thing you want to determine is whether you’d need an account information service provider license (AISP), a payment initiation service provider license (PISP), or both.
AISPs facilitate open banking examples and use cases by accessing user account information in a read-only way: they can view financial data, but they can’t modify it. Another of our open banking examples for today involves an AISP license. Such a license could help build a money management tool like MoneyHub, which uses machine learning to understand its users’ spending habits and build value through data analysis. It could also be used to create a loan application product like CreditKudos, which shares data gathered from a user’s account with a lender to facilitate the loan application process.
PISPs differ from AISPs in that they can send and receive payments. PISPs have been leveraged to create open banking examples and opportunities and start or enhance quite a few businesses, including Sofort, a real-time online banking and transfer service, and Trustly, which allows customers to pay for things online directly from their bank accounts. PISPs also open up plenty of unusual new possibilities and open banking examples, like Amazon’s short-lived but promising IoT service Dash, which allowed users to reorder a specific product at the click of a button, or Dave, a slightly scary app that pre-approves users for loans and sends them money whenever they’ve overdrawn their bank accounts.
The advantage of AISPs over PISPs when it comes to creating open banking examples and opportunities is that they’re much easier to access for newcomers. PISPs require significant capital and will have you working to overcome quite a few regulatory hurdles including liability, data protection, security, and insurance requirements- putting restrictions on the kinds of open banking examples and opportunities they can be used for. Making a final decision about which license to use (or deciding you need both) will depend on your specific business needs: if you only need to access your users’ financial information, an AISP will work just fine (as can be seen through the kinds of open banking examples that use them), but if you need to initiate payments on their behalf, you’ll have to go the extra mile and apply for a PISP.
Which license is best for me?
For many open banking examples, choosing between an AISP and PISP license will come down to a variety of factors that vary from business to business. You’ll have to consider the cost and ease of access of each option, it’s impact on the open banking examples and opportunities that you want to create, as well as its potential for building value within the context of your particular use case. If this seems daunting, remember that you can also partner with a company who has a license and build the rest of the product yourself.
Whether you’re starting out or trying something new, joining forces with a licensed company can be a good way to test the waters and how the open banking examples we’ve talked about above will work for you without taking on too much risk on your end. Say you’re an online merchant who accepts credit card payments. Dealing with potential chargebacks due to fraud can be a costly headache. If you have access to a PISP license through a service like Tink – or another of the aforementioned open banking examples – it’ll greatly increase security, as customers will be paying directly from their accounts without having to enter their banking details on your website. Partnering with a third party can also help avoid dealing with PCI compliance, a legal hurdle required if any credit card numbers come into direct contact with your business. A licensed payment processor like Stripe, for example, can handle this for you.
That said, working with a partner isn’t right for everyone. First of all, third-party providers will charge for their services. Secondly, when working under someone else’s license, you become their agent and are responsible for operating compliantly and in accordance with their standards. If you were to build on someone else’s licensed platform to sell a product to third-party companies, for example, not only would you be legally bound to their terms, but your partners would too, as would their customers, and so on. This can create a messy legal chain you’d be better off avoiding if you plan on providing services to companies rather than individuals.
What should I know about APIs?
The open banking examples we’ve cited, and open banking in general are largely based on APIs, you’ll have to keep a few important technical considerations in mind when coming up with a business model, too. Though the open banking directive in the UK has a unified set of rules for banks to follow when sharing APIs, the PSD2 directive doesn’t specify how exactly European banks should share their data through these various open banking examples and platforms. And although certain standards do exist, you generally need to approach integration differently with each bank’s API.
One thing you want to focus on is the functionality of the API you’ll be using for any open banking examples and opportunities you create. As this process is so new, many banks are still changing and fixing their APIs. If you’re building open banking examples, platforms or opportunities around them, you can easily find yourself in a situation where something stops working from one day to the next. A good way to pinpoint risks before making any commitments is to use sandboxes, which are environments where you can try a bank or third-party license provider’s way of processing payments for free. Most banks offer one, as do aggregator companies like TrueLayer.
Another big technical consideration with any open banking examples or opportunities is security. You want to build a product that gives you and your customers peace of mind, especially when dealing with financial services. Although most companies in the U.S. still use screen scraping, APIs are already the norm for security in Europe, despite the additional costs that licensing incurs. This seems to be the direction the industry is heading in overall as well: Plaid, a Silicon Valley start-up bought by Visa for over $5 billion, recently announced it had struck up agreements with a number of banks to start using APIs in its services.
Open banking: a tough learning curve with big potential.
Though open banking is a promising new development, getting a product to market will come with a number of complex legal and technical issues that are hard to avoid. It’s important to do your research, understand the environment, and know what you want to get out of any open banking examples or opportunities we’ve mentioned today. Don’t rush legal considerations like licensing and liability, prefer APIs over screen scraping when thinking about security, and remember to look closely at the functionality of whichever APIs you do end up working with.
Here at Mooncascade, we have plenty of insight into the engineering process behind a host of successful FinTech products. We can use our knowledge of app and backend development to help you better understand the industry and apply our experience to your own use cases. To learn more about our expertise and what we can do to make your open banking product shine, get in touch today!
