1997–2001: Why Chinese Brokerages Had to Centralize Trading

#

From Branch Computers to KCBP/KCXP

#

In the early 1990s, putting a computer in a securities branch was already a major technological improvement.

By the late 1990s, however, the problem was no longer:

“How do we computerize a branch?”

It became:

“How do we connect hundreds of branches, millions of accounts, multiple exchanges, multiple trading seats, banks, clearing systems and registration systems into one coherent transaction network?”

This was the architectural problem that drove China’s securities IT industry toward centralized brokerage systems and transaction middleware.

1. The First Generation: Every Branch Was Almost Its Own World

#

The earliest computerized brokerage systems were naturally branch-oriented.

A simplified architecture looked like:

Branch A
   ↓
Local Brokerage Server
   ↓
Local Database


Branch B
   ↓
Local Brokerage Server
   ↓
Local Database


Branch C
   ↓
Local Brokerage Server
   ↓
Local Database

Each branch maintained information about its own customers.

For example:

Branch A

Customer A001
Customer A002
Customer A003
...

and:

Branch B

Customer B001
Customer B002
Customer B003
...

This architecture made sense.

The market was young.

Branches were relatively independent.

Computer networks were expensive.

Wide-area networking was immature.

And the amount of transaction data was still manageable.

2. But the Market Started Growing Much Faster

#

As China’s securities market expanded, the number of:

Investors
+
Accounts
+
Securities
+
Orders
+
Trades
+
Branches

grew rapidly.

A brokerage could no longer think of itself as:

100 independent branches

It increasingly had to operate as:

1 brokerage company
+
100 branches

This distinction sounds trivial.

Technically, it was enormous.

3. The First Major Problem: Customer Information Was Fragmented

#

Suppose Zhang San opened an account at:

Branch 001

Later, he wanted to trade at:

Branch 023

A purely local architecture would have a problem.

Branch 023 might not know:

Who is Zhang San?

or:

What securities does he own?

or:

How much cash does he have?

or:

Does he have outstanding orders?

The architecture therefore had to evolve from:

Customer → Branch

toward:

Customer
   ↓
Central Customer / Account Database
   ↓
Multiple Branches

4. The Concept of “Centralized Brokerage”

#

The solution was usually described as:

集中交易

Centralized trading.

But “centralized trading” should not be interpreted as simply moving the exchange into the brokerage firm’s headquarters.

It meant centralizing the brokerage firm’s transaction processing.

Instead of:

Branch
   ↓
Local Trading Server
   ↓
Exchange

the architecture became:

Branch
   ↓
Central Brokerage System
   ↓
Trading System
   ↓
Exchange

The branch increasingly became a client access point rather than an independent transaction-processing center.

5. The Architectural Transformation

#

The old architecture:

                   EXCHANGE
                   /   |   \
                  /    |    \
                 /     |     \
             Branch Branch Branch
               A       B       C

The centralized architecture:

              Branch A
                  \
              Branch B
                   \
              Branch C
                    \
                     ↓
              ┌───────────────┐
              │ Central       │
              │ Brokerage     │
              │ System        │
              └───────┬───────┘
                      │
                      ▼
               Trading System
                      │
                      ▼
                   Exchange

This was a fundamental change in data ownership.

6. What Did “Centralized” Actually Mean?

#

Centralization could occur at several different levels.

Customer data

#

Customers
   ↓
Central Database

Account data

#

Accounts
   ↓
Central Account Management

Order processing

#

Orders
   ↓
Central Transaction Engine

Risk control

#

Orders
   ↓
Central Risk Checking

Trading connectivity

#

Central Trading Gateway
   ↓
Trading Seats
   ↓
Exchange

So a more complete architecture looked like:

                    CLIENTS
                       │
                       ▼
                  BRANCHES
                       │
                       ▼
              ┌────────────────┐
              │ Central Broker │
              │ Infrastructure │
              └───────┬────────┘
                      │
        ┌─────────────┼─────────────┐
        ▼             ▼             ▼
     Accounts       Orders        Risk
        │             │
        │             ▼
        │       Transaction Layer
        │             │
        └─────────────┤
                      ▼
                Trading Gateway
                      │
                      ▼
                Trading Seat
                      │
                      ▼
                   Exchange

