Thought Machine and AWS launch AI core-migration solution

Thought Machine, the London-headquartered core-banking software company, announced on 29 September 2026 that it has launched a joint AI-assisted migration solution with Amazon Web Services (AWS), designed to speed up the move from legacy core-banking systems to Thought Machine's Vault platform. The solution combines AWS Transform, which reverse-engineers old applications, with Vault Forge, Thought Machine's product-generation engine, to turn undocumented legacy rules into draft banking products and test suites for human review and sandbox evaluation.

For UK banks undertaking legacy-core modernisation, the proposition is not generic AI-assisted coding. It is an attempt to extract business logic from legacy application code and turn it into a traceable specification a bank can inspect before it goes anywhere near production. The announcement does not explain how the workflow captures rules that exist only in operational practice, manual exceptions or institutional memory rather than in code.

Thought Machine Group Limited, company number 11114277, is an active UK private company incorporated on 15 December 2017 with a registered office in London. The Thought Machine brand says it was founded in London in 2014. The announcement matters now because UK banks face continuing operational-resilience obligations on the systems that run their most important services, obligations that apply whether a bank buys a new core platform, modernises in place, or does nothing at all.

How the four-stage workflow works

Thought Machine describes the process in four stages: extraction, consolidation, synthesis and validation.

In extraction, AWS Transform analyses a bank's legacy application and converts what it finds into structured specifications written in Easy Approach to Requirements Syntax (EARS), a format intended to make business rules readable and traceable rather than buried in code. Thought Machine says the rules it targets include interest calculations, fee schedules, repayment workflows and account lifecycles.

In consolidation, the vendors propose rationalising redundant legacy product variants into a smaller set of modern specifications. This stage is not purely mechanical: deciding which behaviour to preserve, amend or retire is a policy choice, and the announcement does not explain how a bank distinguishes genuine duplication from contractual differences or individual customer entitlements that must be kept.

In synthesis, Vault Forge uses specialised AI agents, run through Amazon Bedrock, to generate software development kit-compliant Python code for financial products, along with test suites and Vault platform configurations.

In validation, human review gates give the bank sign-off authority before the generated products are deployed to a Vault sandbox for further evaluation. Thought Machine says the whole workflow is designed to run inside the customer bank's own AWS environment.

What is genuinely new here

The more interesting claim is architectural rather than procedural. Thought Machine's Vault platform represents financial-product logic in Python, separately from the underlying banking infrastructure. That separation is what allows extracted legacy rules to be recreated as higher-level product code, rather than translated line by line from one legacy language into another. If it works as described, a bank gets a specification it can read and a product it can test.

That architecture does not, on its own, establish that a generated product behaves identically to the legacy one it replaces. AWS's own public guide to core-banking modernisation, published 22 May 2026, warns that replacing a core system with a commercial off-the-shelf platform does not automatically preserve functional parity, because the new platform carries its own process models and data structures. Rule extraction and product generation are a starting point for equivalence testing, not proof of it.

Claims versus evidence

Thought Machine's announcement makes two commercial claims that the research behind this article could not independently verify: that the joint solution can compress multi-year migration processes into days, and that it allows modernisation at a fraction of traditional cost.

Neither claim comes with a named bank, a defined benchmark, a lines-of-code figure, or a disclosed price. AWS's broader modernisation guide, by contrast, describes comparable AI-enabled programmes compressing multi-year efforts into months, not days. The gap between the two figures may reflect a bounded stage of work, such as converting a single product, rather than a complete migration from legacy system to live production. Without a shared definition of what is being timed, the two claims cannot be reconciled, and neither can be taken as a reliable guide to what any individual UK bank should expect.

No named bank, pilot or production deployment was identified in the material reviewed for this article, and no accuracy rate was published for extracted rules, generated code or generated tests.

Why core migration remains difficult

AWS's own material describes core-migration programmes as typically taking multiple years, a baseline the vendors use when framing the appeal of a faster workflow. Reconciling a new system with everything downstream is one of the main reasons such programmes take so long. A generated Python product still has to be checked against the legacy system's actual balances, interest accruals, fee calculations, contractual terms, general-ledger postings and regulatory reporting. It has to cope with rules that exist only in manual exception-handling or long-standing operational practice rather than in source code. And a bank still needs parallel running, reconciliation, cutover controls, rollback arrangements and an exit plan if something goes wrong after go-live. The announcement does not set out how any of these are handled.

Human approval and operational risk

The human-in-the-loop gate is presented as the control that keeps the bank in charge: nothing reaches a Vault sandbox without sign-off. That is a meaningful governance mechanism, but it is not, on its own, evidence that reviewers can catch every mistranslated or omitted rule. The announcement does not disclose who the approvers are, what qualifications or segregation of duties apply, or what evidence they must review before signing off.

The Bank of England's own AI roundtables, summarised in minutes from February 2026, heard industry participants argue that agentic AI challenges conventional human-in-the-loop controls, and that testing, monitoring and outcome guardrails matter as much as a sign-off step. The Bank's April 2025 financial-stability assessment of AI similarly identifies model, data, governance and operational risks that insufficient testing and controls can create. These positions are not incompatible with Thought Machine's approach, but they are a reminder that approval is one control among several that a bank would need, not a substitute for them.

UK regulatory implications

UK banks' obligations do not change because a vendor offers a faster migration path. Under the Financial Conduct Authority's (FCA) operational-resilience rules, in-scope firms were required, from 31 March 2025, to be able to remain within impact tolerances for their important business services during severe but plausible disruption. The FCA has said explicitly that where a third-party provider supporting an important business service fails, responsibility for staying within impact tolerance remains with the regulated firm, not the provider. Using AWS and Thought Machine does not transfer that responsibility.

The Prudential Regulation Authority's (PRA) supervisory statement on outsourcing and third-party risk, SS2/21, in its November 2024 version, took effect on 31 December 2024 and sets expectations for governance, data security, business continuity and exit planning in arrangements like this one. A revised version of SS2/21 is due to take effect on 18 March 2027, alongside new UK operational-incident and material third-party reporting requirements, which banks planning multi-year migration programmes will need to build into their timelines.

On AI specifically, the FCA said on 8 June 2026 that it does not plan a separate AI rulebook. Instead it will rely on existing frameworks, including the Consumer Duty and the Senior Managers and Certification Regime, to hold firms and their senior managers accountable for outcomes. A human sign-off step supports that accountability; it does not replace it.

This is general reporting on a vendor product launch and the regulatory obligations that surround it, not advice on whether any bank should adopt a particular migration approach. No UK regulator has assessed or endorsed this specific product.

What to watch next

The questions that matter for UK banks are not yet answered by what Thought Machine and AWS have published. Readers should watch for a named UK pilot or production deployment, an independently reported accuracy or cost result, clarity on which AI models process bank data through Amazon Bedrock and on what retention terms, and how banks preparing for the operational-incident and third-party reporting requirements taking effect on 18 March 2027 factor a vendor-led migration solution into their resilience planning. Official detail on resilience obligations is available from the FCA's operational-resilience pages and the PRA's SS2/21 supervisory statement.