Digital Finance APIs Come with Risks – Here’s One Way to Manage Them

Often an open API initiative starts when a digital financial services (DFS) provider sees the potential for scaling the exposure of services, such as payments, to partners and third parties. However, internal resistance can squelch the initiative, as management grapples with potential security, data privacy and brand reputation risks. While these concerns are valid, if providers believe open APIs make sense from a commercial perspective, they should think about how to address risks rather than miss out on the opportunities of open APIs altogether. One way to do this is through the use of fair, standardized legal contracts with partners and third-party providers.

A resource from CGAP and law firm Hogan Lovells, “Key Considerations When Developing Legal Terms and Conditions for Financial Services APIs” (2020), aims to help DFS providers address potential risks when exposing open APIs. It describes the risks a DFS provider will need to consider and includes a contract template that can help DFS provider’s initiate discussions internally. Sound legal contracts can complement operational risk management practices. And like APIs themselves, standardized legal contracts can reduce on-boarding time when working with external partners.

Common risks when exposing APIs

Three of the most common types of risks that DFS providers may face when opening up APIs include:

• Unauthorized transactions. Fraudulent actions may be taken on the DFS provider’s customer accounts.
• Misuse or exposure of customer data. Customer data might be exposed through APIs without consent or a partner might use customer data unlawfully or beyond what was agreed with the provider.
• Reputational. A DFS provider’s brand may be tarnished if a partner acts inappropriately, especially when partnerships and initiatives are co-branded.

In each of these cases, the DFS provider could be liable for damages that result from risky API use. By tailoring the sample contract mentioned in this post to their legal needs and context, DFS providers can identify risks, clarify responsibilities with third parties and specify which party is liable in different circumstances.

Six characteristics of an API contract

Some of the key issues that an API contract may seek to clarify include:

1. Withdrawal/suspension/termination. A contract should clarify the rights of both parties if a partner acts (or is believed to have acted) outside the contract provisions.
2. Customer consent. The DFS provider can explain how API consumers will need to confirm customer consent for access to their data or to initiate payments.
3. Data protection. DFS providers can explain how partners are expected to manage joint customer data and how they will manage data on third parties.
4. Security. The DFS provider can stipulate how it and the third party are expected to manage security issues.
5. Technical considerations. The contract should stipulate the DFS provider’s responsibilities and ways of working, clarify any technical standards that third parties must use and set service-level performance expectations.
6. Dispute resolution. The contract should explain how disputes will be resolved.

In addition to covering these issues, the contract template includes provisions to protect the DFS provider and third party and to ensure the third party has enough confidence to build commercial products for the parties’ shared customers.

An API contract should also seek to define how a DFS provider will open its functionalities sufficiently to allow third parties to create innovative products, while ensuring the safety of end customers and the adherence of all parties to regulatory and commercial concerns. Strict contract clauses may give DFS providers certainty, but too many restrictions will prevent third parties from generating value for customers. A legal contract helps ensure that the terms of use, the dispute resolution process and the level of liability are fair. This gives third-party providers confidence that they can build a viable business consuming the DFS provider’s APIs.

While DFS providers will need to adapt the contract to meet their local laws and partner on-boarding processes, using an API contract template removes the need for DFS providers to reinvent the wheel. Adapting a standard contract template to fit the DFS provider’s market context, risk profile or legislative framework can lower costs and reduce time to market for the provider.

To learn more about how to manage the risks of APIs, see "Key Considerations When Developing Legal Terms and Conditions for Financial Services APIs" (CGAP and Hogan Lovells, 2020) and the accompanying API contract template.