Handling Partial Fills in Trading Software

A trading order does not always move directly from requested quantity to fully executed quantity. Depending on the order and market conditions, only part of the requested quantity may be executed while the rest remains open, is cancelled, or follows another broker-defined outcome.

For automated trading software, this matters because a partial fill changes the actual position. If an application treats the original requested quantity as fully executed, its risk calculations, exit logic, account records and user interface can all become inaccurate.

What Is a Partial Fill?

A partial fill happens when an order is executed for less than its requested quantity.

For example, an automated strategy sends a buy order for 1,000 units. The broker reports that only 400 units have been executed. The remaining 600 units may still be open, depending on the order type and broker rules.

The software therefore needs to track at least two different quantities:

• Requested quantity: The quantity originally submitted.
• Filled quantity: The quantity actually executed.
• Remaining quantity: The quantity that has not yet been executed.

A simple example is:

• Requested: 1,000
• Filled: 400
• Remaining: 600

The application should not treat this as a 1,000-unit position.

Why Partial Fills Matter in Automated Trading

A strategy may generate an entry signal for a specific position size, but the broker's execution result determines the actual position.

If software ignores this distinction, several problems can occur:

• Position size can be overstated.
• Exit orders can use the wrong quantity.
• Risk calculations can become inaccurate.
• Profit and loss reporting can be misleading.
• The user interface can show an incorrect status.
• Repeated retries can create unintended exposure.

Example of the risk

Suppose a strategy requests 500 units and receives a fill for 200 units.

If the software assumes all 500 units were filled, it may later send an exit for 500 units. Depending on the account and order rules, that could produce an unintended order rather than simply closing the intended position.

The safer design is to base position and exit logic on actual executed quantity, not only on the original request.

Track Order Quantity and Position Quantity Separately

A good trading application should distinguish between the lifecycle of an order and the resulting position.

An order can have:

• Requested quantity
• Filled quantity
• Remaining quantity
• Average execution price, where applicable
• Current order status

The position can separately have:

• Current quantity
• Average entry price
• Direction
• Realised and unrealised profit or loss, where supported
• Related strategy or account information

This separation is important because one order can produce a position that changes over time.

Example

A strategy requests a 1,000-unit buy order.

The broker reports:

1. 300 units filled.
2. Another 200 units filled.
3. The remaining 500 units are cancelled.

The final result is:

• Requested quantity: 1,000
• Total filled quantity: 500
• Cancelled or unfilled quantity: 500
• Actual position created by this order: 500 units

The application should preserve these events instead of replacing them with a single simplified status.

Use Explicit Order States

Partial-fill handling becomes easier when order states are clearly defined.

Depending on the broker API and application design, useful internal states can include:

• Created
• Submission pending
• Open
• Partially filled
• Filled
• Cancellation requested
• Cancelled
• Rejected
• Reconciliation required

The exact names can differ, but the software should distinguish partially filled from fully filled.

Why state transitions matter

Consider an order that starts with:

`Requested -> Open -> Partially Filled -> Filled`

Another order might follow:

`Requested -> Open -> Partially Filled -> Cancelled`

These are different outcomes. The first produces the full requested position. The second produces only the quantity that was actually executed.

A state machine or equivalent controlled workflow can help the application process these transitions consistently.

Handling Remaining Orders

When an order is partially filled, the unfilled quantity may remain active.

For example:

`Requested: 1,000`

`Filled: 400`

`Remaining: 600`

The software needs to know whether the remaining 600 units are still open, have been cancelled, expired, rejected, or otherwise changed according to the broker's order lifecycle.

Do not assume the remainder still exists

A common implementation mistake is to calculate remaining quantity but never verify the broker's current order state.

The application should use broker-confirmed information when deciding whether an outstanding quantity can still be executed.

This is particularly important after:

• Network interruptions
• Application restarts
• Broker disconnections
• Manual changes through another platform
• Order cancellations

Exit Logic Must Use the Actual Position

Partial fills have a direct effect on exits.

Suppose an automated strategy requests 1,000 units but only 350 units are filled. The strategy later generates an exit signal.

The exit logic should first determine the actual position quantity.

If the position is 350 units, the system should not blindly assume that 1,000 units need to be closed.

Strategy-level and account-level checks

In a multi-strategy system, the software may also need to determine which position belongs to which strategy.

This becomes more complex when multiple strategies trade the same symbol or when manual trades exist in the same account.

