From KCBP to KOCA-LDP: The 30-Year Evolution of Kingdom Technology's Middleware

📌 Core Argument: The evolution of Kingdom Technology’s middleware is essentially an industrial history of China’s securities trading systems transitioning from “branch-level” to “enterprise-level”, from “centralized trading” to “distributed low-latency ultra-fast trading”, and from “IOE dependency” to “full-stack IT Application Innovation (Xinchuang)”.

This main thread can be clearly divided into five stages: the introduction of self-developed middleware into securities trading systems around 1998 → KCBP/KCXP becoming the cornerstone of domestic financial middleware in 2003 → the initiation of the 5th-generation core trading and settlement technology platform in 2017 → the release of the KOCA cloud-native platform in 2019 → and the iteration of the KOCA-LDP distributed low-latency platform to V2.0 in 2023.

Every leap in each stage was not an isolated technical upgrade, but the result of the combined effects of brokers’ business demands, regulatory environments, hardware computing power, and the Xinchuang (IT Application Innovation) strategy. Understanding this evolutionary path means understanding the complete trajectory of China’s FinTech self-reliance and controllability over the past 30 years.

I. The Starting Point: Around 1998, Introduction of Self-Developed Middleware into Securities Trading Systems

#

1.1 The Era Background

#

In 1998, Kingdom Technology was officially established. At that time, China’s securities trading systems were mostly dominated by a “branch-level” architecture—each branch independently deployed a set of trading systems, resulting in severe data silos, difficulties in cross-branch trading, and poor system scalability.

In the early 1990s, Kingdom launched an early securities trading counter—a simplified relational database management system. But the real turning point occurred around 1998: Kingdom took the lead in the industry by introducing self-developed middleware technology, pioneering the third-generation securities trading system with a three-tier C/S architecture, which significantly improved business processing capabilities and security features.

The Revolutionary Significance of the Three-Tier C/S Architecture:

• Presentation Layer (Client): Responsible for the user interface.
• Middle Layer (Middleware + Application Logic): Responsible for transaction processing and communication exchange.
• Data Layer (Database): Responsible for data persistence.

The introduction of the middle layer was a key step for the securities trading system to move from “branch-level” to “enterprise-level”—it decoupled the transaction processing logic from the front-end interface and the back-end database, laying the architectural foundation for subsequent nationwide centralized trading.

1.2 The First Generation of Centralized Securities Trading Systems

#

To achieve the goal of 100% localization of China’s securities trading systems and middleware, Kingdom independently developed the transaction middleware KCBP and communication middleware KCXP, both with independent intellectual property rights, and built China’s first generation of centralized securities trading systems.

💡 Historical Positioning: In the late 1990s, foreign middleware (such as IBM WebSphere, Oracle Tuxedo, ActiveMQ, etc.) almost monopolized the Chinese market. Kingdom’s choice to develop middleware independently was not just a technical decision by a single company, but the starting point of autonomous control for China’s financial infrastructure.

II. The Cornerstone Era: KCBP/KCXP Forging a National Brand for Financial Middleware

#

2.1 KCBP: Kingdom Core Business Platform

#

KCBP (Kingdom Core Business Platform) is a transaction management middleware developed by Kingdom, belonging to scalable, high-performance transaction middleware for enterprise critical businesses.

Core Functions:

• Managing various computer resources (e.g., database connection resources, communication resources).
• Providing a runtime framework for applications to ensure high system efficiency.
• Managing transaction integrity and scheduling application execution.

Technical Features:

• Supports multiple OS platforms including UNIX, NT, and Linux.
• Supports cross-platform transmission in heterogeneous systems; messages support both text and binary formats.
• Enables transparent cross-hardware platform conversion of C language structured data types.
• Shields differences in hardware platforms, operating systems, databases, and networks.
• Supports various databases like IBM DB2, Oracle, Microsoft SQL Server, Sybase, and MySQL.
• Simplifies user system complexity by increasing its own internal complexity.

Architectural Form:

graph LR
    A[KCBP Server] <-->|KCXP Queue Tech<br/>Fuzzy Load Balancing Cluster| B[KCXP Communication Platform]
    B <--> C[KCBP Client]

The KCBP server forms a fuzzy load-balancing cluster through KCXP queue technology. The number of KCBPs participating in the cluster computing can be dynamically and transparently adjusted, making it a natural computing grid.

2.2 KCXP: Kingdom Communication Exchange Platform

#

KCXP (Kingdom Communication Exchange Platform) is a high-performance, highly available communication middleware platform independently developed by Kingdom, based on message queue technology.

Core Functions:

• Transmits messages across different network protocols, computer systems, and applications.
• Provides Native APIs and supports the JMS specification.
• Establishes network communication channels for reliable data transmission, ensuring no duplicate or lost data.

