Digital banking: 5 things you need to know before starting a project

Pitfalls and issues will inevitably arise while working on any project: from building a house to creating a digital banking system. In this article I provide a brief overview of digital banking projects in a technological context to help you learn more about the implementation of digital banks and types of obstacles you may encounter.

Sure, 5 is a very optimistic number of possible risks. However, we picked the most significant ones, let’s focus on them.

Risk #1 Digital Banking Design

This is a real pain – both for the Vendor and the Bank. Tired of template-based solutions, Customers wish for a good and unique design for a wow-effect.

The trickiest thing here is that ‘good’ becomes a matter of taste.

Based on our experience, Customers tend to choose between using the Vendor’s own UI studio and hiring a third-party studio.

•         Working with third-party UI designers

Although this option may look very intriguing for Customers, it is ineffective from the developer’s point of view. As a software company, we treat Customer’s decisions with great respect. We just want to be positive that all parties connect the dots before the start and consider possible difficulties at the stage of planning. So, the greatest pitfall is the cost.

The project estimated price is likely to be even higher than the price of the Vendor’s development and design on its own.

How so?

Indeed, third-party designers can create an attractive visual solution, which is easily approved by the Bank top managers. However, such a UI solution can be extremely difficult to apply to the real projects in the field of Banking and FinTech because of specific engineering and system-building requirements.

Why it can happen?

1) Quite often the design is not systematic enough. The structure can be missing graphical components that are used in building the platform. Moreover, the set of these components may vary depending on the project. Digital banking is a multi-tier structure consisting of modules and blocks, therefore, the UI principles should apply to the entire system. Designers need to clearly understand the importance of UI-mapping when building a system, as it helps ensure the consistent structure of graphic blocks and all sorts of CTA buttons.

2) The UI studio may not have a clear idea of adaptive design and the way of accurate information display on different mobile devices.

3) Using third-party services for UI design requires extra coordination efforts between the teams. In addition, it can seriously affect the software development costs. Designers do their job: they go for fresh visual solutions and hardly think of the development process cost. That’s what the Bank should consider.

Therefore, it’s important to discuss the rules before the project starts. In the case of delegating UI design to a creative studio, make sure you manage coordination, approval process and communication between the teams. It is an absolute must to avoid a situation when the Vendor receives already approved the visual design with no clear idea on how to implement it.

•         Decision-making process

Who is approving the final UI design in a Bank? The decision-making practices depend on the country, size of the organization and its corporate management system.

Just to make sure: it’s a good idea to back up the top managers’ choice with the opinion of niche specialists. Outstanding UI is more than a picture on the screen, so it can’t be selected by subjective likes or dislikes.

•         Widgets

Widgets have always been something mesmerizing for Banks and FinTech. On the one hand, this is nothing bad about that. On the other hand – be cautious. In our experience, extra-flexible interface and almost infinite customization options don’t always work out. It guarantees additional load on the bank call center, while it cannot guarantee improved convenience. However, since widgets are still trendy, since you may like them, feel free to use them. Just watch out.

Risk #2: Digital Banking Platform

In this part, we will discuss how Banks choose Vendors and Digital Banking platforms to build their projects. I was honored to hold a few hundred meetings with various banks. At such meetings I focus on our StandFore FS front-end platform, its excellent scalability, maintainability, easy support and so on, talking about opportunities for further product extensions. And the typical question from the Bank sounds like: “So, can it make a bank statement?”

Okay, there is a grain of truth in every joke.

We just want to say that the choice of platform should be based on crucial parameters, and not because you like a particular feature. 

The rest can be added and refined in the process, so at this stage, specific features should not influence your decision. Skilled developers can implement any idea, add any function and even color the button red or green. Make sure you dig deeper than flipping through beautiful pictures.

For example, ask the Vendor about how long the changes to the platform will take. Some solutions can require 3 months of development to get a new field added in a specific place. The time-to-market is now a critical parameter, so a well-thought-out decision is a must.

Risk #3: Agile Transformation

The topic is so thrilling that we must point out that we find Agile principles awesome. We really do. But let's be honest: the combination of Banks and Agile methodology can hardly be smooth and seamless. Let’s analyze the possible pain points.

Budget

As a Vendor, we usually cooperate with banks at a fixed cost. Before all this hype around Agile, the fix-price in the contract came along with the fixed-scope of work. The use of Agile development methodology in the format expected by Banks may lead to misunderstandings with the Vendor.

Another option for open-ended projects is to hire a dedicated team to work on the project (T&M model).

This will help avoid potential problems with timing and budget planning.

Aligning Agile with the bank approach to management

In banks, the authoritarian or administrative management styles are far more common than in other organizations. However, Agile is all about flexibility. We don’t have a ready-made solution to offer, we have just identified this problem and we are talking about it.

There is a project team, the team boss, and the boss of this team boss. Bank teams cannot work independently as developer teams. It’s time for Agile to transform, but it’s a bit hard to say how.

Agile drawbacks

The initiative of moving to Agile can come from the top management of the Bank. Being flexible is a trend, so let’s schedule meetings, participate in discussions and use boards for visualization. And now imagine the meeting of the Bank’s team with the Vendor’s team, a total of about 60 people. There is an independent SCRUM master with impressive experience in how to start and how to manage discussions, but with a blurred idea of the project.

The participants are divided into groups and discuss the pros, cons, pains and growth opportunities. The whole thing may last for a few days. It does bring some benefits, but our technical experts believe that time can be spent with a better output.

Non-Agile elements

In Banks, there is a number of non-agile elements (Lawyers, Board of Directors, etc.)

According to Qulix expertise, Agile can be applied to banking and financial product development. Until some minor legal issue arises and suddenly blocks the project workflow. And the time is running out. I mean that such things require attention and timely support.

Risk #4: Bank IT Department

In order to properly analyze the project requirements and features, we need quite a lot of expertise from the Bank. We need people, who know how the bank system is organized, where the data is stored and how to deal with requirements.

From Qulix experience, banks rarely hire enough Information Technology specialists (there are cases when there is just one for the whole Bank). The stage of cooperation becomes the development process bottleneck. We engage 5 analysts for the project, but there are hardly enough people at the Bank, who are able to work at the same speed. When working with requirements, Vendors need careful back-up analysis and refinement. When the cooperation is slow, the processes are blocked.

Risk #5: Customization for the Sake of Customization

Like any other aspect, this one also has the flip of the coin. We understand the Bank’s desire to have a super flexible system and allow users to customize each button and the button’s title. However, when the degree of customization is skyrocketing, it becomes irrational and brings more chaos than good. There is a sufficient level of settings, which just doesn't need a boost. By increasing this level, you are not likely to contribute something valuable to the project, but - on the contrary - are very likely to increase the development cost. In addition, the more settings there are - the higher the chance to set something up the wrong way.

Bonus Risk: Several Vendors Working on the Same Project

There is a tricky tendency to avoid keeping eggs in one basket when building a Digital Banking project.

Say, the Bank goes Digital: the back-end development is provided by the Company A, iOS is developed by the Company B, web – by the Company C and there is also an authorization module handed by the Company D.

The release date is scheduled on the Bank President’s birthday.

I hope you got the idea.

Some things work better together. As for the independent systems – their development can be safely and effectively carried out by different vendors. Digital Banking is not the case, because all changes go through analytics, architecture, and through a single-style UI / UX design. When there are a lot of vendors out there, the cross-communication becomes a real mess.

Final Takeaways

All these difficulties can no way hold us from building a high-quality Digital Banking Projects according to Customer’s vision. However, if you consider them in advance, the development will be a lot faster and cheaper.