Low code software development will hasten some builds but hamstring others. Before incorporating these tools into your go-to-market strategy, take an honest look at your team and its capabilities.
The right team can use low code software development to involve a broader range of professionals in the design and build process. But for others, it creates logistical nightmares. So what does “low code” mean? And what are the obvious use cases for it in the financial services sector?
What Is Low Code?
Low code refers to applications that allow you to build custom software without coding from scratch. Many take a visual approach to software development.
Their primary purpose is intended to break down the barrier between the business and IT, promote collaboration and give the line of business greater freedom to develop solutions to meet their needs. Practically speaking, these types of solutions are often layered on top of legacy systems to enable greater collaboration and reactivity while minimizing expenses that can come with heavy-duty system updates.
Leveraging low code development across the team can significantly improve go-to-market time and reduce IT and training costs.
How Low Does it Go?
Low code is distinct from “no code.” IT resources are still required at deployment and occasionally thereafter. However, the size of the team and the amount of time required to make changes is dramatically reduced.
Just because low code development can simplify the process, it doesn’t mean its products will be basic. Low code-built systems can be as sophisticated as any enterprise-level solution.
How can it be applied within financial institutions?
There are many relevant use cases for this type of approach to solutioning; however, it is especially valuable:
- in domains that require agility to react and iterate,
- where existing core technology is costly and time consuming to update,
- when you want to avoid a costly and time-consuming RFQ,
- when you’re facing a pressing business problem that needs resolving quickly and
- when layering on technology to your existing architecture makes sense from a tactical perspective.
I’ve outlined additional real market examples below.
Product Development
Product teams are frequently hamstrung by a lack of resources due to cost constraints and an overall shortage of software developers in the market. As a result, time-to-market is frequently nine months or more, which makes it impossible to react to market changes rapidly. This, in turn, makes it virtually impossible to then iterate to achieve product-market fit. Many initiatives are consequently shelved before they even really get started. Significantly shortening your go-to-market time will enable your business to boost revenue.
One View of Customer Information
Banks frequently have separate systems and repositories for KYC, fraud, transactional data, lending and credit information, expected activity, etc. Occasionally some of the systems are connected and speak to one another, but frequently this isn’t the case. When analysts are reviewing payments or transaction monitoring alerts, they have to switch between multiple different systems and often end up duplicating work. It makes investigations more time consuming and cumbersome than they should be.
Low code applications are being leveraged to aggregate this information into one central customer risk repository, thus providing a single source of truth about the customer at any given point.
Financial Crime Prevention
Criminals are wily and creative. They adapt to gaps in controls and oversight almost instantly. Existing compliance solutions installed in banks are typically legacy systems, with cumbersome rules and algorithms that require ongoing IT support to maintain.
Updates frequently require large IT projects and have to be budgeted for and scheduled far in advance. None of this supports reacting to criminals (or changes in typologies) in real time. The costs of slow reactivity are real and include recruitment and training costs of additional FTE to deal with spikes in alerts, clearing alert backlogs and potentially missed criminal activity – all of which can have a detrimental impact to the bottom line, as well as your personal and organizational reputation.
Potential Versus Reality
All of this remains the potential of low code use, but it doesn’t always work that way in reality. The use of low code applications is a divisive subject because it speaks to the complexity of banks, their competing priorities and politics and the difficulty in enacting change as a result.
Almost all of those I spoke with pointed to the challenges in committing to and sustaining digital transformation. They all viewed low code solutions as being beneficial for the aforementioned reasons, but they were also worried that adopting these types of solutions could delay or impact digital transformation even further.
One executive at a tier one bank immediately cited “shadow IT” as a concern, and everyone I spoke to highlighted this in one way or another. Technical debt is rightly on everyone’s mind. After years of banks trying to improve legacy infrastructure, they’re left with a patchwork of solutions that have limited interoperability, draw from/to different data feeds and take massive amounts of resources to maintain.
The concern also highlights the internal struggle within banks. IT almost always wants to control the entire tech stack and its corresponding budget. As a result, even simple change requests to technology typically take weeks or even months. Maybe a decade ago, this was acceptable. However, the pace of change is such that banks simply need to react more quickly. This is needed not only defensively (against fraud and financial crime), but also offensively; banks are fighting to maintain or grow market share in a field that is increasingly crowded with more agile fintech and payment firms.
As Wolfgang Mair of the Liechtensteinische Landesbank summarized, “Banking core systems and critical processes need to be assessed and (re-)designed front to back with today’s digital challenges in mind. While low code systems can be a valuable tool to support this journey, they should not be considered a replacement for building native digital transformation capability.”
Replacing legacy technology is often what’s right for the bank. However, it requires complex collaboration and decision-making, significant IT resources and time. In short, it’s a very expensive proposition.
Wrapping Up
In summary, each bank has competing demands for its resources, and pragmatism typically wins out, as it should. Low code technology can achieve dramatic efficiencies for your organization. It can enable you to avoid time-consuming replacement RFQs and simply optimize your current technology, processes and workflows.
Deciding whether or not low code technology is right for your bank is really dependent on the current needs of your business, the resources you have available, how urgent your problem is and what your digital transformation strategy happens to be.
Ultimately, everyone is working very hard to digitize banks, improve their data quality and interoperability and update and replace legacy technology. It’s not an easy task and takes years of staying focused on the goal. Unfortunately, banks are beholden to their shareholders and are judged on a quarterly and annual basis, which makes achieving long-term goals more difficult – but not impossible. Give low code technologies a serious look and do your own research – but don’t fall victim to analysis paralysis. The material benefits of low code technology solutions are market ready today.