Technical Features:

• Supports multiple network protocols: TCP/IP, SNA, IPX/SPX, UDP, NetBios, etc.
• Supports cluster applications with robust security mechanisms.
• Ensures reliable message delivery in heterogeneous system environments with different network protocols.
• Runs on Linux, Windows, AIX, and other operating systems.

2.3 “Small Core, Broad Extension”: The Architectural Paradigm of Centralized Trading

#

After the millennium, nationwide centralized trading became almost the only choice for the securities industry. Kingdom’s “New Generation Centralized Trading System” deployed KCXP at the communication layer and KCBP at the core business processing layer, forming a cross-platform centralized trading system:

graph TD
    A[Client Layer] --> B[KCXP Communication Layer<br/>Message Queue / Protocol Conversion / Reliable Transmission]
    B --> C[KCBP Business Layer<br/>Transaction Processing / Concurrency Control / Transaction Management]
    C --> D[Database Layer<br/>Oracle / DB2 / MySQL, etc.]

This architecture features the “Small Core, Broad Extension” system characteristic:

• Small Core: KCBP handles core transaction logic with concise, stable, and reliable code.
• Broad Extension: KCXP connects various peripheral systems (clearing, risk control, market data,资讯, etc.).

2.4 Establishing the Cornerstone Status & The Yu’e Bao Case

#

Relying on efficient concurrent processing capabilities, KCBP/KCXP became a solid technical foundation for core business systems. They still hold a very high market share in China’s securities market today, steadily supporting the secure operation of trillion-level trading volumes in the A-share market.

Landmark Case - Yu’e Bao: In late September 2013, Yu’e Bao Phase II went live. The solution still utilized Kingdom’s mature, IP-owned middleware KCBP and KCXP, and the Phase II TA direct sales system was entirely migrated to the cloud. This was the first true De-IOE (Decoupling from IBM, Oracle, EMC) solution in the financial industry. This marked a breakthrough in the application of KCBP/KCXP middleware in the asset management sector—extending from securities trading to broader scenarios like fund direct sales and third-party payments.

💡 Historical Significance of the Cornerstone Era: KCBP/KCXP are not just Kingdom’s technical products; they are the foundational works of China’s national brand for financial middleware. They proved that domestic middleware could replace foreign products like IBM and Oracle in core financial scenarios, planting the first seed for subsequent full-stack Xinchuang.

III. The Cloud-Native Era: Release of the KOCA Open Cloud-Native Platform

#

3.1 Evolution Drivers & KOCA Positioning

#

As the business complexity carried by capital market IT systems surged, in 2017, Kingdom began R&D on the 5th-generation core trading and settlement technology platform based on a “converged” architecture.

In 2019, the KOCA (Kingdom Open Cloud-native Architecture) open cloud-native platform was officially released. As Kingdom’s 4th-generation JAVA-based platform in its tech history, its positioning is as follows:

• The overarching term for Kingdom’s new-generation distributed cloud-native tech architecture for the digital era.
• Kingdom’s unified technology platform and brand.
• The foundational tech platform comprehensively empowering the digital transformation of the financial industry.

3.2 The Seven Core Characteristics of KOCA

#

3.3 KOCA Product Matrix

#

KOCA is not a single product but a complete tech middle-platform matrix:

• Dev Platform: KOCA-LCP (Low-code), KOCA-DEVOPS.
• Runtime Platform: KOCA-MXP, KOCA-DIDA, KOCA-LDP (Low-Latency Platform), KOCA-HARE, KOCA-KGMS, KCBP/KCXP (Legacy but evolving), KOCA-MDB, etc.
• Ops Platform: KOCA-AMO.

💡 Strategic Significance: The release of KOCA marks Kingdom’s upgrade from a “middleware vendor” to a “financial-grade cloud-native tech platform vendor”.

IV. The Ultra-Fast Era: The Rise of the KOCA-LDP Distributed Low-Latency Platform

#

4.1 Evolution Drivers: Time is Money

#

According to securities trading rules, continuous auction follows the “price priority, time priority” matching principle. Traditional KCBP architecture faced challenges in microsecond-level ultra-fast trading scenarios: high middleware layer overhead, database I/O bottlenecks, and the inability to achieve microsecond-level end-to-end latency.

4.2 Architecture Design of KOCA-LDP

#

Based on the KOCA platform, Kingdom independently developed the LDP Distributed Low-Latency Platform:

graph TD
    A[KGMS Microservice Gateway<br/>Unified Access / Protocol Conversion / Fast Routing] --> B[HARE High-Speed Message Bus<br/>Distributed / Agentless / Microsecond-level]
    B --> C[KMDB In-Memory Database<br/>Full In-Memory Trading / Persistence]
    C --> D[KMAP Low-Latency App Platform<br/>Full C/C++ Stack Implementation]

