Broker API order management integration: example scenario

This page does not describe a real client project. It is an example scenario that shows how Fincode approaches this kind of work. Technical details are based on official documentation; scope, timeline and price are set for each project.

Project summary
Who it is for	The treasury team of a company trading equities for its own account (example scenario)
Service	Exchange API integration
Platforms	Brokerage trading API (FIX or REST/WebSocket), Borsa Istanbul Equity Market
Technologies	Python or Java, PostgreSQL, message queue, FIX engine
Deliverables	Order management service, permission and risk module, reconciliation reports, source code and documentation

The need and the legal frame

In this scenario, the treasury team of a company that trades shares on Borsa Istanbul for its own account enters orders by hand in its broker's screen and tracks positions and limits in separate spreadsheets. The goal is to send orders from the company's internal tools through the broker's trading API, track their status in real time and reconcile them with the broker's records at the end of the day.

The frame for access is fixed from the start. Article 37 of Turkish Capital Markets Law No. 6362 lists receiving and transmitting orders as an investment service, and Article 39 states that investment services may only be performed by investment firms. Under Article 35 of the Capital Markets Board (SPK) Communiqué III-37.1, accepting orders electronically is subject to a framework agreement, an account and a registry number from MKK, Turkey's central securities depository. Borsa Istanbul's algorithmic trading procedure defines direct market access as client orders passing the member's position and risk checks and reaching the exchange through the member's systems; a client cannot send orders to the exchange without using the member's systems.

API access is therefore provided by an SPK-licensed brokerage firm under its own terms and contract. The system is used only for the company's own accounts and never collects or transmits orders for third parties. No specific broker is recommended; the chosen broker's API documentation is reviewed together at the start.

Solution architecture

Connectivity adapter: the only component that talks to the broker's API (a FIX session, or REST and WebSocket). It maps order, cancel, amend and status messages to the internal model, so switching brokers means rewriting only this layer.
Order management layer: keeps each order's life cycle (new, sent, partially filled, filled, canceled, rejected) as a state machine. Every order gets a unique client order ID on the company side; in FIX this is ClOrdID, which by definition must be unique at least within a trading day.
Position and balance service: builds real-time positions from fills and regularly compares them with the broker's position and statement data.
Market data: prices and depth from the broker's API feed screens and risk checks. Borsa Istanbul data is licensed, and according to the exchange's FAQ, non-display use such as risk management or automated trading requires a Data Distribution Agreement signed directly with Borsa Istanbul, so the intended use is settled together with the license.
Audit trail: who placed which order, from which screen, with which approval and what the broker answered, kept in an append-only log with synchronized clocks.

General integration patterns are covered in exchange API integration and in Fincode's exchange API integration service.

Permission model and risk checks

Role	Permissions
Viewer	Sees positions, orders and reports; cannot place orders.
Trader	Places orders in assigned accounts and shares, within user limits.
Approver	Approves orders above a threshold as a second person.
Administrator	Manages users and limits and can trigger the kill switch.

Each order is checked on the company side before it reaches the broker: maximum buy and sell size, deviation from the last price, allowed share list, orders per second, repeated identical orders and intraday position limits. These follow the same logic as the limits members can set in Borsa Istanbul's BISTECH pre-trade risk management application; they run before, not instead of, the broker's and the exchange's controls. Practical patterns are described in trading bot risk management.

Order prices are validated against the tick size and the day's price limits. Under the Equity Market Procedure, limits are the base price plus or minus the margin; as of October 2026 the margin for shares is ±10%, on the Star and Main Markets under the exchange's practice in force until further notice and on the Sub-Market, Watchlist Market and Pre-Market Trading Platform under the procedure itself. The kill switch blocks new orders and sends cancel requests for open orders through the broker's API. Withdrawals and cash transfers are out of scope.

Connection continuity and error handling

Unknown orders: if no response arrives for a sent order, it moves to an “unknown” state and is never resent before its status is queried with the same client order ID. This is the core rule against duplicate orders.
Reconnection: after reconnecting, open orders and the day's fills are queried from the broker. If they differ from local records, new order entry stops until the difference is resolved.
Backup connection: if the broker offers more than one endpoint, primary and backup sessions are defined; the first step after failover is again a state reconciliation.
Limits and sessions: the broker's request limits come from its documentation, and excess requests wait in a queue. The Equity Market Procedure lists which order types are accepted in which session phase; continuous trading runs from 10:00 to 18:00, and order type checks follow that schedule.

Testing and go-live

The broker's API documentation, order types, request limits and whether it offers a test environment are reviewed together.
Where a test environment exists, partial fills, cancels, rejects and disconnects are exercised there first.
In shadow mode the system sends no orders; it follows manually entered orders and broker statements to prove the reconciliation.
Go-live starts with low limits and a single user group; limits open gradually as end-of-day reconciliations come back clean.
Rule-based automated order generation, if planned, is assessed separately. Under Borsa Istanbul's procedure, the member is responsible to the exchange for algorithmic order systems and must inform the exchange in writing about the algorithm software used, so the broker's conditions are clarified up front.

Deliverables

Connectivity adapter and order management service
Role- and account-based permission module with approval flow
Pre-trade risk module and kill switch
End-of-day reconciliation report and break list
Audit trail and query screen
Source code, operations runbook (disconnect, failover, kill switch) and test report

How success is measured

At the end of each day, no unexplained differences remain between company records and the broker's orders, trades and positions.
Every order can be traced end to end with its user, approval, risk check result and broker response.
Tests show that orders breaching limits, off the tick grid or unauthorized never reach the broker.
Disconnect, failover and kill switch drills are completed using documented steps.

Frequently asked questions

Can orders be sent straight to Borsa Istanbul through a broker API?

No. Under Borsa Istanbul's algorithmic trading procedure, a client cannot send orders to the exchange without using the member's systems; orders pass the broker's risk checks and are routed by the broker.

Can the system route orders for other people?

No. Receiving and transmitting orders is an investment service under Capital Markets Law No. 6362 and may only be performed by licensed investment firms. The system in this scenario serves only the company's own accounts.

Which broker does Fincode work with?

No specific broker is recommended. The documentation and contract terms of an SPK-licensed brokerage firm that offers API access are reviewed together at the start of the project.

How is the risk of duplicate orders reduced?

Every order gets a unique client order ID on the company side. An order without a response is never resent before its status is checked with that ID.

Sources

Planning a similar project?

Tell us the platform, what the software should do and your timeline in a short form; a written proposal follows the initial review. Fincode is a software company and does not provide investment advice, portfolio management or crypto asset services.

Exchange API integration services Send a project brief