Insights · 5 min read
A trading platform is not a chart and a buy button. Order routing, market data, risk, and settlement all have to agree across markets on different clocks.
By GGP Editorial
A trading platform looks simple from the outside. A chart, an order ticket, a positions table. People assume the hard part is the interface, and it isn't. The hard part is everything that has to happen between the moment a user taps "buy" and the moment the fill comes back, plus everything that has to stay true about that fill afterwards.
I have watched teams spend months polishing the front end and then freeze when they reach order routing. So here is where the work actually sits, based on a brokerage system we built that runs Hong Kong stocks, US stocks, and A-shares from a single platform.
The UI is maybe ten percent of the job. The rest is plumbing. An order has to be validated (does the account have the buying power, is the instrument tradable this second), routed to the right venue, matched, filled, and written back to both the position and the ledger. Every one of those steps can fail in its own way, and each failure has a different fix.
The three markets we support do not behave alike, which is the real source of pain:
| Market | Session (local) | Settlement | What trips people up |
|---|---|---|---|
| Hong Kong | 09:30-16:00 HKT | T+2 | Frequent half-days and public holidays |
| US | 09:30-16:00 ET | T+2 | Pre/post market, daylight saving shifts |
| A-shares | 09:30-15:00 CST | T+1 | Price limits, no same-day round trip |
A system that treats all three the same will break within a week. The session calendar alone is a full module. Get a Hong Kong public holiday wrong and you let orders through on a day the market is closed, which is the kind of bug clients remember for a long time.
Order types are another quiet source of scope creep. Market orders, limit orders, stop-loss, take-profit, and conditional orders that trigger other orders. Each one needs its own validation path and its own edge-case tests. The trading team will ask for a new order type the same week you thought you were done.
The part founders rarely budget for is the back office. Positions have to reconcile against the clearing house every single day. Margins have to be computed in real time, otherwise a client buys more than they can cover and you eat the loss. Corporate actions (splits, dividends, rights issues) have to be applied to positions, or your P&L slowly drifts away from reality.
This is where a project succeeds quietly or fails loudly. A fill that doesn't match a position report by a few cents, multiplied by a few thousand trades, turns into an audit problem nobody can explain on the spot. Build reconciliation in from day one. Retrofitting it after launch is miserable and expensive, and I have not met a team that enjoyed it.
For this kind of system we default to Java with Spring Boot and Spring Cloud. The services stay small and independent, so the order gateway can scale without dragging the market data service along with it. Redis sits in front of the hot data (live quotes and positions), because a database round trip is too slow when a quote is moving every tick. MySQL holds the ledger, where durability beats speed. Nginx fronts the API and absorbs the burst of requests when a market opens.
None of that is exotic, and that is the point. A trading platform is not the place to try the new database you read about last week. Boring, proven parts are a feature here, not a compromise.
GlobeSoft is a China-based team, and we have shipped for clients in Brazil, South Africa, Singapore, and the US. I want to be honest about the trade-off. The time difference is real, but it is manageable when both sides commit to a shared overlap window. We schedule a daily block where the client's morning meets our evening, keep a dedicated group chat open, and run everything in English (or Portuguese when the client prefers it).
The payoff is the part clients notice first: a bug filed at your 6pm is often fixed by your morning, because our day was just starting when yours ended. That rhythm is why offshore works for trading systems specifically, where issues never wait for a convenient hour. The same team builds financial systems, online payment, and property platforms, so a brokerage project rarely surprises us.
If you are planning a trading platform, or already have one that is creaking, tell us what you are dealing with.
Tell us what you are building and where you are today. We typically reply within 24 hours.
