Designing a correspondent settlement platform for Cambilex
Cambilex needed to rethink settlement across its correspondent network. The problem crossed operations, finance and technology, and had to fit within existing systems and security.
01 / The challenge
Settlement is where several systems have to agree.
A correspondent settlement platform is not simply a reporting application.
Before a settlement can be calculated, the system needs to bring together information from different sources, apply business rules, account for exchange rates and commissions, and preserve enough history to explain every result. For Cambilex, the challenge was defining how all of those pieces should work together before development began.
- 01
Transaction Sources
Financial operations originated in different internal platforms.
- 02
Commissions & Rules
Settlement needed to account for products, variables, commissions and correspondent-specific conditions.
- 03
Exchange Rates
Official exchange-rate information had to become part of the calculation process.
- 04
Operations
Teams needed visibility into processes, results, exceptions and historical settlements.
- 05
Security
Access had to fit the company's existing identity infrastructure and role model.
- 06
Auditability
Financial calculations needed a clear trail from source data to final settlement.
02 / The approach
Understand the settlement process before designing the system.
We started with the business process.
Working with Cambilex's operational and technical counterparts, we mapped how settlement worked, where the information came from, which rules affected the calculation and what users needed to manage or verify.
From there, discovery moved into technical definition: business requirements, integration constraints and architecture decisions defined as one system, not separate documents engineering would need to reconcile later.
- BUSINESS FLOWS
- DATA SOURCES
- SETTLEMENT RULES
- INTEGRATIONS
- SECURITY
- AUDITABILITY
03 / The solution
An implementation-ready platform definition.
Six functional layers, designed around Cambilex's existing systems rather than replacing them.
Settlement Engine
Core domain model for operations, products, commissions and settlement entries, the foundation for calculating and preserving results over time.
SettlementsData Integration
Scheduled ETL from Dynatech and Creditflow into the settlement domain, with manual triggers for authorized operational users.
ETLOfficial Exchange Rates
Integration with the Banco Central del Uruguay API to retrieve and preserve official exchange rates.
BCU APIOperations & Reporting
Operational interfaces, reporting, historical settlements and tools to investigate how a result was produced.
BackofficeIdentity & Access
Active Directory integration with role-based access. No separate user-management model.
Active DirectoryAudit & Traceability
Structured logging, action auditing and settlement history linking source operations to final records.
AuditTechnology
Application
- Angular
- Java + Quarkus
- Metabase
Data
- PostgreSQL
- SQL Server
- BCU API
Infrastructure
- Docker
- Proxmox
- Active Directory
04 / The results
From an operational process to a buildable system.
The discovery produced a shared definition that Cambilex's business and technology teams could use as the foundation for implementation.
Cambilex had an implementation-ready blueprint connecting the operational model with the system required to support it.
For Alabama, the Cambilex engagement is a good example of what technical discovery should accomplish: understand the business process deeply enough to define the software, integrations and architecture needed to make it work.
- BUSINESS DEFINITION
- flows, rules and operational requirements
- SYSTEM ARCHITECTURE
- frontend, backend, data and infrastructure
- INTEGRATION DESIGN
- Dynatech, Creditflow and BCU data
- AUDIT STRATEGY
- traceability from source to settlement