Application Programming Interfaces (APIs) in payment processing are gaining traction globally. In addition to open banking, they are now being used end to end in the payment value chain – linking internal systems together more efficiently, accessing external
applications, enabling the microservices transformation of legacy systems, and providing new channels for customers.
However, without a consistent approach to their us, and an overall strategy, APIs can exacerbate traditional bank IT challenges, such as increasingly expensive legacy system management, lack of standardization, exposure to security risks, and a failure to
meet customer expectations. With a strategic outlook, the bank misses out on enabling monetization, control, and efficiency.
Here are five areas that banks should consider before introducing, publishing, and consuming external and internal APIs in payment processes.
1) Security: Open banking exposes endpoints in banks to third parties, so requires appropriate levels of audit, control, and monitoring. The current manual auditing and static reporting practices are not sufficient, and given the speed at which
threats manifest themselves, an automated continuous API Security Assessment is needed.
Using a dynamic, real-time automated tool to analyze your open banking readiness – quantitatively and qualitatively – is the preferred approach, which provides actionable insights and remediation measures. API security issues highlighted by such tools
may require you to refactor the processes, applications, internal policies, and people to reduce the security gaps, and help you integrate with external third parties that in cases such as PSD2 and UK Open Banking you may have no contractual relationship with.
2) Standards: Multiple API projects, whether introducing new systems or legacy modernization, introduces a new set of interfaces to the bank. Without a strategic and unified standardization approach, banks will continue to face legacy issues
and experience inconsistent results in the digital transformation journey. Future-proof set of banking standards, such as Banking Industry Architecture Network (BIAN), can help banks streamline operations during simultaneous API project implementation.
BIAN creates a common architectural framework for enabling banking interoperability. There are several reasons to look at utilizing this standard:
- IT simplification - BIAN standards enable disparate systems to interact more fully, thereby lowering the cost of ownership and reducing system connectivity complexity and overhead
- Flexibility & speed – allows banks to adapt within ever-changing environments, with plug and play modularity
- Leverage the platform economy – technology components as discrete services to integrate and consume as needed, facilitating simpler interactions and transactions between parties
3) Performance: The open banking revolution means banks are expected to provide ‘always-on’ highly performant APIs. To match customer expectations, banks need to ensure that all processes and systems operate in real-time, end to end, including
core banking applications which may need refactoring, away from batch-based processes.
4) Innovation and Monetization: Even if a bank’s primary objective in providing external APIs is compliance, it is possible to leverage these investments to obtain a commercial return through new revenue opportunities.
By providing API access to new services, banks can explore new ways to provide information to customers – like account balances and transactions detail for corporates, or use APIs to help collaborate with third parties building joint propositions or enabling
customer access to new functionality and services. This, in turn, will open doors to innovative business models, and increase chances of monetization.
However, to enable such API-driven services, banks will need to make significant changes to their information infrastructures. These changes will also open the door to non-traditional revenue-generating opportunities in the form of API monetization. For
many banks, these APIs will become a set of products, addressing a rapidly evolving financial services ecosystem, furthermore, by monetizing APIs in a strategic way, banks can protect their market share and disarm the threat of nimble FinTechs.
API monetization can be in the form of simple APIs bringing new or extended access to bank services such as transactional data. However, banks are increasingly collaborating with fintechs to build new joint propositions, improve internal processes, or simply
partner to bring services that banks don’t want to offer independently. Fintech collaboration works best when done on purpose. For instance, through an open innovation platform, that can facilitate innovation for banks beyond standard sandbox, by using simulated
data and bank processes - without impacting live systems providing controlled access to curated fintechs, to help solve internal bank challenges or create new propositions to provide directly to customers,
The data-driven services that API monetization will leverage, demand best-practice systems and processes for information security and fraud detection, as well as for compliance and consent management. Crucially, banks will need a scalable, high-performance
billing engine that can implement a wide range of differentiated pricing strategies. For banks with mature capabilities in these areas, APIs can become the foundation for strategic commercial relationships with fintechs.
5) Modernization – As well as assisting in legacy system modernization enabling microservices re-engineering of core systems, APIs are either replacing or being used as an alternative to existing data transfer methods. SWIFT, for example,
are producing services that move away from using their traditional messaging standards as part of their API initiative. For example, SWIFT’s gpi propositions are improving cross-border b2b payments by enabling end-to-end tracking, same-day payments, the ability
to stop and recall payments mid-flight, and integration with case management and other E&I systems. The tracking platform behind gpi enables bank to utilize APIs to interact with the service, reducing the need to send and receive unstructured messages between
parties via the SWIFT network, enabling automation of existing bank processes, and the ability to allow corporates to track, query, and provide missing information about blocked payments as a self-service function, thereby reducing the burden on bank customer
Even if your organization has taken a tactical approach to API adoption for regulatory purposes, having a holistic approach to API adoption will help your organization to: address security impacts correctly, consider recognized standards, recognize the need
to produce performant APIs, and embrace their role in modernization of systems. This, in turn, will help to foster internal and external innovation and provide an opportunity to reduce costs and monetize.