FinTech: API Strategies

What is API?

APIs are an essential component in cost-effective application development. To stay ahead of the development curve, developers and senior management in large corporations must strategically plan API environment creation and maintenance. For example, megabanks, such as Deutsche, HSBC, and JPMorgan Chase, have developer portals and APIs to help customers and partners develop tools that interact seamlessly with their data and their workflow needs.

Any API strategy has associated development and maintenance costs. APIs take time and labor to create. However, that time and labor is generally made up — and then some — by the convenience and efficiency they provide to the programmers who use them. A side benefit of using APIs is that they allow systems/applications to be built by a third party, because they simplify the programming process. An enterprise should develop an API strategy that consists of public and private APIs and that is well documented and part of all release cycles.

To better understand APIs, imagine that you had friends over, and you wanted to serve an Italian dinner. You could assemble all the ingredients yourself and make it, but it would take an hour and a half, and you have only 30 minutes. What do you do? You pull out a jar of spaghetti sauce, boil some water for dried pasta, and buy a prepared loaf of garlic bread. And voilà! Dinner is served.

Having APIs in your programming pantry is like having premade spaghetti sauce, garlic bread, and pasta. The components/ingredients needed to prepare the program are all available in the source code. When bundled together, they make up the API.

The beauty of APIs is that you can swap out components. If you don’t like spaghetti, you can easily have corned beef instead. Or if a friend wanted something different, he could take the APIs available to everyone and make something out of the same underlying components/ingredients. Anyone using these APIs doesn’t have to know anything about how to cook or assemble the ingredients; it’s all preconfigured for him. The following figure illustrates the concept.

Delivering dinner via APIs versus source code.

As you can see, having prepackaged elements already tested and ready to use speeds up the time to completion of any application. The providing company can choose what it wants to prepackage so the nature of the “secret sauce” (in other words, the underlying code) is never revealed — just the end product.

API benefits

Providing APIs makes sense because they expand the reach of a company’s core business through user-friendly interfaces and API tools. APIs provide for faster application development and integration, and they increase the ease with which partners and customers can use and develop custom work on the top of the application’s code. Partners and customers can then own those components, which are specific to their corporate needs, and the company can retain and integrate those applications that have universal appeal into their master codebase. By providing easy access to API libraries internally, you can encourage employee innovation and ownership. APIs can also be used to modernize and replace legacy systems more efficiently.

APIs assist in the integration of data and the streamlining of workflow. By exposing APIs, you can reveal important data to customers and partners without revealing proprietary code. APIs also speed up the development process and make development by external users possible without security risk.

Without APIs, your developers would need to support application onboarding, which involves time away from core development work and results in less product creation and a higher cost of ownership to the application.

Developing an API strategy

Developing and adhering to a detailed API strategy is critical to an organization’s success.

• Defining the optimal outcomes for API usage both internally and externally
• Publishing the expected outcomes and approaches to the target groups involved for feedback
• Understanding and identifying the way your technical teams work
• Understanding and identifying the systems that the organization, its customers, and its partners use
• Developing a beta deployment process that includes an easy way to track and support internal and external beta users
• Developing a feeder structure in which each iteration is first rolled out to “heavy” internal users and then to customers and partners who are committed to using the APIs and providing feedback
• Assuring that support and maintenance personnel have been assigned and given clear key performance indicators (KPI) around the API framework
• Tying the successful development and maintenance of this system to all new releases
• Developing a user group philosophy where external users are encouraged to share and develop user groups and are rewarded and recognized for doing so
• Establishing an API web portal that includes easy interfaces for gathering user feedback; a repository of new packages and libraries created by both employees and external users; easy access to all documentation; and rapid knowledge exchange
• Developing a process for version control, tools, and documentation that provides and augments designing, testing, and developing in every release and every API package
• Offering the ability to license the use of the APIs and to monitor the use against possible security intrusion via the web portal

Any standardization practice is only as good as its users. The API strategy, once created, must be adhered to by all developers and participants.

Including REST and RAML

What do we mean by RESTful API? REST stands for REpresentational State Transfer. It is stateless — each action is treated uniquely, there is no record of previous interactions, and it enables plain-text exchanges, rather than HTML, which allows coders to use efficient configuration directives for start-up and saved settings. It also enables security policy inheritance, which allows for the inheritance of as well as adherence to security requirements. RAML (Restful API Modeling Language) allows REST APIs to be formally defined. RAML can define every resource and operation exposed by a microservice.

Both tools are scalable and secure components and include a mechanism for creating license agreements that stipulate how the APIs are used. Tools are also available for monitoring the use of third-party developers to guard against privacy and security violations. They also include provisioning tools for logging and updating issues.

Trying tips for API success

• Recruit from the start. Get buy-in from senior management and appoint a project owner who is eager to evangelize about the benefits.
• As with all development, it’s important to keep an up-to-date library of use cases and terms so that instead of re-inventing the wheel, you’re recycling and reusing whenever possible.
• Don’t get bogged down in the minutiae.
• Build a flexible high-level plan that can be easily altered and expanded.
• Revisit that plan on a scheduled basis. Each company should develop a calendar that meshes with its development cycles. In general, API strategies should be reviewed at least annually, though some are reviewed at the time of each release.
• Develop a robust API portal to handle internal and external users — from licensing through downloads and support. Most API downloads are stored and updated on the general product download site.
• Build a back-end management system.

APIs and security vulnerabilities

Some inevitable security risks come with implementing a flexible and accessible API strategy. Be sure to review the level of data vulnerability at each point in the process, looking at issues of data controls, movement, and encryption, and either accept or take steps to decrease the risks.

• Employ a comprehensive licensing mechanism.
• Create clear requirements around authentication and event logging.
• Test every release against clearly defined security standards.
• Use multifactor authentication.
• Establish clearly defined rules for data encryption.