FinTech & Trading
Order Management System for a Broker: Buy a Vendor OMS, Extend the One in Your Trading Platform, or Build Your Own
What an order management system does for a broker, how it differs from an EMS and from the order handling inside a trading platform, what EU and US rules expect from order records, and when to buy, extend or build.
By amBrain9 min read
In this article
A broker's order management system (OMS) is the software that handles a client's order from the moment it arrives until it is filled or cancelled. It checks the order, sends it to a venue or another broker, follows it and records every step. You can buy one from a vendor, extend the order handling already inside your trading platform, or build your own. The right choice depends on how many platforms and venues your orders pass through, and on whether the way you handle orders is part of what you sell. The duties do not change with the choice. Your firm answers for the risk checks and the records, whoever wrote the software.
The short answer: extend your trading platform if most clients trade on it and the gap is narrow, such as one risk rule or one new liquidity provider. Buy a vendor OMS if you handle orders much like the vendor's other clients and need many venue connections soon. Build your own when orders arrive through several platforms and you want one record and one set of risk limits across them. On every path, make sure you can export the full order history.
What does an order management system do for a broker?
An order goes through the same steps wherever it comes from: a mobile app, a desktop terminal, the client's own software through an API, or a call to your dealing desk. The OMS is the part of your systems that runs those steps:
- It accepts the order and gives it an ID that stays with it to the end
- It runs pre-trade checks: enough money or margin, size and price within limits, and permission to trade the instrument
- It sends the order to an exchange, a liquidity provider or an upstream broker
- It tracks the order's state, such as working (still open in the market), partly filled, filled, cancelled or rejected, and any changes the client makes along the way
- It passes each fill back to the client's account and to your back office
- It records every step with its time
The sending step often runs over FIX, a shared message format that brokers and venues use to pass orders and fills between them. The FIX Trading Community, which maintains it, describes the FIX Protocol as “a global, open standard that enables financial institutions to communicate trading information”. Its list of trade messages starts with “Orders and executions”. Ask each venue and broker you plan to connect to which FIX version and which messages it expects.
How is an OMS different from an EMS and from our trading platform?
In this article, the OMS is the system that keeps the official record of orders: what each client asked for and what happened to it. An execution management system (EMS) is a trader's tool for working an order in the market. For example, it can split a large order into smaller ones or hand it to an execution algorithm. Vendors use the two names loosely, and many products do both jobs.
Retail brokers often have a third kind already: the order handling inside their trading platform. The platform's server accepts the order, checks the account, and either keeps the risk with the broker or passes the order on through a connector called a gateway. On its page for brokers, MetaQuotes says a MetaTrader 5 gateway “enables brokers to instantly hedge their risk”. For many brokers, this built-in handling is their OMS, even if nobody calls it that.
What do regulators expect from the order records?
A complete record of every order with its times, and procedures that treat client orders fairly. US rules also require a broker with market access to keep its risk controls in its own hands.
In the EU, Article 25 of MiFIR says investment firms “shall keep at the disposal of the competent authority, for five years, the relevant data relating to all orders and all transactions in financial instruments which they have carried out”. Article 28 of MiFID II asks firms that execute client orders for “procedures and arrangements which provide for the prompt, fair and expeditious execution of client orders, relative to other client orders or the trading interests of the investment firm”.
Article 27 of MiFID II, on best execution, says a firm must be able to show a client, on request, “that they have executed their orders in accordance with the investment firm's execution policy”. To show that, a firm needs a record of when each order arrived and where it went.
In the US, SEC Rule 17a-3 requires broker-dealers to keep a record of each brokerage order, whether it was executed or not. The rule calls this record a memorandum. It must show “the terms and conditions of the order or instructions”, “the time the order was received, the time of entry, the price at which executed” and, “to the extent feasible, the time of execution or cancellation.”
FINRA is the self-regulatory body that oversees US broker-dealers. SEC Rule 613 requires FINRA and the US national securities exchanges to jointly submit a plan for a consolidated audit trail, known as CAT. FINRA's page describes it as a consolidated audit trail “that collects and accurately identifies every order, cancellation, modification and trade execution for all exchange-listed equities and options across all U.S. markets.” The same page says “each member of a national securities exchange or national securities association is required to comply with all the provisions of the CAT NMS Plan.”
SEC Rule 15c3-5 requires a broker-dealer with market access to “establish, document, and maintain a system of risk management controls and supervisory procedures”. Those controls “shall be under the direct and exclusive control of the broker or dealer”, with a narrow exception for customers that are themselves broker-dealers. You can buy the software, but the limits stay under your control.
All sources in this article were opened on 2 November 2026. The article covers only EU and US rules. Other countries have their own.
What stays the same whichever path we choose?
These jobs exist on every path. What changes is who writes and runs the software:
- Pre-trade risk checks on every new order and on every change to a working order, with limits that your own risk staff set
- An audit trail: every order, change, cancellation, fill and rejection with its time, kept for as long as your rules require
- FIX connections to each venue and upstream broker, each one set up and tested with the firm on the other side
- Reconciliation: a daily match of your orders, fills and positions against the records of your venues, brokers and clearing firm, with every difference explained
A vendor or a platform can do part of this work for you, but your firm still answers for all of it.
When should a broker buy a vendor OMS?
Buy when your order flow looks like that of the vendor's other clients. Typical signs:
- You trade the asset classes and order types the product already supports
- You need connections to many venues or brokers soon, and the vendor already runs those connections
- Your team is small, and you want someone else to keep the connections working when venues change their specifications
- What sets you apart is your pricing or your app, not the way you handle orders
What you give up is control. Your rules have to fit the vendor's settings, and a feature you need waits until the vendor plans it or you pay for custom work.
When should we extend the order handling in our trading platform?
Extend when most of your clients trade on one platform, its order handling works, and only a narrow piece is missing. That piece might be a risk rule its settings cannot express, a route to a new liquidity provider, or a link to your back office. Platform makers offer programming interfaces, called APIs, for this. MetaQuotes says its “Gateway API is used for MetaTrader 5 integration with other trading systems and creation of custom data feeds.” Spotware describes the Manager's API of its cTrader platform as giving brokers “Full control over cTrader server entities”.
Before you extend, find out:
- Whose licence the platform runs on, and what happens to your additions if that licence ends
- How your additions are tested each time the platform maker releases a new version
- Whether the interface gives your code every order and every change in time to act on it, and not just a report at the end of the day
Code written for one platform's interfaces does not move to another platform. If you plan to offer clients a second platform, keep the shared parts, such as the risk checks and the order record, outside both of them.
When is building our own OMS worth it?
Building your own pays off in these cases:
- Orders arrive through more than one platform or channel, and you want one record of every order and one set of risk limits across all of them
- Your order handling is part of what you sell, for example your own routing rules or order types that the products you tested do not support
- Fees per user, order or connection have grown larger than the cost of a team that runs your own system
- You want the complete order history in your own database, in a layout you control
- You plan to add or change platforms and venues, and you do not want to rebuild your records each time
It does not have to mean replacing everything. Often it is one layer between your client channels and your venues that holds the order record and the risk checks, with your existing platforms left in place underneath.
The work does not end at launch. Someone has to answer alerts during trading hours and keep up with each venue's specification when it changes. If you have nobody for that and do not plan to hire anyone, buy or extend first.
What should we check before signing with an OMS vendor?
- Can we export the complete order history and audit trail at any time, in a documented format, and what does that cost when we leave?
- Who sets and changes risk limits: our staff in our own screens, or the vendor's support team on request?
- Which venues and brokers are connected and in use by other clients today, and which are only planned?
- How do the fees change when the number of users, orders or venue connections doubles?
- What happens to working orders if the OMS or one connection goes down, and can our staff cancel all working orders for one account or for the whole firm?
- How are custom rules priced and scheduled, and who owns the code written for us?
- How much notice do we get if the vendor withdraws or reprices the product?
What does owning the code and the data mean?
Owning the code means you receive the source code with everything needed to build and run it, and you may hire any team to change it. Owning the data means every order record sits in a database you control, in a documented layout, so a regulator's request does not wait on anyone else.
A vendor owns the code of its OMS, and a platform maker owns its platform. Your data, and any additions you paid for, are yours only if the contract says so. With your own build, you can own both. Ask the builder to list in the contract any components it keeps, and the licence under which you may keep using them.
What should we ask a firm that would build it?
- Which order states will the system track, and how does it handle partial fills and changes to a working order?
- After a restart in the middle of the trading day, how does the system rebuild working orders and positions, and check them against the venues' records before trading resumes?
- Which venues and brokers will you connect first, over which FIX version, and who arranges the testing with each of them?
- Where do the risk checks run, how long do they take, and how was that measured?
- What is written to the audit trail for each order, with which timestamps, and can the system produce the records our regulator asks for?
- How does the daily reconciliation work, and who is told when it finds a difference?
- Can you show this working in a system that runs today?
Where does amBrain fit?
amBrain publishes this blog. It describes this part of its work in one line: “amBrain builds algorithmic trading infrastructure: order execution, market data and pre-trade risk controls.” Another line on amBrain's website reads: “Trading terminal development, order management systems, and FIX protocol exchange integration.”
amBrain has been building software since 2019. On how it works with clients, it says: “Three formats: full delivery, a dedicated team, or engineers embedded in your team.” Its line on ownership is “The client keeps full ownership of the product and the code, except our reusable components.” Ask for the list of those components by name before you sign.
This article is not a case study and describes no client work. It does not say that amBrain has built, bought or extended an OMS for any client. It quotes the FIX Trading Community, MetaQuotes, Spotware and FINRA from their published pages and claims no relationship between amBrain and any of them. It gives no amBrain prices or timelines.
It is not legal advice either. Check the rules that apply to your firm with a lawyer. If amBrain is on your shortlist, ask it the same questions as any other firm.
Topics
- Order Management
- Brokerage
- FIX Protocol
- Build or Buy