Around 2000: What Were the Trading Host, Seat, Middleware, and Exchange Actually Doing?

#

If the development of China’s securities IT infrastructure during the 1990s could be summarized in one sentence, it would be:

China’s securities market was moving from “computerized branches” to “networked securities firms.”

By around 2000, however, the difficult question was no longer simply how to computerize a brokerage branch.

The real question had become:

Where does an order enter a securities firm, which servers and communication layers does it pass through, which trading channel or seat does it use, and how does it finally reach the Shanghai or Shenzhen Stock Exchange?

To understand the generation of securities software represented by KCBP, KCXP, AS, AR, and HARE, we first need to separate four concepts that are often mixed together:

the trading host, the trading seat, middleware, and the stock exchange.

1. First, the Key Point: These Four Things Were Not the Same

#

The simplest architecture looks like this:

Investor
   ↓
Securities Branch
   ↓
Central Securities Trading System
   ↓
Trading Middleware
   ↓
Trading Gateway / Seat Connection
   ↓
Stock Exchange

There are actually several distinct layers:

① Investor / Securities Branch
② Securities Firm's Core Trading System
③ Trading Middleware
④ Trading Seat / Exchange Connectivity
⑤ Stock Exchange

Historical descriptions often blur these layers.

That is why it is easy to encounter statements such as:

“Was a trading seat just a server?”

Or:

“Was the trading host the exchange?”

Or:

“Was KCBP itself the trading host?”

None of these descriptions is sufficiently precise.

2. Start With One Simple Order

#

Suppose an investor wants to buy:

Stock: 600000
Quantity: 1,000 shares
Price: RMB 10.00

The investor does not normally send the order directly to the Shanghai Stock Exchange.

At the most basic level:

Investor
   ↓
Securities Branch
   ↓
Securities Firm
   ↓
Trading Seat
   ↓
Exchange

But this is far too simple from an IT perspective.

A more realistic conceptual architecture would look like:

Investor
   ↓
Branch Terminal
   ↓
Branch Access System
   ↓
Centralized Trading System
   ↓
Trading Host
   ↓
Middleware
   ↓
Trading Gateway
   ↓
Trading Seat
   ↓
Shanghai Stock Exchange

After execution, the direction reverses:

Shanghai Stock Exchange
   ↓
Trading Seat
   ↓
Trading Gateway
   ↓
Middleware
   ↓
Trading Host
   ↓
Centralized Trading System
   ↓
Securities Branch
   ↓
Investor

This is the data flow that matters.

3. What Was a Securities Branch?

#

Let’s start at the investor-facing end.

In the early 1990s, a securities branch was already a relatively complete computer system:

Customer
   ↓
Branch Counter
   ↓
Branch Server
   ↓
Branch Database

The branch handled functions such as:

• customer information;
• cash accounts;
• securities accounts;
• order entry;
• executions;
• printing;
• account inquiries;
• certain risk-control functions;
• parts of settlement and reconciliation.

Therefore:

An early securities branch was essentially a small local computing center.

4. What Happened to the Branch After Centralized Trading?

#

As centralized trading infrastructure developed, branches gradually lost part of their role as independent computing centers.

The architecture increasingly became:

Customer
   ↓
Securities Branch
   ↓
Network
   ↓
Central System

The branch increasingly became:

a front-end node of the securities firm.

Its primary responsibilities were increasingly:

Input
 ↓
Transmission
 ↓
Display

rather than performing the entire transaction-processing chain locally.

5. What Was the Centralized Trading System?

#

Imagine a securities firm with:

Branch 001
Branch 002
Branch 003
...
Branch 100

The old architecture looked more like:

Branch 001 → Local System
Branch 002 → Local System
Branch 003 → Local System

Centralized trading changed this into:

Branch 001 ─┐
Branch 002 ─┤
Branch 003 ─┤
...         ├──→ Central Trading System
Branch 100 ─┘

The central system increasingly became responsible for:

Customers
Accounts
Cash
Securities
Orders
Executions
Risk
Transaction Status

Therefore:

Centralized trading fundamentally meant concentrating transaction-processing capabilities and data.

6. So What Exactly Was the “Trading Host”?

#

The Chinese term 交易主站, commonly translated as trading host or main trading station, can easily be misunderstood by modern engineers.

It was not simply:

“the main server.”

