Digital Banking: thriving banks tend to choose co-development instead of ready-made software

Like other businesses, banks tend to go digital, moving from mostly brick-and-mortar presence at the financial market and vigorously competing for leadership in e-channels.  

At this point, banks have 2 ways to go: to invent and implement new digital solutions in order to keep up with (or even beat) competitors or to stay in the niche and admit their defeat in the digital sphere. This article is going to be of interest for those, who prefer the first option.

When the strategy is clear, it’s time to analyze possible cooperation models with a software development company (the Vendor):

1. The development and updates are carried out solely by the Vendor (on a turnkey basis).

2. The Bank accumulates expertise by itself and creates a technical team without any third-party assistance.

3. Hybrid model: the Vendor implements the solution, moves to the co-development and gradually transfers its technical expertise to the Bank for its independent work later on.

Which model to choose?

In terms of efforts, flexibility, price and time expenditures, the hybrid cooperation model is the winner (in most cases). Banks get enough autonomy being securely covered by experienced vendors.

The Vendor develops a digital banking solution and transfers the source code along with a great chunk of technical expertise to the Bank. In addition, the Vendor is committed in improving the processes within the e-channels to help the Bank increase profitability. For example, it can help in selecting and training bank IT department employees, who will then take over the work on the project.

All that is referred to as a Digital Banking Handover, which is an important part of implementing large-scale projects in banking software development.

Therefore, a step-by-step development project handover and a smooth transition to the subsequent co-development of the Vendor and the Bank should be planned out well in advance.

The digital banking handover is an indispensable follow-up step. However, it is important to treat it like an independent project (usually implemented under a single contract).

Getting prepared for co-development

At Qulix Systems, we advise banks to divide up the preparations for a handover into 3 key steps:

Step 1. Revision of the existing systems. It is important to embrace the need for transformation. At this stage, banks set goals, formulate tasks, receive approvals and allocate funds.

Step 2. Implementation of basic functionality with its subsequent expansion. The Bank chooses a Vendor, signs contracts and gets the initial project version. The functionality is gradually increasing due to the cooperation of the parties.

Step 3. Integration of third-party services. At this stage, banks start integrating external services, for example, open-API implementation. It helps to expand bank’s capabilities by attracting third-party fintech start-ups to better meet customers’ needs.

We recommend starting the digital banking handover project right after the initial step. The project should have a clear plan, a specified budget, defined responsibility and calculated terms.

It is necessary to:

1. Form a team of the technical specialists at the Bank in order to accumulate expertise. The Vendor can assist in specifying channels and areas to commence.

2. Allocate budgets for the development itself and for the co-development part.

3. Create a flawlessly working production system for further independent development and improvement.

As a result of the preparations, the Bank:

• Gets the basic functionality of its digital solution deployed.

• Creates detailed documentation for the platform.

• Accumulates certain knowledge on systems, data, business logic, and etc.

• Starts cooperating with the Vendor

• Formulates the contract clauses for future project support.

Responsibility

At each stage of the project implementation, only one of the parties should be responsible for the overall project delivery.

There are 2 parties involved:

• the Expert - who is responsible for the delivery, QA, module integration, coordinated operation of the system, and etc.

• the Developer - who provides resources and performs pre-arranged tasks of the Expert.

Initially, the role of the Expert is performed by the Vendor, and the Developer’s role is performed by IT Bank employees.

Afterwards, they change roles: the Bank becomes the Expert (owning the backlog of tasks), and Vendor takes the role of the Developer.

Such a way of sharing responsibility shows its viability and productiveness in a lot of large banking projects we deal with.

Handover stages

1. Primary training

It can be started immediately following up the project launch (~ 3 months). Usually training takes place in the “sandbox”. The Bank IT team is refining skills on basic tasks under the Vendor’s supervision. It helps to get used to independent performance later on.

2. The role of the Developer

When these 3, 5 or 10 employees from the Bank's IT-team are done with training and informed about the digital platform quite well, their tasks gradually become more sophisticated.

Their comprehension of the digital system, its architecture, domain and server banking model, as well as the principles of platform expansion and implementation - are a must at this stage.

3. The role of the Expert

When the Bank specialists get enough experience in changing, extending and supporting the platform, the processes get adjusted. It’s up to the Bank to decide, whether to carry out project support by itself from now on or to continue consulting the Vendor on certain issues.

Key aspects

1)   Collaborative development and delivery processes

At the infrastructure level, it is important to establish processes for replicating the GIT repository, cross-working with Jira, storing documentation, sharing files, and modifications.

What are the focal points:

• cooperative document modifications by the parties

• the process of verification and assembling of the product version

• QA tasks and the plan of their fulfillment.

2)   Quality control

The Expert has to perform a code review in the central code repository before each commit. First, it’s a Vendor’s task, but then it is assigned to the Bank. At the same time, comprehensive code review is possible only if the Expert has a clear idea of the product function (for example, about the documents analyzed). Keep in mind that such code reviews require additional time.

3)   Project Management

There should be only one Project Leader: a Project Manager from the Vendor or from the Bank. It is crucial to have a clearly outlined procedure for defining and managing tasks for developers, monitoring results, timely delivery, and etc.

4)   Responsibility for the system integrity

Any change in the system must be seamless and agreed by both parties. It includes analyzing requirements for the developer, creating and updating specifications, possible changes in the UI/UX. It is helpful to find a responsible party to analyze the overall architecture integrity, the necessary architectural changes and dependencies. It is worth considering the way reusable components can be implemented in the development of new functions. And most importantly, how these components will be provided to the developer.

5)   System support

It is vital to define and agree on the rules of the platform update and the way it affects the core system changes. In addition, it is important to determine and agree on the SLA impact and on the research and problem elimination (only the Expert should be responsible for analyzing and classifying defects.) To be sure, it wouldn’t hurt to determine who corrects the defects caused by Developer’s actions.

Co-development and Handover Plan

Inception phase: defining project participants and the process framework, forming a team at the Bank

Training phase: training Bank IT staff on working with the platform, setting learning objectives, and creating the infrastructure. In addition, the training phase includes the joint plan implementation, surveys, monitoring, consulting, and etc.

How much does the Digital Banking Handover cost?

Both parties should clearly understand that the budget and resources should be allocated in advance to complete the project successfully.

What to consider:

1) Costs for code review and consulting services (recurring)

2) Costs associated with the process establishment in the project handover (discussion of documents, regulations, rules, repository organization, and etc.)

3) Possible costs of risks associated with additional responsibility in the project, for example, when new IT employees are recruited by the Bank (recurrent).

Given all of the tasks and actions mentioned above, the cost of the digital banking handover is not going to be low, but can be reasonable and quite predictable.

It is a valuable investment in the opportunity to quickly create new services and products, easily adapt internal processes under the changing conditions, scale and implement new ambitious projects. As you can see, it’s worth a lot.

About the author:

Denis Novikov, Deputy Director of Business Development at Qulix Systems.

Denis is:

· A strategy development consultant for Digital Banking products;

· An expert in the field of software development and implementation for financial organizations;

· A representative of the StandFore FS intellectual banking platform.