The Hardest Problems in a Broker API Integration Are the Ones Nobody Wrote in the RFP

Every embedded-investing RFP we receive is well written. It names the broker. It lists the asset classes. It specifies SSO, multi-currency funding, portfolio views, and – always, and rightly – an obsession with UX. What it almost never contains is the one sentence that will decide whether the product can exist at all.

That sentence is usually about a broker API constraint the client has no reason to know about: something that lives four layers below the product surface, inside the API and protocol documentation, in a footnote about which channel supports which order type. Broker API integration is where these constraints surface – usually in sprint 9, when the estimate is already contractual.

Finding those sentences before the contract is signed is most of what a competent delivery partner is actually for. Below are two problems that keep showing up in regulated trading work: one that clients get wrong because the vocabulary is ambiguous, and one that clients cannot get right because the information is genuinely buried.

Problem 1: choosing the wrong infrastructure category

Before you inspect an API constraint, make sure you are solving the right category of problem. The first fork in any regulated trading build is not a technology choice. It is a category choice, and the market’s vocabulary actively obscures it.

Two things get called the same thing. A brokerage operations foundation is a shared, multi-tenant infrastructure layer: accounts and a double-entry ledger, funding safety, order-risk primitives, tenant-scoped supervisory tooling, and pluggable adapters for clearing, custody, and execution partners. It owns the plumbing and expects a tenant to build the product. A full broker-dealer OEMS is the end-to-end order and execution management system a registered firm runs: order construction and staging, low-latency connectivity to dozens of venues, smart order routing, post-trade matching and allocation, surveillance, and books-and-records that must survive an examination. We wrote about this distinction at length in [Brokerage Operations Foundation vs. Full Broker-Dealer OEMS]; the short version matters here because the category decision quietly sets the budget, the timeline, and the compliance conversation.

Two categories. One gets sold as the other. The label sets the bar that buyers, auditors and regulators will measure the platform against:

	Brokerage operations foundation (shared · multi-tenant · embeddable)	Full broker-dealer OEMS (end-to-end · registered firm)
Owns end-to-end	Ledger, funding safety, order-risk primitives, audit and supervisory hooks	All of that, plus routing, execution, surveillance, supervisory case management
Assumes a partner owns	Clearing, custody, the venue	Nothing. The firm owns the lot.
Clearing model it fits	Introducing, fully disclosed	Self-clearing, omnibus, sell-side
Net capital that implies (SEC Rule 15c3-1 minimum)	USD 5,000 – fully-disclosed introducing broker	USD 250,000 – carrying customer accounts
Where it breaks	Operator still needs its own supervisory procedures, and must supervise the provider	Opinionated workflows built for a trading desk, imposed on a first-time retail investor

The two categories also sit on a spectrum – from embeddable (a feature inside someone else’s app, where differentiation lives in the experience layer) to complete retail broker (a standalone regulated venue, where differentiation lives in execution and supervision). Most bank and super-app briefs sit close to the embeddable end.

The practical failure mode: a bank or a super-app comes in describing an investing feature – a tab inside an app people already use, guided themes for first-time investors, recurring contributions, a portfolio screen. Then the words “trading platform” appear somewhere in the requirements, and the shortlist fills up with institutional OEMS vendors quoting six-figure setup fees and multi-quarter implementations for smart order routing, basket algos, and program-trading tools the product will never issue a single call to. The category answer for that product is almost always embeddable: a feature inside someone else’s app, where the differentiation lives entirely in the experience layer and the heavy regulated machinery stays with a clearing or executing partner. Over-specifying it does not buy safety. It buys a workflow model built for a trading desk, imposed on a customer who has never bought a share before – and unit economics that stop making sense at a $50 monthly ticket.

The brokerage operations foundation we developed sits deliberately at the embeddable end of that line: it owns the ledger, the funding controls, the reservation-first order lifecycle, and the audit surface, and it leaves the execution venue behind a pluggable adapter rather than baking one broker’s assumptions into the product. Two edges to name, since this is our own category. A foundation does not make its operator a broker-dealer – written supervisory procedures, designated supervisors and an AML programme remain the operator’s, and outsourcing recordkeeping to a provider does not outsource responsibility for it. And a foundation should not try to swallow the layers that are genuinely better bought: identity and MFA, standard reporting, off-the-shelf dashboards.

Getting this right is mostly a matter of vocabulary discipline. Which makes it the easy problem. Here is the hard one.

Problem 2: the broker API capability that exists on the venue, but not on the channel

Client names and identifying details below are removed; broker capabilities are cited from the vendors’ published documentation, since they are the point. The shape of the problem is what generalizes.

