Findev changes the engine. The market keeps moving.

The currency hedging engine had a problem that neither version of the software reported as an error. Moved toward the cloud, its daily rebalance ran long enough for a load balancer to drop the connection. Findev caught the timeout by testing the old and new deployments side by side. The episode captures something easily missed in a migration plan: software can appear healthy while the work it exists to do quietly fails.

Findev works in the machinery behind trading: order execution, market data, risk calculations, analytics and compliance. Banks, funds, asset managers and brokers are its territory. These organizations accumulate systems that reflect particular markets, counterparties and operating habits. Replacing the code means finding those habits before accidentally erasing them.

01The old system is the specification

Founder and CEO Dmitry Trub had already spent more than two decades delivering financial technology, including leading engineering teams on Deutsche Bank platforms. Findev dates its formation to 2020, when, by its account, clients urged the core team to build a dedicated global business. The distinction matters: a relatively young company sells experience acquired long before its founding.

In the foreign-exchange case, the platform covered more than 20 repositories. Findev began with the currency hedging engine, leaving its Oracle database on premises. That narrowed the work, but introduced a practical complication: database conversations now crossed between cloud and on-premises infrastructure. Every unnecessary round trip became more expensive in time.

The team separated the engine from unavailable message-queue components, upgraded its runtime and reduced repeated database calls. Findev reports roughly three weeks of active effort, an approximately ninefold improvement in the rebalance job, and more than 100 known vulnerabilities closed. The application owner independently checked that the engine generated the same rebalance trades. Trading continued during the move.

The useful lesson is the order of operations. Establish comparable outputs, isolate a manageable component, then investigate the behavior that differs. A cloud deployment can be successful as infrastructure and disappointing as a business process. Findev’s case is interesting because it checks both.

02A test can pass and still tell you nothing

A separate broker exposure service presented a different puzzle. Its desktop client used an undocumented socket protocol. The target cloud environment routed web traffic. A straightforward move would leave the trading desk unable to reach the service.

There were no automated tests to inherit. Findev reconstructed behavior from the implementation, built a protocol bridge and compared deployments using real reference data: nearly 300 exposure limits across more than 700 broker codes. Testing then uncovered a subtler defect. Some tests could pass without demonstrating whether the exposure was actually within its limit or in breach.

The team anchored those checks to verdicts known from production. That is a useful warning for anyone buying AI-generated testing: an impressive quantity of tests can coexist with a missing answer. The question is what each test establishes.

Findev also reports a first migration wave for a repo trading platform delivered by one engineer in three weeks. Its comparison is an estimated 18 months of traditional development and testing. That estimate deserves to stay attached to the claim. The first wave also deserves to stay distinct from the whole estate, which spanned more than 700,000 lines of code.

03Buy a first step, not a leap

Findev sells engineering engagements. Its broader services describe discovery, a pilot and a formal contract. Its modernization offer makes the first commitment more concrete: a bounded pilot, fixed-price after a short assessment. A prospective customer can start with a first-pass estimator using a public repository, a short questionnaire or aggregate code counts generated inside its own network.

This places Findev among specialist engineering consultancies. An internal team is another route; a packaged platform may cover sufficiently standard requirements. Findev’s argument rests on the awkward remainder: bespoke workflows, tangled dependencies and knowledge concentrated in a shrinking group of people. Its named tools, including Discovery Agent and Test Forge, support that service.

For a technology leader, the estimator is an opening conversation rather than a complete procurement decision. Findev asks about languages and code volume; its assessment examines dependencies and readiness. The more consequential cost is often the work surrounding the code: recovering undocumented rules, creating trustworthy checks and organizing a release that the trading desk can accept. In the broker service, producing the baseline was part of the engineering, alongside the migration. A pilot makes that work visible before the customer commits to a larger program.

The same method has conditions. Engineers need access to meaningful evidence and representative data, and customers need to validate the result. Matching an old system proves continuity; it cannot, by itself, establish that every inherited business rule deserves to survive. Those decisions still require people who understand the trades.

04The engineers have their own legacy

Findev’s internal AI experiment makes an unusually revealing companion to its client work. In September 2026, Trub described employees using AI while invoices still ran through Excel and accounts were provisioned manually. Personal productivity had spread unevenly. Company operations had scarcely changed.

After practitioner training, he concluded that internal agents were premature. Context had to come first. By October 22, the company had mapped recurring duties into nine functions and separated roles from the people holding them. Operational knowledge needed a written home before a machine could use it.

Its employment policies offer another clue to the model. Findev describes senior hiring, direct communication and salary bands published internally. The careers page says most annual profit goes to the team, with a specific allocation tied to tenure. The operating premise is that experienced people should stay long enough to understand difficult systems. For a consultancy selling institutional knowledge, retention has a commercial purpose as well as a cultural one. The careers page compresses the engineering preference into five words: build systems, not features.

There is a consistent engineering instinct here. Learn the existing system, make its behavior visible, then change a bounded piece. Findev applies it to trading software and, increasingly, itself. For a buyer, the question to borrow is wonderfully practical: before approving the replacement, ask the team to show exactly how it will know the old work still gets done.