In the historical context of China’s securities industry, the trading host generally referred to:

the central transaction-processing node within the securities firm’s trading network.

Conceptually:

                 Central Trading Host
                         │
        ┌────────────────┼────────────────┐
        ↓                ↓                ↓
     Branch 001       Branch 002       Branch 003

At the same time:

Central Trading Host
        ↓
Trading Connectivity
        ↓
Exchange

So the trading host sat between:

the securities firm’s branch network and the external exchange network.

7. The Trading Host Was Not the Exchange

#

This is the first principle to remember:

Securities Firm Trading Host ≠ Shanghai Stock Exchange

The trading host belonged to:

Securities Firm

while the exchange belonged to:

Market Infrastructure

The relationship was therefore:

Securities Firm
   ↓
Trading Host
   ↓
Trading Connectivity
   ↓
Shanghai Stock Exchange

or:

Securities Firm
   ↓
Trading Host
   ↓
Trading Connectivity
   ↓
Shenzhen Stock Exchange

8. Then What Was a “Trading Seat”?

#

The trading seat was another concept entirely.

A rough modern analogy is:

a trading seat represented a securities firm’s qualification and access identity for trading on the exchange.

It should not simply be interpreted as:

One Server

Nor as:

One Network Cable

Nor as:

One Securities Branch

Conceptually:

Securities Firm
   ↓
Trading Qualification
   ↓
Trading Seat
   ↓
Exchange

9. Why Are Historical Trading Seats So Easy to Misunderstand?

#

Because early trading seats had a very strong physical meaning.

Inside an exchange trading hall, there could literally be:

┌────┬────┬────┬────┐
│Seat│Seat│Seat│Seat│
└────┴────┴────┴────┘

A trader sat there.

A telephone was nearby.

A trading terminal was nearby.

Orders arrived from branches.

The trader entered those orders into the exchange’s trading system.

Thus, historically:

A trading seat was both an institutional concept and a physical trading position.

10. Trading Seats Gradually Became Electronic

#

As trading technology evolved:

Physical Seat
     ↓
Electronic Trading Seat
     ↓
Logical Trading Channel

The seat became less like an actual chair and more like:

Trading Qualification
+
Identity
+
Market Access
+
Trading Connectivity

Thus, under centralized trading:

Multiple Branches
        ↓
Central Trading System
        ↓
One or More Trading Seats
        ↓
Exchange

11. One Seat Could Serve Many Branches

#

This is one of the most important ideas in understanding centralized trading.

For example:

Branch A ─┐
Branch B ─┤
Branch C ─┤
Branch D ─┼──→ Central Trading System
Branch E ─┘             ↓
                       Seat
                        ↓
                  Shanghai Exchange

Therefore:

A securities branch was not the same thing as a trading seat.

Instead:

Orders from many branches could be aggregated by the centralized trading system and sent through a trading seat.

This was one of the defining characteristics of the centralized model.

12. This Created a Very Important Many-to-Few Architecture

#

On the investor-facing side:

Many Branches
+
Many Investors
+
Many Orders

On the exchange side:

Fewer Trading Seats
+
Fewer Standardized Exchange Connections

The resulting topology looked like:

                ┌→ Seat 1 → SSE
Many Branches → Central System ─→ Seat 2 → SZSE
                └→ Other Channels

In abstract terms:

Many
 ↓
Centralized Processing
 ↓
Few

This was the characteristic topology of centralized securities trading networks.

13. Why Did Middleware Appear?

#

Now another problem appears.

If the central trading system directly handled:

Shanghai Stock Exchange
Shenzhen Stock Exchange
Banks
Registration
Clearing

the internal architecture would become increasingly complicated.

For example:

Core System
 ├── Shanghai Exchange Interface
 ├── Shenzhen Exchange Interface
 ├── Bank Interface
 ├── Registration Interface
 └── Clearing Interface

This creates significant coupling.

The architecture therefore increasingly moved toward:

Core Trading System
        ↓
Middleware
        ↓
External Systems

14. What Did Middleware Actually Do?

#

A useful way to understand securities middleware is:

It acted as a translation, routing, and reliable-transport layer between the securities firm’s internal business systems and external market systems.

For example, the core system might generate an internal order:

Customer: 10001
Security: 600000
Quantity: 1000
Price: 10.00

