APN News

Banking the bits and the bytes

4 steps to a future-proof connectivity strategy for the finance sector

By Ivo Ivanov, CEO of DE-CIX International, the world’s leading Internet Exchange operator and interconnection provider

To be fit for the modern world, banks and other financial service providers need to reduce their costs, develop new business models, activate new revenue streams beyond the standard set of financial services, and meet the needs and expectations of increasingly tech-savvy customers. They need to achieve full digitalization. To achieve this, it is necessary for banks and financial service providers to take a different approach to managing their data – these bits and bytes are the basic commodity of the digital age. These institutions need and want to become the moderator of their customer’s entire financial life-cycle, across multiple sectors and value chains. This means that, as part of their journey towards transformation, they need to develop an interconnection strategy.

An interconnection strategy will provide a framework for considering the ways in which the bank wishes to control connectivity with its own digital resources, its partners, and its customers. It is worth breaking this process down into manageable steps in order to test, to gain experience, to understand the benefits of gaining control over the bank’s interconnection infrastructure, and to develop a long-term strategy. The following four-step process will help the institution to develop its interconnection experience and build its strategy.

1.Starting with the basics – how interconnection helps IT systems to work efficiently and effectively

Before even thinking about the outward-facing systems, the first essential step is to ensure that internal systems are functioning effectively. Connections to cloud resources and applications like Microsoft 365 and Microsoft Dynamics for CRM and ERP systems must be seamless, high-speed, secure, and redundant – so that whatever happens, you still have access to your data and workloads.

Traditionally, cloud resources are accessed over the public Internet, with all the risks that this entails. By making use of a cloud exchange through a secure and high-performance interconnection platform, on the other hand, it is possible to connect the bank’s network directly with the cloud provider’s network, bypassing the public Internet. This strategy has multiple benefits: not only is the connection – and thus the data travelling through it – protected against malicious attacks against its resources, but also the direct connection means that the data doesn’t have to travel so far. Because the further data needs to travel, the slower the response time will be. We call this delay ‘latency’, and the lower the latency, the faster the response, and the better the performance of applications. 

This is the case for accessing data in the cloud and using applications like video-conferencing systems, and becomes even more critical when it comes to processing transactions. Artificial intelligence applications, such as customer service bots or AI analytics and process automation, are further applications that need to be sourced from the cloud – and are extremely latency-sensitive. Therefore, direct interconnection to cloud resources and applications is the foundation of progressive digital transformation. Latency truly is the new currency when it comes to the future of banking.

2.  Security first: to control the financial customer journey, create private digital banking ecosystems

Clearly, banks need to ensure the security of their systems and their customer data. But customers are demanding easy-to-use digital systems and flexible access to banking products, and are more willing to shop around for a better deal – for example, through the growing range of FinTech companies on the market. Therefore, for banks to become truly digitalized, they need to nurture a secure and private interconnection ecosystem with their many partners, not to mention to their customers. By interconnecting with this ecosystem in a ‘closed user group’, banks bypass the public Internet for all of their customer care, data management, and access to clouds and resources.

Let’s look at a couple of examples: Firstly, a bank customer accesses their account on the Internet banking platform of the bank. Regardless of how secure the banking platform itself has been made, the customer is connecting to the bank via their Internet service provider (ISP) and then via the public Internet. If, on the other hand, the bank invited that customer’s ISP to interconnect directly via a ‘closed user group’ (CUG) , then this entire journey would be shielded from the risks of the open Internet, and would be protected further by the platform’s added security services. And that would be the case not only for this customer, but also for every other customer of this ISP.

The same goes for a webshop: A company runs a webshop with integrated payment services from the bank – but the connection of the webshop to the bank flows over the public Internet. Suppose the company’s own network is big enough. In that case, it could itself interconnect directly with the bank in such a private ecosystem – but SMEs remain dependent on connecting via their ISP, just like a private individual. So, the SME and the SME’s customers can be best protected by ensuring their respective ISPs have a direct interconnection with the bank via a ‘closed user group’.

Another extension of this concept is the development of multi-cloud set-ups using workloads and computing resources involving multiple cloud service providers, accessed and managed via a cloud router service, something which has become part of the offering on well-developed interconnection platforms. This can be managed easily and at extremely reduced latency, therefore improving the performance and usability of cloud-based resources.

3.  Meeting the regulatory and risk mitigation requirements for digital banking

With a framework for open banking having been introduced in the revised EU Payment Services Directive (PSD2), which came into effect in 2018, and with other regions following suit, like the US in 2021, banks are becoming obliged to make data available to third parties through their own application programming interface (API). This requirement forces banks to take strategic digital action and is just one of a range of new regulatory initiatives that aim at regulating digital banking. Managing the compliance of company policies and regulations (for example, in regard to data protection) becomes increasingly complex when connecting with a large number of different partners. Here, the traditional method used in the financial sector – connections via MPLS , data transport using intransparent IP transit , and bilateral agreements for each and every partner network – becomes a management nightmare. This can be simplified by creating a ‘closed user group’, in which compliance with the stipulated policies and regulations is made a mandatory prerequisite for participation in the ecosystem. In this way, the bank can set policies for all members of the ecosystem, and do so at the click of a button.

One particularly interesting regulatory initiative currently emerging in several jurisdictions is the requirement to mitigate the cloud concentration risk. Clearly, no bank should place all their eggs in one basket, and this goes also for digital infrastructure. It is necessary to have distributed infrastructure to avoid any single point of failure, whether we’re talking about the clouds, the data centers, or the networks you’re using. To meet the requirements of cloud concentration risk mitigation, having a multi-cloud strategy is essential – and easy to manage without the risk of vendor lock-in if you use a data center neutral cloud exchange that offers a wide variety of cloud providers and services. Even in regions where such risk mitigation is not yet mandatory, it soon will be – and, to be frank, business logic demands that a bank that wants to provide its customers with the best security possible should adopt this kind of concentration risk mitigation plan.

Exit mobile version