4.3 Four Core Components & Performance Metrics

#

The KOCA-LDP V2.0 version upgraded key technologies across components, placing overall performance in the industry’s first tier:

💡 Fundamental Shift in Architectural Philosophy: The KCBP era was “application middleware + relational database”, pursuing stability and cross-platform capabilities; the KOCA-LDP era is “full in-memory + full C/C++ stack + hardware acceleration”, pursuing extreme low latency. The former solved “enterprise-level centralized trading”; the latter solved “microsecond-level ultra-fast trading”.

V. The Implementation Era: FS2.5 and Full-Stack Xinchuang

#

5.1 FS2.5: The Next-Gen Core Trading System

#

Kingdom’s FS2.5 is positioned as the new-generation securities core business system. Built on KOCA, it adopts a microservices architecture and containerized packaging.

Performance Leap Comparison:

5.2 Xinchuang Adaptation & Representative Cases

#

KOCA-LDP fully supports Xinchuang (X86/ARM dual architectures, domestic OS, domestic databases). Among the top 20 brokers in brokerage business, Kingdom’s core trading and settlement system holds a market share of over 50%.

• CICC Wealth Securities: FS2.5 successfully went live, achieving the first overall implementation case and “Xinchuang upon launch”.
• Huaxing Securities: Fully localized single-track launch of Kingdom’s FS2.5, achieving pure domestic operation from application software to foundational hardware and software.

VI. Three Underlying Logics Behind the Evolution

#

6.1 Business Driven: From “Stable Operation” to “Ultra-Fast Trading”

#

The core demand in the KCBP era was “stable operation” (trillion-level volumes must not fail or stop). The core demand in the KOCA-LDP era is “ultra-fast trading” (with the rise of quant and HFT, microsecond latency is the core competitiveness).

6.2 Tech Driven: From “Cross-Platform” to “Low Latency”

#

KCBP’s core value was “cross-platform” (shielding heterogeneous environment differences). KOCA-LDP’s core value is “low latency” (full in-memory, lock-free, hardware acceleration).

6.3 Strategy Driven: From “De-IOE” to “Full-Stack Xinchuang”

#

graph LR
    A[De-IOE<br/>2013 Yu'e Bao on Cloud] -->|Break foreign monopoly| B[Cloud-Native<br/>2019 KOCA Release]
    B -->|Open-source + Targeted Open-source| C[Full-Stack Xinchuang<br/>2023 KOCA-LDP V2.0]
    C -->|Domestic CPU/OS/DB/Middleware| D[Full Autonomous Control]

VII. The Relationship Between KCBP and KOCA-LDP: Inheritance, Not Replacement

#

Many mistakenly believe KOCA-LDP is a “replacement” for KCBP, which is the biggest misunderstanding of Kingdom’s middleware evolution.

graph TD
    A[KCBP/KCXP Cornerstone<br/>Communication / Business Layer] -->|Inherit| B[KOCA Cloud-Native Middle Platform<br/>Unified Tech Matrix]
    B -->|Extend| C[KOCA-LDP Low-Latency Platform<br/>HARE/KMDB/KGMS New Components]

• KCBP/KCXP were not abandoned; they continue to serve as the “stable operation” components in the KOCA matrix, supporting traditional centralized trading.
• KOCA-LDP is the newly added capability for “ultra-fast trading” scenarios. Together, they form the complete picture of Kingdom’s middleware.

VIII. Conclusion: A History of Autonomous Control in Middleware

#

Looking back at the 30-year evolution of Kingdom’s middleware from KCBP to KOCA-LDP, what we see is a complete epic of China’s FinTech autonomous control.

From the introduction of self-developed middleware in 1998, to the first De-IOE solution in the financial industry in 2013, to KOCA-LDP fully supporting Xinchuang in 2023, Kingdom has walked a complete path of FinTech self-reliance over 30 years.

📌 Author’s Note: The deep significance of this evolutionary path lies in proving that Chinese FinTech enterprises are fully capable of breaking through from the “application layer” all the way up to the “middleware layer”, “database layer”, “OS layer”, and “CPU layer”, ultimately achieving full-stack autonomous control. When FS2.5 went live with “Xinchuang upon launch” at CICC Wealth, the evolution of Kingdom’s middleware was no longer just a technical upgrade history, but a microcosm of China’s national strategy for FinTech autonomous control.

From KCBP to KOCA-LDP, what changes are the architecture, performance, and tech stack; what remains unchanged is the original aspiration of “independent R&D, secure and controllable, serving finance”.

Appendix: Quick Reference of Kingdom Middleware Evolution Milestones

#

If this article helped you understand the evolution of Financial IT architecture, please like, bookmark, and share it with your peers!