Vacuumlabs is a certified Thought Machine implementation partner. We have delivered Vault Core deployments for new bank builds and core banking transformation programmes across Europe and Asia, including the first Vault installation in Asia, completed in 18 months from licensing to market.

This article explains what Thought Machine and Vault Core are, how Vault Core compares to legacy core banking and to other modern platforms, and how to choose a platform and an implementation partner. It is based on our direct implementation experience across multiple live banking environments.

Key takeaways

Choosing a platform comes down to product configurability, real-time processing, deployment model, migration path and the partner who implements it.

Thought Machine is a London-based core banking technology company founded in 2014. Its flagship product is Vault Core.

Vault Core is a cloud-native core banking engine that focuses on the ledger. Product behaviour is written as Python smart contracts and transactions are processed in real time.

It runs as managed SaaS, in a bank’s own cloud account, or on private infrastructure.

A tale of two perspectives on core banking

The world of banking has always been a tale of two approaches. On one side, incumbent banks wrestle with legacy systems creaking under decades of custom code. Their architectures are often inflexible. A regulatory change or new product request can take months of planning and testing. Navigating these systems can be slow and add a lot of stress to teams, using up energy that could be going towards inventive features.

On the other side, neobanks thrive on agility, built on modular, cloud-native cores like Thought Machine’s Vault Core. Changes roll out in days, not months. Experimentation is baked directly into their foundation, letting you test, tweak, and iterate.

There’s a gap between old-school and modern approaches. Let’s dive into what we can learn from each. 

All-in-one vs. modular architecture

Traditionally, core banking has been all in one. Legacy cores bundle everything: ledgers, risk engines, customer management into a single system. In theory, it’s convenient. It’s simply a single vendor with one support agreement and one upgrade cycle. In practice, it becomes a huge backlog. Every change funnels into a monolithic backlog, and patches multiply until innovation grinds to a halt. Worse, replacing components requires risky “heart surgery”: parallel processing, compensation logic, and brittle workarounds (e.g., intercepting transactions for external risk engines and reconciling mismatches).

Modular cores, like Vault Core, focus solely on the ledger. Postings. Transaction logic. Balance updates.  Everything else like risk, payment processor integration, CRM, lives outside, connected via APIs. Swapping a KYC provider? No core rebuild needed. But this approach isn’t without debate. Some argue it’s too modular. Like separating the general ledger, which initially causes some concern. Yet, the separation of concerns (customer-facing logic vs. accounting) ultimately wins by streamlining both innovation and compliance.

General ledger separation

Another benefit of modern platforms is general ledger separation. The core streams transaction events out in real time to an external ledger system. Product teams can focus on customer-facing behavior, crafting new interest schemes or fee models. Accounting teams simply consume the event stream to handle amortization, accruals, and monthly reporting. No more wrestling with a monolithic core to extract financial reports. The separation of concerns speeds up both development and reconciliation.

Cloud Adoption: On-Prem vs. cloud vs. self-hosted

Incumbent banks often favor on-premise deployments. Their workloads are predictable and they know where the peaks are. Hardware costs have already been amortized. The argument goes that burst-style scaling is unnecessary, but cloud can offer resilience and multi-zone availability that on-prem simply does not match. The downside is potentially higher run-rate expenses once you factor in ongoing cloud egress and managed service fees. And if all your developers must go through a central infra team to spin up new resources, you lose speed and autonomy. But cloud adoption isn’t just about scalability; it’s about developer autonomy. Centralized infrastructure teams create bottlenecks, stifling experimentation. While cloud run-rate costs can exceed on-prem, the trade-off is resilience and multi-zone availability. Not to mention the freedom to spin up resources on demand.

Neobanks, however, need burst scaling and speed. SaaS is their default when regulations allow. Otherwise, self-hosted cloud deployments offer control. New partnerships and integrations demand dynamic scaling and developer self-service is essential. That is why SaaS solutions are often the first choice when regulations permit. When they do not, self-hosted deployments on your own cloud account deliver the control you need. And emerging “cloud in a box” offerings bring cloud-style platforms onto customer-owned hardware for those who need a cost-sensitive scale with tight data control.

