Open Source Technology in Telecom and Banking: From Infrastructure to AI

Introduction

Telecom operators and banks operate some of the most complex technology environments in the enterprise world. Telecom providers manage network infrastructure, subscriber records, billing systems and operational telemetry across geographically distributed environments. Banks coordinate payments, customer information, risk systems, regulatory reporting and increasingly demanding AI workloads.

Both industries need reliable technology, interoperability and strong controls. Yet much of the infrastructure required to deliver these capabilities does not differentiate one business from another. A secure data pipeline, a container platform or a policy engine may be essential to operations, but the competitive advantage comes from how the organization uses that infrastructure to improve customer experience, manage risk or deliver new services.

This is where open source technology has a meaningful role. Open source components can reduce dependence on proprietary implementations, support portability and give engineering teams access to widely adopted frameworks. In telecom, that can mean cloud-native network software and centralized data platforms. In banking, it can mean shared interoperability standards, distributed AI infrastructure and event-driven architectures.

However, the availability of open source software does not eliminate the work of integration, security, maintenance or compliance. Enterprises still need to establish ownership, enforce controls and demonstrate how their data and systems operate.

Edgematics explores the broader commercial argument in Open Source Technology: The Enterprise Advantage Beyond Cost Savings. In telecom and banking, the next question is more specific: where can open technologies deliver practical value, and what governance capabilities make them suitable for regulated production environments?

TL;DR

• Telecom: Open RAN ecosystems, Kubernetes-based delivery and policy-driven data hubs support interoperability, faster software releases and more efficient operations.
• Banking: Open source infrastructure can reduce duplicated engineering effort, support interoperable financial applications and improve the utilization of AI computing resources.
• Documented results: Nokia reported saving several hundred testing hours per release, a telecom data-hub implementation reported approximately 50% lower operational data management costs, and China Merchants Bank reported over 60% lower inference cost per million tokens in its specific deployment.
• Edgematics case studies: Work with telecom and banking organizations demonstrates how data quality, integration, lineage and governance support reliable operations and AI.
• The critical requirement: Open source is not a substitute for governance. Regulated enterprises still need clear ownership, traceability, security controls and an accountable maintenance model.

Why Open Source Fits Telecom and Banking

The business case for open source in regulated industries begins with a distinction between shared infrastructure and differentiated capabilities.

A bank does not necessarily gain a competitive advantage by developing its own container orchestration system. A telecom operator does not need to independently recreate every data processing component required to manage network information. Both can benefit from proven technologies that allow engineering teams to concentrate on capabilities that matter more directly to customers and business outcomes.

The FINOS introduction to open source software explains the role of open source in financial services and the importance of organizational readiness. Similarly, the FINOS 2025 report on open source in financial services examines how financial institutions use shared technology to reduce duplicated effort and direct investment toward differentiating capabilities.

Three characteristics make the model particularly relevant to both sectors.

Heterogeneous technology estates. Telecom and banking environments contain legacy systems, specialized applications, multiple vendors and infrastructure introduced through acquisitions or modernization programmes. Open interfaces and portable technologies can help connect these environments without requiring a complete replacement.

Operational and regulatory pressure. Both sectors must manage sensitive information, service continuity and audit requirements. Open source can provide flexible technical components, but those components must operate within enterprise security, privacy and governance controls.

Increasing AI investment. Telecom operators use AI for network optimization, predictive maintenance, customer experience and fraud detection. Banks invest in fraud analytics, customer personalization, risk analysis and AI infrastructure. Both need reliable data and efficient computing environments to move from experimentation into production.

The benefits depend on implementation. An open component that creates more integration overhead than it removes may not improve the business case. The objective is to select technologies that simplify the architecture, support interoperability and remain practical to operate over time.

Open Source Technology Use Cases in Telecom

Telecom operators have several opportunities to use open technologies across network infrastructure, software delivery, data management and real-time analytics.

1. Open RAN and Multi-Vendor Network Infrastructure

Traditional radio access networks have often relied on tightly integrated vendor solutions. Open RAN aims to introduce greater openness and interoperability through defined interfaces and more disaggregated network architectures.

Open source projects contribute software implementations and development environments that support this ecosystem. Examples include the O-RAN Software Community, OpenAirInterface and srsRAN. A peer-reviewed survey of Open RAN and open source approaches discusses their role in enabling research, experimentation and more flexible network architectures.

