This is a financial & insurance problem we approach through our Platform to Platform service line.
The problem
You want to put a personalised recommendation in front of a retail client: here is what someone with your goals, your horizon and your risk tolerance should consider, and here is how much of it. The demand side of that is not in question. Industry reporting puts Australia’s licensed adviser population at roughly half its 2018 level, and comprehensive personal advice is priced well beyond most households. Digital and hybrid advice is the mechanism everyone agrees fills the gap.
The constraint is that the moment your tool produces personal financial product advice, it is you giving it. ASIC’s RG 255 makes the position plain: digital advice is advice, the AFS licensing regime applies in full, and putting an algorithm where the adviser used to be does not shrink a single licensee obligation. In the EU the same logic holds under MiFID II — the suitability requirement sits with the firm and is not reduced because an automated system made the recommendation.
So the engineering brief is not “build a recommendation engine”. It is: build a recommendation engine whose behaviour your responsible manager can explain, whose output your compliance function can sample, whose overrides are on the record, and whose every historical recommendation can be reconstructed when someone asks why a client was told what they were told.
Why it’s hard
A ranking is not a recommendation you can size. Most models emit “best option first”. A sized action — invest this much, allocate this fraction — requires calibrated confidence: a number that means the same thing across clients and across days. Without calibration, mapping a risk profile to an amount is arithmetic performed on a fiction, and the suitability of the result is not defensible.
Suitability is per-client state, not a model feature. The same recommendation is suitable for one client and not another, and the inputs that decide it — objectives, situation, declared tolerance — arrive through a questionnaire the client fills in with limited human help. ESMA’s suitability guidelines call this out directly for robo-advice: the firm has to ensure the questionnaire works without a human in the room, disclose that an algorithm is used, and be able to say when and why it would override the algorithm. That override path has to exist in the architecture before it can exist in a disclosure document.
Testing is ongoing, not a launch gate. RG 255 requires the algorithm to be monitored in production, including sampling the advice actually produced. A model that was validated once and then drifted is a compliance failure that looks, from the inside, like a working system. The monitoring, sampling and regression machinery is a build item with its own backlog, and it is routinely the item that gets cut when the launch date is fixed.
Explainability has become a governance requirement before becoming a statutory one. ASIC’s REP 798 reviewed 624 AI use cases across 23 licensees and found governance lagging adoption, singling out a credit-risk model whose variables could not be explained. Australia has no AI Act equivalent; the obligations flow from existing licensee duties, which means “the model said so” is already an inadequate answer. A responsible manager has to understand the algorithm, which constrains the class of model you can responsibly deploy far more than any accuracy benchmark does.
Execution is where trust is won or lost. A recommendation that the client then has to carry out manually in another system leaks value and creates a gap between what was advised and what was done. Automated execution closes that gap and raises the stakes: it must run only under explicit, revocable client authorisation, enforced in the code path rather than asserted in the terms.
How we approach it
Calibrated confidence as a first-class model output. The engine emits a probability the sizing layer can consume, not a rank. Model versions are recorded against every recommendation, so “which model told this client that” has an exact answer.
A profile-to-action layer that is legible before it runs. The client’s declared risk profile and budget map to an action size through rules your compliance function can read and sign off. In BetrBets this was three profiles — conservative, moderate, aggressive — with the stake derived from budget and the tip’s confidence score, so a marginal recommendation was a smaller action by construction. The same shape carries directly: the mapping is configuration reviewed by compliance, not behaviour buried in a model.
Human override with an audit trail, not a config change. Experts can overrule the model, and the model can be re-weighted against expert input, with every override recorded and attributable. This is the mechanism behind ESMA’s “when and why the firm might override the algorithm” disclosure — a sentence in a document is only true if the system underneath records it.
Execution under explicit authorisation. Where the product acts on the recommendation, it does so at live prices, per-client, revocable, with nothing placed without authorisation. We built exactly this against the Betfair Exchange for BetrBets, operating under Betfair’s public vendor rules — venue rules enforced in the integration, not around it.
Reproducibility as a design constraint. Any historical recommendation can be reconstructed from the model version, the inputs and the rules in force at the time. This is what makes advice-sampling and complaint-handling tractable, and it is close to impossible to retrofit.
Scenario modelling where planning needs a forward view. Projection and what-if machinery draws on the same time-series and scenario-generation approach we built for a price forecasting engine in another domain: forecasts carrying their own confidence, and an optimiser that presents scenarios rather than one false-precision answer.
What we do not do. We do not provide financial advice, hold an AFS licence, or design your suitability policy — those are yours and your lawyers’. We also will not build an engine whose recommendations cannot be explained to the responsible manager who has to stand behind it; if a model family cannot meet that bar, we say so and use one that can.
What it takes
Your licensing position, settled first. Whether the tool provides general or personal advice, and under whose licence, shapes the architecture — the questionnaire, the disclosures, the sizing layer. Engineering built ahead of that answer gets rebuilt.
A compliance function in the room from the first sprint. The profile-to-action mapping, the override policy and the monitoring plan are compliance artefacts implemented in software. They need an owner on your side who can approve them, because RG 255 puts a responsible manager’s name against the algorithm.
Data with a defensible lineage. Client profile data, market data and model training data each need a stated source and update cadence. The suitability of a recommendation inherits the quality of the inputs.
A monitoring and sampling regime, budgeted as a deliverable. Ongoing algorithm testing, output sampling and drift detection are RG 255 obligations with engineering cost. They are scoped and priced in the build, not appended after it.
Realistic sequencing for execution. Recommendation-only first, execution under authorisation second. Automated execution multiplies both the value and the obligations, and turning it on is a decision your board should make with the recommendation layer already proven.
Where this has been done
The recommendation-to-sized-execution architecture is a shipped, named reference — in wagering, not financial advice, and we state that plainly rather than blurring it. BetrBets, a mobile tipping product we designed, built and later sold, generated model-driven recommendations matched to conservative, moderate and aggressive risk profiles, sized each stake from the user’s budget and the model’s confidence, recorded expert overrides against versioned models, and executed automatically on the Betfair Exchange at live prices once the user authorised it. Mechanically, that is the robo-advice pattern: calibrated recommendation, suitability by declared profile, sized action, human oversight, authorised execution.
The forecasting and scenario layer draws on an anonymised delivery: a price forecasting and optimisation engine for a manufacturer, covering 100+ product SKUs, with daily time-series forecasts and scenario-based optimisation.
We have not delivered an AFS-licensed advice product, and this page does not claim otherwise. What we bring is the engineering of the machinery RG 255 and MiFID II require a licensee to operate.