OXAdvisor
Investment & wealth advisory accelerator
Client goals become a defensible, fully allocated investment plan in minutes. Optimization, forecast and monitoring run on one board, and every proposal records the risk profile, the model and the constraints in force when it was made, which is what a supervisor asks for months later.
Problem vs solution
The same three weeks, on every new client.
How this normally goes
A proposal begins as a conversation and ends as a spreadsheet. Someone reads the mandate, picks an allocation from a model portfolio that has drifted, builds the forecast by hand, and writes the suitability note last.
Why a model-portfolio shortcut fails
Dropping every client into one of five models is fast, and it stops being defensible the moment a client has a constraint the model does not carry.
What we deploy instead
An engine that takes the mandate as structured input and returns the allocation, the forecast and the instruments, recording what it was based on. Monitoring continues after the plan is booked.
Presales and Discovery
What our architects hand you before implementation starts.
Book an architecture sessionSystem Design
How the engine meets your custodian, your book and your suitability process.
Assumptions review
Whose capital-market assumptions apply, and how they are governed.
Model transparency pack
What the optimiser does, what it does not, and how to explain it to a supervisor.
Universe and constraints
The instrument set, the eligibility rules and the client-level limits.
Under the hood
Goals in, plan out
Objective, risk appetite, horizon, capital and constraints become an allocation across eight asset classes.
A real optimiser, not a lookup
A maximum-Sharpe portfolio computed on live market data, then mixed toward the client risk target.
Monte-Carlo, in three cases
Bear, base and bull, so a client sees a range they can react to instead of a single line that will be wrong.
Drift and rebalance signals
Live value, market regime and distance from target, surfaced when the portfolio needs it rather than on a calendar.
Advisor cockpit and client view
One engine behind both, so nothing has to be kept in step by hand.
Mixed to the client risk target rather than assembled by hand.
An advisor cockpit and a client onboarding view over one engine.
Bear, base and bull, simulated rather than extrapolated from one path.
Level of customization
Yours to change
Capital-market assumptions, the instrument universe, risk mapping, constraint rules, and both interfaces.
What we keep stable
The record. Every proposal keeps the inputs, model and constraints it was made under, because that is what a review asks for.
How it ships
In your cloud, so proposals, assumptions and client data stay inside your boundary.
ROI and economics
What you do not build
The optimiser, the simulation, the monitoring board, and the record-keeping that makes a plan reviewable.
Where the calendar goes
Not the first optimisation, but suitability, governance and the monitoring that has to keep running for years.
Advisor capacity
Proposal preparation stops being a multi-day exercise, and the advisor spends the time on the client rather than the spreadsheet.
What a mandate can hold
The accelerator ships with a nine-sleeve universe and the constraint logic around it. Anything beyond that is engineering, not configuration, and the table says which is which.
Listed markets
US, developed ex-US and emerging equities, government bonds, corporate credit, real assets and cash, each with a representative instrument and a fee.
Alternatives
Gold, broad commodities, managed futures and global infrastructure, held as a diversifier rather than a return engine.
Digital assets
A capped satellite, absent from the conservative model and sized so a total loss on it does not move the plan off its goal. The exclusion toggle removes the sleeve and returns the weight to core equities.
Derivatives overlay
Listed options and futures for hedging a concentrated position or a currency exposure, modelled where fills and margin are modelled properly rather than approximated.
Private and illiquid holdings
Carried as constraints rather than as optimisable instruments. A locked-up stake changes what the liquid part of the book has to do, and the plan says so.
Evidence a supervisor accepts
In wealth the regulated artefact is not the trade. It is the argument that the trade suited this client on that day.
The policy is tested, not just the allocation
A target allocation is a photograph. What a client actually experiences is the rebalancing policy: when it trades, what it tolerates before it acts, what it does in a drawdown. Every cadence is replayed over the same history, holding included, so the question of what a policy would have done has an answer rather than an opinion, and the cadence in the mandate has a reason behind it.
The rationale is written down
Each recommendation carries the case for it, the case against, and the risk objection, in language a client reads and a reviewer can audit. It is produced as a transcript attached to the proposal, and a person signs it.
The constraints are recorded in force
Risk profile, model version, exclusions and assumptions are stored with the proposal at the moment it was made. Months later the question is what was known then, and the record answers it without reconstruction.
The engines underneath, and their licences
You receive the source, which makes a licence an engineering constraint rather than a legal footnote. Everything below was selected so the codebase you own carries no obligation to publish it.
Optimisation
skfolio under BSD-3 for mean-risk optimisation on real returns. Chosen over the AGPL alternative for exactly this reason.
Market connectivity
CCXT under MIT prices the digital sleeve from venue data rather than an ETF wrapper. Daily closes are paged back five years, joined to the listed-market calendar so weekends are dropped rather than invented.
Market regime read
A K-line foundation model, MIT for both code and weights, samples several futures for an index and scores the spread as risk-on or risk-off. It informs the dial and nothing else: an allocation has to be explainable line by line, and a sampled forecast is not.
Execution and simulation
NautilusTrader under LGPL-3.0, linked unmodified, where the backtest and the live path are the same code. Changes to the library itself get published; your strategy code does not.
Research and rationale
A multi-agent research pass under Apache-2.0 that argues both sides of a position and records the disagreement.
Learned allocation policies
Reinforcement-learning environments under MIT, as an alternative policy engine behind the same approval gate as any other model. Research-grade code, so it is forked rather than depended on.
What we will not put in your codebase
GPL-3.0 tooling, because handing you the source is distribution and would oblige you to publish. A widely used vectorised backtester whose Commons Clause forbids selling a service built substantially on it. An unlicensed CLI, whatever its star count.
Where this fits
A good fit
An advice business with a real book, constraints that model portfolios cannot express, and a supervisor who asks why this client holds this allocation.
Not a fit
A firm looking for a finished robo-advisor service rather than engineering it will own. We are the second thing.
Part of Wealth
Investing platforms that hold up to audit
Trading and portfolio systems
built for real rails.
Tell us what you need to run: execution, reporting, local and international rails. We'll architect it for the regulators too.