Red Hat 블로그
Digital leaders are embracing open banking as a cornerstone to their banking distribution strategy. They are using APIs to connect with partners and bring innovative digital services to their customers who continue to seek better experiences.
More broadly, customers want banking services that integrate into their digital life, explains Capgemini in its World Retail Banking Report 2018. “That’s why it makes strategic sense for banks to support the API-led economy and collaborate with third-parties to offer new-age services,” the report says.
In fact, Capgemini noted in its 2017 World Retail Banking Report that more than 78 percent of banks, and almost an equal number of fintechs, want to use APIs to improve their customers’ experience. Many also said that they believed APIs could help them generate new revenue streams. Accenture Research finds that the number of financial services-related APIs that third parties could connect to have nearly doubled since 2014, sprouting from 911 to 1,675 in 2017.
APIs matter in the digitalization of the financial services industry, but they do need to be continually updated to deliver value for partners and ultimately customers. As new technologies emerge, banks need to evaluate how they can improve software delivery and more importantly attract and retain partners. A container first approach can provide a more coherent and nimble platform without the bloat of previous generations of API management products.
Here are four key tactics for improving the delivery of APIs in banking:
1. Design effective APIs. Thoughtful design means fewer setbacks in being able to reap the value of APIs that can drive critical business metrics. Ask yourself:
Are you creating the right APIs? Not all APIs have the same commercial or customer impact.
Are you employing design thinking with developer empathy to the APIs that are being designed? Complex, obtuse, system driven design hampers adoption.
Are you considering the end to end design? It is important to consider the technology to support the business capability being delivered, and not just the API contract design.
2. Work through your operations plans. In other words, set the stage to help make sure that APIs deliver according to partner expectations. Ask yourself:
What are your plans for access control? Take into consideration end to end access control, including plugging into a service control plane
Are you focused on keeping traffic loads predictable? Spikes will happen but rate limits and usage quotas on incoming volumes can ease the load. This is especially true when the system of record does not have elastic capabilities. Preparing for variations by analyzing system processing can help adjust proactively.
Do you know how an API is being used? Having as much visibility as possible about what’s happening to your APIs matters when it comes to fulfilling objectives and it depends on capturing traffic pattern data and analyzing it.
3. Focus on the developer. Design simplicity and flexibility is done with someone in mind. Developers can make or break the success of your API services, so it’s important to engage with them the way they want. Ask yourself:
How clear is the API’s value proposition? If it’s not obvious to your development community, they won’t use it.
How easy is it to onboard developers? How many clicks to “Hello World?” More formal agreements with developers may be required for more sensitive APIs or data access, but a simple, straightforward onboarding can allow for early developer success.
Are you prepared to support the development community? Good docs, FAQs and forums should be used for the self-service approach. But put in place a support mechanism to handle more in-depth questions.
4. Prepare for API change management and end-of-life cycle. Good practices for design, creation, and operation are important, but strong change or retirement practices are as critical or even more so. Ask yourself:
How are you structuring your change and breaking change processes and communication? The first step is knowing what level of service stability and support you are willing to commit to for users when it comes to fixing change policies. The second is having a release process in place so that that commitment isn’t violated – you don’t want your reputation to be sullied.
Do you have a clear detection and retirement support process? If you don’t put developer and user IDs in place, you won’t be able to determine version usage among clients and you could be setting yourself up for trouble.
Are you prepared for API evolution to be aligned with related product evolution? A plan should be set in advance with the product organization team so that product needs that require API changes are handled in a way that doesn’t violate API stability guarantees.
Red Hat’s open banking solution includes capabilities to effectively manage APIs, which is designed to address these issues, which can help to make it easier to distribute your APIs, as well as monetize them. To learn more, including our recommended practices, visit us here.
About the author
Eric Marts is a financial services leader at Red Hat. Prior to joining Red Hat, Eric shaped solutions globally in the Retail Banking and Wealth Management business at HSBC. He has more than 20 years of professional experience across both startups and incumbents. He is particularly interested in unlocking new market opportunities and making financial services simpler and more inclusive for customers with cloud technology.