A secure intermediation layer between legacy and digital systems
Financial institutions are experiencing a paradoxical imperative: to open their information systems to comply with PSD2 and offer new services, whilst protecting a banking core that has sometimes been running for 25 years. IT teams are juggling between COBOL mainframes that process critical operations, business applications developed through successive mergers and acquisitions, and regulatory requirements that pile up each year.
The result: the smallest API project with a fintech partner requires six months of coordination between IT, compliance and business units. Developers spend more time mapping dependencies than coding. Security managers block openings due to lack of visibility over flows. Meanwhile, neobank competitors are launching functionalities within a few weeks.
The application estate is not a technical problem to be solved: it is an economic reality to work with, without jeopardising what functions.
This solution belongs to the Data, Master Records & Reporting family.
Challenges holding back your performance
The classic temptation: developing point-to-point connectors between each legacy system and each new requirement. After three years, you have 47 specific interfaces, unevenly documented, maintained by different teams. When a developer leaves the company, part of the knowledge disappears with them. Previous generation ESBs promised to resolve this, but they have often become rigid points themselves: cumbersome to evolve, expensive in terms of licences, dependent on a single vendor.As for off-the-shelf API management platforms, whilst they manage external exposure well, they ignore the complexity of internal systems. One ends up with an attractive façade and fragile pipework behind it.
Our Technical Approach
Our approach relies upon an intermediary layer that acts as a nervous system between your legacy applications and the external world. Rather than proliferating direct connections, we create unified entry points that normalise exchanges: each legacy system exposes its capabilities via stable contracts, independently of its underlying technology.
This layer manages end-to-end encryption, strong authentication, and granular access control: the non-negotiable prerequisites for any regulatory opening. Distributed caching absorbs traffic spikes without taxing your critical systems with every request. Real-time monitoring finally provides consolidated visibility across all flows, not merely those of new APIs.
The architecture is designed for high availability from the outset, not as an option added retrospectively. The result: your business teams can build new services by consuming properly exposed capabilities, without requiring legacy experts for each iteration.
Security & Encryption
Protection of each data flow through mutual authentication (mTLS) and AES-256 encryption.
Unified Entry Points
A single point of entry enabling your applications to request only the data they strictly require.
Distributed Caching
Utilisation of caching systems to relieve the mainframe of repetitive read requests.
High Availability
Distributed architecture ensuring that your services remain accessible even during back-office maintenance.
Real-Time Supervision
Traceability tools enabling immediate identification of slowdowns and auditing of each transaction.
Technical Architecture
Several sources, one master record to arbitrate between them, then analysis: Core HR & Unified Repository and Observatories & Open Data stem from this same chain.
- Security & EncryptionProtection of each data flow through mutual authentication (mTLS) and AES-256 encryption.
- Unified Entry PointsA single point of entry enabling your applications to request only the data they strictly require.
- Distributed CachingUtilisation of caching systems to relieve the mainframe of repetitive read requests.
- High AvailabilityDistributed architecture ensuring that your services remain accessible even during back-office maintenance.
- Real-Time SupervisionTraceability tools enabling immediate identification of slowdowns and auditing of each transaction.
Smooth and frictionless integration
We do not require you to replace your banking core or migrate your databases. The urbanisation layer sits between your existing systems and new use cases: it consumes what exists, it does not require transformation. Deployment begins with a restricted perimeter, typically a specific Open Banking use case, before gradually expanding.
Your teams remain in control of their application estate.
Mapping of flows and dependencies
Audit of existing systems, identification of critical interfaces, documentation of current data flows and known friction points.
Target architecture and pilot use case
Design of the urbanisation layer adapted to your context, selection of a first concrete Open Banking use case to validate the approach.
Progressive deployment and securing
Production deployment of the pilot with real-time supervision, load testing, security validation and regulatory compliance.
Extension and autonomy of teams
Extension to other use cases, transfer of expertise to your teams, comprehensive operational documentation.
Measurable results for your organisation
- Time to production for a new partner API reduced from 6 months to 6-8 weeks
- Zero core banking system modifications for the first 12-18 months of new services
- Consolidated visibility across 100% of incoming and outgoing flows in real time
- Reduction of 60% in incidents related to interfaces between systems
- Demonstrable PSD2/Open Banking compliance during regulatory audits
- Reduced legacy system load by 35% through distributed caching
Clarifying your decision-making
What is the actual risk to our banking core during deployment?
The urbanisation layer does not touch the core banking system: it connects to it read-only, through existing interfaces. Deployment always begins with an isolated test environment, then a non-critical use case in production. Your core system carries on exactly as before.
How do you manage dependency on Clarendis once the system is in place?
The architecture rests on open standards: OAuth 2.0, OpenAPI, standard messaging protocols. Your teams are trained to operate and extend it, and everything is documented. If you decide to take full control back in two years, that is possible without a rewrite.