Implementing changes to banking products can offer significant advantages when using a next-generation core banking system. While every bank and business model is unique, they often face common challenges in product improvements. We recommend Thought Machine’s Vault Core as the ideal next-generation core banking system, primarily due to its advanced ledger functionality and its ability to support customized banking products.
This article will examine the impact of product changes on bank architecture, product implementation, and the selection of core banking systems. We’ll also explore a valuable example of smart contracts—specifically, how they can test the effect of product changes on the broader system.
Vault Core allows us to test smart contracts in isolation from the rest of the system. Using a modern core banking system and a well-designed microservices architecture allows you to build different stages of testing environments, and to identify the impact of changes to different system components.
Being able to test and evaluate the validity of a proposed change and its effect on the rest of the system is as important as making the change itself. In order to properly test the effects of the change, we need to understand its scope.
A smart contract is a program that automates and enforces terms. In the simplest terms, they are contracts which are coded with certain rules that will determine their actions once specific conditions are met.
Smart contracts are useful in making processes more efficient and reliable.
Though their applications can vary, they provide the following benefits across the board:
Transparency: Each step within a smart contract is visible to all parties involved, ensuring that there are no hidden clauses or unexpected changes. This openness fosters trust among participants, as they can all see the exact terms and progress of the agreement.
Security: Once a smart contract is coded, it cannot be altered. The immutability of the contract guarantees that the rules remain consistent throughout the transaction, providing a high level of protection against fraud.
Efficiency: By cutting out third parties, smart contracts significantly reduce the time and costs traditionally associated with executing agreements.
Let’s dive into the nuances. How can we apply smart contracts in testing system changes in large projects like core banking.
Although testing strategies differ between banks, any testing strategy should address questions such as:
Given that banking systems are typically large and complex, it is crucial to implement a proper testing and monitoring strategy to identify direct and indirect dependencies that may be impacted by the change. Indirect components, such as internal accounting systems or settlement mechanisms that consume outputs generated by the implemented products, may also require updates to continue functioning properly after the change. Effective testing not only ensures the success of the change, but also plays a significant role in improving the time-to-market for the modified product. The testing process in complex, heavily-coupled banking architectures with legacy systems is inherently complicated, and testing the entire environment can take a considerable amount of time. Thus, it is essential to have a robust testing strategy in place to minimize downtime and ensure a smooth transition to the updated product.
Our testing strategy, which is to test the isolated changes first, then the affected components and then the system as whole, is aligned with the use of Vault Core as our core banking platform of choice. Vault Core allows us to test smart contracts in isolation from the rest of the system. Using a modern core banking system and a well-designed microservices architecture has allowed us to build different stages of testing environments, and to identify the impact of changes to different system components. If we change one product, the change is usually contained within the smart contract implementation of that product, its associated microservice and the components that consume the outputs of the product.This is a great example of smart contract application.
Since we mostly modified the smart contract of the deposit product, we need to test first the smart contract, then the smart contract in combination with the directly connected components and then verify the overall state of the whole bank system. This is another example of how our core banking selection helped us to properly test the changes on different levels since we were able to first test isolated changes within the core banking system itself, then extend to the corresponding microservice and, after everything was verified, validate the impact of the changes on the entire system. This approach helps us to easily identify potential issues within the whole system’s architecture and deploy the change faster, free from the domino effect of highly coupled or legacy architectures.
After the changed product is tested in an isolated environment, we continue with integration testing and system testing. This testing covers the integration of the changed product with the rest of the existing banking system and is automated within a continuous integration setup. Besides other purposes, it serves as an automatic validation that any direct and indirect dependencies that might have been affected are not overlooked.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
By submitting this form you agree to the processing of your personal data according to our Privacy Policy.
By submitting this form you agree to the processing of your personal data according to our Privacy Policy.
Thank you for contacting us! One of our experts will get in touch with you to learn about your business needs.