7. Why Was the Trading Seat Still Necessary?

#

This is where many modern readers get confused.

If the brokerage had a central system, why couldn’t it simply connect directly to the exchange?

Because the exchange did not originally treat every individual customer as a direct participant.

The market was organized around:

Exchange Members
        ↓
Trading Seats / Trading Units
        ↓
Brokerage Firms

The brokerage firm’s customers were behind the member.

Therefore:

Customer
   ↓
Broker
   ↓
Trading Seat
   ↓
Exchange

remained the fundamental market-access structure.

8. The Brokerage Now Had Two Worlds

#

By the late 1990s, a brokerage system effectively had to connect two different worlds.

World A — Customer Side

#

Customer
   ↓
Branch
   ↓
Client
   ↓
Cash Account
   ↓
Securities Account
   ↓
Order

World B — Exchange Side

#

Order
   ↓
Trading Gateway
   ↓
Trading Seat
   ↓
Exchange
   ↓
Execution

The difficult engineering problem was the middle:

CUSTOMER WORLD
       ↓
       ?
       ↓
EXCHANGE WORLD

That middle layer became increasingly important.

9. This Is Where Middleware Appears

#

The simplest definition of middleware is:

Software that connects different systems while hiding their communication and protocol differences.

In securities:

Brokerage System
       ↓
   Middleware
       ↓
Exchange Interface

The brokerage system should not need to understand every low-level detail of every exchange connection.

Instead:

Brokerage Core
      ↓
Standard Internal Message
      ↓
Middleware
      ↓
Exchange-specific Message

This is a crucial architectural idea.

10. Why Was a Simple Network Connection Not Enough?

#

Because “network connectivity” and “business connectivity” are different things.

A TCP connection can tell you:

The other machine is reachable.

It does not tell you:

The order is valid.
The order has been accepted.
The order has been executed.
The order has been rejected.
The execution corresponds to this customer.
The response is a duplicate.
The connection recovered after a failure.

Securities middleware therefore had to understand business messages.

11. An Order Was Not Just a Packet

#

Imagine:

Buy
600000
1,000 shares
10.00 RMB

The system needed additional information:

Client ID
Cash Account
Securities Account
Branch
Order ID
Trading Seat
Market
Security
Price
Quantity
Order Type
Timestamp

The exchange might require a completely different message structure.

So middleware performed transformations such as:

Internal Order
      ↓
Validation
      ↓
Routing
      ↓
Message Transformation
      ↓
Exchange Order

12. The Central Transaction Main Station

#

This is where the historical concept of a 交易主站, or transaction main station, becomes important.

A main station was not simply:

“a powerful server.”

It was a logical center of transaction processing.

A simplified model:

                 Branches
                    │
                    ▼
            Transaction Main
                 Station
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
      Account              Trading
      Processing           Processing
                              │
                              ▼
                        Trading Seat
                              │
                              ▼
                           Exchange

The main station became the center through which large numbers of branch transactions could be processed.

13. Why Did the Main Station Need Middleware?

#

Because the main station was sitting between systems with different responsibilities.

For example:

Branch System

might speak in terms of:

Customer
Account
Order

while:

Exchange

might speak in terms of:

Trading Member
Seat
Order
Execution
Market

and:

Clearing System

might speak in terms of:

Trade
Settlement
Netting
Cash
Securities

The main station therefore needed a common transaction layer.

14. The Emergence of KCBP/KCXP-Type Architecture

#

This is the environment in which products such as:

KCBP
KCXP

became meaningful.

They should not be understood simply as:

"old versions of an API gateway."

Their historical role was much closer to:

Transaction Middleware
+
Message Processing
+
Routing
+
Protocol Adaptation
+
Trading Connectivity

The exact internal implementation changed across versions and deployments, but the architectural problem remained consistent:

How do you move securities transaction messages reliably between brokerage applications and external trading/settlement systems?

15. KCBP and KCXP in the Larger Picture

#