A bank was building an embedded global-investing experience on top of an established international broker, under an introducing-broker agreement it had already signed. The commercial thesis was explicit and correct: the wealth segment was the entry point, but the real prize was mass market – because fractional shares, ETFs and funds together let a customer start with a very small monthly amount, the proposition generalises beyond the wealthy.

The product that expresses that thesis is guided thematic investing: a handful of curated baskets of roughly ten names each, bought with a small recurring contribution. It is a good product. It is also a product with a hard arithmetic dependency that nobody had written down.

The arithmetic

A themed basket of ten names, bought with a $50 monthly contribution, allocates about $5 per leg. Large-cap share prices run from roughly $12 to $400+. Whole-share execution therefore fills almost nothing.

This is not an edge case to handle later. It is the product. Without fractional execution, the flagship experience degrades into “you now own two of the ten companies in the theme you thought you bought” – or, at genuinely mass-market ticket sizes, into a cash balance that never gets invested at all. The requirement “support fractional shares” appeared nowhere in the brief, because from the client’s seat it was not a requirement. It was a property of the broker they had already selected. The broker does support fractional trading. That part was true.

The finding: fractional trading works over FIX/CTCI, not the broker’s REST API

What discovery surfaced was that the support is real but channel-bound. On that venue – Interactive Brokers – fractional orders can be placed over the FIX/CTCI protocol – and not through the REST APIs that every integration plan starts from. Interactive Brokers’ own FAQ states it in a single sentence: fractional trading is supported via FIX/CTCI but not via API at this time. Their FIX implementation manual goes further, specifying fractional quantity to four decimal places in tag 38 with a minimum size of 0.0001, the supported order types, and the restriction to regular trading hours – and it includes a captured message log of an actual fractional execution.

So the capability exists on the venue. It does not exist on the channel around which the entire integration – and the entire estimate – would otherwise have been scoped.

The trap inside the trap

This is the part that should worry anyone planning to find such things during implementation rather than during discovery.

The REST API does expose fractional vocabulary. Account endpoints return a supportsFractions flag. Contract-rules endpoints return fraqTypes – the order types permitted for fractional trading – and fraqInt, the number of decimal places allowed in a fractional order size. Order quantity is typed as a double, not an integer. Everything an engineer would check before writing the ticket says yes.

There is also a dollar-denominated order field, cashQty – send a cash amount instead of a share count – and a 2026 changelog entry announcing that stocks now support it. Read quickly, that is the fractional feature arriving.

Read the endpoint documentation and it says something else. Stock orders submitted with a cash quantity through the API round down to the nearest whole share, and an order worth less than one share is rejected outright.

So the field that looks like the answer has two failure modes, and a basket product hits both. Above one share, it truncates silently: ask for $50 of a $12 stock and you get four shares, with $2 stranded – no error, no warning, just a fill that is quietly smaller than the instruction. Below one share, it rejects – which is most legs of a ten-name basket at a $5 allocation. Neither is fractional trading. One of them looks like success in a log.

None of those fields are lying. They are the capability surface that powers the broker’s own front end, exposed for reading, not an order path opened for writing. Distinguishing “this field exists” from “this field does what I need on this channel” is the entire job. It takes reading the endpoint notes, the order-type limitations page, the error-code table, and the protocol specification against each other – not one page and an optimistic assumption.

The part that is not an engineering problem

FIX access is not a self-service API key. It carries published minimums – USD 10,000 in equity under management, and USD 1,500 a month in commissions for the first session (USD 1,000 for each subsequent one) – plus an onboarding path: vetting, a FIX integration form, and a supervised certification test. Institutional and enterprise clients are required to arrange dedicated connectivity; everyone else may run FIX over the internet through the broker’s gateway.

And even once you are through, the feature has edges worth designing around. Fractional trading covers eligible US, Canadian and European stocks and ETFs – not Asian markets – from a one-dollar minimum. The fractional order types over FIX are market, limit, stop and stop-limit only, with nothing accepted outside regular trading hours. A recurring-contributions product that fires batches on a schedule has to be built around that last constraint, not discover it.

Two observations about those numbers, because both change how you plan around them.

First, they are small. For a bank, the commercial minimums are a rounding error. This matters because the folklore says otherwise: search the topic and you will find confident claims that FIX sits behind an assets-under-management threshold a new platform has to grow into, and therefore that fractional trading is something to defer until the book is large enough. That threshold is not in the primary sources. It shapes roadmaps anyway – we have seen it sequence a product plan around a gate that does not exist. Any commercial figure driving an architecture decision should arrive with the URL it came from and the date it was read, or it will harden into a fact on its own.

