Building Financial Marketplaces: Approaches and Mistakes

Unfortunately, usual referral systems and showcases of non-financial service providers are sometimes passed off as marketplaces and ecosystems. What is the difference between approaches to creating marketplaces in retail and corporate segments? What are the main mistakes banks make when trying to build an ecosystem for SME clients? Why is the separation and independent development of the front-end and back-end of the remote banking service environment so important? What should be done first to increase commission income from non-financial services?

The question of how to create an ecosystem is often discussed on numerous forums and at other events in the banking sector. Marketplaces are a popular trend. Banks are eager to get into non-financial retail, while traditional retail and telecommunication companies are trying to push back against the banks by expanding the range of their traditional services to include financial ones.

From the outside, all this looks like a search for a silver bullet in order to resell an existing client base, but only a few succeed in this. And here is why.

Neither the market nor the solution providers for the financial sector have yet agreed on the terminology and conceptual framework. Banks often launch such projects without understanding the infrastructure specifics and without having the right team and internal processes. They perceive these projects as the implementation of some software.

In front of the management board, bank business units speak in support of projects for creating "marketplaces" that are aimed at increasing commission income. However, these marketplaces are, in fact, anything but the desired silver bullet: from basic referral systems to e-commerce websites affiliated with the bank.

Approaches to building remote banking services for the retail and corporate segments are almost identical due to user-oriented mechanics, but ecosystem approaches and tasks for creating marketplaces for the corporate and retail segments have significant differences.

Any ecosystem is a set of external distribution environments that are focused on the end client and are seamlessly perceived by them during the customer journey. 

Main ecosystem features:

• a single "genetic" interface and methods to create it, regardless of the production environment that the customer interacts with;

• common identification methods;

• seamless data transfer;

• a seamless cycle of movement between front-end environments: from receiving traffic to providing single window services.

The key similarity of the approaches to building marketplaces in the retail and corporate segments is the ability to package the sale of third-party services under the digital facade of the bank.

This is where the similarities end.

The marketplace is not specific "software"; first of all, it is a distribution ideology. 

What is relevant to a retail client besides the main banking service? The answer is the specific product offer which requires a financial product.

What is important to a corporate client in addition to cash management services? Clients want to integrate the information environment associated with cash management services into their own business processes and information systems, as well as to obtain additional products that are smoothly integrated into the cash management service structure or the business process.

The difference in these approaches creates a request for different front-end production environments, different internal teams in the bank and roles within them, different product matrices, and different ways to distribute someone else's product offer.

What is the future of banking ecosystems for the retail client?

Retail, based on the request for a specific product offer, looks towards either traditional e-commerce platforms with an integrated credit process, with online scoring, and online approval where possible, or towards the most financially vast markets: real estate, the automotive industry, the travel industry and related insurance products.

We will probably soon see similar solutions in the auto business and other financially large consumer verticals.

This trend is largely correct: the client does not need to take out a loan, they need to buy an apartment or a car, and an attempt to "take over" the product selection/offer zone seems quite logical.

Such industry projects will be successful if the bank already has vast client traffic and manages to aggregate the main product offers from end suppliers of the selected industry vertical in its front-end environments.

The result of the above-mentioned factors will be presented as a financial and product classified platform, which can complete the client’s "search-choice-purchase" cycle in a single banking window.

However, banks will face tough competition from classic classifieds and large e-commerce players in this sphere, and banks that do not have a client base with large internal potential should be no less advanced in the competition for digital attraction of industrial traffic. 

How many banks are now able to do this as successfully as online stores or aggregators?

Classic classifieds are also unlikely to give away their hard-won audience without a fight.  Soon we will get more deeply integrated financial instruments created by these market leaders. It is possible that in this fight, we will also see banks striking deals to buy strong specialized classified platforms to "control" their audience. 

Ecosystems for SMEs: approaches and mistakes

SME services in banks are traditionally lagging behind retail, so the topic of marketplaces has become relevant for existing successful retail cases. 

When creating marketplaces for the corporate segment, certain instruments can help systemize the main types of mistakes. One of these instruments is custom scenarios for upselling financial and non-financial services, which differ from retail. Another is retail benchmarks that are incorrectly applied to SMEs.

• Misconception № 1: You can easily upsell to your client

Banks are so enthusiastic about selling their own third-party and non-financial services that they sometimes forget to properly provide their main service to SMEs - cash management services.

And the most common and core misconception - that they own the client and therefore can easily upsell them something - in the vast majority of cases leads to disappointing financial results when implementing showcases of non-financial services.

This scenario of "ownership" can work in retail: a client reaches out to us to get approval for a mortgage or car loan, we show them product offers on the market and receive a commission income for making them focus on a particular seller. But in SMEs, this method is hardly applicable.

A corporate client who uses cash management services won't implement a search pattern on the bank's site. Quite often, the need to buy something is not formed at all; however, as soon as it appears, the customer immediately gets into the digital mechanics of the vendor and buys directly.

The only way for a bank to seize the upsell initiative is to seamlessly fit the correct product offer into the banking service consumption structure - into the remote banking service itself.

