Robo-Advisor Development: The Parts That Are Not the Algorithm

The optimisation problem at the centre of a robo-advisor is well understood and has been for decades. Mean-variance portfolio construction is textbook material, the libraries exist, and a competent quantitative developer produces a working allocation engine quickly.

That engine is a small fraction of the system. The rest is regulated advice, custody integration, tax-aware rebalancing, and the ability to reconstruct years later why a specific client was told to do a specific thing. Those are the parts that determine the timeline.

Advice is a regulated act, and the interface is part of it

Recommending that someone invest in something is, in most jurisdictions, regulated financial advice. That obligation attaches to what your product does, not to how you describe it, and a disclaimer stating that nothing here constitutes advice does not change the analysis if the product plainly gives advice.

The practical consequence is that suitability is an engineering requirement. You need to establish a client's circumstances, risk capacity and objectives, and demonstrate that the recommendation follows from them. That means the questionnaire is not a signup form to optimise for completion — it is evidence, and the pressure to shorten it for conversion is in direct tension with the obligation it exists to satisfy.

It also means every recommendation needs to be reproducible. If a client complains in three years, you need to show the inputs, the model version, the parameters and the resulting allocation as they were on that day. That is a versioning and immutability requirement running through the whole system, and it is difficult to add afterwards.

Rebalancing is where the real complexity lives

Constructing a target allocation is straightforward. Moving an actual portfolio toward it, repeatedly, under real constraints, is not.

Trading costs mean the optimal trade is frequently no trade. Drift of half a percent is not worth a transaction, so you need threshold logic, and the threshold interacts with account size — the same percentage drift on a small account may be a trade whose cost exceeds the benefit.

Tax makes it substantially harder in jurisdictions where realised gains are taxable. Selling an appreciated holding to rebalance creates a liability, which may exceed the benefit of being correctly allocated. Doing this properly means lot-level tracking, tax-aware ordering of sales, awareness of wash-sale or bed-and-breakfast rules, and sometimes deliberately holding an imperfect allocation because correcting it costs more than the drift.

Then there is cash. Dividends arrive, contributions arrive, withdrawals are requested. Each is an opportunity to rebalance without selling anything, which is the cheapest possible correction. A system that only rebalances on a schedule misses those, and over years that is a measurable difference in client outcomes.

Custody integration constrains the design

You are almost certainly not holding the assets. A custodian or broker does, and their interface shapes what your product can honestly promise.

Settlement is not instant. Fractional share support varies. Order types differ. Some custodians batch orders at specific times, which means a client pressing a button at ten in the morning gets a price determined hours later. Corporate actions — splits, mergers, spin-offs — arrive as data you have to handle correctly or your positions silently diverge from reality.

The most common design error is building the product as though positions update immediately, then discovering that reconciliation against the custodian's end-of-day file disagrees with what the client was shown. The custodian is authoritative. Your system holds a view of the truth that needs reconciling on a defined cadence, with a clear rule for what a client sees while the two disagree.

The audit trail is a feature, not logging

Regulated advice needs a reconstructable history. Not just what the portfolio held, but what the client told you, which model version ran, which parameters applied, what was recommended, what the client chose, and which trades resulted.

Treating this as application logging is the mistake. Logs rotate, get sampled, and are structured for debugging rather than for reconstruction. What you need is domain data: immutable records of assessments, recommendations and decisions, versioned and queryable, with a retention period matching your regulatory obligation rather than your observability budget.

Onboarding is where the funnel actually breaks

The drop-off in robo-advisor onboarding is rarely the risk questionnaire, which is what teams instinctively try to shorten. It is identity verification and funding — the two steps where an external system says no and the customer has no idea why.

Identity checks fail for mundane reasons: a name that does not match the document, an address changed last month, a document photographed in poor light. A generic failure message loses the customer permanently. What retains them is a specific, actionable message and a manual review path, which means your onboarding needs an operational queue and someone watching it, not just an API integration.

Funding fails differently. Bank transfers take days and arrive without reliable reference data, so matching an incoming payment to an account is a real matching problem rather than a lookup. Open banking or instant payment rails reduce this considerably where available, and the difference in completion rates usually justifies the integration cost on its own.

Fee calculation is easy to get subtly wrong

Management fees are typically quoted annually and charged monthly or quarterly on average balance, which sounds simple until you handle a mid-period deposit, a partial withdrawal, or an account opened on the eleventh of the month. Each requires a defined pro-rating rule, and clients notice when the rule is inconsistent.

Charge fees through the same ledger as everything else, as explicit entries with the calculation inputs recorded alongside. A fee stored only as a total is one you cannot explain when a client asks, and "our system calculated it" is not an answer that survives a complaint.

Sequencing that works

Establish the regulatory position first, with counsel, because whether you are giving advice or offering execution-only access changes the entire product. Then the custody integration, since its constraints are not negotiable and are better discovered early. Then the ledger and audit model. Then suitability. The allocation engine, the part everyone wants to start with, can come last and will take the least time.

If the answer to the first question is that you would rather not be a regulated adviser, that is a legitimate product decision — and it points at a materially simpler system.