A simplified conceptual architecture is:

                    CLIENTS
                       │
                       ▼
                  BRANCH SYSTEM
                       │
                       ▼
                CENTRAL BROKERAGE
                       │
                       ▼
                  KCBP / KCXP
                       │
            ┌──────────┼──────────┐
            ▼          ▼          ▼
         Market A    Market B    Bank
            │          │          │
            ▼          ▼          ▼
        Exchange    Exchange    Banking

This should be understood as a conceptual architecture rather than a claim that every historical deployment used exactly this topology.

The key idea is the middle layer.

16. Why Not Let the Brokerage Core Talk Directly to the Exchange?

#

Suppose the brokerage has:

100 branches

and:

3 trading markets

If every application directly handles every external protocol, complexity explodes.

Conceptually:

Application A → Exchange 1
Application A → Exchange 2
Application A → Bank

Application B → Exchange 1
Application B → Exchange 2
Application B → Bank

Application C → Exchange 1
Application C → Exchange 2
Application C → Bank

This creates a large number of integration points.

Instead:

             Applications
           /      |      \
          /       |       \
         ▼        ▼        ▼
       ┌────────────────────┐
       │ Transaction         │
       │ Middleware          │
       └───────┬────────────┘
               │
       ┌───────┼────────┐
       ▼       ▼        ▼
   Exchange 1 Exchange 2 Bank

Now the brokerage applications can use a more standardized internal interface.

17. Middleware Reduces Protocol Coupling

#

Without middleware:

Brokerage Core
      │
      ├── Exchange Protocol A
      ├── Exchange Protocol B
      ├── Bank Protocol C
      ├── Registration Protocol D
      └── Clearing Protocol E

With middleware:

Brokerage Core
      │
      ▼
Internal Message Model
      │
      ▼
Transaction Middleware
      │
 ┌────┼────┬────┐
 ▼    ▼    ▼    ▼
 A    B    C    D

This is one of the fundamental reasons middleware became valuable.

18. Message Routing Became a Core Function

#

Consider:

Customer A

sending:

Buy Shanghai Stock

while:

Customer B

sends:

Buy Shenzhen Stock

The middleware must determine:

Where should this order go?

The routing logic may depend on:

Market
Security
Trading Session
Branch
Account
Seat
Business Type

So the architecture becomes:

ORDER
  ↓
Routing Rules
  ↓
Market Selection
  ↓
Seat Selection
  ↓
Exchange Gateway

19. Routing Is More Important Than It Looks

#

A trading middleware system is essentially a specialized routing engine.

For example:

IF market = SH
    → Shanghai Trading Gateway

IF market = SZ
    → Shenzhen Trading Gateway

IF business = OTC
    → OTC Processing

IF business = Bank-Securities Transfer
    → Bank Gateway

This is conceptually similar to modern message brokers and API gateways.

But the requirements are much stricter.

20. Why Securities Messaging Must Be Reliable

#

Imagine an investor sends:

Buy 10,000 shares

The network breaks.

The brokerage system does not know whether the exchange received the order.

Now the system reconnects.

What should it do?

If it blindly resends:

Buy 10,000

the investor might accidentally purchase:

20,000 shares

This is unacceptable.

Therefore securities middleware needs concepts such as:

Message ID
Order ID
Sequence Number
Acknowledgement
Replay
Duplicate Detection
State Recovery
Reconciliation

21. Sequence Numbers

#

Suppose messages are:

1001
1002
1003
1004
1005

If the receiver receives:

1001
1002
1004
1005

it knows:

1003 is missing.

The system can request recovery.

This simple idea is fundamental to reliable financial messaging.

22. The Importance of Acknowledgement

#

An order can have several states:

Created
   ↓
Sent
   ↓
Received
   ↓
Accepted
   ↓
Executed

or:

Created
   ↓
Sent
   ↓
Rejected

These are not the same thing.

A middleware system must therefore distinguish:

Transport Success

from:

Business Success

For example:

TCP packet delivered

does not mean:

Exchange accepted the order.

23. This Creates a State Machine

#

A simplified order state machine:

NEW
 │
 ▼
SENT
 │
 ▼
ACKNOWLEDGED
 │
 ├──────────→ REJECTED
 │
 ▼
PARTIALLY_FILLED
 │
 ▼
FILLED

An order might also become:

CANCEL_REQUESTED
       ↓
