How Azati modernized a live capital-markets platform while preserving its financial-system integrations, configurable business rules, and production delivery
Azati supported the modernization of the platform's core services, helping move the product from its legacy web architecture to a modern Java/Spring foundation while introducing configurable competition mechanics, new financial-system integrations, and more frequent ranking processing. The work was delivered within the client's existing product, infrastructure, and security environment. Figures below are current as of September 2026. The 2026 competition season runs through December 2026.
Financial markets supported
2026 competition season
Ranking recalculation cycle
Case study at a glance: Azati contributed Java engineering to the modernization of a long-running retail investment competition platform, supporting core competition services, broker registration, rankings, leagues, nominations, administration, integrations, and the migration from Java 11/Spring Boot 2 to Java 21/Spring Boot 3.
The business problem: The competition had outgrown its legacy platform. The organization needed to relaunch it as a more configurable product with leagues, nominations, tasks, partner participation, and consumer finance platform integration while continuing to work with real broker accounts and established financial-market systems.
The engineering challenge: The modernization had to happen within an existing exchange technology and security environment, with live financial integrations, changing competition rules, and a delivery team that couldn't treat the product as a greenfield build. The platform also had to evolve while the underlying business logic was still changing.
What was at stake: The organization needed more than a new technology stack. It needed a platform that could support a substantially longer competition season, more configurable participation mechanics, more frequent ranking updates, and additional partner-driven activity without breaking its connection to the existing financial ecosystem.
The hard part wasn't simply replacing an outdated application. The platform had to evolve inside an established financial ecosystem, while its product rules, integrations, and delivery needs continued to change.
The competition depended on existing exchange and consumer finance platform infrastructure for trades, orders, positions, prices, instruments, dividends, calendars, authentication, notifications, and other operational data. The modernization therefore had to improve the application layer without replacing the surrounding financial infrastructure.
Leagues, nominations, tasks, prizes, starting-capital rules, and other mechanics could change during the product lifecycle. Releasing code for every business-rule adjustment would have made the new platform harder to operate.
The platform could not be treated as a frozen legacy system. New leagues, nominations, tasks, prizes, participating brokers, and supported instruments continued to evolve as the product moved toward the new competition season.
The modernization had to fit the client's existing product organization, development standards, repositories, reviews, and security controls. Azati engineers worked within that environment rather than creating a separate vendor-led delivery track, allowing domain knowledge and ownership to build alongside the product team.
If your financial application is becoming harder to evolve but still depends on established trading, market-data, identity, or enterprise systems, modernization does not have to start with a clean-sheet rebuild.
Discuss your financial platform modernizationAzati evolved the platform's core competition services to support leagues, nominations, tasks, achievements, rankings, participant profiles, portfolios, transaction exports, and business reporting. This expanded the product beyond its former ranking-focused model and gave the organization a foundation for more varied competition mechanics.
Business outcome: The organization could run a substantially richer competition product without rebuilding the underlying platform around every new participation model.
Azati introduced configurable handling for leagues, nominations, tasks, prizes, brokers, instruments, and other competition parameters, separating frequently changing business rules from application logic.
Business outcome: Product teams gained more freedom to adapt competition mechanics as requirements changed, without turning every operational adjustment into a software release.
Azati developed and evolved the integration layer connecting the competition platform with exchange data, market and instrument information, data-warehouse services, corporate identity, notifications, and consumer-finance platform workflows.
Business outcome: The organization could modernize the application layer without replacing the surrounding financial infrastructure the product depended on.
Azati evolved calculation and performance services supporting participant rankings, portfolio performance, and statistics across three markets. The new platform moved ranking recalculation to a 15-minute cycle and introduced an external-system emulator for integration and load testing.
Business outcome: The platform gained a more frequent and controlled way to process participant performance, while the engineering team could test calculation behavior without directly depending on production financial systems.
Azati contributed to the migration from Java 11 and Spring Boot 2 to Java 21 and Spring Boot 3 while new competition functionality continued to be developed.
Business outcome: The technology foundation could evolve alongside the product instead of requiring a separate modernization freeze.
Azati's engineers worked within the client's existing development, security, and delivery environment, including GitLab, Jira, code review, VDI, VPN, and 2FA. The engagement built domain knowledge over more than a year as the platform evolved.
Business outcome: The client could introduce external specialist engineering without moving project assets outside its controlled environment or creating a separate delivery stream.
Modernization gets harder when the product is live, business rules keep changing, and releases cannot simply stop. Azati helps financial organizations evolve legacy Java and enterprise applications alongside ongoing product delivery.
Discuss your Java modernization roadmapThe most interesting architectural decision wasn't simply "use microservices." It was separating changing competition rules from application releases. The business can change leagues, nominations, challenges, prizes, participating brokers, partners, supported instruments, and other competition parameters.
That matters because the product is inherently seasonal and partner-driven. Requirements don't stop changing just because the season has started.
The platform therefore needed to be able to absorb business change without repeatedly turning that change into an engineering project.
| Area | What Azati contributed | Business / operational outcome |
|---|---|---|
| Legacy modernization | Java/Spring modernization of core services | Modern application foundation without separating modernization from product delivery |
| Competition product | Leagues, nominations, challenges, rankings, profiles and rewards | Expanded the product beyond the legacy ranking model |
| Business configuration | Configurable rules, prizes, partners, brokers and instruments | More flexibility to adapt the product as requirements changed |
| Financial integrations | Market data, DWH, identity, notifications and consumer-finance integrations | Modernized the application without replacing the surrounding financial ecosystem |
| Performance processing | Calculation and ranking services across three markets | 15-minute ranking recalculation cycle |
| Testing infrastructure | External-system emulator with synthetic market and participant data | Integration and load testing without direct production dependencies |
| Secure delivery | Engineering inside the client's VDI and infrastructure perimeter | External specialists capacity within the existing security model |
| Continuous modernization | Modernization alongside live product development | Product evolution continued while the technology foundation changed |
The engagement accumulated domain knowledge across more than 19 months of continuous product evolution, allowing the same engineering context to carry across modernization work, new competition mechanics, financial integrations, and ongoing season changes.
More importantly, the platform became substantially more adaptable: business teams could introduce new competition mechanics while the underlying architecture continued to evolve.
The new season introduced three portfolio-size leagues, 10+ nominations, partner-funded nominations, challenges, badges, and a larger reward structure compared with the earlier platform.
The new system recalculates rankings every 15 minutes across three markets, replacing the less frequent batch approach of the previous platform.
The new architecture provides a base for subsequent seasons rather than requiring the competition to be rebuilt around each new set of rules.
The engagement shows that specialist external engineering can work within a tightly controlled financial infrastructure without requiring the client to move project assets into a vendor environment.
This modernization approach suits financial organizations with established applications that cannot simply be replaced. It is especially applicable when modernization must happen alongside live product delivery, existing financial integrations, and changing business requirements.
Embedded engineering is not automatically the best delivery model. A different engagement may make more sense when:
If you don't have an established product organization, architecture, or delivery process, a dedicated product-development team may provide better coverage.
When the client wants one partner responsible for discovery, architecture, delivery, QA, and product execution, a project-based engagement is likely more appropriate than embedded engineers.
If the organization has not yet established what to modernize, what to keep, or how the target architecture should work, an assessment or modernization roadmap should come first.
For a genuinely greenfield application without legacy integrations or organizational constraints, this particular modernization model adds less value.
This case is most relevant to technology and product leaders in organizations that have valuable software they cannot simply replace. That includes:
Capital markets software modernization typically involves updating an established application architecture while preserving the financial workflows, integrations, security controls, and business logic that the organization still depends on. Depending on the platform, this can include legacy Java modernization, microservices decomposition, API and event-driven integration, database modernization, configurable business rules, performance engineering, and modernization of testing and deployment processes.
In this engagement, Azati contributed to Java and Spring modernization, financial-system integrations, configurable competition rules, calculation services, and testing infrastructure while the live product continued to evolve.
Financial platform modernization is the process of updating an established financial application so it can support current business requirements, integrations, security expectations, and operational needs without necessarily replacing the entire surrounding ecosystem.
In this engagement, the legacy competition application was rebuilt around modern Java/Spring services while retaining integrations with the client's existing financial-market systems.
A practical approach is to modernize incrementally around business-critical services rather than treating the entire application as one replacement unit.
In this engagement, selected services were migrated from Java 11/Spring Boot 2 to Java 21/Spring Boot 3 while the live product continued to evolve.
Rules that change frequently can often be represented as configurable domain data rather than hard-coded into application releases.
The competition platform uses administrative capabilities for leagues, nominations, challenges, prizes, partners, brokers, and instruments, allowing many changes to be managed without modifying application code.
Yes. The delivery model needs to be designed around the client's security requirements.
Here, the Azati engineers work through the client's VDI environment, with project assets and access remaining inside the client's controlled infrastructure.
Embedded engineering can be appropriate when the client already owns product management, architecture, and delivery but needs additional specialist capacity.
In this engagement, Azati engineers became the primary developers for several services while working directly within the client's established product team.
A modern application layer can expose or consume controlled interfaces to existing systems rather than replacing them all at once.
This project integrates with market-data services, the data warehouse, document management, notification infrastructure, corporate SSO, and broker-related workflows.
A dedicated emulator can reproduce external-system contracts and generate synthetic data for integration and load testing.
The project includes such an emulator for market-data and participant scenarios, allowing calculation services to be tested without directly loading production financial systems.
No. AI is not required to modernize a financial application.
The competition product itself uses deterministic business logic and calculations. AI is used separately as an internal development aid, not as part of the product's functionality.
Explore our successful projects and see how Azati delivers measurable results for our clients.
A financial institution's heavily loaded monolithic backend caused mobile app load times of around 15 seconds and limited system performance. The client needed to improve responsiveness and scalability without compromising security or regulatory requirements.
Azati redesigned the backend architecture by decomposing the monolith into independent microservices, optimizing SQL and data processing, and separating transaction history from the main mobile workflow. The resulting architecture improved performance, fault isolation, and scalability while providing a foundation for further development.
A UK fintech operated a payment orchestration platform with a lean engineering team responsible for product development, cloud infrastructure, and operational support. Infrastructure work and an extended search for senior DevOps expertise were diverting engineering leadership from platform architecture and payment capabilities.
Azati embedded platform engineering expertise into the client's existing organization, modernizing AWS infrastructure, Infrastructure as Code, CI/CD, monitoring, and operational processes without disrupting ongoing payment platform development.
A Latin American FinTech needed to scale its financial automation platform—which handles banking connections, transaction synchronization, and reconciliation—while ensuring continuous delivery of new features without compromising financial accuracy. They required expertise to expand banking integrations, improve testing, and modernize the platform while maintaining operational stability.
Azati embedded senior Ruby on Rails engineers into the client's product team to enhance core financial workflows, improve banking integrations, strengthen security, modernize parts of the platform, and expand automated quality assurance. The engagement combined feature development with stabilization of existing functionality, enabling continuous product evolution while preserving the integrity of financial operations.
A financial institution needed to continuously evolve its digital banking platform while ensuring service reliability, high transaction performance, and ongoing regulatory compliance.
As an embedded engineering partner, Azati enhanced and stabilized the client's digital banking platform. Through ongoing maintenance, feature development, and performance optimization, the team enabled continuous product evolution and improved reliability, supporting growing user activity and regulatory compliance without the need for large-scale replacement.
Last updated
