How does Vault Core compare to closed-box systems, and what does this mean for product development?


Kerry Harrison

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. 

<< Previous blog
Next blog >>
How does Vault Core compare to closed-box systems, and what does this mean for product development?
Read this blog
Introducing our Enablement Portal – a complete resource for support, knowledge and training on the Vault platform
Read this blog
The Integration Library: a growing collection of solutions with best-in-class technology vendors
Read this blog
Building a bank on top of kubernetes
Read this blog
From speech technology to banking
Read this blog
Strategic partnership with Lloyds Banking Group
Read this blog
Cloud computing will save banks billions. Here's how
Read this blog
A demand for COBOL expertise underlines the fragility of critical infrastructure
Read this blog
Why are cloud systems so much more reliable?
Read this blog
Life may have slowed down but innovation doesn’t!
Read this blog
Building a core banking system in a distributed environment
Read this blog
Strengthening our commitment to cloud native design
Read this blog
Cloud Native - what does it mean? An interview with CNCF's Cheryl Hung
Read this blog
Shaping the future of banking IT: We’ve joined the Banking Industry Architecture Network (BIAN)
Read this blog
Why microservices are the future of banking
Read this blog
GFT and Thought Machine forge strategic partnership to accelerate global banking transformation programmes
Read this blog
Q&A with Nick Wilde, MD of Thought Machine Asia-Pacific
Read this blog
How Thought Machine can unlock the cloud for banks with Red Hat OpenShift
Read this blog
Round table: Meeting the challenge of a digital future
Read this blog
How to go full cloud native with CockroachDB
Read this blog
Meet our chair Andy Maguire
Read this blog
Core banking transformed: accelerating migrations with cloud-native cores
Read this blog
Let business justify your investments into digital-native core banking systems
Read this blog
How Thought Machine exceeds global industry standards in compliance and security
Read this blog
Thought Machine redefining banking with Standard Chartered
Read this blog
Sign up to our newsletter
Thank you! You will now receive some incredible content in your inbox!
Oops! Something went wrong while submitting the form.
For information about how we use your data please read our privacy policy.