CANCELLED

Middleware must preserve these transitions correctly.

24. The Problem of Duplicate Messages

#

Suppose:

Order 10001

is sent twice because of a communication failure.

The exchange may receive:

10001
10001

The middleware must determine whether these are:

Two legitimate orders

or:

One order transmitted twice.

Therefore:

Order ID
+
Sequence
+
Session State
+
Execution State

become extremely important.

25. Why This Looks Like Modern Distributed Systems

#

A surprising thing about securities middleware is that many problems now associated with distributed systems were already present:

Network Failure
Message Loss
Duplicate Messages
Out-of-Order Messages
Partial Failure
State Recovery
Idempotency
Replay
Consistency
Reconciliation

The technology in the 1990s was primitive compared with today’s systems.

The business problems were not.

26. The Branch Was Becoming a Thin Client

#

Under the old model:

Branch
   ↓
Local Database
   ↓
Local Transaction Engine

Under the centralized model:

Branch
   ↓
Network
   ↓
Central System

The branch increasingly became responsible for:

Customer Interaction
Order Entry
Receipt Printing
Local Device Management

while the central system handled:

Account State
Order Processing
Risk
Transaction State
Position
Routing

This is the historical ancestor of today’s centralized brokerage architecture.

27. Why This Was Difficult in the 1990s

#

Today we take for granted:

Broadband
TCP/IP
Data Centers
Load Balancers
Distributed Databases
Message Queues
Cloud Infrastructure

In the late 1990s, the environment was much more heterogeneous.

A brokerage might have:

Unix
Windows
DOS-era terminals
Proprietary network equipment
Different databases
Different exchange interfaces
Different branch systems

The architecture therefore had to tolerate technological heterogeneity.

28. The Real Meaning of “Heterogeneous Environment”

#

Imagine:

Branch A
   ↓
System A
   ↓
Database A

while:

Branch B
   ↓
System B
   ↓
Database B

and:

Exchange
   ↓
Protocol C

and:

Bank
   ↓
Protocol D

The middleware layer becomes the translator:

A ─┐
B ─┼──→ Middleware ──→ C
D ─┘

This is why historical securities middleware should be viewed as infrastructure rather than simply an application.

29. The Main Station as a Transaction Hub

#

A useful conceptual model is:

                 BRANCHES
             /      |      \
            /       |       \
           ▼        ▼        ▼
      Customer   Customer  Customer
           \        |        /
            \       |       /
             ▼      ▼      ▼
             CENTRAL MAIN
                STATION
                   │
                   ▼
             TRANSACTION
               MIDDLEWARE
                   │
          ┌────────┼────────┐
          ▼        ▼        ▼
       SH Market SZ Market Banks
          │        │        │
          ▼        ▼        ▼
       Exchange Exchange Banking

This is the basic shape of a centralized brokerage network.

30. The “Double Speed” Nature of Securities Networks

#

There was an interesting architectural tension.

Customer-side traffic could be:

Thousands of branches
Millions of customers
Large number of requests

while the exchange-side connection could be:

Relatively few trading seats
Highly controlled interfaces
Strict message formats

Therefore the brokerage middleware effectively performed:

Many-to-Few

aggregation.

Branch A ─┐
Branch B ─┤
Branch C ─┤
Branch D ─┼──→ Central Middleware ──→ Trading Seat
Branch E ─┤
Branch F ─┘

This is one reason centralized middleware could dramatically simplify the network.

31. From Many Branches to Few Market Connections

#

The old model:

Branch A → Exchange
Branch B → Exchange
Branch C → Exchange
Branch D → Exchange

could become:

Branch A ─┐
Branch B ─┤
Branch C ─┼──→ Central Trading Infrastructure
Branch D ─┤
Branch E ─┘
                    │
                    ▼
               Trading Seat
                    │
                    ▼
                 Exchange

The network topology became dramatically more centralized.

32. Centralization Also Changed Risk Control

#

Under local systems, risk checks could be performed locally.

But centralized architecture made it possible to evaluate:

Customer
+
Account
+
Existing Positions
+
Available Cash
+
Outstanding Orders

in one place.

For example:

Available Cash = 100,000

Existing Orders = 30,000

