There is a general complaint encountered by developers from among open banking participants, even after partner APIs are made available: Adoption isn’t straightforward.
We’ve experienced this across hundreds of integration points. Even with the developer assistance toolbox, which includes documentation, software developer kits and sandboxes, and developer self-service consoles, partner integration timelines are intractable. Developer and support teams are overloaded for each integration.
For financial products with complex customer journeys and for BaaS partnerships requiring complex on-boarding, compliance and API integrations, the degree of handholding required is even greater.
More support, higher integration cost
This also impacts open banking accessibility, putting it out of reach for the broader ecosystem. If there is a high cost to a partnership, the benefit becomes a key criterion. As financial institutions become picky about who partners with them, this de-levels the playing field creating a disadvantage for smaller players.
So, what is the right level of integration assistance? How can open banking be made accessible to all?
This is a discussion on how to create integration options for your API consumers. I’ll discuss what the options are and why and when they are meaningful.
A typical partner integration follows these 4 steps:
1. Channel front-end: This is the application on which the services powered by the APIs will be made available to the end user. This is where the partner designs its customer journey.
However, while the partner has complete control over the branding, look and user experience (UX), this is also where the customer authenticates themself, inputs their personal information, and provides consent to the app to share this via APIs. For designing such a user interface (UI), a partner without adequate experience may require oversight to ensure that the overall customer journey meets the regulatory requirements.
2. Data security compliance: In addition to consent, there are compliance requirements that govern how and what customer data should be captured, transmitted, shared and stored. In an open banking partnership, this compliance may also be the responsibility of all ecosystem partners involved in the integration, and the integrating partner needs to ensure that its application and connectors meet the requirements.
3. API service orchestration: In a typical multi-API journey, the APIs need to be stitched together to create the journey. This may entail a session management and authority; message encryption and decryption; third party handoffs; and logic-built into a middleware layer, which may likely be development-intensive, depending on the complexity of the journey.
4. API integration: For each API required for the journey, the partner application must consume the API; this means it must be on-boarded and complete the configuration requirements, complete the development to call the required methods and consume the responses.
Not all partners in the integration may have the capability for all four steps. For example, there may be incumbents from a nonfinancial industry who want to partner with a bank for co-branded lending or a card offering for its customers, but don’t meet the PCI-DSS compliance requirements.
This means there will need to be significant investment from the partner to become compliant or that a sub-par customer experience design will result. Also, there may be smaller fintechs without the developer capacity for the orchestration effort required. Hence, they may need to stretch beyond their reach to make the partnership happen.
Integration effort is variable
How can we best reduce the integration effort?
The nuance this question misses is that different types of partners have very different needs. There are players who want complete control over their customers’ experience, and want to “look under the hood” and tinker with the parts, nuts and bolts. There are players who want control, but do not want to take on the burden of compliance. And there are players who only want the BaaS partnership to complete their digital offerings, but don’t want to invest in any additional development.
Democratizing API integration: 4
The starting point is, of course, understanding partner archetypes and partner requirements from the integration. The platform solution design follows these four needs.
1. Build-your-own integrations: Making raw materials and tools available
This integration option is analogous to starting from basic raw materials, or ingredients, and is for those that know exactly what they want and how to achieve it. The key platform offerings are the APIs and a complete developer experience toolbox. If you’re curious about what that means from an API banking context, we have a piece about that.
The kind of integrating partners who are likely to use the build-your-own option are those with offerings closely adjacent to banking, and that have done this before.
2. Integration with managed data compliance: All raw materials and tools, with compliance crutches
With this option, also, the integration partner has all the raw materials to completely control the experience, but without the overhead of compliance, especially related to sensitive data.
With the help of cross-domain UI components, tokenization, collection and storage of data can be handled entirely at the bank end, while the partner only has to embed these components into its front-end.
This option is especially helpful for those integrating partners that want to control the experience, but to whom financial services is not a core offering, and so compliance is an unnecessary overhead which they are happy to avoid.
3. Pre-built journeys
Offering pre-built journeys allows a partner to focus only on the front-end experience, while the entire API orchestration and compliance is handled in a middleware layer and abstracted away for the integrating partners.
For a typical banking service, designing an API-first journey means working with a number of separate endpoints and stitching the services together. For instance, a simple loan origination journey for a customer may look like this: (simplified for illustration)
This journey requires five services from the bank: customer authentication and consent, customer personal data collection, credit decisioning and approval, KYC and loan disbursal.
Stitching these services together to create a single end-to-end digital experience for a customer may call for a thick middleware with a database and caching, data tokenization and encryption, session management, handoffs across services and other related orchestration.
To enable partners to deliver this journey without the need for orchestration, this layer can be moved to a platform on the bank side and offered as an integration solution to the partners. The partner now only needs to integrate with the platform, and build its UI and UX.
Such a solution, of course, helps drastically cut down development time for the integration and is especially compelling for smaller players and channel sales partners that want to offer banking products or services to their customers.
4. Pre-built UI or shareable links
No integration required, but with directly embeddable, customizable UIs, partners can offer the relevant banking functionality or services with minimal effort. This is equivalent to a contextual redirect and is extremely useful for cases where the partner wants to avail itself of only minimal open banking services and does not want to go through the entire on-boarding, configuration and integration processes required for all other integration options.
Bringing it all together
While it is certainly possible to continue to grow partnerships by offering customizations and assistance to each integration, for achieving a rapid scale-up in open banking ecosystem partnerships, there is a need for a platform that standardizes these concerns and cuts across developer experience and integration needs.
Tvisha Dholakia is the co-founder of London-based apibanking.com, which looks to build the tech infrastructure to remove friction at the point of integration in open banking.
