AI-Assisted Modernization of an FX Trading Platform

A global asset manager needed to move its FX trading platform from on-premises to AWS EKS without disrupting trading operations. The platform is the core of the firm's FX technology stack, spanning more than 20 repositories, with nearly 150k lines of code. Its Java order-management core routes orders to electronic FX venues over FIX and venue APIs.

Findev moved the currency hedging engine first, under a deliberately narrow mandate: prove it behaves identically in the cloud while its database stays on-premises. After the first cloud deployment, our engineers made the engine's heaviest job, the daily rebalance of hedge trades, about 9× faster. In about three weeks of active effort, the team took the engine into production on AWS EKS.

 

Problem

The hedging engine shared a monolithic process with functions that depended on the enterprise message queue. That queue was not available on the target platform, so moving the engine meant separating it without forking the code or carrying the queue dependencies across.

The database was not moving either: every call the engine made from the cloud would cross back to an on-premises Oracle instance, so the round-trip cost had to be measured, not assumed. This mattered most for the rebalance, the engine's heaviest job: a slow rebalance does not fail loudly.

Solution

Findev applied its AI-assisted method, phase by phase, to a service that had to run in a hybrid environment:

• App Assessment — Complexity Meter: scored the platform and identified migration risks and blockers to guide the choice of the first component to move.
• Knowledge Discovery — Discovery Agent: reconstructed 10 business workflows, 63 message types and 18 data flows from source code and runtime logs, with particular focus on the rebalance workflow and its dependencies.
• Test Generation — Test Forge: built packs comparing both deployments on production reference data, checking full response bodies and each side's own logs. The side-by-side tests exposed a load-balancer idle timeout that dropped the connection before the rebalance finished, a failure neither side logged as an error.
• Modernization: split the codebase into two run profiles so the engine starts in the cloud without the message-queue components; lifted the runtime from Java 11 to Java 21 and brought its libraries up to date; replaced the database connection pool with a container-friendly one. Performance changes cut repeated round trips to the on-premises database.
• Deployment: deployed to AWS EKS pre-production alongside the on-premises service, on the same database, then released to production.

AI did the analysis, test generation and code changes; our engineers made the design and release calls, and the application owner validated the result independently before production planning began.