Second, the real constraint is not money. It is calendar. The certification cycle has no published duration, and it sits on the critical path of a launch date the client had already communicated internally. That is the risk worth naming out loud.

It is not one vendor’s quirk

Change the asset class, the regulator and the vendor, and the same shape appears. On a different engagement the requirement was live data: a desk that needed to see what the market is doing now, not what a file said two hours ago. The vendor’s platform could do it – it publishes a real-time drop-copy feed over FIX, alongside a REST API and a scheduled file drop, and the existing system was built on the file drop.

There the constraint was not in the documentation at all. It was in the subscription. Which feeds a customer is entitled to, at what scope and what rate limit, is a term of the contract with the vendor rather than a property of the product. Two firms reading the same API reference can have materially different systems available to them, and neither reference will say so.

That is the generalisation worth carrying out of both stories: a capability is bound to a specific channel and to a specific contract, and the API documentation describes neither. Which is why “confirm the entitlement in writing, before the estimate is fixed” appears on our discovery plans as a named deliverable rather than an assumption inside one.

How we work a problem like this

There is a version of this engagement that is very good for us commercially: recommend FIX from day one, book the FIX engine, the certification track, and the dedicated connectivity into phase 1, and bill every hour of it. It is a defensible recommendation. It is also the one that puts an unbounded external dependency directly under the client’s launch date.

We did not recommend it. Here is the sequence we do use.

1. Verify against primary sources, and record where each fact came from.

Not a vendor’s marketing page and not a forum answer – the protocol specification, the FAQ, the published requirements page, with the revision date. On this problem the specification mattered: fractional support was only added to that manual in a 2020 revision, and the pre-2020 answer (“not supported”) still circulates in community threads and even in some third-party tooling documentation. A team relying on secondary sources would have concluded the opposite of the truth.

2. Evaluate the alternatives properly, and write down why each one loses.

• A second broker with native fractional REST support. This is not hypothetical: on Alpaca’s Broker API, notional is a first-class order field – a dollar amount, mutually exclusive with quantity, minimum one dollar on the buy side – and fractional quantity is a decimal string. It is the same capability, exposed the way an integrator would expect. We have shipped this pattern. But for this scope it fails on coverage: US-listed instruments only, against a brief promising dozens of international markets and fund products. And it introduces split custody across two brokers, two KYC packets, two funding rails, and a two-custodian story that compliance has to sign and the product has to explain in one sentence to a first-time investor. It stays on the page as considered-and-rejected, not as a recommendation.
• Omnibus pooling with an internal fractional ledger. Technically elegant and well-precedented in retail fintech. But it moves the client from an agency model into a custodial one: a different licence category, regulatory capital sitting idle on the balance sheet, customer statements that stop being pass-through, and a disclosure that customers hold a beneficial interest rather than a titled position. That is a board decision, not an architecture decision, and it belongs in front of compliance before it appears in an estimate.
• An intermediary broker holding the FIX link. Rejected. It stacks a second counterparty’s insolvency risk on top of the first and doubles the commission stack – on exactly the micro-ticket sizes the product is built for.
• Whole-share rounding with a cash sweep. Ships immediately, requires nothing, and produces the outcome in the figure above. Not a launch plan.
• Server-side automation of the broker’s own portal. Rejected on sight, and written down explicitly so it could not resurface. It routes around a policy the broker maintains deliberately, breaks the audit chain that says the customer authorised the trade, and puts money movement at the mercy of someone else’s HTML.

3. Put the execution channel behind an interface, so the channel stops being an architectural commitment.

Everything above the port – the basket engine, recurring plans, onboarding, funding and FX, the ledger and the audit surface – is written once and never learns which wire carried the order, or whether the quantity was whole or fractional. That single boundary is what converts an unresolved external dependency from a design problem into a delivery-sequencing problem.

The same discipline applies to every external feed, not just the order path. Some feeds are genuinely batch and should stay batch. What matters is that batch-versus-real-time becomes a per-feed choice the platform owns, rather than a platform-wide limitation baked into whichever integration happened to get built first.

4. Phase the delivery so the external dependency is never on the critical path.

Phasing is not, by itself, an insight. Every serious vendor proposes phases, most buyers already believe in them, and “modernise, don’t rewrite” is printed on every capability deck in the market. What separates a plan from a slogan is where the boundary is drawn: around a named external dependency, with a named owner and a named verification step – or wherever the scope happened to divide neatly. Ours is drawn at the certification cycle, because that is the one thing on the plan we do not control.

