HKIB ECF-Operational Risk Core study materials
HKIB ECF-Operational Risk Core study resources

Robo-Advisory Launch: Conditional Approval Under Vendor Dependency

HKIB ECF-Operational Risk Core · Put your knowledge to work in context.

All case studies

Robo-Advisory Launch: Conditional Approval Under Vendor Dependency

A Hong Kong bank plans to launch a robo-advisory service for mass retail customers with a minimum investment of HKD 1,000. The investment engine is licensed from a US fintech and hosted in the US; the bank's staff cannot inspect the model logic, and the contract gives audit rights only over the vendor's own premises, not its cloud subcontractor. The model was trained on 10 years of US market data and has not been tested on Hong Kong customers. Marketing wants the slogan 'suitable for everyone'. The product approval committee meets in three weeks. Operational risk has been asked to sign off. The bank's risk appetite allows new-product risk acceptance only with a pilot limit and a defined exit. The vendor's API is a single point of failure, and the bank has no in-house capability to run the model if the vendor fails.

1. What are the principal operational risks, and which must be resolved before launch rather than monitored after?

Read the worked answer

Principal risks: model risk (trained on US data, not validated on Hong Kong customers, no explainability), conduct and suitability risk (mass retail, HKD 1,000 minimum, 'suitable for everyone' is misleading), outsourcing and concentration risk (single API, no audit rights over the cloud subcontractor, no in-house capability), data privacy and cross-border transfer, cyber, and complaints and dispute handling.

Must be resolved before launch: suitability and risk-profiling framework, local model validation and backtesting, explainability for staff and customers, audit rights over the vendor and subcontractor, a documented exit plan, a kill switch and manual override, and a complaints and compensation process. Can be monitored after launch: model drift, complaint rates and availability. The slogan must be withdrawn before any approval; it is a conduct risk that no pilot limit can cure. Sign-off should be conditional, not unconditional, and operational risk should record the conditions in the approval minutes.

2. What conditions would you attach to a conditional approval, and what residual risks would remain for risk committee acceptance?

Read the worked answer

Conditions: a pilot cap (for example, HKD 50 million AUM and 1,000 customers), no mass marketing, mandatory suitability assessment with human review for vulnerable or high-value customers, a local validation report accepted by an independent model risk function, explainability of the recommendation logic, audit rights extending to the cloud subcontractor, data-residency and security commitments, a tested exit plan and kill switch, incident and complaint reporting to operational risk, and a compensation policy.

Residual risks for risk committee acceptance: model performance may differ in Hong Kong, vendor failure may interrupt service, and cross-border data exposure may occur. These are acceptable only with limits, monitoring and a credible exit. The committee should record the acceptance, the limits and the review date; it should not accept the risk simply because the product approval deadline is in three weeks. If the vendor refuses audit rights, the condition is not met and the launch should be deferred.

3. Design three KRIs for the first six months and explain how each would drive action.

Read the worked answer

Three KRIs for the first six months:

  1. Suitability override rate - percentage of customers whose final portfolio differs from the model recommendation after human review, with a threshold and escalation. A rising rate suggests the model is mis-profiling customers or staff are overriding without documented reason.
  2. Complaint rate per 1,000 accounts, segmented by suitability and disclosure complaints. This is a lagging conduct indicator but the most direct signal of customer harm and mis-selling.
  3. Model drift - deviation of recommended allocations from the approved risk profile or benchmark, reviewed monthly. Drift beyond threshold should trigger model review or suspension, not just a report.

Add system availability and API latency against agreed service levels, and a leading indicator on completion of customer risk assessments. Each KRI needs an owner, threshold and defined action. Review at three months before lifting the pilot cap, and report the results to the product approval committee and risk committee.