Emerging “cloud in a box” solutions (e.g., pre-packaged Kubernetes or managed databases on customer-owned hardware) deliver a middle ground: cloud-like agility with on-demand scaling, but without locking data into public cloud providers.

Real-time processing with and without Vault Core

Legacy cores were designed for batch workflows. Transactions would pile up during the day and end-of-day jobs would run overnight. They relied on “real-time shields”, layers of caches, interceptors, and backup stores to mask batch-oriented designs. Cards and instant payments bolt onto these systems, requiring complex workarounds. Channels needed backup stores when the core went offline and the result was an intricate web of services to keep the front-end running. Sure, end-of-day snapshots provide consistency, but the architecture is fragile.

Vault Core is real-time by design. Transactions stream via Kafka APIs, processed in milliseconds. Timestamped events enable midnight snapshots, backdated transactions (within grace periods), and interest accruals, so no batch windows needed. Yet, challenges remain: backdating requires careful grace-period management, and fraud detection still happens externally, using card-inspired authorization-settlement patterns to reserve balances during checks. 

But here’s the really important distinction: Vault Core’s native real-time architecture eliminates the need for fragile ‘real-time shields.’ Fraud checks integrate seamlessly via authorization-settlement patterns (like card networks), reserving balances during verification without compromising speed. And because every event is timestamped, you can reconcile discrepancies without the legacy maze of caches and compensation logic.

Product design & evolution with Vault Core 

For incumbent banks, product innovation is often stalled by legacy systems. Backlogs overflow with regulatory fixes and production patches, while new features languish. It’s an architectural issue. Legacy cores enforce rigid, hardcoded rules. A single change can ripple across dozens of interconnected modules, requiring exhaustive testing. Over time this can creep into the entire day-to-day as banks develop a maintenance-first culture, where innovation takes a backseat to keeping the lights on.

Worse, legacy systems force product teams to “leak” features through cracks. Imagine a core designed 20 years ago: its original architecture never anticipated modern needs like real-time spending categories or dynamic overdrafts. Teams resort to duct-taping new logic onto outdated frameworks, creating Frankenstein systems that nobody fully understands. 

Modern platforms like Thought Machine’s Vault Core offer a different path. Smart contracts replace hard-coded rules. Business logic lives in Python snippets at lifecycle hooks: on-posting, on-acceptance, scheduled triggers. Products can even be prototyped in days. Overdraft rules, fee structures, interest models are now all configurable per account version. What if you want to A/B test two versions of a product? Now, you can assign each group its own smart contract version and traffic splits automatically. And if a change goes awry, you can roll back safely by reverting to an earlier contract version. It is like service versioning for your products.

Q&A recap from our recent Vault Core focused webinar 

In our recent webinar on core banking challenges, here’s a quick summary of what we learned together if you missed it live: 

Hybrid approaches in banking 

Incumbent banks often blend in-house builds with third-party modules depending on strategic priorities, though legacy systems tend to prioritize maintenance over innovation, creating cultural barriers to change. Neobanks typically rely on external providers for specialization and speed, though some may build key components in-house when needed.

The evolving infrastructure landscape

On-prem tech stacks still thrive on container platforms such as OpenShift, coexisting with traditional servers in many data centers. Emerging solutions like cloud-in-a-box offerings are bridging the gap between cloud agility and on-prem control.

Handling compliance and real world innovation 

Today’s core banking platforms handle compliance workloads more intelligently. Critical transactions flow through prioritized Kafka streams for guaranteed SLAs, while non-essential operations use standard channels. Fraud detection operates externally but integrates seamlessly using card-network inspired authorization patterns – maintaining both security and performance. This versioned smart contract approach provides business continuity protection, so teams can safely roll back problematic changes or fix-forward, with no risk to live financial data. 

These capabilities are exactly what enable powerful innovations like real-time spending controls, which automatically enforce category limits as transactions occur. While legacy systems batch process overnight, modern platforms execute these rules instantly, creating tangible competitive advantages for forward-thinking banks.

Recapping the Vault Core basics 

If you want a simple, informative summary of Vault Core, you can check out Thought Machine’s dedicated product page here or read our handy summary below to help you make your first step towards a modern core solution. 

