Open Banking implementation: How to chart the right course
Published on January 26, 2023,
The Open Banking landscape in North America is primed to take a large step forward in early 2023 in response to anticipated national financial regulations in Canada. Additionally, in October 2022, the US Consumer Financial Protection Bureau (CFPB) announced its intent to introduce similar measures aimed at ensuring personal financial data rights for Americans. Financial institutions, data aggregators and fintechs operating in the US and/or Canada will soon be required to eliminate screen scraping practices, and will need to decide on the best path to adoption of standards such as FAPI and FDX that will likely underpin these to-be regulations. There are many misconceptions surrounding Open Banking implementation. Foremost of these is the “buy vs build” decision regarding how to implement the APIs, authorization and consent mechanisms that are required to comply with the standards. The fact is that this is far from a binary decision; in reality, it’s more of a sliding scale.
Build or buy? It's not that simple
The extreme “build” end of this scale is a very heavy lift for any organization. There are new APIs to deploy, OAuth / FAPI implementation, and a consent management system to build. Even the sharpest technologists assigned to such a task will take months (if not years) to consume the related specifications and produce a workable production-ready implementation. Once the implementation is "done," expect to have to keep up with constant changes in the standards as the industry fine-tunes the specs through real world usage, missteps, and corrections. We've seen this firsthand in both the UK and Australia: security and privacy never sleep.
On the other extreme, the “buy” end of this scale, an organization could select one of the very few complete Open Banking SaaS offerings available today, and then integrate it with an existing (possibly non-compliant) banking APIs. This will certainly be the faster option, and at least in the short run (if not in all cases) will likely end up costing less than an implementation built and operated internally.
Organizations faced with making this build vs buy decision generally end up seeking answers to one or more of these questions:
- What if our organization falls somewhere in between?
- What if we don’t have a top-tier development team that can quickly turn the specs and standards into a working implementation?
- What if we do have that development team, but they’re busy for the foreseeable future working on another initiative?
- What if we need to avoid creating yet more infrastructural components that our understaffed operations and support team will need to take ownership of?
- What if we already have a solid consent management system that can easily be adapted to meet Open Banking requirements, but we don’t have the development horsepower to meet the authorization requirements?
The list of “what if” scenarios goes on and on. The right choice in most of these scenarios is to land somewhere along the scale between build and buy, to meet business needs without exceeding internal technical capabilities.
Open Banking implementation options
While there are many different combinations of services and technologies that can create a compliant Open Banking implementation, let’s break down the options into four categories to make things simple:
- Build everything – The 100% DIY model. Organizations going this route must a) consume the specification, b) implement the various components required to fulfill the authorization, consent and 3rd party registration requirements set forth by the Open Banking standards, and then c) create and deploy APIs using those components. Again, the work essentially never stops: organizations need to keep up with ongoing specification and implementation maintenance costs as newer versions of the standards are released.
- Buy Security, Build APIs – This option allows organizations to avoid the most complex parts of the specifications and standards by purchasing a solution that can fulfill the authorization, consent, and 3rd party registration requirements. This allows the organization to create and deploy APIs using an API management platform such as Google Apigee that allows seamless integration with the authorization and consent platform provider. This would mean buying or subscribing to software from a vendor that supports standards such as FAPI and FDX – Cloudentity is one of very few vendors that can do this at all, and we are absolutely the only vendor that can provide this support via SaaS and customer deployed software, with no need for customization. One thing that makes the vendor selection process difficult here is that, because there is not yet a true conformance test available for FDX, any vendor can claim compliance, which causes a lot of confusion. There is, however, a conformance and certification program for FAPI - we strongly suggest organizations start with this list if considering this route.
- Buy an Open Banking solution that includes security – With this, organizations deploy a “black box” solution that has already integrated a security solution and implemented FDX and FAPI compliant APIs. The main internal step here is to map to existing business APIs to the solution. There are only a handful of vendors that offer this type of solution – one of the more mature offerings is Axway Open Banking which uses Cloudentity to provide its security and consent layer.
- Buy (or subscribe to) a complete Open Banking service – This full "buy" option allows organizations to simply use the Open Banking service provider’s system, without significant internal technical lift. There are even fewer of these options available today. The best, and only concrete, option here is the recently announced Symcor COR.CONNECT platform which also uses Cloudentity to provide its security layer.
As businesses in North America begin to make these Open Banking implementation build vs buy decisions, understanding the range of options is critically important. That said, don't determine business or technical requirements based on what software options are available: the requirements should drive the technology choices and will ultimately drive the direction of the technology itself. Laying out an honest assessment of the objectives and capabilities of the business should be the first step in this process, followed by matching those objectives and capabilities to an implementation strategy. Once a strategy has been decided on, organizations can compare the vendors and products that fit the strategy directly to decide what will work best for the business.