New Order = 80,000

The central system can immediately determine:

80,000 + 30,000 > 100,000

and reject or restrict the order.

This became increasingly important as trading volumes grew.

33. Centralization Also Solved the “Single Source of Truth” Problem

#

Suppose:

Branch A says:
Cash = 100,000

while:

Branch B says:
Cash = 80,000

Which one is correct?

A centralized account system can establish:

Central Account State
        ↓
100,000

Branches become views of the central state rather than independent authorities.

This is a profound change in system architecture.

34. The Securities Account Became a Central Data Object

#

Recall the previous article:

Shareholder
   ↓
Securities Account
   ↓
Position

Now add centralized brokerage:

Customer
   ↓
Central Client Record
   ↓
Securities Account
   ↓
Position

Orders from different branches can therefore operate against the same account.

Branch A ─┐
Branch B ─┼──→ Central Account
Branch C ─┘

This was difficult to achieve with independent branch databases.

35. The Transaction Main Station Became the Nervous System

#

A useful analogy is the human nervous system.

Branches are:

Hands
Eyes
Ears

The central system is:

Brain / Nervous System

The exchange is:

External Environment

The middleware is:

Neural Communication

This analogy is not exact technically, but it captures the architectural idea:

Branches interact with customers; the central system maintains transaction state; middleware moves messages between internal and external systems.

36. Why KCBP/KCXP Were Historically Important

#

The significance of KCBP/KCXP was not simply that they could send messages faster.

Their importance lies in the fact that they addressed the transition from:

Application-to-Application

toward:

Application
     ↓
Common Transaction Layer
     ↓
Multiple External Systems

This allowed brokerage applications to become less tightly coupled to individual external interfaces.

37. The Architecture Was Becoming Layered

#

By the end of the 1990s, a conceptual stack looked like:

┌─────────────────────────────┐
│ Customer / Branch Apps      │
├─────────────────────────────┤
│ Brokerage Business Logic    │
├─────────────────────────────┤
│ Transaction Middleware      │
│ KCBP / KCXP-type Layer      │
├─────────────────────────────┤
│ Communication / Protocol    │
├─────────────────────────────┤
│ Trading Seat / Gateway      │
├─────────────────────────────┤
│ Exchange                    │
└─────────────────────────────┘

This layering is crucial.

Each layer solves a different problem.

38. The Same Architecture in Data Flow Form

#

An order:

BUY 600000 1000 @ 10.00

could conceptually travel as:

Customer
   ↓
Branch Application
   ↓
Central Brokerage
   ↓
Risk Check
   ↓
Transaction Middleware
   ↓
Routing
   ↓
Message Transformation
   ↓
Trading Gateway
   ↓
Trading Seat
   ↓
Exchange

The execution comes back:

Exchange
   ↓
Trading Seat
   ↓
Trading Gateway
   ↓
Middleware
   ↓
Central Brokerage
   ↓
Branch
   ↓
Customer

The complete round trip is therefore:

ORDER PATH

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


EXECUTION PATH

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

39. And Then Comes Clearing

#

Execution is not the end.

After:

ORDER
 ↓
TRADE

the system still has to process:

CLEARING
 ↓
SETTLEMENT
 ↓
POSITION UPDATE
 ↓
CASH UPDATE

Therefore the complete architecture becomes:

Trading
   ↓
Execution
   ↓
Clearing
   ↓
Settlement
   ↓
Registration
   ↓
Account / Position

The brokerage system must reconcile its own records with external records.

40. Reconciliation Became Essential

#

Imagine the brokerage system says:

Trade count = 10,000

while the exchange or clearing system says:

Trade count = 9,999

There is a problem.

The system must determine:

Which trade is missing?

This is why historical securities systems required:

Daily Reconciliation
Trade Reconciliation
Cash Reconciliation
Position Reconciliation
Settlement Reconciliation

These functions became major parts of brokerage software.

41. A Securities System Is Therefore Not Just a Trading System

#

This distinction is extremely important.

A brokerage platform is more accurately:

Customer Management
+
Account Management
+
Order Management
+
Trading
+
Clearing
+
Settlement
+
Registration
+
Risk
+
Reconciliation