What is Thought Machine?

Thought Machine is a London-based technology company, founded in 2014, that builds cloud-native core banking software, with Vault Core as its flagship product.

The company wrote its platform from scratch rather than porting an older mainframe system to the cloud. Banks use Vault Core to run current accounts, savings, loans, mortgages and cards on a single real-time ledger. Publicly announced Thought Machine clients include Lloyds Banking Group, Standard Chartered, Intesa Sanpaolo, SEB, ING Bank Śląski, Atom bank, Judo Bank and HD Bank. Thought Machine works with a network of implementation partners, listed on its official partner directory.

What is Vault Core

Vault Core is a modern, cloud-native core banking engine that focuses exclusively on the financial ledger. It processes transaction requests (“postings”), applies configurable business logic through embedded smart contracts, and streams events in real time to downstream systems. It runs on any public or private cloud or as a hosted SaaS service, and replaces legacy monoliths with a lightweight, always-on ledger core.

For a full overview of the product from the vendor itself, see Thought Machine’s Vault Core product page.

What is a cloud-native core banking system?

A cloud-native core banking system is a core built from the start to run on cloud infrastructure: modular services, horizontal scaling, open APIs and real-time, event-driven processing.

This is different from a legacy core that has simply been moved onto cloud servers. A lifted-and-shifted core still runs overnight batches and tightly coupled modules. McKinsey describes next-generation cores as modular, with transaction management separated from surrounding banking services, and as processing and posting transactions in real time through an event-driven architecture (McKinsey, Should US banks be moving to next-generation core banking platforms?). Thought Machine, Mambu, 10x and Finxact are commonly cited examples of this generation (McKinsey, Next-generation core banking platforms: A golden ticket?).

Who are the top Thought Machine implementation partners?

Thought Machine implementation partners fall into three groups: global systems integrators, technology consultancies, and specialist engineering firms with hands-on Vault delivery experience.

The right group depends on your programme. Global integrators bring scale for multi-year enterprise transformations. Specialist firms bring deep Vault engineering, smart contract development and faster delivery for new bank builds and focused modernisation programmes. Whichever you consider, judge partners on evidence rather than logos:

1. Certification: is the firm an accredited Thought Machine partner, listed in the official directory?
2. Live deployments: how many Vault Core implementations has it taken to production, and in which markets?
3. Smart contract engineering: can it design, test and version Python smart contracts in-house?
4. Everything around the core: payments, cards, KYC, data platforms and customer apps, which make up most of a real bank build.
5. Named references: clients you can call, and timelines from licence to launch.

Our proof as a Thought Machine partner:

• Certified Thought Machine implementation partner, with a global partnership.
• First Vault Core installation in Asia: a Hong Kong virtual bank that went from initial licensing to market in 18 months.
• Afin Bank (UK): Afin Bank selected Thought Machine’s Vault Core and partnered with Vacuumlabs to support its operations and build its customer mobile app (FinTech Futures).
• Multiple Vault deployments across new bank builds and core banking transformation programmes in Europe and Asia.

For a deeper checklist, read how to choose a core banking implementation partner.

Our proof as a Thought Machine partner:

• Certified Thought Machine implementation partner, with a global partnership since 2021.
• First Vault Core installation in Asia: a Hong Kong virtual bank that went from initial licensing to market in 18 months.
• Afin Bank (UK): Afin Bank selected Thought Machine’s Vault Core and partnered with Vacuumlabs to support its operations and build its customer mobile app (FinTech Futures).
• Multiple Vault deployments across new bank builds and core banking transformation programmes in Europe and Asia.

For a deeper checklist, read how to choose a core banking implementation partner.

How do you choose a modern core banking platform?

Choose a modern core banking platform by testing it against your product roadmap, real-time needs, deployment constraints, migration path and total cost of ownership, in that order.