For telecom operators, the potential business value lies in greater choice. They can evaluate components from different suppliers, develop specialized capabilities and reduce dependence on a single vendor for every part of the network.

However, open RAN does not mean that every network component is open source, nor does an open interface guarantee seamless interoperability. Operators still need to validate performance, security, integration and operational compatibility across the complete network.

The practical takeaway is to separate interface standards, software licensing and deployment architecture when evaluating a multi-vendor strategy. Each affects technology flexibility in a different way.

2. Kubernetes and Infrastructure-Agnostic Software Delivery

Telecom vendors deliver software into operator environments that may differ considerably in their underlying infrastructure. A product that works in one deployment may require additional testing or adaptation before it can run in another.

Kubernetes and the broader cloud-native ecosystem help address this challenge by providing a consistent orchestration environment for containerized applications.

The CNCF Nokia case study documents how Nokia used Kubernetes to separate application concerns from the underlying infrastructure. By testing the same software artifact independently of individual target environments, Nokia reduced duplicated testing and reported saving several hundred hours in every release.

The result is specific to Nokia’s implementation, not a universal saving for every telecom operator. Its architectural lesson is more broadly useful: consistent deployment environments can reduce integration friction, identify defects earlier and allow engineering teams to focus on application functionality instead of repeatedly adapting to infrastructure differences.

The same principle applies when operators modernize legacy environments. Containerization alone does not remove architectural dependencies, but it can make application delivery and operations more consistent when supported by suitable automation, testing and governance.

3. Centralized Data Hubs and Policy-as-Code

One of the most relevant use cases sits behind the network itself: consolidating operational data from fragmented systems and enforcing consistent rules before that data reaches downstream applications.

Network data may arrive from multiple equipment vendors, operational support systems, billing platforms and service applications. Differences in schemas, identifiers and business rules can make a common view difficult to maintain. These inconsistencies also limit automation because downstream applications cannot reliably interpret the information they receive.

A CNCF case study of an Infosys-led implementation for a European telecom operator describes a centralized Network Data Store built on a Kubernetes-based architecture. The implementation used Open Policy Agent (OPA) and Rego-based policies to validate and transform data across network domains.

Separating policies from application code allowed rules to change without requiring the corresponding application logic to be rewritten or redeployed each time.

The case study reports approximately 50% lower operational data management costs. It also identifies an estimated improvement of approximately 80% in the data quality index, alongside improvements in data consistency and service management.

These are results reported for that particular implementation, not guaranteed outcomes for all operators.

The architectural principle is nevertheless important. A reusable policy layer can help organizations enforce common data rules across heterogeneous systems, while a centralized data hub provides consistent information to analytics and automation applications.

This is also where telecom data strategy becomes closely connected to open source adoption. Technology choices should support the way network, customer and operational data will be governed and used, rather than creating another isolated platform.

4. Real-Time Network and Customer Analytics

Telecom systems generate continuous streams of events, including network performance measurements, subscriber activity, billing events and service changes. Batch reporting remains useful for many purposes, but time-sensitive decisions often require information to be processed while it is still relevant.

Open source technologies such as Apache Kafka and Apache Flink can support event ingestion and stream processing. Their role is not simply to move larger volumes of data. They allow operators to build workflows that react to changing conditions.

Relevant applications include network congestion detection, service quality monitoring, proactive maintenance, fraud scoring and customer experience management.

Edgematics’ article on Telecom Streaming Analytics: Act on Data in Real Time explores how real-time data can support these operational decisions, including proactive retention and network assurance.

The business value depends on data freshness, quality and the action that follows the signal. A streaming pipeline that rapidly delivers inconsistent information will not produce dependable decisions.

Open source components therefore need to operate alongside schema management, quality checks, observability and clearly defined downstream responsibilities.

5. Data Integration During Network Expansion and M&A

Telecom expansion often creates another challenge: bringing acquired infrastructure and operational records into an existing network inventory without disrupting ongoing operations.

Edgematics’ AI-powered inventory migration platform for a leading UK fibre provider’s M&A rollout illustrates this challenge.

The engagement used a PurpleCube AI and Python integration layer, a conformed data model and automated API-based migration into the target operational support system. The approach separated the complexity of incoming source systems from the target environment and incorporated metadata management for traceability and error handling.

The reported outcome was four times faster onboarding of accurate inventory data, with end-to-end lineage from source systems to active inventory records.

