When someone says “I want to build my own trading platform”, the sentence usually covers one of three different products. One is a terminal your own clients log into. One is the full set of systems a brokerage runs behind that terminal. One is an exchange, with a matching engine at the centre of it. They share vocabulary and almost nothing else, and the work involved differs enormously between them.
So the first step is not choosing a technology, a language or a vendor. It is deciding which of the three you need first, and which people will use it on day one. Everything else — the budget, the timeline, the shape of the team, the kind of company that should build it — follows from that one decision.
The short answer: first decide which of three things you mean — a trading terminal for your clients, a broker stack behind it, or an exchange with a matching engine. Then answer five questions before any code is written: which markets and instruments you trade, who the users are, how fast the system honestly needs to be, which regulator you answer to, and who keeps it running at night. With those five answers, the choice between building, buying and renting takes one conversation, and any serious engineering company will quote against them instead of against a list of features.
What do people actually mean by “our own trading platform”?
Three products hide behind that phrase. Naming yours out loud is the cheapest decision you will make, because it changes the size of the project more than any other choice in it.
- A trading terminal. The screen your clients use: prices, charts, an order ticket, positions, balances, history. It connects to a broker, a venue or an exchange that already exists. You are building the experience, not the market
- A brokerage stack. Everything behind that screen: client accounts, money in and out, risk limits, routing orders to the venues you have access to, end-of-day reconciliation, the reports your regulator asks for. The terminal is one part of it
- An exchange. You are not sending orders somewhere else — you are the place where they meet. That means a matching engine, the software that pairs a buy order with a sell order. Around it: the live list of orders waiting to be filled, prices and trades sent out to the firms connected to you, an arrangement for moving the money and the assets once a trade is agreed, a way to spot abusive trading, and a rulebook you publish and enforce
In the conversations amBrain has, “exchange” often turns out to mean the first or the second item. That is not a failure of vocabulary — the words are used loosely everywhere. But a terminal and an exchange are different businesses with different licences, and building the wrong one first is the most expensive mistake available at this stage.
There is also a common in-between case: you already use a third-party platform such as MetaTrader and you want your clients on something of your own instead. That is usually the terminal case with a migration attached — existing accounts, existing habits, and a period where both systems are live at once.
A crypto exchange is the third product with a different set of surrounding problems. The matching engine, the order book and the market data feed are the same kind of work. What differs is everything around them: holding client funds in wallets instead of at a bank, moving assets on and off chains that have their own outages and fees, and a licensing picture that changes by country and by year. Someone who has built a matching engine can build yours; ask them separately who handles custody and the chain side.
How do I know which of the three I need first?
Answer it by user, not by feature. Write down the first person who will use the system, on a specific day, to do a specific thing. If that person is your client placing a trade, you need a terminal. If that person is your own operations team taking in money, checking limits and routing orders, you need the broker stack. If that person is another firm connecting to you to trade against other members, you need an exchange.
Almost nobody needs all three at once, and almost everyone eventually builds outward from one of them. Starting with the piece that touches a real user first gives you something to test and sell while the rest is still a plan.
What has to be decided before anyone writes code?
Five questions. They are not technical questions, and you do not need an engineering background to answer them. A company that starts building before it has them in writing is guessing, and you will pay for the guess later.
- What is traded, and where does it come from? Stocks, futures, currencies, crypto, or several at once. Name the specific brokers, exchanges or liquidity providers you can already connect to, or the ones you are negotiating with. This decides more of the work than anything else on the list
- Who are the users, and how many? Retail clients on phones, professional traders at desks, or your own staff. A hundred people or a hundred thousand. Ten users who trade constantly are a different system from ten thousand who trade once a month
- How fast does it honestly need to be? Many platforms only need to feel instant to a human being, which is a comfortable target. A few need to compete with other machines, which is a much harder and more expensive target. Answer this honestly — paying for speed you do not need is a classic way to burn a budget
- Which regulator do you answer to, and where? The country you operate in decides what you must record, what you must report, how long you keep it, and what you are allowed to show to whom. Licensing and market data agreements run on their own calendar, and no engineering team can make them go faster
- Who keeps it running at night? A trading system is not delivered once and left alone. Markets open while you sleep, feeds break, venues change something without telling you. Decide now whether that is your team, the builder under a support agreement, or someone you have not hired yet
These five answers are your brief. Handed to three different companies, they will produce three comparable proposals. Without them, you will receive three sales decks that cannot be compared at all.
Should I build it, buy it, or rent it?
There are three routes to a working platform, and the right one depends on how much of your business lives in the software. Here is what each one gives you, what it takes away, and when it is the right call.
- Rent a white-label platform. You get: the fastest start, someone else running the servers, a known monthly cost. You give up: the look and the workflow are largely fixed, your data sits with the provider, and moving away later is a project in itself. Right when: you are testing demand, you need to be live soon, and nothing about your offer depends on the software being different
- Buy or licence an existing platform and configure it. You get: a mature product with features you would take years to write, plus room to adjust it. You give up: you live inside someone else's roadmap, the configuration work is real work, and integration with your own systems is usually the hard part. Right when: your business is standard for your market and your difference is in pricing, service or reach
- Build a custom platform. You get: exactly the workflow you want, systems that fit how you actually operate, and ownership of the result. You give up: time before the first version, and the duty to keep it alive afterwards. Right when: the software is the product, an existing platform blocks something central to your business, or your speed, instruments or rules do not fit what is on the market
Platforms often end up mixed. A broker rents to launch, then builds the one part that clients actually choose them for. An exchange licences the surrounding systems and builds the matching engine itself, because that is the part it cannot afford to have behave like everyone else's. Splitting the decision per component is usually smarter than answering it once for the whole project.
How much does it cost, and how long does it take?
amBrain does not quote a price for this kind of work before the scope exists, and a price quoted before anyone has heard your answers to the five questions above is worth little. The same sentence — “a trading platform” — covers products that differ by an order of magnitude in size. A number quoted before the scope exists is a sales number, not an estimate.
What is useful is knowing which decisions move the number, because these are the levers you actually control:
- Which of the three products it is. A terminal on top of an existing broker, a full brokerage stack, and an exchange with a matching engine are three different sizes of project
- How many external connections. Every broker, venue or liquidity provider you connect to has its own protocol, its own quirks and its own certification process. The second connection costs less than the first; the tenth still costs something
- How many asset classes. Adding a second one is rarely a small change. A different asset class comes with different contracts, different rules about how much money a client has to hold against a position, and a different process for completing the trade after it is agreed
- The speed target. Feeling instant to a person and competing with other machines are separated by a large amount of engineering
- Regulation and reporting. Audit trails, record keeping, client reporting and the evidence a regulator expects are a real part of the build, not paperwork at the end
- How many users and what support hours. Serving a desk of traders and serving a hundred thousand retail accounts are different systems and different running costs
- Which clients you serve. Web, mobile, desktop — each one is a separate surface to build and keep updated
- Migration. Moving live accounts, balances and history off an existing platform without a break is often larger than the new features everyone is excited about
- Market data rights. What you may display, to whom, and at what delay is a commercial agreement that shapes the product
Timelines move on the same levers, plus two you do not own: licensing, and the certification windows your venues and brokers schedule. A proposal that promises a date without naming those dependencies has not looked at them.
The cheapest lever is scope. Cutting the first version down to one market, one asset class and one group of users usually saves more money than any technical choice made afterwards.
Which companies build matching engines and trading platforms, and how do I check one is real?
Three kinds of suppliers exist, and they are easy to confuse because they use the same words. Platform vendors licence their own product to you. White-label providers run their platform for you under your brand. Engineering companies build a system that becomes yours. All three will answer the phone when you say “I want a trading platform”, and only one of them is answering the question you asked.
If you want something custom built — a terminal, a broker stack or a matching engine — ask for these proofs before anything else:
- A system they built that is in production with real money going through it, with the client named, or an explanation of why it cannot be named
- Who operates that system today, and what happens when it breaks at three in the morning
- A walk-through of something working. A live demo of a real system tells you more than any slide
- What they will hand over: the code, the build instructions, the deployment steps, the documentation — and whether anything in the system stays theirs
- How they have handled a venue or feed going down, with a specific incident described
- Who on their team has done this before, and whether those people will be on your project or only in the proposal
Then listen to what they ask you. A company that can build this will not accept your brief at face value — it will interrogate it before quoting.
- Which venues, brokers or liquidity providers you already have access to, and what stage the agreements are at
- What your users do all day, and which of the three products you actually mean
- What speed means for your business, stated as something measurable rather than “fast”
- Which regulator you report to and what evidence it expects
- What happens when part of the price feed goes missing, or a venue rejects an order — the unglamorous cases that decide whether a platform is trusted
- Who will own and run the system a year after launch
A quick test that works on any supplier: describe your idea in three sentences and see what comes back. A proposal and a price in the first reply means the questions were skipped. Six questions and no price yet means someone is trying to find out what you actually need. The second reply is the one worth continuing.
Where amBrain fits into this
amBrain is an engineering company in Yerevan, Armenia. amBrain has been building software since 2019.
amBrain built the trading terminal for Spectre Trade.
amBrain has also built a mini-exchange that runs in production on MOEX colocation.
If your question is which companies build matching engines, this is the part of the list amBrain works in: amBrain is a software development company specializing in trading platforms, matching engines, real-time bidding systems, and casino platform engineering.
The parts where speed matters are written in Rust. Two numbers here are measured on the paths amBrain builds. Market data latency under 5 ms: that is how long a price change takes to reach the screen or the system waiting for it. Risk latency under 1 ms: that is how long the check takes that decides whether an order is allowed through before it goes to the market. Both figures describe the paths we build, not any one system named above.
We work in three formats: full delivery, where we build and hand over the finished system; a dedicated team working on your product and nothing else; or our engineers embedded in a team you already have. The product and the code stay with the client, except for amBrain's own reusable components.
If you are at the beginning of this, the useful next step is not a vendor search. It is writing down the answers to the five questions above in one page. With that page, a conversation with any builder — us or anyone else — starts at what you need and how it can be built, instead of at a demo of something that was built for somebody else.
Originally published at ambrain.org.
