Navigating the Complex Landscape of Vendor Control in Banking Platforms

January 8, 2024
Blog

In some countries, it’s not uncommon to find vendors owned by other banks. For example, an application initially created by a subsidiary of a bank for the use by this bank may also be offered to other banking participants on the market. This ownership structure can lead to situations where these vendors may intentionally delay, deploy old versions or restrict access to certain products or services to the customers of competing banks. This practice results in an unfair competitive advantage for the final owner of such vendor, often at the expense of their other banking customers choices and market fairness.

Such bank-owned IT companies have no vision beyond their internal group’s image . They prioritize main shareholder demands over product-like development. Their opportunistic sales tactics rarely achieve sustainable customer satisfaction for customers outside of their group, leading to short-lived success and eventual decline.

Contrast with Practices in Developed Countries

Unlike in emerging markets, developed countries often have stringent regulatory bodies, like competition commissions, that oversee and regulate such practices. These institutions ensure that the industry remains competitive and that no single player has undue control over the market.

Risks and Implications of Bank-Owned Vendors

1. Access to Competitor Information: Even in test environments, bank-owned vendors may have access to other banks’ data. This information could range from product usage metrics to specific customer data, posing a significant risk to competition and customer privacy.

2. Exploitation of Customer Requests: When a customer bank makes specific feature requests to a vendor owned by another bank, there’s a risk that this information could be used to the owning bank’s competitive advantage.

3. Technological Control: In essence, a vendor owned by a bank can exert significant control over the technology and operational capabilities of its other customer banks.

4. Dependency and Financial Burden: To counteract these risks, other customer banks often consider acquiring source codes, which leads to unnecessary financial burdens for them and does not necessarily eliminate dependency, as the need for updates and maintenance from the vendor persists.

5. Demand Prioritization: The focus tends to be predominantly on enhancing new features to meet the ambitious demands of the main shareholder, rather than addressing the essential needs of other customer banks.

Considering Fimple is a system independent from bank ownership, we avoid the above described risks.

The Role of Open Banking and BaaS

The concept of open banking, initially introduced in the UK through the CMA9 regulation, aimed to break the hegemony of large banks by fostering greater competition. While the idea promotes increased competition, the practice of banks owning vendors seems counterintuitive to the principles of a free and competitive market.

The customer journey is rapidly shifting from a product-centric focus (what banks historically had) to a contextual approach that focuses on solutions at the point of need. These journeys are being supported by new providers offering solutions like embedded finance and Banking-as-a-Service (BaaS). Fimple, inherently compatible with BaaS architecture, enables rapid service banking and creation of embedded finance use. However, we also experience the difficulties banks with legacy systems face in implementing BaaS and enduring years of endless projects, although to a lesser extent. Fundamentally, BaaS aims to eliminate vendor locking problems in product development processes, aligning with the philosophy of CMA9. Core banking systems that are not BaaS enabled stand little chance of survival.

The Need for Regulatory Intervention

For a healthy financial ecosystem, it is imperative that competition authorities in various countries intervene in situations where bank-owned vendors might distort the market. These interventions are crucial to maintain the integrity of the financial sector and to protect interests of other banking consumers and smaller market players. Core banking vendors, such as Bank-owned IT companies, compete with core banking provider firms, thereby negatively affecting the competitive technology sector, and controlling the competitive power of small players due to their limited and restricted product offerings.

Yet, API-based banking systems like Fimple break this hegemony, allowing many small financial technology companies to develop products in a competitive environment and enabling financial players to access a variety of different products within Fimple’s marketplace.

Banking as a Public Entity

Banks, usually accredited institutions, are protected and regulated by law. Operating with a public mandate due to their ability to leverage deposited funds, they bear a significant responsibility. This public aspect strongly suggests that the practices of bank-owned IT companies, including their product-like offerings, pricing algorithms, fairness, and technology management, should be under rigorous scrutiny. Such oversight ensures transparency and compliance with market norms. If different customer banks are subjected to varied pricing, it could disrupt the free market and impede innovation. Therefore, regulatory policies should promote long-term planning and strategic product development in the bank-tech sector, aiming to eliminate monopolistic tendencies and deviations.”

Conclusion

In conclusion, the control of vendors by banks poses significant risks to market dynamics, customer data security, and the principles of fair competition. To foster a healthy, competitive, and secure financial market, it is essential that regulatory bodies closely monitor and regulate these relationships, ensuring that the market remains open and fair for all participants. The case of Fimple, a banking platform independent of any banking ownership, highlights the need for vigilance and regulatory oversight in this crucial aspect of the modern banking.