This is an Edgematics integration and data governance case study, not a claim that open source alone delivered the result. It demonstrates a requirement that remains essential in open, proprietary or hybrid architectures: components must exchange consistent data through controlled interfaces, and the organization must be able to trace what entered the target system.

A related trusted data foundation case study for a UK fibre provider describes how pipeline-embedded data quality controls help identify duplicates and inconsistencies before they affect downstream systems.

These examples show that architecture flexibility creates business value when paired with repeatable integration and governance practices.

Open Source Technology Use Cases in Banking

Banks use open source for different but related reasons. Shared technologies can support infrastructure modernization, financial application interoperability, regulatory data management and AI workloads without requiring each institution to develop every technical capability independently.

1. Shared Components and Financial Application Interoperability

Banks operate complex application environments, from customer-facing platforms to internal trading, payments, risk and compliance systems. Integrating these systems can require considerable engineering effort, particularly when applications use different interfaces or proprietary integration methods.

FINOS supports collaboration on financial services technologies and shared standards. One example is FDC3, which focuses on interoperability between desktop applications used in financial services.

The FDC3 2.0 release announcement from the Linux Foundation describes efforts to improve interoperability across the financial services ecosystem.

FDC3 is an interoperability standard, not simply a software package to install. Its significance is that common interface conventions can reduce the need for every organization to build a separate integration mechanism for each application combination.

The same principle applies to non-differentiating infrastructure such as data processing, monitoring and policy enforcement. Standardized, reusable components can reduce duplicated engineering work and give banks more flexibility in how they integrate systems.

That flexibility does not remove the need to review licensing, support arrangements, security requirements or the suitability of each component for its intended workload.

2. Kubernetes and AI Infrastructure Efficiency

As banks introduce more AI workloads, infrastructure utilization becomes a business concern. Model training, fine-tuning and inference can compete for accelerators, storage access and compute resources, particularly when different teams maintain separate environments.

China Merchants Bank provides a documented example of how cloud-native infrastructure can address this problem.

In its CNCF case study on unifying AI training and inference, the bank described a Kubernetes-based platform using technologies including Kueue, KEDA, Prometheus, HAMi and Fluid, alongside its distributed training and inference stack.

The redesigned platform brought heterogeneous accelerator resources under a unified management approach and coordinated scheduling, inference scaling, resource allocation and access to datasets and model weights.

The reported results were significant:

• Average accelerator compute utilization increased from 35% to more than 60%.
• Inference cost per one million tokens, counting input and output, fell by more than 60% under comparable model and service conditions.
• A five-tenant configuration for low-rank adaptation training increased training density fivefold by allowing tenants to share one base-model instance.

These results reflect China Merchants Bank’s own platform design and workloads. They should not be treated as a forecast for every bank deploying Kubernetes or the same open source components.

The broader lesson is that AI economics depend on orchestration, scheduling, data access and resource utilization, not just the model selected. Open source infrastructure can give banks building blocks to improve those factors, provided they have the skills and operating model to run the platform effectively.

3. Event Streaming and Transaction Data

Transaction processing and financial analytics often need to combine operational events with historical information. Event-driven architectures can help separate transaction producers from downstream consumers, allowing reconciliation, analytics and monitoring processes to operate without requiring every application to communicate directly with every other application.

Apache Kafka is one option for event streaming. Its official documentation describes its core capabilities and configuration options for distributed event streams.

In a banking environment, event streams can support transaction monitoring, fraud analysis, operational alerts and downstream data integration. Relational databases such as PostgreSQL may complement such architectures where applications need structured storage and transactional processing.

However, using a stream of events does not automatically create a compliant audit record. Retention, access control, event integrity, reconciliation and evidence requirements must be designed explicitly. The organization also needs to understand which system is authoritative for a particular transaction or financial record.

The appropriate design depends on the banking workload, its consistency requirements and the controls required by the institution.

4. SupTech and Shared Regulatory Capabilities

Supervisory technology, or SupTech, uses technology and data-driven methods to support regulatory supervision. It may involve reporting automation, anomaly detection, risk analysis and new methods of processing regulatory information.

Open and shared code can support collaboration and reduce fragmentation, particularly when multiple organizations need similar technical capabilities. However, each institution and supervisory authority still needs to define how data, models, policies and outputs are governed.

The Bank for International Settlements paper on generative AI in SupTech discusses the potential role of shared codebases in reducing fragmented and siloed approaches to supervisory technology.

