↓ Skip to main content
vtoollab
  1. Posts/

Around 2000: What Were KCBP and KCXP? Reconstructing Kingstar's Early Securities Middleware Architecture

2848 words·
Securities History Financial Technology Securities IT Kingstar KCBP KCXP HARE AS AR Middleware Trading Host Trading Seat Securities Trading System Shanghai Stock Exchange Shenzhen Stock Exchange
Table of Contents

Around 2000: What Were KCBP and KCXP?
#

Reconstructing Kingstar’s Early Securities Middleware Architecture
#

In the previous article, we reconstructed the basic architecture of China’s securities trading infrastructure around 2000:

Branch → Central Trading System → Trading Host → Middleware → Trading Seat → Exchange.

The next question is much more specific:

Where exactly did KCBP and KCXP sit in this architecture?

And more importantly:

Why did securities firms need products like KCBP and KCXP at all?

To answer that, we need to stop thinking about them as two mysterious product names and instead reconstruct the engineering problem they were designed to solve.

1. Start With the Problem, Not the Product Name
#

Around the late 1990s and early 2000s, a securities firm could have:

Hundreds of Branches
        ↓
Thousands of Terminals
        ↓
Millions of Customer Orders

At the same time, those orders had to reach external market systems:

                 ┌── Shanghai Stock Exchange
                 │
Central Trading ─┼── Shenzhen Stock Exchange
                 │
                 ├── Registration / Clearing
                 │
                 └── Banking Systems

The problem was obvious:

The internal securities system and the external market systems did not speak exactly the same language.

This created the need for a dedicated communication and middleware layer.

2. The Simplest Architecture
#

A conceptual model is:

Investor
   ↓
Branch
   ↓
Central Trading System
   ↓
KCBP / KCXP
   ↓
Trading Channel
   ↓
Exchange

But this diagram is still too simple.

A more useful model is:

                     Securities Firm
                           │
                           ▼
                 ┌───────────────────┐
                 │ Central Trading   │
                 │ System            │
                 └─────────┬─────────┘
                           │
                           ▼
                 ┌───────────────────┐
                 │ Middleware        │
                 │                   │
                 │ Message Processing│
                 │ Routing           │
                 │ Queueing          │
                 │ Protocol          │
                 │ Recovery          │
                 └─────────┬─────────┘
                           │
                 ┌─────────┴─────────┐
                 ▼                   ▼
              SSE Channel        SZSE Channel
                 │                   │
                 ▼                   ▼
              SSE                   SZSE

This is the architectural territory in which products such as KCBP and KCXP become meaningful.

3. The First Important Distinction
#

We need to distinguish three things:

Trading Business Logic
        ≠
Middleware
        ≠
Exchange

For example, the securities firm’s core system might decide:

Customer 100001
Buy
600000
1,000 shares
RMB 10.00

That is business logic.

The middleware’s job is different:

How should this message be sent?

Where should it go?

What protocol should be used?

Has it been acknowledged?

What happens if the connection breaks?

How do we recover?

And the exchange has another responsibility:

Does this order match another order?

These are three separate layers.

4. KCBP / KCXP Should Be Understood as Infrastructure
#

The easiest conceptual mistake is to imagine:

KCBP = Trading System

or:

KCXP = Trading System

That is generally too broad.

A better way to think about the products is:

Core Securities System
        ↓
KCBP / KCXP
        ↓
External Trading Infrastructure

In other words, they belonged to the communication and transaction-processing infrastructure surrounding the core securities application.

Their importance came from what happened between two systems.

5. Why Could the Core System Not Simply Connect to the Exchange?
#

At first glance, this seems easy.

Why not:

Core System
      ↓
Socket
      ↓
Exchange

Because the real environment was more complicated.

The firm could have:

Shanghai Market
Shenzhen Market
Multiple Seats
Multiple Channels
Primary Connections
Backup Connections

and each external interface could impose different requirements.

The resulting architecture would become:

