Domain separation
Keeps clearing capabilities from becoming another tightly coupled application.
Technology stack
Java 25
Spring Boot 4
Spring Security
Spring Cloud
Spring WebFlux
Spring Data JPA
R2DBC
Vue 2
Vuex
Vuetify
PostgreSQL
Hibernate
Flyway
Ehcache
RabbitMQ
Vue Router
OpenFeign
OpenAPI Generator
Docker
GitLab CI/CD
Maven
OAuth2/JWT
Prometheus
Grafana
Vue Router
The challenge: modernizing clearing logic while keeping the financial ecosystem connected
How do regulated financial organizations modernize a core clearing system when its business logic and integrations cannot simply be replaced at once?
The difficult part was not building another Java platform. It was moving clearing logic out of a business-critical monolith while keeping the surrounding financial ecosystem connected.
The legacy clearing platform had accumulated substantial domain logic around commodity-market operations, while its monolithic architecture made further changes and integrations increasingly difficult.
The transition also had to preserve the rules, controls, and operational workflows governing regulated clearing.
Three constraints therefore shaped the modernization:
- Preserve complex clearing logic while moving away from the monolith.
- Continue integrating with surrounding systems, including trading, delivery, accounting, CRM, and verification platforms.
- Migrate progressively, while the legacy system remained part of the operational landscape.
How Azati is modernizing the clearing platform
The difficult part was not choosing microservices. It was deciding where the clearing domains belonged, how they should communicate, and how the new platform should coexist with the systems that still run the market.
Rather than attempting a big-bang replacement, Azati is building Catena as a modular microservices platform and progressively moving clearing capabilities into the new architecture.
The work combines domain decomposition, Java development, integration engineering, document processing, operator tooling, security, and automated delivery.
01
Clearing domain decomposition into microservices
The new platform separates major areas of clearing functionality into independently developed services rather than reproducing the legacy monolith as one large application.
More than 40 microservices have been implemented around domains including participants, registers, obligations, supply contracts, payments, clearing decisions, reporting, risk management, and gas-market operations.
The separation gives each clearing domain a defined place in the new architecture and makes it possible to move functionality progressively rather than recreate the monolith service by service.
Stack: Java 25, Spring Boot 4, Spring Data JPA, PostgreSQL
Key capabilities:
- Clearing participant management
- Monetary, commodity, clearing, and transport registers
- Obligations
- Supply contracts
- Payments
- Clearing decisions
- Risk management
- Gas-market operations
- Regulatory reporting
02
Event-driven communication between clearing services
The new services communicate asynchronously through RabbitMQ, with synchronous APIs where direct request-response integration is more appropriate. This allows individual clearing domains to evolve as separate services while maintaining communication across the broader platform.
Stack: Spring AMQP, RabbitMQ, Spring Cloud OpenFeign.
Key capabilities:
- Event-driven service communication
- RabbitMQ messaging
- Domain-level service separation
- Synchronous API integration where required
03
Integration with the trading and enterprise systems around clearing
Azati isolated external-system dependencies behind dedicated adapters for trading, delivery, accounting, CRM, and verification systems.
The integration layer currently covers systems including the exchange's trading system, commodity delivery operator, accounting systems, CRM, and verification modules. This keeps integration-specific logic at the edge of the platform instead of spreading external-system dependencies through the core clearing domains.
The integration approach combines the Adapter pattern, OpenFeign, RabbitMQ, and XML/JSON processing.
Integration areas
Key capabilities:
- Trading system
- Commodity delivery operator
- Accounting systems
- CRM
- Verification and checking modules
- External APIs
04
Document processing and regulated data exchange
Clearing operations generate and consume substantial amounts of structured documentation. Processing it reliably requires validation before information reaches downstream services or storage.
Azati developed a document-processing pipeline that separates validation, processing, and storage rather than treating document handling as a single operation. A dedicated Document Storage Service uses a reactive stack based on Spring WebFlux and R2DBC to handle document persistence.
Stack: Spring WebFlux, R2DBC, Jackson XML, StAX, Apache POI
Key capabilities:
- Document validation
- Document processing
- Document storage
- XML processing
- JSON processing
- Structured data exchange
- Electronic signature integration
05
Clearing operations and regulatory reporting
The new platform implements business requirements derived from the exchange's clearing rules and regulatory reporting obligations, payments, registers, and clearing decisions. The operations are validated against the applicable rules before the relevant workflows proceed.
Compliance context: exchange clearing rules, regulatory reporting, OAuth2/JWT, authentication, role-based access, electronic signatures, XML security controls.
Key capabilities:
- Clearing-rule validation
- Obligation processing
- Payment workflows
- Clearing decisions
- Regulatory reports
- Electronic signatures
06
Operator workspace for clearing operations
Modernizing the backend alone does not modernize the operational experience. Clearing specialists also need a consistent interface for working with the entities and processes represented by the new platform.
Azati developed a Vue-based operator workspace providing access to participants, registers, obligations, payments, documents, and reports. The interface gives operators a unified workspace across functionality that had previously been associated with the legacy clearing environment.
Key capabilities:
- Participant management
- Register management
- Obligation management
- Payment operations
- Document handling
- Reporting
- Operational workflows
07
Security, testing, and controlled delivery
Azati incorporated authentication, authorization, electronic signatures, XML security controls, automated testing, and coverage checks into the delivery pipeline rather than treating them as a final release gate.
The delivery pipeline uses GitLab CI/CD, automated Maven builds, test execution, and coverage controls. Testcontainers is used to support integration testing against realistic infrastructure dependencies.
This gives the team a repeatable build, test, and deployment path on the client's infrastructure.
Stack: Spring Security, Avanpost, Docker, GitLab CI, JaCoCo, Testcontainers, Prometheus, Grafana.
Key capabilities:
- OAuth2/JWT authentication
- Role-based authorization
- Electronic signatures
- XML security / XXE protection
- Automated testing
- Coverage gates
- Containerized deployment
- CI/CD automation
Delivery & modernization outcomes
| Area | What Azati delivered | Operational value |
|---|---|---|
| Clearing modernization | Built 40+ domain-oriented microservices covering core clearing capabilities | Establishes a modular foundation for progressive replacement of the legacy monolith |
| Phased migration | Developed Catena alongside the existing clearing system | Allows functionality to move progressively rather than requiring a single cutover |
| Domain coverage | Implemented participants, registers, obligations, payments, contracts, risk management, reporting, and clearing decisions | Brings core commodity-clearing workflows into the new platform |
| External integration | Built adapters for trading, delivery, accounting, CRM, and verification systems | Isolates clearing logic from external-system dependencies |
| Document & data processing | Implemented validation, processing, storage, XML/JSON exchange, and electronic-signature workflows | Creates a structured path for regulated document and data exchange |
| Operator experience | Delivered a Vue-based workspace for participants, registers, obligations, payments, documents, and reports | Gives operators a unified interface across key clearing workflows |
| Controlled delivery & security | Implemented OAuth2/JWT, role-based access, XML security controls, automated testing, coverage gates, and GitLab CI/CD | Makes security, quality verification, and deployment controls repeatable |
Modernizing a business-critical financial platform?
Discuss your legacy architecture, domain constraints, and migration options with an engineering team experienced in regulated financial systems.
Discuss your modernization projectWhy this modernization approach matters for regulated financial platforms
Modernizing a clearing system is less about introducing newer technology than about changing the architecture without losing the domain knowledge embedded in the existing platform.
The result is not a claim that modernization becomes risk-free. It is a more controlled path away from a business-critical monolith, where established clearing logic and operational dependencies can be migrated rather than discarded.
In this engagement, three decisions make the transition more controlled:
Integration adapters
Isolate the new platform from the protocols and dependencies of surrounding systems.
Phased migration
Allows new capabilities to be introduced while the legacy platform remains part of the transition.
Who this modernization model is best suited for
This approach is most relevant to regulated financial organizations that need to modernize business-critical platforms without discarding established domain logic or forcing a single high-risk replacement.
It is a strong fit when the organization:
- Operates clearing, settlement, trading, or transaction-processing infrastructure
- Has a monolithic or tightly coupled legacy platform
- Needs to preserve established financial-domain rules and workflows
- Depends on multiple trading, ERP, accounting, CRM, or regulatory integrations
- Needs to modernize incrementally while production operations continue
- Is considering Java/Spring modernization but needs domain decomposition and a migration strategy, not just development capacity
Frequently asked questions
A clearing system processes the obligations created by market transactions, including determining what participants owe, maintaining relevant registers, managing collateral and payments, and producing clearing decisions and reports.
For a commodity exchange, the system also has to reflect the specific rules governing commodity contracts, delivery obligations, trading sessions, and related market operations. Catena implements these domains for a regulated commodity-market environment.
Legacy clearing platforms can become difficult to scale, maintain, integrate, and change as market infrastructure and regulatory requirements evolve. Their architecture may also make each new integration or functional change increasingly dependent on the existing monolith.
A phased modernization can separate business domains, introduce modern interfaces and integration patterns, and transition legacy components without requiring the entire system to be rewritten at once.
In this engagement, the legacy clearing system is being progressively replaced by Catena, a platform built around 40+ Java microservices.
Microservices can separate complex financial-domain capabilities into independently developed components, making large systems easier to evolve when their domains have sufficiently clear boundaries.
The architecture also allows integration, deployment, and modernization decisions to be made at the service level rather than across one monolithic application.
Catena currently includes 40+ services covering areas such as participants, registers, obligations, payments, documents, reporting, and risk management.
A phased migration keeps the legacy platform in the transition architecture while individual capabilities are developed and moved to Catena.
The critical requirements are clear domain boundaries, controlled interfaces between old and new components, data consistency, and a migration sequence that reflects business dependencies.
Catena uses domain-separated microservices and dedicated adapters to support this migration model while the legacy clearing platform remains part of the transition.
The modern platform can use dedicated adapters to isolate its core business logic from the protocols and implementation details of surrounding systems.
This means the clearing domain does not need to directly absorb every legacy interface, reducing coupling between the new architecture and existing enterprise systems.
In this engagement, Azati implemented adapters for the trading system, commodity delivery operator, accounting systems, CRM, and verification modules.
Modern clearing platforms typically combine transactional data management, domain-oriented services, asynchronous messaging, API integration, security controls, and automated delivery. The exact stack depends on the existing infrastructure, integration landscape, regulatory requirements, and migration strategy.
For Catena, the stack includes Java 25, Spring Boot 4, Spring Cloud, PostgreSQL, RabbitMQ, Vue, Docker, and GitLab CI/CD, with OAuth2/JWT security and Prometheus/Grafana observability.
Regulated financial modernization has to account for domain rules, security controls, testing, integrations, operational continuity, and regulatory reporting at the architecture level rather than treating them as separate compliance activities.
A practical modernization approach therefore combines incremental architecture changes with controlled access, explicit validation, secure data processing, automated quality checks, and a migration sequence that reflects business dependencies.
In the Catena engagement, Azati works with commodity-clearing rules, bank reporting requirements, electronic signatures, OAuth2/JWT authentication, role-based access, and XML security controls as part of the platform implementation.