For banking data teams, this connects directly to data quality, lineage and the ability to explain how a reported figure was produced. The challenge is not resolved simply by adopting an open tool. Data definitions, transformations and ownership must remain consistent across systems.

Edgematics examines these issues in From Regulatory Reporting to SupTech Readiness, including the importance of governed data and traceable information for increasingly data-driven supervisory processes.

5. Governed Customer Data and AI-Driven Banking

Customer analytics and personalization require banks to connect information across customer records, interactions, transactions and service channels. If these data assets remain fragmented, models may work with incomplete information or inconsistent identities.

Edgematics’ Data Governance Centre of Excellence case study for a leading Pan-American bank describes a programme that established governance and quality capabilities, standardized data at ingestion and introduced custom connectors and migration practices.

The engagement reported faster fraud detection, stronger compliance reporting and lower operational costs through AI-powered automation. The case does not attribute these outcomes to open source alone. Instead, it shows the data quality, ownership and governance work required to make complex banking data more usable.

A related UAE-based banking enterprise case study describes the use of analytical master data management, customer journey analytics and a data governance framework to support AI-driven personalization and more informed decision-making.

Together, these cases illustrate a consistent principle: AI capabilities depend on the quality and governance of the information underneath them, irrespective of whether the supporting software is open source, proprietary or a combination of both.

Telecom and Banking: A Side-by-Side View

The technologies and workloads differ, but the architectural problem is similar: connect multiple systems, enforce consistent controls and make information reliable enough to support business decisions.

What Regulated Enterprises Must Govern Before Adopting Open Source

Open source adoption is a technology decision, but operating it safely is an enterprise responsibility.

The governance model should cover more than the code itself. It should also address the data that flows through the architecture, the dependencies that keep the system operating and the decisions made by downstream applications.

Licensing and Dependency Management

Maintain an inventory of the components used in critical systems, including dependency versions and applicable licences. Software bills of materials can help teams understand what an application contains and investigate the impact of newly disclosed vulnerabilities.

Licence obligations vary, so legal review should account for how components are combined, modified and distributed.

Security and Maintenance

Define how teams discover vulnerabilities, prioritize patches, test upgrades and respond to unsupported components. Assess the health of project communities and determine whether critical dependencies need additional support or a replacement plan.

Data Quality, Lineage and Access

Data moving between open source components needs consistent controls. Quality rules should be enforced at appropriate points in the pipeline, lineage should connect source records to downstream outputs, and access policies should protect sensitive information.

Edgematics’ article on Data Quality as a Revenue Problem explains why data quality has consequences beyond technical operations. In telecom and banking, inaccurate data can affect network decisions, fraud signals, customer records and regulatory reporting.

The same logic applies to governance architecture. Layers of Data Governance examines how metadata, lineage, quality and ownership work together to support trust in enterprise data.

AI and Model Governance

Where open source components support AI, governance needs to extend to the datasets, model versions, configuration and prompts involved in the workload. Enterprises should document provenance, enforce access controls, evaluate model performance and maintain evidence for material changes.

For autonomous workflows, additional controls may be needed around permitted actions, human review and audit trails. The more a system can do independently, the more important it becomes to define what it may access and how its actions can be reviewed.

Operational Ownership and Total Cost

Open source may reduce certain licence costs, but it does not remove the need for engineering and support. Organizations should assign clear owners for critical components, allocate responsibility for upgrades and budget for the expertise needed to keep systems reliable.

A sensible adoption decision weighs the entire operating cost against the benefits of reuse, portability and flexibility.

How to Start: A Practical Adoption Framework

Rather than introducing several technologies at once, telecom operators and banks should begin with one material business or operational problem.

1. Choose a non-differentiating capability. Identify a layer where open technologies can reduce duplicated effort or improve interoperability, such as data ingestion, container orchestration, policy enforcement or event streaming.

2. Map dependencies and constraints. Document upstream and downstream integrations, data sensitivity, performance requirements, licensing obligations and operational risks.

3. Define ownership and controls. Decide who maintains the technology, who approves changes, which quality and security checks apply, and how incidents will be handled.

4. Pilot one workload. Test the selected component in a bounded use case. Measure integration effort, reliability, performance, remediation effort and total cost, rather than relying solely on vendor or community benchmarks.

5. Prove governance before expanding. Verify that data quality rules, access policies, lineage and audit evidence work across the relevant systems. Once the controls are proven, expand the architecture to additional workloads.