Core System
 ├── SSE Connection
 ├── SZSE Connection
 ├── Seat A
 ├── Seat B
 ├── Seat C
 ├── Backup A
 └── Backup B

Now every change to the external market interface potentially affects the core system.

That is bad architecture.

6. Middleware Introduced a Boundary
#

Instead, the architecture became:

                  Core System
                       │
                       ▼
                ┌─────────────┐
                │ Middleware  │
                └──────┬──────┘
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
        SSE          SZSE        Other

Now the core system only needs to understand an internal message model.

For example:

INTERNAL_ORDER
{
    account
    security
    side
    price
    quantity
}

The middleware translates this into the external representation.

Conceptually:

Internal Order
      ↓
Protocol Adapter
      ↓
External Exchange Message

7. This Is One of the Most Important Architectural Ideas
#

The core system should not care whether the destination is:

SSE
SZSE
Bank
Registration System
Clearing System

It should simply say:

Send Order

The middleware determines:

Destination
Protocol
Connection
Session
Sequence
Retry
Recovery

This separation became extremely important as securities firms grew larger.

8. Why “Message” Is the Correct Mental Model
#

Consider a normal order:

Buy 1,000 shares

Internally, it becomes a message:

ORDER

The exchange may respond with:

ACK

Then:

EXECUTION

Or:

REJECT

Or:

CANCEL

The lifecycle becomes:

ORDER
  ↓
ACK
  ↓
EXECUTION

or:

ORDER
  ↓
REJECT

or:

ORDER
  ↓
CANCEL
  ↓
CANCEL_ACK

This is why early securities middleware was fundamentally a financial message-processing system.

9. KCBP / KCXP and the Message Pipeline
#

A useful conceptual pipeline is:

Order
  ↓
Receive
  ↓
Validate
  ↓
Queue
  ↓
Route
  ↓
Convert
  ↓
Send
  ↓
Wait for ACK
  ↓
Receive Execution
  ↓
Route Back
  ↓
Update Core System

Every arrow represents an engineering problem.

10. Receive
#

The middleware first has to receive an order from the internal system.

For example:

Core System
     ↓
Middleware

The message might contain:

Order ID
Account
Security
Price
Quantity
Buy/Sell
Market
Timestamp

The middleware must parse it correctly.

11. Validate
#

Before sending the message outside the securities firm, the middleware may need to verify:

Is the message structurally valid?

Is the session active?

Is the destination available?

Is the message sequence correct?

Is this a duplicate?

This is not necessarily the same as business-level risk control.

That distinction matters.

A core trading system might determine:

Does the customer have sufficient buying power?

while the communication layer might determine:

Is this a valid message for the current session?

12. Queue
#

Why queue messages?

Because the producer and consumer do not necessarily operate at exactly the same speed.

Core System
    ↓
Message Queue
    ↓
Exchange Connection

Suppose:

Core System = 10,000 messages/sec
Exchange Connection = temporarily slower

A queue provides temporary buffering.

Conceptually:

Producer
   ↓
[1][2][3][4][5][6]
               ↓
             Consumer

This was particularly useful during market bursts.

13. Routing
#

Suppose the order is:

600000

and the destination is Shanghai.

The middleware must route it toward:

Shanghai Exchange

If another order belongs to Shenzhen:

000001

it follows:

Shenzhen Channel

Therefore:

                 Middleware
                 /        \
                /          \
             SSE           SZSE

Routing rules became a fundamental part of the architecture.

14. Protocol Conversion
#

This is another major reason middleware existed.

Internally:

BUY_ORDER

Externally, the exchange may require a specific message format.

Conceptually:

Internal Message
      ↓
Adapter
      ↓
Exchange Protocol

The reverse happens with execution reports:

Exchange Protocol
      ↓
Adapter
      ↓
Internal Execution Message

Thus:

Internal Language
       ↕
Middleware
       ↕
External Language

is one of the most useful ways to understand the technology.

15. Session Management
#

An exchange connection is not simply:

Open socket
Send forever

It generally has a session lifecycle.

Conceptually:

