Vault Core – a hyper-configurable neo-core banking system from Thought Machine

Vault Core is suitable for reacting quickly to customer needs and trying out innovative banking products, which would not be possible or would be too expensive with a traditional core banking system. Depending on the business case, it may be necessary to connect third-party applications to obtain further data via APIs.

Vault Core can be used as a platform for the development of a new banking system, or to "collect” applications from banks with architectures that have become increasingly complex over the years, and cover them step-by-step with a modern, clear architecture. 

Banks typically enter the Vault Core universe by means of a sandbox environment, which Thought Machine offers as early as possible in the sales process so that potential clients can test the functionality of the product first-hand, followed by a minimum viable product (MVP), which should make a "quick win" possible: After a proof of concept of about 6 to 8 weeks, Vault Core is connected to the bank's existing core banking system via interfaces so that the new product to be introduced (e.g. eWallet) can query the required data (e.g. sufficient account funds) in real-time via an API.

Vault Core supports the core strategic elements of system support, which were described in this earlier article for banks to consider, as follows: 

Openness: Vault Core provides all functionalities via APIs and therefore fulfils the requirement of standardised interfaces for digital networking.
With regard to APIs and data ecosystems, it must be made sure that the philosophy of openness is also supported by the systems to be connected.

Data: Customer data is not held in Vault Core's kernel, but typically in a bank's CRM. This not only allows the anonymised operation of Vault Core, as the CRM only transfers UniqueIDs, but also improves structured data storage. The principle of "platform on the cloud, personal data on site" is also advantageous when it comes to meeting regulatory requirements for handling personal data.

Where possible, the data is not assigned to the customer across the board, but instead is kept service- and object-specific. For example, the data (e.g. lending amount, interest rate, term, etc.) can be assigned directly to the property or mortgage. This distributed data management simplifies the integration of external data within the context of service provision in ecosystems (e.g. ensuring up-to-date cadastral land register data). 

Functions: Vault’s functionality focuses on enabling a bank to create any financial product. Financial products are underpinned by accounts and embedded in automated processes via in-built workflow management. The provision of further functions through peripheral systems requires integration expertise from the bank or its provider. A good intermediate route must be found that does justice to the "best of breed" approach (with complex integration architectures), but which also allows for easy-to-integrate peripheral systems to cover additional functions. 

Processes: Process automation is one of Vault Core's strengths. However, the process expertise for implementing Vault Core must be maintained within the bank. Above all with regard to ongoing operation, attention must be paid to consistency, simplicity and the highest possible level of process standardisation.