The middleware would transform this into:

A message format understood by the Shanghai exchange connection.

For the Shenzhen market:

Core System
 ↓
Middleware
 ↓
Shenzhen Protocol

For the Shanghai market:

Core System
 ↓
Middleware
 ↓
Shanghai Protocol

Therefore:

The core business system did not need to understand every external market protocol itself.

15. Middleware Performed at Least Four Major Functions

#

We can summarize its role as:

① Message
② Routing
③ Protocol
④ Reliability

1. Message

#

Handling:

Orders
Executions
Cancels
Acknowledgements
Rejects

2. Routing

#

Determining:

Shanghai?
Shenzhen?
Bank?
Registration?
Clearing?

3. Protocol

#

Converting:

Internal Message
       ↓
External Protocol

4. Reliability

#

Handling:

Disconnection
Retransmission
Duplicates
Message Loss
Ordering
Recovery

Together, these functions explain the real value of securities middleware.

16. Why Were Messages So Important?

#

Suppose an order has the following lifecycle:

Order 100001
 ↓
Submitted
 ↓
Accepted
 ↓
Partially Executed
 ↓
Fully Executed

Or:

Order 100001
 ↓
Submitted
 ↓
Rejected

Or:

Order 100001
 ↓
Submitted
 ↓
Cancel Request
 ↓
Cancel Confirmed

Therefore, a trade was not simply one event.

It was:

a state machine.

17. What Was an Order From the IT System’s Perspective?

#

From the investor’s perspective:

Buy 1,000 shares

From the trading system’s perspective:

Order ID
Customer ID
Account ID
Market
Security ID
Price
Quantity
Timestamp
Session
Sequence
Status

And then additional events appeared:

Order
 ↓
Acknowledgement
 ↓
Execution
 ↓
Cancel
 ↓
Cancel Acknowledgement

Thus:

A securities trading system was fundamentally a high-reliability financial messaging system.

18. Why Was Securities Middleware Different From Ordinary Enterprise Middleware?

#

A normal enterprise system might tolerate:

The message arrives a little later.

A securities trading system cannot casually tolerate:

We don't know the status of the order.

For example, the investor believes:

“I cancelled my order.”

But the exchange actually processed:

The order was executed.

This creates a serious business problem.

Therefore the trading system must precisely maintain:

Order Status
Execution Status
Cancellation Status

19. The Most Dangerous Situation: A Network Failure

#

Suppose:

Order 100001

has already been sent.

Then:

Network Connection Lost

The securities firm no longer knows:

Did the exchange receive it?

If the firm simply sends the order again:

Order 100001

it may create:

Duplicate Order

Therefore the system needs mechanisms such as:

Sequence Numbers
+
Message IDs
+
Acknowledgements
+
Recovery
+
Deduplication

This is one reason securities middleware was much more sophisticated than a simple socket connection.

20. Middleware Became a Reliable Financial Message Bus

#

Conceptually:

                    Middleware
                        │
          ┌─────────────┼─────────────┐
          ↓             ↓             ↓
        Order       Execution       Cancel
          │             │             │
          └─────────────┼─────────────┘
                        ↓
                  Trading Channel
                        ↓
                     Exchange

It was not merely:

Socket → Socket

Instead:

Business Message
      ↓
Routing
      ↓
Protocol Conversion
      ↓
Reliable Transport
      ↓
State Management
      ↓
Recovery

21. This Clarifies the Relationship Between the Trading Host and Middleware

#

This is another important distinction.

We should not simply say:

Trading Host = Middleware

A better conceptual model is:

Trading Host
└── Central transaction-processing environment

Middleware
└── Software layer responsible for messaging,
    routing, protocol adaptation, reliability, etc.

Therefore:

The trading host is an architectural/node concept, while middleware is a software-layer concept.

They exist at different conceptual dimensions.

22. A Trading Host Could Contain Multiple Components

#

A simplified model might look like:

┌──────────────────────────────┐
│       Trading Host           │
│                              │
│ ┌──────────────────────────┐ │
│ │ Customer / Account       │ │
│ ├──────────────────────────┤ │
│ │ Order Processing         │ │
│ ├──────────────────────────┤ │
│ │ Risk Control             │ │
│ ├──────────────────────────┤ │
│ │ Trading Messages         │ │
│ ├──────────────────────────┤ │
│ │ Middleware / Communication│ │
│ └──────────────────────────┘ │
└──────────────────────────────┘

