Direct Answer
A broker capability matrix is a side-by-side comparison of order types, time-in-force values, asset classes, and API features supported by up to three brokers you're evaluating. Entering each broker's capabilities produces a structured matrix that highlights where one broker's integration falls short of a strategy's requirements. It's a due-diligence step before committing engineering time to a specific broker's API.
Tool
Enter names for up to three brokers and set their capability level for each feature. Then click Generate Matrix to see the comparison.
Order Types
Time-in-Force Values
Asset Classes
API Features
Uses synthetic or user-entered data only. Verify all capabilities against your broker's current documentation and empirical testing.
How to Use This Tool
Name up to three brokers you're evaluating (or leave the third blank for a two-way comparison). For each capability category, select the support level for each broker: Yes (fully supported), Partial (limited or conditional support), No (not supported), or Unknown (not yet tested).
Click Generate Matrix to render the side-by-side comparison table. The score row at the bottom counts the number of "Yes" capabilities for each broker, useful for a quick ranking when all required features carry equal weight.
This tool uses only the values you enter, no external data. Populate values from your capability discovery testing (empirical sandbox tests) rather than from marketing documentation alone. Unknown values should be marked as "Unknown" and scheduled for empirical testing before making a final broker selection.
Understanding the Outputs
The matrix shows each capability as a row and each broker as a column. "Yes" means the capability works as documented for your account type. "Partial" means the capability works under certain conditions, for example, GTC is supported for limit orders but not for market orders, or fractional shares work for equities but not ETFs. "No" means the capability was tested and rejected. "Unknown" means it hasn't been tested yet and shouldn't be assumed either way.
The score at the bottom (Total Yes) is a simple count and doesn't weight capabilities by importance. For a strategy that absolutely requires FOK orders, a broker that scores 12/15 but doesn't support FOK is worse than one that scores 10/15 but does. Use the matrix as a visualization tool, not as a single composite score for decision-making.
Partial support often requires investigation: does the partial support cover your specific use case? A broker that supports trailing stops "partially" might mean they support percent-based but not price-based trailing stops. Record the details of what "partial" means for each capability in your capability manifest alongside the matrix results.
The matrix is most useful when populated from fresh capability discovery testing (see the Capability Discovery guide), not from documentation claims. A capability marked "Yes" from documentation but untested empirically should be treated as "Unknown" in the matrix until verified.
Assumptions and Limitations
- This tool stores no data, entries are lost on page reload. Screenshot or copy the matrix before leaving.
- Capability values are user-entered and represent your testing results or documentation research, not verified current broker state.
- Broker capabilities change with API updates; a matrix populated today may be stale in 3 months. Schedule re-validation quarterly.
- The score count weights all capabilities equally; your strategy requirements may weight some capabilities (e.g., WebSocket streaming) far more heavily than others (e.g., fractional shares).
FAQ
What should I do if a capability shows as "Partial" for all brokers?
Document the specific limitation for each broker and determine whether your strategy can work within those limitations. If a core required capability is only partially supported everywhere, you may need to synthesize it at the adapter layer (build the missing piece yourself) or accept the limitation in your strategy design. Partial support is often acceptable if you can verify the specific condition under which it works covers your use case.
How do I determine the right level of capability to require?
Start from your strategy's order execution requirements: which order types does the strategy actually use, which TIF values, which asset classes? Mark those as required. Everything else is optional or "nice to have." A broker that scores poorly on optional capabilities but covers all required capabilities is still a better fit than one that scores highly overall but misses a required feature.
Should I include rate limits in the capability matrix?
Yes, add a row for "Order submission rate limit (requests/min)" and populate it with the empirically observed limit for each broker. This is especially important if your strategy submits orders in bursts during market events. A broker with 60 requests/min vs. 200 requests/min is a significant capability difference for high-frequency strategies.
Can I use this matrix for crypto exchange comparison as well as equity broker comparison?
Yes. The order type rows (market, limit, stop) apply to both. You may want to add crypto-specific capabilities: post-only orders (maker-only limit orders), reduce-only orders, perpetual swaps, funding rate support, and cross/isolated margin modes. Add rows for any capability that's relevant to your specific asset class and strategy.
What are the most commonly differentiated capabilities across brokers?
The capabilities that differ most across brokers are: trailing stop support (many don't support it natively), FOK order support (fewer brokers support it than IOC), fractional share availability (varies significantly), WebSocket event granularity (some brokers send minimal fill events, others send full order book updates), and API rate limits (varies by an order of magnitude). These five are the most useful differentiation dimensions for choosing an execution broker for an automated strategy.
Who should own the matrix and how often should it be refreshed?
Ownership belongs with whoever maintains the adapters, because they are the ones who discover a capability change first. Refresh naturally attaches to two triggers rather than to a fixed calendar: whenever a broker publishes an API change, and whenever an integration test or a production incident reveals behavior that differs from what the matrix records. A periodic review still helps as a backstop, since capability removals are frequently announced quietly or not at all.
How should a capability that exists but is unreliable be recorded?
A binary supported or unsupported entry cannot express a feature that works most of the time, works only during regular hours, or works only for some instruments. Recording a qualified state alongside a note describing the observed limitation is more useful than either extreme, because the routing decision depends on the specific constraint. The note should say what was observed and when, so a later reader can tell whether the limitation was tested or assumed.
How does the matrix connect to a routing decision at runtime?
The matrix is documentation, so relying on a human to consult it before routing leaves the system unprotected. The stronger pattern is deriving a machine-readable capability manifest from the same source and having the router consult that, refusing or translating an unsupported instruction rather than sending it and handling the rejection. That keeps one description of what each broker can do instead of a document and a separate set of conditional statements scattered through the code.
What should a capability entry cite as its source?
Each entry benefits from recording whether it came from broker documentation, from an empirical test in the sandbox, or from observed production behavior, along with the date. These three sources disagree often enough that the distinction matters: documentation can describe an intended behavior that the implementation does not match, and sandbox behavior can differ from live. An entry with no provenance cannot be re-verified without repeating the original work.