Phase 1 ships on the original date, on the channel that is available today, with one narrow and deliberate seam: for the specific slice that genuinely requires fractional buying, the customer is handed off – explicitly, in a framed full-screen transition, not a disguised iframe – into the broker’s own hosted portal, re-skinned under the bank’s brand. Fractional trading there is an ordinary retail feature: it needs neither FIX nor an API, because a human is placing the order in the broker’s own UI.

Interactive Brokers calls this White Branding; it is free, it covers the client portal, the registration system, statements and the mobile apps, and it now extends to fonts, colours and borders rather than just a logo. What it does not give you is the layout, the flow, or your own domain.

We want to be precise about the scope of that recommendation, because “use the broker’s white-label” can be heard as “give up and resell.” That is not what this is. The white-labeled surface is used for one capability only – the fractional slice – plus a couple of low-frequency back-office flows like statements. It is not the golden path, it is not where the guided experience lives, and it is not the differentiator. It is a stopgap on a single line item, sized to the gap it fills.

And it carries its own open question, which belongs in writing rather than in an assumption. No single published sentence says “white-branded portals support fractional trading for an introducing broker’s clients.” What is documented is each piece separately: fractional is a client-portal feature; the white-branded portal is that same hosted portal re-skinned; and the broker’s back office has a first-class flow for enabling a broker’s clients to trade in fractions. Composition says yes. Composition is not a citation – so it went to the broker’s sales engineering in writing, along with the one term that genuinely constrains onboarding design: introducing brokers enable clients for fractional trading on an all-or-none basis – every client, or none.

Until that written confirmation lands, the white-labeled seam is a candidate path, not a commitment – the same standard this article asks of every other capability claim. If the answer comes back no, the fractional slice waits for Phase 2 rather than shipping in a degraded form, and the rest of Phase 1 is unaffected, because nothing else depends on it.

Phase 2 certifies the FIX session and swaps the adapter. Baskets and recurring contributions become automatic and fractional; the seam disappears; no screen is rewritten. The certification clock starts on day one, in parallel – it just is not standing between the client and their launch.

Why we recommend the smaller first phase

The phased plan bills fewer hours in phase 1 than the FIX-first plan. That is not an accident of scoping and it is not modesty.

An integration partner who lets a client walk into a launch date with an uncontrolled external certification cycle on the critical path has not been conservative – they have transferred a risk they understood onto a client who did not. When that date slips, the hours already billed do not make the relationship survivable.

The premium a client is actually paying for is not lines of code. It is the discovery work that finds a constraint like this before it is contractual, the intellectual honesty to say “the capability you assumed you had is not on the channel we were both about to build on,” and the willingness to recommend the sequence that protects the launch rather than the sequence that maximises the first invoice. Phase 2 is a better contract to hold when it is a scheduled upgrade the client asked for, than when it is a rescue.

Five questions worth asking your platform vendor

1. Which category are you actually selling me – a shared operations foundation, or a full broker-dealer OEMS? Which one does my operating model need?
2. On which channel does each capability I care about actually work, and is it in my contract? Not “does the vendor support X” – “does X work on the channel in this plan, under the entitlements my agreement actually grants.”
3. What is on the critical path that you do not control? Certifications, permissions, connectivity provisioning, per-account enablement, vendor sign-off.
4. Where is the source for that number? Every commercial threshold and protocol limit in the proposal should carry a link and a revision date.
5. What did you consider and reject, and why? A proposal with no rejected alternatives is a proposal where nobody looked.

If the answers are specific, you are talking to a partner. If they are enthusiastic, you are talking to a vendor.

FAQ

Does the Interactive Brokers REST API support fractional shares?

No. Per Interactive Brokers’ own FAQ, fractional trading is supported via the FIX/CTCI protocol but not via API at this time. The REST API’s cash-quantity orders round down to the nearest whole share, and orders worth less than one share are rejected.

What are the minimums for FIX API access at Interactive Brokers?

Published minimums are USD 10,000 in equity under management and USD 1,500 per month in commissions for the first FIX session (USD 1,000 for each subsequent one), plus vetting, an integration form, and a supervised certification test with no published duration.

Why does a broker API capability differ between channels?

Because a venue’s capability is exposed per channel – REST, FIX, hosted portal – and each channel has its own order types, limits and entitlements. A capability the venue advertises is not a capability every channel can express, and entitlements are a term of the contract, not a property of the product.

How do you verify a broker API capability before committing to an architecture?

Against primary sources with revision dates – the protocol specification, endpoint notes, order-type limitations and error tables read against each other – and with entitlements confirmed in writing before the estimate is fixed. Community threads and third-party tooling docs routinely carry outdated answers.

By ulyana.senkevich