CONNECT
   ↓
LOGIN
   ↓
ESTABLISHED
   ↓
MESSAGE EXCHANGE
   ↓
LOGOUT

If the connection breaks:

ESTABLISHED
      ↓
DISCONNECTED
      ↓
RECONNECT
      ↓
RECOVER
      ↓
ESTABLISHED

This is why securities middleware needed session state.

16. Sequence Numbers
#

Imagine the middleware sends:

1001
1002
1003
1004

The exchange acknowledges:

1001
1002
1004

What happened to:

1003

The system needs to know.

Therefore sequence numbers provide a basic mechanism for detecting:

Missing Message
Duplicate Message
Out-of-Order Message

Conceptually:

1001 ✓
1002 ✓
1003 ?
1004 ✓

Now recovery can begin.

17. Duplicate Messages Are Dangerous
#

Suppose the middleware sends:

ORDER 100001

but does not receive an acknowledgement.

Did the exchange:

Receive it?

Maybe.

The network could have failed after the exchange accepted the order but before the acknowledgement returned.

If the system blindly resends:

ORDER 100001

it risks creating a duplicate order.

This is one of the hardest problems in transaction middleware:

The sender may not know whether the receiver has already processed a message.

18. Recovery Is Therefore Part of the Product
#

A mature middleware system must support something like:

Normal Operation
      ↓
Failure
      ↓
Reconnect
      ↓
Determine Last Known State
      ↓
Recover Missing Messages
      ↓
Resume

This is very different from ordinary application networking.

19. Execution Messages Must Also Return Reliably
#

The flow is not one-way.

We have:

Order:
Core
 ↓
Middleware
 ↓
Exchange

but also:

Execution:
Exchange
 ↓
Middleware
 ↓
Core

For example:

ORDER 100001

returns:

ACK 100001

and later:

EXEC 100001
Qty = 500
Price = 10.00

then:

EXEC 100001
Qty = 500
Price = 10.01

The core system must combine these into:

Total Executed = 1,000
Remaining = 0

20. This Creates a State Machine
#

The order can be represented as:

NEW
 ↓
SENT
 ↓
ACKNOWLEDGED
 ↓
PARTIALLY_FILLED
 ↓
FILLED

Or:

NEW
 ↓
SENT
 ↓
REJECTED

Or:

NEW
 ↓
SENT
 ↓
CANCEL_REQUESTED
 ↓
CANCELLED

The middleware and core system must cooperate to preserve this state correctly.

21. Why Logs Became So Important
#

Suppose a customer says:

“I submitted an order at 10:15:32.”

The securities firm needs to determine:

When did the branch receive it?

When did the core system accept it?

When did middleware send it?

When did the exchange receive it?

When did the exchange acknowledge it?

When was it executed?

When did the execution return?

Therefore the system needs logs such as:

10:15:32.001 Receive
10:15:32.003 Validate
10:15:32.004 Queue
10:15:32.005 Send
10:15:32.008 ACK
10:15:32.120 EXEC

The exact implementation varied by system, but the principle was universal:

A financial transaction must be traceable.

22. KCBP and KCXP Should Therefore Be Viewed as “Infrastructure Products”
#

Rather than asking:

“What screen did KCBP have?”

the better questions are:

What messages did it handle?

What systems did it connect?

How did it route?

How did it maintain sessions?

How did it recover?

How did it interact with the trading host?

How did it interact with the seat?

How did it handle multiple markets?

That is where the actual technical significance lies.

23. The Boundary Between KCBP and KCXP
#

This is where we need to be careful.

Historical product names do not always map neatly onto modern architectural terminology.

It is tempting to say:

KCBP = Layer A
KCXP = Layer B

as if there were a universal industry specification.

That would be too simplistic.

A safer historical reconstruction is:

Kingstar Securities Software
          │
          ├── Core Trading Functions
          │
          ├── Communication / Middleware
          │
          ├── Exchange Connectivity
          │
          └── Supporting Infrastructure

KCBP and KCXP should be understood within this larger product architecture rather than treated as isolated standalone applications.