The important principle is to evaluate open source as part of an operating environment, not as an isolated software download.

Our Perspective: Open Technology Still Needs Governed Data

Across telecom and banking, the hardest part of modernization is often not finding a capable technology. It is making the surrounding systems and information work together consistently.

Open source can give organizations the flexibility to combine technologies, adapt architectures and reduce reliance on proprietary implementations. But every additional component introduces integration and ownership decisions. If data quality varies across acquired systems or lineage stops at application boundaries, the organization can still struggle to explain the outcomes produced by its platform.

Edgematics’ work with a leading US wireless carrier focused on modernizing the data ecosystem while strengthening accuracy, privacy controls and compliance. Its telecom data transformation case study illustrates why these controls need to operate inside data workflows rather than as checks performed only after processing.

The same principle applies to banks. The Pan-American bank engagement demonstrates how governance structures, standardized data and lineage support fraud detection and compliance reporting across a complex environment.

These are not claims that open source itself delivered those outcomes. They are examples of the integration and governance requirements that remain essential when an enterprise combines technologies from multiple sources.

Our approach brings these concerns together through Data Engineering & Governance and AI and Machine Learning capabilities. At the platform level, PurpleCube AI supports unified data orchestration across heterogeneous environments, while Axoma addresses governed enterprise agentic AI workflows.

The objective is to help enterprises retain technological flexibility while making data flows, controls and AI-enabled processes understandable and accountable.

Conclusion: Open Source Creates Opportunity, Governance Makes It Sustainable

Open source technology has a practical role in telecom and banking because both industries need reliable infrastructure, interoperable systems and efficient ways to support growing data and AI workloads.

In telecom, the opportunities span Open RAN, cloud-native software delivery, policy-driven data hubs, network analytics and integration during infrastructure expansion. In banking, shared application standards, AI infrastructure, transaction analytics and supervisory technology demonstrate how open components can support important enterprise capabilities.

The reported results from Nokia, the Infosys-led telecom implementation and China Merchants Bank show that benefits can be measurable, from lower testing effort to better infrastructure utilization and lower unit inference costs. Those results remain specific to the environments in which they were achieved.

For any enterprise, the decision should therefore be guided by the workload, the architecture and the operating model. Open source is most useful when organizations can integrate it effectively, maintain it responsibly and connect it to the governance requirements of their industry.

The real advantage is not simply access to open technology. It is the ability to use that technology to build reliable services, trusted data and responsible AI capabilities without creating unnecessary complexity.

Frequently Asked Questions

What are the common open source use cases in telecom?

Common use cases include Open RAN-related software, Kubernetes-based application delivery, centralized data hubs, policy-as-code, event streaming and real-time network analytics. The value depends on interoperability, integration quality and operational management.

How do banks use open source technology?

Banks use open source across infrastructure, data engineering, application interoperability, event streaming, analytics and AI computing. Shared standards can reduce duplicated integration work, while cloud-native tools can help teams coordinate computing resources more effectively.

Is Open RAN the same as open source?

No. Open RAN is an architectural and industry-standardization approach that promotes openness and interoperability across radio access network components. Open source projects contribute software to this ecosystem, but the terms do not mean the same thing.

Is open source suitable for regulated industries?

Yes, provided the technology fits the workload and the organization can manage its risks. Regulated enterprises still need licensing reviews, vulnerability management, data governance, access controls, audit trails and clear operational ownership.

Is open banking the same as open source banking technology?

No. Open banking concerns controlled sharing of financial data through APIs, subject to applicable consent and regulatory requirements. Open source describes how software is licensed and developed. Open source components may be used to build open banking solutions, but they are distinct concepts.

How does Edgematics help telecom and banking organizations adopt technology for AI?

Edgematics supports data strategy, engineering, governance, quality, lineage and AI capabilities. Its work includes telecom data transformation and migration, banking governance programmes, unified data orchestration through PurpleCube AI and governed agentic workflows through Axoma.

Where We Can Help

Open source can provide the building blocks for more flexible telecom and banking environments. Making those building blocks reliable requires sound architecture, trusted data, repeatable controls and a clear operating model.

Edgematics works with regulated enterprises on data engineering and governance and AI initiatives built on governed data. We help organizations connect fragmented systems, improve data quality, strengthen lineage and prepare data environments for analytics and AI.

Explore Edgematics’ capabilities to assess where open source technologies can support your modernization priorities and where governance and integration need greater attention.

Edgematics Group