Skip to content
ZERO-RISK100% replacement guarantee on every hire.See how we work
Back to all case studies

CASE STUDY · WEALTHTECH PLATFORMS

Automating portfolio rebalancing for a boutique wealth manager.

CLIENT · ANONYMISEDWEALTHTECH PLATFORMS
  • 2 weeksRebalancing down from 2 weeks to 2 days
  • 12 hoursAbout 12 hours a week saved

01 · PROJECT OVERVIEW

The client and the brief.

An anonymised boutique wealth manager. Name withheld under confidentiality.

Rebalancing rules, an approval step and trade-file export. The system compares each account with its model, applies the firm's rules, and proposes trades. A portfolio manager reviews and approves them. Approved trades are exported in the format the firm's trading platform accepts.

WHAT THE CLIENT WAS DEALING WITH
  1. Rebalancing took 2 weeks.
  2. Each cycle, an analyst exported positions, compared them with model portfolios in a spreadsheet, worked out trades by hand and emailed them for approval.
  3. Because it took so long, portfolios drifted for weeks between cycles.
  4. Errors crept in through copy and paste, and each client exception, such as restrictions or cash needs, was tracked in someone's memory.
  5. The firm wanted faster, more consistent rebalancing without losing human control.

02 · WHAT WENT WRONG

What went wrong, and how we fixed it.

Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.

  • PROBLEM 01In shadow mode, the engine proposed trades that portfolio managers would never have made

    Most came from client restrictions that lived in emails and notes, not in any system. We added a structured restrictions record per account, filled it in with the team, and made the engine refuse to propose a trade for an account with missing restriction data. That turned a hidden risk into a visible to-do list, and the shadow comparison became clean.

  • PROBLEM 02That turned a hidden risk into a visible to-do list, and the shadow comparison became clean
  • PROBLEM 03A second problem appeared when the first approved trade file was rejected by the trading platform

    The cause was a rounding difference: our engine rounded lot sizes one way and the platform another, which broke a file-level total check. We matched the platform's rounding rules, added a pre-export validation step that mimics the platform's checks, and logged every rejection with its reason. After that, files went through cleanly, and the team trusted the export.

  • PROBLEM 04After that, files went through cleanly, and the team trusted the export

03 · THE PROCESS

How we ran it.

We spent the first phase writing the firm's rules down with the portfolio managers, including the exceptions they handled informally. We built the rules engine first and ran it in shadow mode against past cycles. Each week we compared its proposals with what the team had done by hand and discussed every difference. Once differences were understood, we added the approval screens and the export. A parallel run followed, where the team did both methods for a cycle, before the old process was retired.

  1. 01
    Step 1

    We spent the first phase writing the firm's rules down with the portfolio managers, including the exceptions they handled informally.

  2. 02
    Step 2

    We built the rules engine first and ran it in shadow mode against past cycles.

  3. 03
    Step 3

    Each week we compared its proposals with what the team had done by hand and discussed every difference.

  4. 04
    Step 4

    Once differences were understood, we added the approval screens and the export.

  5. 05
    Step 5

    A parallel run followed, where the team did both methods for a cycle, before the old process was retired.

04 · RESULTS

What changed.

Measured against the way the work ran before the engagement began.

  • NOW 01

    Analysts spend their time on exceptions, not on arithmetic.

  • NOW 02

    Managers review proposals with the reasoning attached and approve in one place.

  • NOW 03

    Restrictions are kept as data, so a new analyst cannot miss them.

  • NOW 04

    Drift is checked far more often than before, and the firm can show exactly why any trade was made.

  • 2 weeks

    Rebalancing down from 2 weeks to 2 days

  • 12 hours

    About 12 hours a week saved

05 · WHAT WE BUILT

How it works.

  • Positions and model targets are loaded from the firm's data sources and validated on ingest.
  • A rules engine calculates drift, applies tolerances, honours account-level restrictions, handles cash needs and proposes whole-lot trades.
  • Each proposal stores the inputs and rules that produced it, so any trade can be explained later.
  • The approval workflow requires a named reviewer, supports changes and rejection with a reason, and records every action in an audit log.
  • Exports are generated from approved trades only, with a checksum and a reconciliation report.
  • Access is role-based.

06 · QUICK ANSWERS

The short version.

What problem did the client have?
Rebalancing took 2 weeks. Each cycle, an analyst exported positions, compared them with model portfolios in a spreadsheet, worked out trades by hand and emailed them for approval. Because it took so long, portfolios drifted for weeks between cycles. Errors crept in through copy and paste, and each client exception, such as restrictions or cash needs, was tracked in someone's memory. The firm wanted faster, more consistent rebalancing without losing human control.
What did Brandsmashers build?
Rebalancing rules, an approval step and trade-file export. The system compares each account with its model, applies the firm's rules, and proposes trades. A portfolio manager reviews and approves them. Approved trades are exported in the format the firm's trading platform accepts.
How was the work run?
We spent the first phase writing the firm's rules down with the portfolio managers, including the exceptions they handled informally. We built the rules engine first and ran it in shadow mode against past cycles. Each week we compared its proposals with what the team had done by hand and discussed every difference. Once differences were understood, we added the approval screens and the export. A parallel run followed, where the team did both methods for a cycle, before the old process was retired.
What were the results?
Rebalancing down from 2 weeks to 2 days; about 12 hours a week saved.

YOUR TURN

Have a similar requirement?

Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.

NEXT CASE STUDYBuilding a goals-based investing dashboard for a WealthTech client