A robust design should define clearly:

• How positions are identified.
• How strategy ownership is tracked.
• Whether exits apply to the full position or only a strategy-specific quantity.
• How external or manual position changes are handled.

Without these rules, even technically correct quantity calculations can produce incorrect trading behaviour.

Accounting and Profit Calculations

Partial fills also affect financial records.

If different portions of an order execute at different prices, the application should preserve the individual executions or otherwise calculate the appropriate aggregate values according to the broker's reported data.

For example:

• 200 units filled at one price.
• 300 units filled at another price.

The system should not assume that the entire 500-unit position was executed at the first reported price.

Keep execution records

Useful execution data can include:

• Execution identifier
• Order identifier
• Filled quantity
• Execution price
• Execution timestamp
• Applicable fees or charges when provided by the broker
• Symbol and side

These records help support accurate reporting and troubleshooting.

User-Visible Status Should Be Clear

The user interface should make partial fills understandable.

Instead of displaying only Order Successful, a trading application can show information such as:

Partially Filled: 400 / 1,000

This tells the user what was requested and what actually happened.

Useful information may include:

• Order status
• Requested quantity
• Filled quantity
• Remaining quantity
• Average fill price, where applicable
• Broker order ID
• Last update time

Clear status information is especially important when users are monitoring automated strategies and need to understand current exposure quickly.

Reconciliation After a Restart

A trading application cannot assume that its in-memory state is still correct after a restart.

Suppose the application recorded 400 filled units before it crashed. During the downtime, another 200 units may have been executed.

When the application starts again, it should reconcile its stored state with the broker's current order and position information.

A practical recovery process can be:

1. Load persisted order records.
2. Retrieve current broker order information.
3. Retrieve relevant position information.
4. Compare requested, filled and remaining quantities.
5. Update internal state.
6. Mark unresolved differences for reconciliation.
7. Resume strategy processing only after the required state is understood.

This prevents the application from continuing with an outdated assumption.

Common Partial-Fill Mistakes

Several design mistakes repeatedly create problems.

Treating requested quantity as filled quantity

The requested quantity is an instruction, not proof of execution.

Ignoring multiple execution events

An order can receive more than one fill. Software should be able to process cumulative execution information correctly.

Sending exits based on the original order size

Exit quantity should be based on the actual position or clearly defined strategy-level quantity.

Losing state after restart

Partial-fill information should be persisted so the application can recover.

Ignoring external changes

If an order or position can be changed outside the application, reconciliation becomes important.

Hiding important information from users

A generic success message can hide the difference between a full and partial execution.

Designing Safer Partial-Fill Handling

A practical architecture can follow these principles:

1. Store the original order intent.
2. Record every confirmed execution.
3. Calculate filled and remaining quantities from reliable broker data.
4. Maintain explicit order and position states.
5. Use actual position quantity for exit decisions.
6. Persist state for restart recovery.
7. Reconcile with the broker after uncertain events.
8. Show meaningful execution status to users.
9. Log state transitions and execution events.
10. Test partial fills as a normal failure and edge-case scenario.

The exact implementation depends on the broker API, order types, asset class and application architecture. There is no universal partial-fill workflow that can be safely copied into every trading platform.

Testing Partial-Fill Scenarios

Partial fills should be included in software testing rather than treated as an unusual event that can be ignored.

Useful test cases include:

• Order receives one partial fill.
• Order receives multiple partial fills.
• Remaining quantity is cancelled.
• Remaining quantity stays open.
• Application restarts after a partial fill.
• Network connection fails after an execution.
• Exit signal arrives while an entry order is partially filled.
• User changes an order externally.
• Multiple strategies operate on the same account.

The objective is to confirm that the application's internal state, broker state and user-visible state remain consistent.

Conclusion

Partial fills are a normal order-management condition that automated trading software must handle explicitly. The key is to separate requested quantity from actual execution and to maintain accurate order, position and execution state throughout the lifecycle.

A well-designed system tracks filled quantity, remaining quantity, order status and position state, while using reconciliation when information becomes uncertain.

Suyotech Solutions provides software engineering services for trading applications, automation and broker integrations where reliable order and position handling is an important part of the system design.

For custom trading software development, contact Suyotech Solutions to discuss your application requirements. Trading software can improve process automation, but it cannot guarantee execution quality, profitability or future trading results.