1. Product configurability: how are products defined: in code (smart contracts), through parameters, or via a no-code UI? This sets how fast you can launch and change products.
2. Real-time processing: does the core post transactions in real time and stream events, or does it rely on end-of-day batches?
3. Deployment model and data residency: SaaS, your own cloud account, or on-premise. Check what your regulator allows.
4. Product coverage: retail deposits, lending, mortgages, cards, SME, Shariah-compliant products. Map them to your three-year roadmap.
5. APIs and integration: how easily can you connect payments, fraud, CRM and data platforms, and swap them later?
6. Migration path: greenfield launch, progressive “hollowing out” of the legacy core, or full replacement.
7. Total cost of ownership: licence, cloud run-rate, implementation and the in-house team you need to operate it.
8. Partner ecosystem: are there enough experienced implementation partners in your region?
9. Regulatory references: has the platform gone live with banks under your regulator?

Thought Machine vs Mambu vs Temenos

The three platforms are most often shortlisted together. They differ mainly in how products are defined and where the platform can run.

	Thought Machine Vault Core	Mambu	Temenos (Transact)
Founded	2014, London	2011, Berlin	1993, Geneva
Architecture	Cloud-native, ledger-focused core	Cloud-native, composable SaaS core	Established core suite, modernised for cloud
How products are defined	Python smart contracts	Configuration through UI and APIs	Parameterised product builder with model-bank content
Deployment	SaaS, own public cloud, private cloud or on-premise	SaaS	On-premise, cloud or SaaS
Often chosen for	Deep product control in code, new bank builds and core transformation	Fast SaaS launch of lending and deposit products	Broad functional coverage for incumbent banks

Compiled from public vendor information. Check current capabilities with each vendor before a decision.

A tale of two perspectives on core banking

The world of banking has always been a tale of two approaches. On one side, incumbent banks wrestle with legacy systems creaking under decades of custom code. Their architectures are often inflexible. A regulatory change or new product request can take months of planning and testing. Navigating these systems can be slow and add a lot of stress to teams, using up energy that could be going towards inventive features.

On the other side, neobanks thrive on agility, built on modular, cloud-native cores like Thought Machine’s Vault Core. Changes roll out in days, not months. Experimentation is baked directly into their foundation, letting you test, tweak, and iterate.

There’s a gap between old-school and modern approaches. Let’s dive into what we can learn from each.

All-in-one vs. modular architecture

Traditionally, core banking has been all in one. Legacy cores bundle everything: ledgers, risk engines, customer management into a single system. In theory, it’s convenient. It’s simply a single vendor with one support agreement and one upgrade cycle. In practice, it becomes a huge backlog. Every change funnels into a monolithic backlog, and patches multiply until innovation grinds to a halt. Worse, replacing components requires risky “heart surgery”: parallel processing, compensation logic, and brittle workarounds (e.g., intercepting transactions for external risk engines and reconciling mismatches).

Modular cores, like Vault Core, focus solely on the ledger. Postings. Transaction logic. Balance updates. Everything else like risk, payment processor integration, CRM, lives outside, connected via APIs. Swapping a KYC provider? No core rebuild needed. But this approach isn’t without debate. Some argue it’s too modular. Like separating the general ledger, which initially causes some concern. Yet, the separation of concerns (customer-facing logic vs. accounting) ultimately wins by streamlining both innovation and compliance.

General ledger separation

Another benefit of modern platforms is general ledger separation. The core streams transaction events out in real time to an external ledger system. Product teams can focus on customer-facing behavior, crafting new interest schemes or fee models. Accounting teams simply consume the event stream to handle amortization, accruals, and monthly reporting. No more wrestling with a monolithic core to extract financial reports. The separation of concerns speeds up both development and reconciliation.

Cloud adoption: on-prem vs. cloud vs. self-hosted

Incumbent banks often favor on-premise deployments. Their workloads are predictable and they know where the peaks are. Hardware costs have already been amortized. The argument goes that burst-style scaling is unnecessary, but cloud can offer resilience and multi-zone availability that on-prem simply does not match. The downside is potentially higher run-rate expenses once you factor in ongoing cloud egress and managed service fees. But cloud adoption isn’t just about scalability; it’s about developer autonomy. If all your developers must go through a central infra team to spin up new resources, you lose speed and experimentation.

