Today’s banks and fintechs must be able to adapt their services quickly in response to competition, market changes and new regulations. Sometimes in a matter of days, if not hours.
A bank may need to adjust interest rates on its loan products to account for the higher costs of borrowing money, offer a mortgage payment holiday, or quickly change a term on a credit card.
With market conditions and customer needs changing rapidly, bank decision makers face a difficult question: how do they deliver high-quality products at pace while making them cost and time-efficient?
Closed-box systems: limiting product innovation
Many of today’s banks run on closed-box, legacy systems. A closed-box system is one where the underlying product code is locked away by the vendor – inhibiting the bank from being able to define product features. Some systems offer a limited set of configuration parameters for the product, but largely, they remain inflexible and unable to adapt to changing market conditions.
These systems were suitable for a bygone time of telephone and branch banking when customers expected only a basic suite of products, such as current accounts, savings accounts and credit cards. The closed-box system simply does not allow the bank to build innovative, personalised products as it is limited to a set of available parameters.
A closed-box system is not suited to the needs of modern-day customers. It restricts product innovation in several ways, including:
- Manual changes: Banks running legacy, closed-box systems struggle to make automated changes to products or accounts en masse. To change one term across many accounts, such as changing interest rates or fees, the bank would rely on the vendor to make those changes manually. This is expensive and time-consuming. Banks, on occasion, have been forced to shut down entire product lines because they have failed to adjust terms in accordance with new regulation.
- Vendor dependency: Legacy software vendors typically maintain the software’s entire codebase and provide switches to turn a limited set of features on or off. The vendor is responsible for core and product systems (credit card, CASA, loans, and so on). The underlying product code is unavailable to the bank, so it must rely on the vendor to change existing products or configure new ones.
- Service reliability: With a legacy system, many of its services are tightly coupled and depend on one another. This means that a small change in one area of the system, be they scheduled or reactive, could impact a large part – or even all of – the service.
Smart contracts: a blank canvas allowing banks to design any product
Vault Core is different – it’s an open-box system. We allow banks to build any financial product through a Universal Product Engine. With the Universal Product Engine, banks can access a library of pre-built financial products, end-to-end documentation and tooling, and our product development framework: smart contracts.
Smart contracts allow banks to write their own logic and build products from scratch using a simple interface. The bank can develop these products quickly, make changes en masse without dependency on Thought Machine, and do so without any risk of touching critical platform code. Smart contracts enable product innovation for several reasons, including:
- Control: Vault Core’s configuration layer is decoupled from the platform layer, allowing banks to make changes to products without forking the code of the common platform. With smart contracts, banks can define the product logic to update, replicate or modify products without dependency on Thought Machine.
- Product agnostic: Vault Core’s product engine is universal by definition. It does not consider, nor is it affected in any way by the products it runs. This intentional design choice ensures our clients can build whatever product they want in whichever configuration.
- Product Library: All our clients can access a global Product Library containing pre-written smart contracts, ranging from current, deposit and credit accounts to multi-currency wallets and Shariah-compliant products. They can customise these before launch or write innovative products from scratch using Python code.
- Feature-level configurability: Unlike a closed-box system, banks can also define the parameters of each smart contract at a feature level, which makes product customisation far quicker than before. Currencies, base rates, interest rates, payment fees, and loan terms are all parameters the bank can easily define and change in the smart contract.
- Best-in-class tooling: Banks can access end-to-end documentation and the smart contract software development kit (SDK). This tooling enables banks to simulate the behaviour of smart contracts to ensure all products are well-tested, well-designed and highly performant before launch.
So, what does this mean in practice?
Take for instance our client, Trust Bank.
Trust utilised pre-built smart contracts to accelerate product delivery. The bank configured and developed pre-built smart contracts to launch a comprehensive initial product set that included credit card, savings account and family personal accident insurance. Following its launch, Trust adjsut product parameters and built new features in days based on customer feedback.
Banks using closed-box systems depend on the vendor to make iterations to predefined products. It takes many months, even years, to develop products in legacy systems. Whereas, Trust was able to innovate at a much faster pace without reliance on Thought Machine.
On the other hand, a bank might attempt to build an innovative financial product from scratch. For example, our client, C6 Bank, wanted to roll out a carbon offset account which monitored transactions of a customer’s credit, debit and check accounts using a calculation engine. The engine would monitor and measure transactions in relation to the consumption of CO2 or an equivalent measure.
This was all made possible with smart contracts – allowing C6 Bank to build the product from scratch using a subset of Python code. C6 defined the product logic, and partnered with a CO2 engine to launch the innovative product.
With a closed-box system, the bank would have needed to ask the vendor to build a new product, which would be expensive and time-consuming. This product would be siloed from credit, debit and other accounts, resulting in a poorer overall customer experience. The bank would not be able to iterate the product with innovative enhancements without depending on the vendor.
Leaving the world of legacy technology behind
Closed-box systems are prevalent in banking technology. They offer low or no code interfaces for banks to make marginal product adjustments while tightly coupling product configuration to core operations. This opacity and inflexibility won’t work in a world where banking customers are demanding and expecting more each day.
With open-box modern technology, banking will change for the better. Banks will no longer need to concern themselves about how they build features – they will simply build.
