Pitfalls and issues will inevitably arise while working on any project: from building a house to creating a digital banking system. This article is backed up by vendor experience 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. 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. Any software development company will treat customer’s decisions with great respect. However, it’s a good idea to make sure 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.
If the UI is created by a third-party studio, be ready that it can be more timely and financially consuming. 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, an 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. At the presentation of a front-end platform, vendors highlight 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. The choice of platform should be based on crucial parameters, and not because you like a particular feature. No one should get surprised if we say that most of the existing platforms for digital banking offer the same basic functionality.
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 Agile principles are awesome. They really are. 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
Most vendors prefer cooperating 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.
It is necessary to ensure that either both the budget and the scope of work are fixed, or both these parameters are flexible.
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 development 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 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.)
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. Vendors need people, who know how the bank system is organized, where the data is stored and how to deal with requirements.
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 for 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 UX/UI design. When there are a lot of vendors out there, the cross-communication becomes a real mess.
Final Takeaways
All these difficulties should no way hold you from building a high-quality Digital Banking Projects according to your vision. However, if you consider them in advance, the development will be a lot faster and cheaper.
Written in collaboration with:
Alexander Arabey, Qulix Systems Co-Founder and Business Development Director.
Expert in software implementation for banks and financial organizations based on StandFore FS Digital Banking platform.