Neobanks, however, need burst scaling and speed. New partnerships and integrations demand dynamic scaling, and developer self-service is essential. That is why SaaS solutions are often the first choice when regulations permit. When they do not, self-hosted deployments on your own cloud account deliver the control you need.

Emerging “cloud in a box” solutions (e.g., pre-packaged Kubernetes or managed databases on customer-owned hardware) deliver a middle ground: cloud-like agility with on-demand scaling, but without locking data into public cloud providers.

Real-time processing with and without Vault Core

Legacy cores were designed for batch workflows. Transactions would pile up during the day and end-of-day jobs would run overnight. They relied on “real-time shields”, layers of caches, interceptors, and backup stores to mask batch-oriented designs. Cards and instant payments bolt onto these systems, requiring complex workarounds. Channels needed backup stores when the core went offline and the result was an intricate web of services to keep the front-end running. Sure, end-of-day snapshots provide consistency, but the architecture is fragile.

Vault Core is real-time by design. Transactions stream via Kafka APIs, processed in milliseconds. Timestamped events enable midnight snapshots, backdated transactions (within grace periods), and interest accruals, so no batch windows are needed. Challenges remain: backdating requires careful grace-period management, and fraud detection still happens externally.

The really important distinction: Vault Core’s native real-time architecture eliminates the need for fragile “real-time shields.” Fraud checks integrate via authorization-settlement patterns (like card networks), reserving balances during verification without compromising speed. And because every event is timestamped, you can reconcile discrepancies without the legacy maze of caches and compensation logic.

Product design & evolution with Vault Core

For incumbent banks, product innovation is often stalled by legacy systems. Backlogs overflow with regulatory fixes and production patches, while new features languish. It’s an architectural issue. Legacy cores enforce rigid, hardcoded rules. A single change can ripple across dozens of interconnected modules, requiring exhaustive testing. Over time, banks develop a maintenance-first culture, where innovation takes a backseat to keeping the lights on.

Worse, legacy systems force product teams to “leak” features through cracks. Imagine a core designed 20 years ago: its original architecture never anticipated modern needs like real-time spending categories or dynamic overdrafts. Teams resort to duct-taping new logic onto outdated frameworks, creating Frankenstein systems that nobody fully understands.

Modern platforms like Thought Machine’s Vault Core offer a different path. Smart contracts replace hard-coded rules. Business logic lives in Python snippets at lifecycle hooks: on-posting, on-acceptance, scheduled triggers. Products can even be prototyped in days. Overdraft rules, fee structures and interest models are all configurable per account version. Want to A/B test two versions of a product? Assign each group its own smart contract version and split traffic automatically. And if a change goes awry, roll back safely to an earlier contract version. It is like service versioning for your products.

Benefits of Vault Core 

Product agility: New account types, fees or interest rules are implemented via smart contracts, cutting rollout time from months to days.

Scalability & resilience: Built for horizontal scaling and high availability, it handles pilot launches up through millions of transactions without batch-window downtime.

Composable ecosystem: Open APIs let banks plug in best-of-breed partners for payments, risk, CRM or analytics and swap them as needs evolve.

Lower maintenance overhead: By eliminating batch processes and manual integration glue, ongoing operations are simpler and less costly.

Flexible deployment: Whether on-premise, in a private cloud, across public cloud providers, or as a managed service, Vault Core adapts to regulatory and data-residency requirements.

Features of Vault Core

Smart contract engine: Python-based hooks at each account lifecycle event (on-posting, on-settlement, scheduled jobs) give full control over behavior.

Universal product library: Ready-to-use templates (accounts, loans, cards, mortgages) plus the ability to craft entirely new products.

Event-driven APIs: Kafka-backed interfaces for inbound postings and outbound streams deliver real-time processing, support back-dated transactions, and power analytics.

Cloud-agnostic: Deployments on AWS, Azure, GCP, OpenShift or private infrastructure, and available as SaaS.

Versioned contracts: Run multiple smart contract versions side by side for A/B testing, staged rollouts or safe rollbacks..

Configuration of Vault Core

All product rules live in a separate configuration layer. Banks upload and manage Python smart contracts via APIs, adjust parameters on the fly, and immediately see changes in production. This clear separation between core platform and product logic means platform upgrades never force a re-test of every product variation.