Trading is only one component.

42. Why Centralization Accelerated Around the Late 1990s

#

Several forces came together:

Rapid investor growth
        +
More securities
        +
More branches
        +
Higher trading volumes
        +
Electronic exchanges
        +
Multiple external systems
        +
Stronger risk requirements
        +
Need for unified accounts

Together they made branch-local architectures increasingly difficult to maintain.

43. The Old Architecture Was Running Out of Road

#

The local model:

Branch
 ↓
Local DB
 ↓
Local Transaction Engine
 ↓
Exchange

created problems such as:

Data duplication
Synchronization
Inconsistent account state
Complex maintenance
Difficult risk control
Multiple exchange interfaces
Difficult upgrades
Difficult disaster recovery

Centralization addressed many of these problems:

Branches
   ↓
Centralized Brokerage
   ↓
Centralized Transaction Layer
   ↓
External Markets

44. But Centralization Created New Problems

#

Centralization was not free.

Now the central system became:

Critical Infrastructure

If it failed:

Many branches
   ↓
Unable to trade

Therefore new requirements appeared:

High Availability
Backup
Disaster Recovery
Hot Standby
Message Recovery
Load Management
Fault Isolation

This is another major reason securities IT became a specialized engineering discipline.

45. Centralized Systems Needed High Availability

#

Suppose:

Central Main Station

fails at:

10:30 AM

during active trading.

The consequence could be:

100 branches
×
Thousands of investors

unable to trade.

So architecture increasingly moved toward:

Primary
  │
  ├── Backup
  │
  └── Recovery

and eventually:

Active
   ↓
Standby
   ↓
Disaster Recovery

46. The Middleware Layer Also Needed Redundancy

#

It was not enough to back up the database.

Suppose:

Database = healthy

but:

Trading Middleware = down

The brokerage still cannot trade.

Therefore redundancy had to cover the transaction path:

Branch
 ↓
Main System
 ↓
Middleware
 ↓
Gateway
 ↓
Trading Seat
 ↓
Exchange

The entire chain had to be designed for failure.

47. This Is the Hidden Story Behind “Centralized Trading”

#

When historical documents say:

某证券公司完成集中交易系统建设

the important question is not merely:

“Did they install a centralized server?”

The deeper questions are:

Where did customer data move?

Where did account data move?

Where were orders processed?

Where was risk checked?

Where was routing performed?

Where did the exchange connection terminate?

Where were messages transformed?

Where were execution reports stored?

Where was the final position calculated?

These questions reveal the real architecture.

48. A Full Late-1990s Architecture

#

A conceptual architecture can now be drawn as:

                         INVESTORS
                             │
                             ▼
                     ┌──────────────┐
                     │   BRANCHES   │
                     └──────┬───────┘
                            │
                            ▼
                 ┌────────────────────┐
                 │ Central Brokerage   │
                 │ System              │
                 ├────────────────────┤
                 │ Customer Management │
                 │ Account Management  │
                 │ Order Management    │
                 │ Risk Control        │
                 └─────────┬──────────┘
                           │
                           ▼
                 ┌────────────────────┐
                 │ Transaction         │
                 │ Middleware          │
                 │ KCBP / KCXP-type    │
                 │ Infrastructure      │
                 └─────────┬──────────┘
                           │
             ┌─────────────┼─────────────┐
             │             │             │
             ▼             ▼             ▼
        SH Gateway    SZ Gateway      Bank Gateway
             │             │             │
             ▼             ▼             ▼
        Trading Seat   Trading Seat    Banking
             │             │
             ▼             ▼
          SSE           SZSE

This is much closer to the architecture that shaped Chinese securities software around 1997–2001.

49. Why the “Seat” Became an Abstraction

#

Originally:

Seat

had a strong physical meaning.

It was a place in the exchange trading environment.

As electronic trading matured, the important concept became:

Trading Access Identity

rather than the physical chair itself.

So the architecture evolved from:

Physical Seat

toward:

Logical Trading Channel

This is a classic example of a physical financial institution being transformed into a software object.

50. The Same Thing Happened to the Shareholder Card

#

There is a beautiful symmetry here.

In the 1980s:

Physical Stock Certificate

became:

Securities Account

In the exchange:

Physical Trading Seat

increasingly became:

Electronic Trading Access

In the brokerage:

Physical Branch

increasingly became:

Network Client / Service Node

The financial market was progressively turning physical objects into logical identities.

51. Three Major Transformations Happened Together

#

The evolution can therefore be understood through three parallel transitions.

Ownership

#

Paper Certificate
        ↓
Securities Account

Customer Service

#

Physical Branch
        ↓
Networked Client

Market Access

#

Physical Trading Seat
        ↓
Electronic Trading Channel

And all three were connected by:

Transaction Middleware

52. This Explains the Rise of Securities Middleware Companies

#

Once these transformations happened, brokerages needed specialized infrastructure.

They needed systems that could:

Accept messages
Validate messages
Route messages
Transform messages
Send messages
Receive acknowledgements
Track state
Recover failures
Reconcile transactions

That is not ordinary accounting software.

It is infrastructure software.

And this is precisely where Chinese securities software companies developed a distinctive competitive advantage.

53. KCBP/KCXP Should Therefore Be Studied as Infrastructure

#

Instead of asking:

“What application screen did KCBP provide?”

a better question is:

What infrastructure problem did KCBP/KCXP solve?

The answer is broadly:

Centralized brokerage
        ↓
Transaction processing
        ↓
Message routing
        ↓
External market connectivity
        ↓
Reliable execution handling

The exact implementation details depend on the historical version and deployment.

But the architectural role is much clearer.

54. And This Leads Directly to the “Double-Speed Network”

#

By the end of the 1990s, the securities network effectively had two very different speeds.

Customer / Branch Side

#

Many branches
Many users
Many requests

This side was:

High Fan-In

Exchange Side

#

Fewer trading channels
Strict protocols
Highly controlled connectivity

This side was:

Controlled Market Connectivity

The middleware sat between them:

Many
 ↓
Central Transaction Layer
 ↓
Few

This is the architectural foundation of what can be called a dual-speed securities network.

55. The Historical Evolution in One Diagram

#

1980s
──────────────────────────────

Investor
   ↓
Physical Stock
   ↓
Manual Registration


Early 1990s
──────────────────────────────

Investor
   ↓
Branch
   ↓
Local Computer
   ↓
Trading Seat
   ↓
Exchange


Mid/Late 1990s
──────────────────────────────

Many Branches
      ↓
Central Brokerage
      ↓
Transaction Main Station
      ↓
Middleware
      ↓
Trading Seat
      ↓
Exchange


Around 2000
──────────────────────────────

Customers
      ↓
Centralized Brokerage
      ↓
Transaction Middleware
      ↓
Multiple Market Gateways
      ↓
Exchanges / Banks / Registration

56. The Key Lesson

#

The history of Chinese securities IT is not simply a history of increasingly powerful computers.

It is a history of centralization and abstraction.

The market progressively transformed:

Physical Certificate
        ↓
Electronic Account

Physical Branch
        ↓
Network Node

Physical Seat
        ↓
Trading Channel

Telephone
        ↓
Message

Manual Ledger
        ↓
Database

Clerk
        ↓
Transaction Engine

And eventually:

Independent Systems
        ↓
Middleware
        ↓
Integrated Securities Network

57. Why 1997–2001 Is Such an Important Period

#

This period sits exactly between two worlds.

Before:

Branch-centric
Paper-heavy
Human-mediated
Local databases
Physical trading environments

After:

Centralized
Electronic
Account-based
Networked
Middleware-driven
Exchange-connected

The transition was not instantaneous.

For several years, both models existed simultaneously.

That is why historical securities systems can look strange to modern engineers.

They are literally hybrid architectures from a transitional era.

58. The Next Problem: AS/AR vs KCBP/KCXP

#

Once centralized brokerage systems became common, another question emerged.

If both major Chinese securities software vendors were solving essentially the same problem:

Branch
 ↓
Central Brokerage
 ↓
Transaction Middleware
 ↓
Trading Seat
 ↓
Exchange

why did their architectures evolve differently?

This brings us to the comparison between:

Kingstar / 金证
KCBP / KCXP

and:

Hundsun / 恒生
AS / AR