24. Why Product Boundaries Could Change Over Time
#

Securities software was evolving extremely quickly during this period.

A product could start as:

Communication Component

and later absorb:

Routing
Queueing
Protocol Conversion
Monitoring
Recovery

Another product could move in the opposite direction:

Large Integrated System
       ↓
Separated Modules

Therefore the same product name does not necessarily imply exactly the same internal architecture across every release.

This is particularly important when reconstructing historical systems from:

  • old manuals;
  • deployment diagrams;
  • installation packages;
  • job advertisements;
  • customer references;
  • source code fragments;
  • configuration files;
  • old server lists.

25. What Did the Server Topology Probably Look Like?
#

A conceptual deployment might have been:

                 Branches
              /     |      \
             /      |       \
            ↓       ↓        ↓
        ┌────────────────────────┐
        │ Central Trading System │
        └───────────┬────────────┘
                    │
                    ▼
        ┌────────────────────────┐
        │ Middleware Server      │
        │                        │
        │ Message / Routing      │
        │ Protocol / Session     │
        └───────────┬────────────┘
                    │
             ┌──────┴──────┐
             ↓             ↓
        Exchange A     Exchange B

There might also be:

Primary Middleware
       │
       └── Backup Middleware

and:

Primary Channel
       │
       └── Backup Channel

The exact physical topology varied by deployment.

26. Why Did Middleware Need Dedicated Servers?
#

Because putting everything on one machine creates too much coupling:

Core Trading
+
Database
+
Exchange Communication
+
Message Queues
+
Monitoring

If the communication process becomes unstable:

Communication Failure
       ↓
Core Trading Affected

Separating the layers reduces the blast radius.

Conceptually:

Core Server
      │
      ▼
Middleware Server
      │
      ▼
Exchange

This separation also made maintenance easier.

27. The Emergence of “Gateway” Architecture
#

As systems matured, another useful abstraction appeared:

Core Trading System
        ↓
Gateway
        ↓
Exchange

The gateway became the boundary between:

Internal Securities Network

and:

External Market Network

A gateway could handle:

Connection
Authentication
Protocol
Routing
Message Transformation
Session
Monitoring
Recovery

This architecture is conceptually very close to later:

API Gateway
Message Gateway
Protocol Gateway
Trading Gateway

although the technologies were different.

28. Why This Was a Major Change From the Early 1990s
#

Compare the two periods.

Early 1990s
#

Branch
 ↓
Trader
 ↓
Exchange

The human trader was still a major component of the communication chain.

Around 2000
#

Branch
 ↓
Central System
 ↓
Middleware
 ↓
Trading Channel
 ↓
Exchange

The human had increasingly disappeared from the execution path.

The network became the intermediary.

That is the real technological transformation.

29. From “Trader” to “Message”
#

This is perhaps the most important historical transition.

Early system:

Investor
 ↓
Clerk
 ↓
Trader
 ↓
Exchange

Later system:

Investor
 ↓
Application
 ↓
Message
 ↓
Gateway
 ↓
Exchange

The transaction was no longer primarily a human communication event.

It had become:

a machine-to-machine financial message.

30. Why This Made Middleware Strategic
#

Once the market became machine-driven, the communication layer became mission-critical.

A failure in:

UI

was inconvenient.

A failure in:

Middleware

could stop:

Order Submission
+
Execution Reporting
+
Cancellation

across large numbers of branches.

Therefore middleware was not a peripheral utility.

It was part of the trading infrastructure itself.

31. KCBP / KCXP in One Diagram
#

A simplified conceptual reconstruction is:

                        Investors
                            │
                            ▼
                    Securities Branch
                            │
                            ▼
                   Central Trading System
                            │
                            ▼
                  ┌─────────────────────┐
                  │   KCBP / KCXP       │
                  │                     │
                  │ Message Processing  │
                  │ Queueing            │
                  │ Routing             │
                  │ Protocol Adapter    │
                  │ Session Management   │
                  │ Recovery            │
                  └──────────┬──────────┘
                             │
                   ┌─────────┴─────────┐
                   ▼                   ▼
              Trading Seat        Trading Seat
                   │                   │
                   ▼                   ▼
                  SSE                 SZSE