Already-built financial products of Vault Core 

Deposit & savings accounts: Single- and multi-currency accounts with tiered interest and custom fee structures.

Lending solutions: Personal loans, revolving credit lines and buy-now-pay-later payment products with bespoke repayment and penalty rules.

Mortgages & home finance: Early repayment options, tiered rates and offset account features.

Card issuing: Debit, credit and virtual cards with real-time authorization rules, spending controls and flexible settlement logic.

Shariah-compliant products: Profit-and-loss sharing accounts and financing structures tailored via smart contracts.Vault Core APIs

Vault Core exposes simple, REST-style and event-driven interfaces so you can plug in any front-end or back-end service. The Postings API lets you submit transactions, from customer payments to fee postings, in a few well-documented calls. The Streaming API delivers real-time updates as a continuous event feed, so your fraud detection engine, analytics warehouse or notification service always sees the latest ledger changes without polling. Dedicated admin and configuration endpoints manage smart contracts, product definitions and user permissions, all secured with modern token-based authentication.

Hosting options 

You choose where Vault Core runs:

Managed SaaS: Thought Machine operates and maintains your environment in a dedicated tenancy. No ops work on your side.

Self-hosted cloud: Deploy into your AWS, Azure, GCP or OpenShift account. You keep full control of the infrastructure while using Vault’s automated deployment scripts.

On-prem or private cloud: Install on your own servers or private cloud to meet strict data-residency or compliance needs. You get the same cloud-native features (scaling, resilience and upgrades) behind your firewall.

Smart Contracts and ledger

At the heart of Vault Core is the ledger: a canonical record of every financial movement. Smart contracts are snippets of Python code that live alongside the ledger and define exactly how each product behaves: when interest applies, how fees are calculated, or what happens during an overdraft. Because contracts run in a sandboxed environment during transaction processing, you get immediate, deterministic results and a fully auditable history. Change a contract, and only new transactions use the new logic; past postings and balances stay untouched.

See examples of how smart contracts work in Vault Core.

Several of the answers in the FAQ below come from our webinar Breaking down core banking challenges and proven solutions.

Frequently asked questions:

Ready to explore Vault Core with Vacuumlabs?

Reach out to us and we can discuss a solution right for you. Not ready to talk just yet? Read more about our core banking system solutions.

1. Do banks build core banking components in-house or buy them?

Most use a hybrid. Incumbent banks blend in-house builds with third-party modules depending on strategic priorities, although legacy systems tend to absorb budget in maintenance. Neobanks usually rely on external providers for speed and specialisation, and build in-house only the components that differentiate them.

2. Can a cloud-native core banking system run on-premise?

Yes. Many on-premise stacks now run on container platforms such as OpenShift alongside traditional servers. “Cloud in a box” offerings bring cloud-style platforms onto bank-owned hardware, combining on-demand scaling with full control over where data is stored.

3. How does a modern core banking platform handle compliance and fraud checks without slowing down?

Critical transactions flow through prioritised event streams with guaranteed service levels, while non-essential operations use standard channels. Fraud detection runs outside the core and connects through card-network-style authorisation and settlement, reserving balances during checks. Versioned smart contracts let teams roll back or fix forward safely.

4. What is Thought Machine Vault Core used for?

Vault Core is used to run a bank’s core ledger and products: current and savings accounts, loans, mortgages, cards and Shariah-compliant products. Banks define each product’s behaviour in Python smart contracts, process transactions in real time and stream events to payments, fraud, CRM and analytics systems.

5. Is Vacuumlabs a Thought Machine implementation partner?

Yes. Vacuumlabs is a certified Thought Machine implementation partner. We delivered the first Vault Core installation in Asia, taking a Hong Kong virtual bank from licensing to market in 18 months, and support UK-based Afin Bank, which runs on Vault Core.

6. How long does a Vault Core implementation take?

It depends on scope, product range and integrations. As a reference point, the first Vault Core bank in Asia, delivered with Vacuumlabs, went from initial licensing to market in 18 months. Focused product launches on an existing Vault installation can take considerably less.