Enterprise Platform Modernisation
Clomotech served as a technology vendor partner on a major release of an enterprise web platform used by banking institutions to remotely configure and manage financial device networks. The engagement spanned seven engineering improvements across data consistency, observability, performance, security architecture, and platform infrastructure.
Engineering Inside a Live Enterprise Platform
The platform is a large-scale enterprise web application used by banking institutions to remotely configure and manage financial device networks — including ATM machines and banking terminals deployed at customer sites across bank branches. The system spans multiple functional modules and its reliability is critical: configuration errors or data inconsistencies can affect live devices in production banking environments.
Clomotech's engagement was as a vendor partner embedded in the engineering team, contributing to a significant platform release. The release objective was to modernise the underlying architecture, standardise system behaviours across modules, and improve performance and observability throughout the application. Each contribution addressed a production-grade challenge discovered in the existing system — most arising from natural accumulation of technical debt across a maturing platform.
Seven distinct engineering contributions were delivered, ranging from global data consistency across all UI screens to large-scale infrastructure cleanup across dozens of configuration files.
"Engineering inside a mature enterprise platform requires understanding what the system does before changing how it does it. Every contribution carries responsibility for existing behaviour in a live production environment used by banking institutions."
— Engineering PrincipleSeven Areas of Engineering Work
Each contribution addresses a distinct production challenge in the platform — from global data consistency to API infrastructure and configuration management.
Timezone Consistency
Designed and implemented centralised timezone handling across the full platform — UTC backend storage with dynamic user-specific frontend rendering — eliminating data misalignment across ~30 screens.
Centralised Logging
Architected and integrated a structured logging framework across all major APIs and services. Correlation IDs enable end-to-end request tracing through microservices and components.
Pagination & Performance
Shifted from a bulk-load architecture to a paginated data model — optimising backend APIs, refactoring database queries, and updating multiple UI screens to eliminate slow page loads on high-volume data.
Access Control Modernisation
Migrated legacy access control into a modernised application security framework — standardising authorisation logic across all modules with reusable APIs and a single source of truth for access decisions.
YAML Configuration Cleanup
Executed a large-scale structural cleanup of ~70 YAML files across 3 major branches — stripping deprecated keys, merging duplicates, and enforcing a standardised configuration structure.
High-Impact API Engineering
Engineered four new reusable backend services: User Session API, Omni Search API, System Monitor API, and Authorisation Criteria API — unlocking cross-module functionality and operational observability.
User Activity Reporting
Built a comprehensive User Activity Report interface backed by new activity-tracking APIs with paginated and database-optimised data retrieval — providing compliance audit capability and operational insights.
How the Platform is Structured
The platform serves as the control layer between banking institution operators and physical financial devices deployed in the field. The seven contributions map across three architectural layers.
Financial Device Management Platform — Architecture & Contribution Map
Global Data Integrity
Without a unified timezone strategy, the platform displayed inconsistent time data across approximately 30 screens. Each module — Authorisation, Business, and Channel — had independently implemented its own timezone handling. The result was code duplication spread across the codebase and data misalignment when the same events were presented from different parts of the application.
As the platform scaled to serve global banking users across time zones, the problem compounded. A session event logged in UTC but displayed in local time in one module, and in raw UTC in another, creates genuine compliance and audit risk in a financial-infrastructure context.
The solution required two coordinated changes: standardising all backend data storage strictly to UTC, and introducing a consistent frontend architecture that dynamically applies user-specific timezone offsets at render time. Both changes had to be applied consistently across the ~30 affected screens and their corresponding backend APIs.
All data is stored and transmitted strictly in UTC. No module-level timezone conversion occurs before storage. This eliminates ambiguity at the persistence layer and ensures all downstream consumers receive consistent timestamps regardless of which module produced the data.
A consistent rendering architecture dynamically applies user-specific timezone offsets at the UI layer. All ~30 screens and their API contracts were updated to adopt this approach — eliminating the duplicated, inconsistent per-module logic that had accumulated over the platform's lifecycle.
Scope of the refactor
~30 UI screens and their corresponding APIs were updated. The refactor spanned three modules (Authorisation, Business, Channel), requiring coordinated changes across team ownership boundaries to establish the shared timezone strategy.
Why the problem persisted
Module-level timezone handling feels like a local concern until the platform serves users in multiple time zones — at which point inconsistency becomes visible and data alignment breaks down. The cost of not having a shared strategy compounds with platform growth.
Result
~100% consistency in time-based data across all screens. Timezone-related bugs were significantly reduced and the codebase now has a clean, reusable date-time handling path built for global scalability.
Structured Logging and Paginated Architecture
Two related contributions addressed how the platform monitors its own health and handles growing datasets — both areas where the original architecture created operational risk and performance bottlenecks at scale.
Structured Logging with Correlation IDs
Logging was fragmented across different services with no standardised format — making it impossible to trace a single user action as it propagated through the platform's microservice architecture. Production debugging required manually correlating log entries across disconnected log streams with no shared context.
A centralised logging framework was designed and integrated across all major APIs and services. The framework enforces structured log formats with standard fields, and introduces correlation IDs that persist across service boundaries — allowing any request to be traced end-to-end from a single identifier. Legacy services were updated to conform, with the standardisation also enabling seamless integration with modern monitoring tooling.
Paginated Data Architecture
Several high-volume screens were loading entire datasets at once — causing slow page load times, high browser memory consumption, and poor user experience. As data volumes grew, the performance degradation was non-linear: a doubling of data could cause a far more than proportional increase in load time.
The architecture was shifted from bulk-load to a paginated data model. Backend APIs were updated to support paginated queries — returning only the required data chunk per request. Database queries were refactored for improved execution efficiency, and multiple UI screens were redesigned to support paginated navigation and dynamic loading patterns.
Access Control and Audit Capability
Two contributions addressed the security and governance posture of the platform — the first rearchitecting how access decisions are made and enforced, the second building the visibility layer into how the platform is actually used.
The legacy access control system had accumulated inconsistencies across modules. Different areas of the application enforced authorisation differently — limiting the ability to introduce new permission models and creating maintenance burden at every new feature release. Changing a permission rule required coordinated updates across multiple codebases with risk of inconsistent enforcement.
All authorisation logic was migrated into a modernised Application Security framework — standardising access checks across every module and introducing highly reusable authorisation APIs. The result is a single source of truth for access decisions that any module can reference, rather than each module independently maintaining its own authorisation logic.
Authorisation logic duplicated and independently maintained per module. Inconsistent enforcement across the application. New permission roles required changes across multiple codebases, with risk of divergence.
Single authorisation framework with reusable APIs shared across all modules. Consistent enforcement throughout. New access rules are defined once and propagate uniformly — a single change at the framework level.
The platform had no visibility into user behaviour — no audit trail, no activity reporting, no compliance record. In an enterprise platform managing configuration of banking devices, the absence of auditing creates regulatory exposure and makes operational analysis impossible.
A comprehensive User Activity Report interface was built and integrated with newly developed backend APIs specifically designed for activity tracking. To handle the high volume of activity logs without performance degradation, all data retrieval is paginated and database-optimised — ensuring the audit layer remains a net positive rather than a performance burden.
Single source of truth for access
Centralised authorisation APIs mean that access policy changes are made once and apply uniformly across every module. Previously, updating a permission model required coordinating changes across teams — creating risk of inconsistent enforcement in the interim.
Audit in a banking context
A platform managing remote configuration of ATM machines and banking terminals has real compliance obligations. User activity reporting isn't optional — it's a governance requirement when actions taken in the platform have direct consequences on live banking infrastructure.
Result
The platform now has a stronger, centrally managed security posture. Authorisation duplication is eliminated. Stakeholders have audit and reporting capability — providing both compliance evidence and operational insight into platform usage patterns.
Configuration Cleanup and API Engineering
Two contributions addressed the platform's operational foundation — cleaning up accumulated configuration drift and engineering the missing API infrastructure that enables cross-module capability.
~70 Files, 3 Branches
Over time, the system's YAML configuration files had accumulated redundant, outdated, and duplicate entries across branches — causing environment-specific inconsistencies and increasing deployment risk. The cleanup was a large-scale structural operation requiring rigorous validation throughout.
Mapped all ~70 YAML files across all 3 major branches — identifying redundant entries, outdated keys, and configuration drift between environments.
Established and enforced a consistent configuration schema — a single reference structure that all environments and branches must conform to going forward.
Removed all deprecated configuration keys no longer consumed by the application, reducing noise and preventing future confusion about active vs. inactive settings.
Collapsed duplicate keys that had diverged across branches into single authoritative entries — eliminating the source of environment-specific inconsistencies.
Rigorous validation confirmed no existing environment configurations were broken. Each branch was verified against its deployment target before the cleanup was finalised.
Four New Platform Services
As feature complexity grew, the platform lacked the centralised backend services needed for new cross-module capabilities. Four high-impact, reusable APIs were engineered from scratch — each addressing a gap that had previously forced per-module workarounds.
Unified, secure session management across the platform — replacing inconsistent per-module session handling with a single authoritative service.
Cross-module search from a single endpoint — enabling operators to search across all platform modules without navigating to each one individually.
Health metrics for both cloud and local instances — giving operations teams real-time visibility into system status across all deployment environments.
Dynamic, flexible access control rules — enabling granular permission models to be defined and enforced without hardcoding logic into individual modules.
The Platform Engineering Stack
Need engineering capacity for a major platform release?
Whether it's architectural modernisation, performance engineering, or API infrastructure — we've delivered these at production scale as a trusted engineering partner.