Therefore, seeing a product described as running on a “trading host” does not mean:

The product itself was the entire trading host.

23. Where Should KCBP and KCXP Be Placed?

#

Now we can finally place the products discussed in earlier articles into the architecture.

At a conceptual level:

Securities Branch
       ↓
Centralized Trading System
       ↓
KCBP / KCXP-type Middleware Layer
       ↓
Trading Connectivity
       ↓
Trading Seat
       ↓
Exchange

The underlying problem they addressed was:

After centralized trading became widespread, how could a securities firm reliably connect its internal trading business to external market infrastructures?

Therefore, KCBP and KCXP should not be viewed merely as isolated software modules.

They reflected a much larger architectural transition in China’s securities industry.

24. Why Did Both Kingstar and Hundsun Build Similar Products?

#

Because both vendors faced essentially the same historical environment:

More Branches
+
Growing Trading Volumes
+
Centralized Trading
+
Shanghai Exchange Interfaces
+
Shenzhen Exchange Interfaces
+
Bank Connectivity
+
Registration and Clearing Connectivity

The industry therefore needed solutions for:

Connectivity
+
Messaging
+
Routing
+
Protocol Conversion
+
Reliability

This helps explain why products such as:

Kingstar
KCBP / KCXP

Hundsun
AS / AR

appeared in roughly the same historical period.

The interesting question is not simply:

“Why did both companies build middleware?”

The deeper question is:

Why did the two vendors draw different boundaries around similar problems?

25. Now the Meaning of “Trading Seat” Becomes Much Clearer

#

The overall architecture can now be visualized as:

Customer
   ↓
Securities Branch
   ↓
Central Trading System
   ↓
Middleware
   ↓
Trading Seat
   ↓
Exchange

Each layer has a different responsibility.

Securities Branch

#

Responsible for:

Customer Access

Central Trading System

#

Responsible for:

Securities Business Processing

Middleware

#

Responsible for:

Messaging
Routing
Protocol Conversion
Reliability

Trading Seat

#

Represents:

Trading Qualification
+
Exchange Access Identity
+
Trading Connectivity

Exchange

#

Responsible for:

Centralized Market Trading
and Matching

This distinction is fundamental.

26. Now Consider an Execution Report

#

Suppose:

Order 100001

is executed on the Shanghai Stock Exchange.

The exchange generates:

Execution Report

The message travels:

Shanghai Stock Exchange
       ↓
Trading Seat
       ↓
Trading Channel
       ↓
Middleware
       ↓
Central Trading System
       ↓
Customer Account
       ↓
Securities Branch

The investor eventually sees:

Executed:
1,000 shares
Price:
RMB 10.00

But internally, a much longer chain has taken place:

Exchange Execution
       ↓
Message Generation
       ↓
Message Transmission
       ↓
Message Parsing
       ↓
Routing
       ↓
Account Update
       ↓
Position Update
       ↓
Branch Notification

27. What If the Execution Report Is Lost?

#

This takes us directly back to the core value of middleware.

Suppose the exchange has already executed:

1,000 shares

but the network connection fails between:

Exchange → Securities Firm

The securities firm must be able to:

Detect Missing Messages
       ↓
Reconnect
       ↓
Recover Missing Data
       ↓
Restore Sequence
       ↓
Update State

Therefore:

The most dangerous problem in a trading system was not simply that the network failed.

It was failing without knowing what had happened.

28. This Is Why Reconciliation Became Essential

#

At the end of the trading day, the securities firm had to answer:

How many trades does the exchange say occurred?

and:

How many trades does the securities firm's system believe occurred?

They must match.

For example:

Securities Firm:
100,000 executions

Exchange:
100,000 executions

Everything is consistent.

But:

Securities Firm:
100,000

Exchange:
99,999

something must be investigated.

Therefore:

Trading
  ↓
Clearing
  ↓
Reconciliation

became part of the complete transaction lifecycle.

29. This Was the Real Financial-System Loop

#

A normal Internet application might look like:

Request
 ↓
Response

A securities transaction is closer to:

Order
 ↓
Exchange
 ↓
Execution
 ↓
Clearing
 ↓
Settlement
 ↓
Position
 ↓
Reconciliation