Again, this should be understood as an architectural reconstruction, not a claim that every installation used exactly this process layout.

32. The Important Question: Why Two Products?
#

Now we reach the interesting part.

If KCBP and KCXP were both associated with communication and transaction-processing infrastructure, why were there two products?

There are several possible architectural explanations:

Different Functions
Different Generations
Different Deployment Scenarios
Different Protocol Layers
Different Performance Requirements
Different Customer Architectures

The answer cannot safely be reduced to:

KCBP = Old
KCXP = New

without examining specific historical versions.

Likewise, it would be dangerous to claim:

KCBP = Exchange Adapter
KCXP = Message Queue

as a universal rule without version-specific evidence.

The more useful approach is to reconstruct their functional boundary from actual deployment architecture.

33. Compare the Problem With Hundsun
#

This also explains why Hundsun developed its own products in the same era.

Conceptually:

Kingstar
KCBP / KCXP

and:

Hundsun
AS / AR

were responses to a similar market requirement:

Centralized Securities Trading
        ↓
Multiple External Interfaces
        ↓
Reliable Communication
        ↓
High Availability
        ↓
High Throughput

The competition was therefore not simply:

Product A vs Product B

It was:

Different architectural solutions to the same securities infrastructure problem.

34. The Real Competitive Advantage Was Not the UI
#

For ordinary software products, the user interface might be the most visible component.

For securities middleware, the most important properties were invisible:

Can it survive a network failure?

Can it preserve message order?

Can it reconnect?

Can it recover?

Can it prevent duplicates?

Can it process bursts?

Can it support multiple seats?

Can it provide complete logs?

Can it reconcile?

The customer might never see these mechanisms directly.

But they determined whether the system could actually operate during a busy trading session.

35. Why the Year 2000 Was Such an Important Point
#

By around 2000, China’s securities market had passed through several architectural generations:

1980s
Paper + Counter
        ↓
Early 1990s
Exchange Computerization
        ↓
Mid-1990s
Branch Networking
        ↓
Late 1990s
Centralized Trading
        ↓
Around 2000
Middleware + Gateways + Seats
        ↓
Later
Distributed / Multi-tier / Disaster Recovery

KCBP and KCXP belong to this transitional period.

They represent the moment when securities software was no longer simply:

“an application running in a brokerage branch.”

It had become:

“a distributed infrastructure connecting a nationwide securities organization to centralized financial markets.”

36. The Most Useful Mental Model
#

If you remember only one diagram from this article, remember this:

             CUSTOMER
                 │
                 ▼
             BRANCH
                 │
                 ▼
          CORE TRADING
                 │
                 ▼
          TRADING HOST
                 │
                 ▼
        ┌────────────────┐
        │   MIDDLEWARE   │
        │                │
        │ Message        │
        │ Routing        │
        │ Protocol       │
        │ Session        │
        │ Recovery       │
        └───────┬────────┘
                │
         ┌──────┴──────┐
         ▼             ▼
       SSE Seat      SZSE Seat
         │             │
         ▼             ▼
        SSE           SZSE

The key is:

Core = Business
Middleware = Communication Infrastructure
Seat = Market Access
Exchange = Central Market

These are different concepts.

37. And This Leads to the Next Layer
#

Once we understand the architecture, we can go one level deeper.

The next question is no longer:

“What was KCBP?”

It becomes:

What actually happened inside KCBP when an order entered the system?

For example:

Order arrives
      ↓
Which process receives it?
      ↓
Which queue stores it?
      ↓
Which thread processes it?
      ↓
How is the destination selected?
      ↓
How is the exchange protocol generated?
      ↓
Which socket sends it?
      ↓
How is the response received?
      ↓
Where is the execution stored?
      ↓
How does the core trading system learn about it?

Related