The main and most important point while creating the ecosystem approach should be the creation of a selling front-end remote banking service environment which must be flexible and quickly adaptable to marketing and business tasks. This is achieved by a complete separation and independent development of the front-end and back-end of the remote banking service environment.

In some cases, this is even possible without changing the back-end vendor if it has the described API for front-end products. 

Today, many banks still do not realize that these are different classes of systems. They solve these problems by inertia, using traditional remote banking service vendors that are strangers to digital mechanics and are lost in years of accumulated technological legacy. In the coming years, the trend of product division of these classes of systems will only gain momentum.

• Misconception № 2: Marketplace is a synonym for a separate portal/showcase/affiliated e-commerce

In contrast to the retail segment, for corporate clients, the implementation of the marketplace ideology may not even have a front-end environment. The goal of obtaining commission income from the sale of non-financial services is more achievable with the creation of client-oriented remote banking services, which include an analysis of the consumption profile. There is no need to create a separate web portal as it is no longer useful.

However, in the software market, traditional e-commerce platform vendors are trying to talk banks into buying e-commerce platforms under the pretense of "ready-made portals" for corporate marketplaces. 

Consolidating the b2b audience on a proper digital marketplace of a bank and inculcating a search pattern of third-party service use is possible. However, in practice, it is difficult to achieve and requires huge financial and time resources. 

Such a marketplace requires a mandatory and core financial instrument from the organizing bank, which is smoothly integrated into the market business process of clients. For example, these can be "trust transaction” tools, where bank compliance can be used as a service (compliance as a service) and aimed at end customers in order to assess the reliability of b2b operations. On the other hand, these can be simplified corporate lending mechanisms in the "validated supplier - validated seller" chains. 

This is a very long-term strategy that can be undertaken by only a few players. In all other cases, e-commerce and showcase software vendors simply substitute concepts: similar showcases of non-financial service providers, which are just referral lead-gen models, are passed off as an ecosystem approach. 

Personalization of the offer at the right time and in the right place is particularly important for the sale of non-financial services for SMEs. Standalone web portal showcases that are not aimed at the consumption profile or client base specifics, and are not included in the cash management services process will simply disappear. 

The product matrix of non-financial services cannot be of the same type from bank to bank; it should be created for the main strong financial products of the bank and the profile of its client base. A special role of "product merchandiser/analyst" should be allocated for such tasks within the bank.

However, keep in mind that the distribution models and products components differ for new and existing clients:

• for new clients, the starting kit is important;

• for the existing ones, a deliberate upsale, a relevant offer based on the analysis of available data on the client's transactions is important - why should you offer cloud accounting to those who are already downloading tasks from 1C? 

We get a lot of information about the client from their transactional activity, and this knowledge should help us form the best offer in a convenient front-end production environment. 

Any non-financial service must be seamlessly integrated via API mechanics into the remote banking service itself.

Any serious e-commerce player will say that redirecting a client to someone else's interface to complete a transaction causes both a drop in conversion rate and in traffic. 

• Misconception № 3: A website is the territory of advertising and marketing, remote banking services are IT territory, and marketplaces are dealt with by businesses

This misconception applies equally to retail and SMEs. We often encounter the absence of a "genetic" interface when redirecting a client from one system to another. For instance, there are different suppliers for web products and remote banking services, different remote banking service suppliers for individuals and legal entities, separately developed mobile banking, etc.

There is already one more debate topic among technology visionaries, besides the variety of segmented client environments, which is whether the interface ecosystem will move to mobile first or mobile only. The functional division based on "website", "personal account", "Internet banking", "mobile banking", etc., is a path to nowhere. The entire public web of the bank is useless for current clients, even though it is a marketing zone for products, including new ones. 

The ideal solution to these problems is the creation of a single front-end codebase. It should be built on top of a specialized banking IT landscape, including both the back-end of the remote banking service and specialized content. A banking system should be an information product supplier even for websites.

The role of traditional CMS for websites should be limited exclusively to media content tasks and a set of digital mechanisms for conducting split tests. Given the interaction with a set of external bank interfaces, the ecosystem approach is bound to ensure the transfer of the client’s experience memory when the client moves from one system to another. A website and remote banking service compose one environment; remote banking service and a showcase of non-financial services also compose one environment. There is only a client's public state and a client’s authorized state. Thus, today’s most common approach to the functional division of front-end environments should evolve towards a division that depends on the state of the client who’s interacting with the bank.

Final recommendations

In order to increase commission income from non-financial services, you need to:

1. Create a convenient front-end remote banking service environment.

2. Package your low-automated services, which corporate clients experience when working with you, into digital services inside remote banking services.

3. Conduct API integration of selected third-party vendors and provide for information data exchange with remote banking services.

4. Systematically expand the product line by examining the demand.

5. Don’t try to find the out-of-the-box marketplace. What will work is only microservice architecture, flexible methodologies for implementing and managing business requirements, iterative development from a good front-end of the remote banking service environment to an ecosystem of front-end client environments.

Tinkoff app already meets the marketplace standards in many criteria. Several hundreds of experts from  took part in its creation to help them implement various IT solutions.