Early Hundsun and Kingdom Financial IT Architecture

#

早期恒生与金证金融 IT 架构演进

#

From Branch-Level Systems to Enterprise Centralized Trading Platforms

从营业部级系统，到全国集中交易平台，中国证券 IT 的第一次架构革命。

1. Background: The Birth of Centralized Securities Architecture

#

一、背景：证券行业的大集中时代

#

Before 2000, China’s securities IT systems were mainly branch-oriented architectures.

1990s securities firms usually deployed independent trading systems in each brokerage branch.

Typical architecture:

Trading Terminal
|
|
Local Application Server
|
|
Local Database

Every branch was an isolated information island.

Problems:

• Data fragmentation
• Difficult risk control
• Difficult nationwide operation
• Limited scalability
• High maintenance cost

After 2000, the securities industry entered the era of:

“集中交易（Centralized Trading）”

The architecture goal became:

Hundreds of Branches

↓

National Central Trading Platform

↓

Enterprise Database Center

This transformation required:

• Transaction middleware
• Message middleware
• Application server
• Database cluster
• High availability architecture

At that time, global financial IT was dominated by:

• IBM CICS
• IBM MQ
• BEA Tuxedo
• Oracle Database
• IBM AIX Servers

China’s securities software vendors started building their own middleware platforms.

Two representative routes emerged:

• Hundsun: AR/AS → CRES → Light-JRES
• Kingdom: KCXP/KCBP → KOCA ecosystem

2. Early IOE Architecture Pattern

#

二、早期 IOE 架构模型

#

The typical financial architecture around 2000:

         Users
           |
      Client Terminal
           |
-----------------------
Middleware Layer
-----------------------
           |
Application Server
           |
Transaction Manager
           |
Oracle / DB2 Database
           |
IBM Server + EMC Storage

The characteristics:

Database Centered

#

Database was the core of business processing.

Oracle provided:

• ACID transaction
• Lock management
• Stored procedures
• Data consistency

Middleware Introduced

#

As transaction volume increased:

Business logic started moving upward.

Middleware became responsible for:

• Connection management
• Transaction coordination
• Load balancing
• Communication routing

This was the foundation of early Chinese financial middleware.

3. Hundsun Early Architecture

#

三、恒生早期架构：AR/AS 三层体系

#

3.1 Timeline

#

3.2 AR/AS Architecture

#

Hundsun introduced:

AR (Application Router)

#

Role:

• Request routing
• Load balancing
• Network isolation

AS (Application Server)

#

Role:

• Business execution
• Transaction processing
• Business modules

Architecture:

     Client

       |

      AR

Application Router

       |

      AS

Application Server

       |

    Oracle DB

       |

IBM AIX / Storage

The key innovation:

The application was no longer directly coupled with the database.

A request could be routed and processed by middleware.

3.3 O32 Early Architecture

#

Hundsun asset management system:

Client Terminal

|

Application Server

|

Tuxedo Middleware

|

Oracle Database

|

Storage

Characteristics:

• Three-tier architecture
• Oracle-centered
• Strong business coupling
• Database-driven processing

Typical limitations:

• Business modules tightly coupled
• External integration through tables
• Performance scalability limited

3.4 CRES Evolution

#

Around 2008:

Hundsun introduced:

CRES

#

(C++ Reused Extend Simple)

Architecture:

Client

|

CRES Middleware

|
Business Modules

|

Oracle Database

CRES provided:

• Communication
• Routing
• Transaction processing
• Database access

It replaced earlier Tuxedo based architecture.

Evolution:

AR/AS

↓

CRES

↓

Light-JRES

↓

Cloud Native Financial Platform

4. Kingdom Early Architecture

#

四、金证早期架构：KCXP/KCBP 四层体系

#

4.1 Timeline

#

4.2 Four-Layer Architecture

#

Kingdom proposed:

      Client

        |

      KCXP

Communication Middleware

        |

      KCBP

Transaction Middleware

        |

     Database

DB2 / Oracle / SQL Server

This architecture separated:

KCXP

#

Communication Layer

Responsibilities:

• Message delivery
• Queue management
• Network communication
• Cross-platform communication

Supported:

• TCP/IP
• UDP
• SNA
• IPX/SPX
• NetBIOS

KCBP

#

Transaction Processing Layer

Responsibilities:

• Transaction management
• Resource management
• Business execution
• Database connection management

Business modules:

KCBP

|
+---- LBM Module
|
+---- Trading Logic
|
+---- Clearing Logic

4.3 Kingdom Deployment Model

#

Typical 2005 architecture:

       Branch Terminals

             |

            KCXP

             |

            KCBP

             |

  DB2 / Oracle / SQL Server

             |

Unix / Linux / Windows Server

Key features:

• Multi OS support
• Multi database support
• Hardware independence
• Distributed cluster

Unlike Hundsun’s Oracle-oriented route:

Kingdom emphasized:

“middleware abstraction layer”

5. Hundsun vs Kingdom Architecture Comparison

#

6. Two Different Middleware Philosophies

#

Hundsun Philosophy

#

“Architecture Evolution”

#

Hundsun continuously redesigned middleware:

AR/AS

↓

CRES

↓

Light-JRES

↓

Cloud Native Platform

Advantages:

• Faster technology migration
• Cleaner architecture
• Easier modernization

Cost:

• Existing customers need migration

Kingdom Philosophy

#

“Stable Foundation”

#

Kingdom kept:

KCXP/KCBP

↓

KROUTER/KADP

↓

KOCA Platform

Advantages:

• Long lifecycle
• Protect customer investment
• Extremely stable

Cost:

• Legacy architecture coexistence

7. Why Middleware Was Necessary?

#

A common question:

Why not directly connect applications to database?

Early systems often looked like:

Application

|

Database

Problems:

1. Connection Explosion

#

Thousands of terminals:

10000 Clients

↓

10000 DB Connections

Database becomes bottleneck.

Middleware introduced:

10000 Clients

↓

Middleware Pool

↓

100 DB Connections

2. Transaction Management

#

Financial transactions require:

• atomicity
• consistency
• rollback
• distributed transaction

Middleware provides:

• XA transaction
• transaction coordinator
• recovery

3. Business Logic Isolation

#

Without middleware:

Application

↓

Database Stored Procedure

Problems:

• Database becomes application server
• Difficult migration
• Vendor lock-in

Middleware moved logic upward:

Application

↓

Middleware

↓

Database

8. Historical Significance

#

The emergence of AR/AS and KCXP/KCBP represented:

First Generation Chinese Financial Middleware

#

From:

IBM CICS
BEA Tuxedo
Oracle

to:

Chinese Independent Middleware

AR/AS

KCXP/KCBP

This was the beginning of financial software localization.

9. Conclusion

#

The early 2000-2010 period was the most important architectural transformation in China’s securities IT history.

Hundsun and Kingdom solved the same problem:

How can thousands of brokerage branches become one national financial system?

Their answers were different:

Hundsun:

#

“Build a better application server architecture.”

AR/AS
↓
CRES
↓
Light-JRES

Kingdom:

#

“Build a durable transaction middleware foundation.”

KCXP/KCBP
↓
KOCA

One emphasized continuous architectural evolution.

The other emphasized long-term stability.

Both became the foundation of China’s financial technology infrastructure.

The history of Chinese financial IT is not only the history of products.

It is the history of middleware, architecture philosophy, and the pursuit of independent technology.

AR/AS and KCXP/KCBP were the first generation of China’s financial middleware revolution.