Insights · 5 min read
A trading platform is far more than a chart and an order button. What brokers need from order matching, market data, and settlement, and what it costs to build.
By GGP Editorial
Most people picture a trading platform as a chart with a buy and sell button. That part is visible, and it is maybe ten percent of the work. The rest is order matching, market data, settlement, and a long list of compliance rules that change from one exchange to the next. If you are a broker or a fintech team planning to build one, here is what you actually need.
A working platform is four systems that have to run at the same time. Order entry is what the user sees: quotes, depth, positions, and the buttons to place and cancel an order. Market data feeds carry prices from exchanges to the platform. The matching engine pairs buy and sell orders. Settlement and reconciliation track cash, positions, and fees after trades settle.
New teams usually underestimate the matching engine. A basic engine that matches by price and time is not hard. The hard part is everything around it: market, limit, and stop orders, partial fills, and the audit trail a regulator will ask for. Every order event has to be logged and reproducible. If you cannot replay what happened at 09:31 on a given day, you have a problem that will surface during an audit.
GlobeSoft built a multi-market brokerage system that trades Hong Kong, US, and A-share stocks from a single account. That project taught us things a single-market demo never shows.
Each market has its own trading hours, currency, and settlement cycle. US equities settle on T+2, A-shares on T+1, and short-selling and lot-size rules differ everywhere. A platform that ignores these details shows the user the wrong balance or lets them place an order the exchange rejects.
Currency is another trap. If a customer holds USD and buys a Hong Kong stock quoted in HKD, the platform has to convert, show the rate, and time the exchange. Get the timing wrong and you lose money on every trade, not just on the commission.
| Market | Trading hours (UTC) | Settlement | Lot rules |
|---|---|---|---|
| US (NYSE, Nasdaq) | 14:30-21:00 | T+2 | 1 share, odd lots allowed |
| Hong Kong (HKEX) | 01:30-08:00 | T+2 | Board lots vary by stock |
| A-shares (SSE, SZSE) | 01:30-07:00 | T+1 | 100-share lots |
The table is simplified, but the point stands: one platform, three sets of rules, and all of them drift over time.
Costs vary a lot because a trading platform can mean a white-label front end or a full matching engine.
| Scope | Typical cost | Typical timeline |
|---|---|---|
| Front end on an existing broker API | $20k-50k | 2-3 months |
| Multi-market platform with own back office | $80k-250k | 5-9 months |
| Full matching engine and clearing | $300k and up | 12 months or more |
Most teams should start with the front end on a broker or liquidity provider API, then build their own back office once volume justifies it. Building a matching engine from day one is almost always a mistake. The exceptions are rare and usually involve a license that requires you to own the infrastructure.
If you are starting from zero, ship order entry and market data first, wired to a broker's execution API. Skip the fancy analytics and the social feed. Users open a trading app to place an order and check a position; everything else can wait. Once real trades are flowing, add the back office pieces that let you reconcile and report. That sequence keeps the early scope small and gets you feedback from real users instead of a demo audience.
Latency and data quality cause more production incidents than anything else. A feed that drops for three seconds during market open is not a small bug, it is money. Compliance is the second one: know-your-customer checks, anti-money-laundering rules, and audit logs have to ship in the first release, not get bolted on later.
Our stack for this kind of system is Java and Spring Boot for the back end, MySQL and Redis for state, and Vue or React on the front. It is boring technology, and that is the point. A trading platform is not the place to experiment with the newest framework. You want a stack that is stable, well documented, and easy to hire for.
If you plan to serve customers in more than one market, think about support hours early. A platform that trades three markets runs nearly around the clock, and questions do not stop at 5pm. GlobeSoft delivers across time zones with overlapping hours and a dedicated group, so a team in one region hands off to the next. For a fintech product, that coverage is part of the product, not a nice-to-have.
Pick your market data vendor early and test their failover before you sign. The cheapest feed is not cheap when it goes down during a volatile session, and switching vendors mid-project costs more than the savings. The same rule applies to your payment and settlement rails: a platform that trades but cannot settle cleanly at the end of the day is a liability, not a product.
Tell us what you are building and where you are today. We typically reply within 24 hours.