That is why securities IT systems have historically demanded much stronger consistency and recoverability than ordinary business applications.

30. Why Did Securities Firms Need Primary and Backup Systems?

#

Centralized trading created another problem.

If there was:

One Central Trading Node

and it failed:

All Branches
      ↓
Cannot Trade

Therefore systems increasingly required:

Primary
 ↓
Backup

and later:

Primary Trading Host
        ↕
Backup Trading Host

Eventually:

Production Center
       ↓
Disaster Recovery Center

along with:

Database Replication
+
Transaction Logs
+
Message Logs
+
State Recovery

31. Centralization Created a New Kind of Risk

#

This is one of the paradoxes of centralized trading:

Centralization solved management and consistency problems, but increased the impact of central failures.

Under the old branch-centric model:

Branch A fails

might mean:

Only Branch A is unavailable.

Under centralized trading:

Central Trading Host fails

could mean:

100 branches become unable to trade.

Therefore securities IT began placing enormous emphasis on:

High Availability
+
Redundancy
+
Disaster Recovery
+
State Recovery

32. This Is Why Securities IT Became a Large Distributed-System Problem

#

Although technologies such as:

Microservices
Kafka
Kubernetes
Cloud
API Gateway

did not exist in their modern form at the time, many of the underlying architectural problems already existed:

Large Number of Clients
       ↓
Central Services
       ↓
Messaging Middleware
       ↓
Multiple External Systems

The system also had to provide:

High Throughput
+
Low Latency
+
High Reliability
+
Ordering
+
Failure Recovery
+
Data Consistency

In this sense:

China’s securities IT industry entered the world of large-scale distributed financial systems quite early.

33. Why Did Low Latency Become Increasingly Important?

#

The early manual market operated on a timescale of:

Minutes
or longer

Then:

Seconds

Later:

Milliseconds

As competition increased, the path:

Order
 ↓
Exchange

became increasingly performance-sensitive.

Therefore every layer mattered:

Branch
 ↓
Central Trading Host
 ↓
Middleware
 ↓
Trading Gateway
 ↓
Exchange

Each unnecessary operation added latency.

Securities middleware therefore evolved from:

“It can communicate.”

toward:

“It can communicate reliably and quickly.”

34. This Is What Made Securities Middleware Different

#

A normal enterprise messaging system might primarily require:

Reliability

A securities trading system demanded:

Reliability
+
Ordering
+
Recovery
+
Traceability
+
Low Latency
+
Reconciliation

That is why securities middleware developed such strong industry-specific characteristics.

35. The Entire Around-2000 Architecture

#

A simplified conceptual architecture looks like this:

                         Investor
                            │
                            ▼
                    ┌──────────────┐
                    │ Securities   │
                    │ Branch       │
                    └──────┬───────┘
                           │
                           ▼
                ┌────────────────────┐
                │ Centralized        │
                │ Trading System     │
                │                    │
                │ Customer / Account │
                │ Order / Risk       │
                │ Position / State   │
                └─────────┬──────────┘
                          │
                          ▼
                ┌────────────────────┐
                │   Trading Host     │
                │                    │
                │ Central Processing │
                └─────────┬──────────┘
                          │
                          ▼
                ┌────────────────────┐
                │ KCBP / KCXP-type   │
                │ Middleware Layer   │
                │                    │
                │ Messaging          │
                │ Routing            │
                │ Conversion         │
                │ Session / Recovery │
                │ Reconciliation     │
                └─────────┬──────────┘
                          │
                 ┌────────┴────────┐
                 ▼                 ▼
              SSE Seat          SZSE Seat
                 │                 │
                 ▼                 ▼
              SSE               SZSE

Important:

This is a conceptual architecture, not a claim about the exact production topology deployed by every securities firm in a particular year.

Different vendors, securities firms, and product generations could draw the boundaries differently.

36. The Entire History in One Timeline

#

Around 1986:

The Counter Was the Trading Center

Around 1990:

The Exchange Became the Market Center

Mid-1990s:

Branches Began to Become Networked

Late 1990s:

Securities Firms Built Centralized Trading Systems

Around 2000:

Central Trading System
        ↓
Trading Host
        ↓
Middleware
        ↓
Trading Seat
        ↓
Exchange

China’s securities industry had therefore entered an era of:

Networking, centralization, and electronic trading.