Step 03 · Optimization Engine
On the roadmapSolvenz is the same composite as in the Analytics and Prediction Engine cases. The scenario is illustrative; the regulatory framework is sourced. The Optimization Engine is on Theovya’s roadmap; this case describes the workflow it is designed to run.
The at-risk list told the treasurer who might leave when a competitor moved. It did not tell him what to offer. That question is harder than it looks, and Solvenz had always answered it in the committee room.
Every basis point offered to a depositor who stays is interest expense for as long as the balance remains. Every euro that leaves has to be replaced with more expensive wholesale funding or paid out of liquid assets. And the constraint that actually binds is regulatory. Under Basel III, a bank must hold enough high-quality liquid assets to cover its net cash outflows over a 30-day stress scenario, with less stable deposits assumed to run off faster than stable ones. Losing large, short-tenure balances affects the liquidity coverage ratio on both sides: cash goes out, and the deposits that remain change the stressed outflow assumptions.
Solvenz’s committee had used a three-tier rule: plus fifteen, twenty-five or forty basis points, set by balance band. It is defensible, easy to explain and almost certainly not the best use of the money. The real problem is 2,100 accounts, each with five possible offers, each with a different probability of staying at each offer level, all tied together by one ratio that must stay above the bank’s internal floor. That is an integer programme. No spreadsheet sizes it, and the balance-sheet tools in treasury model portfolios rather than individual offers.
The offer book, solved
When the next competitor moved, the treasurer asked:
Choose a counter-offer for each at-risk account - none, +10, +20, +30 or +40 basis points - to minimize the next twelve months’ funding cost. Keep our liquidity coverage ratio above 135 percent through the stress scenario, keep total offer spend under €1.2 million, and never offer more than the public rate for a new customer.
The Optimization Engine formulated the model before solving it. Decide: one offer level for each account. Estimate: the balance kept at each level, using the Prediction Engine’s rate-sensitivity model extended with offer size. The engine flagged that this extension rested on only two past campaigns, so it solved a pessimistic acceptance scenario alongside the central one. Must hold: the liquidity coverage ratio under stress; the spend cap; the public-rate ceiling. The head of risk added one more constraint before the run: accounts in the same product and balance band receive the same offer unless relationship value differs by a documented criterion. Offers must be consistent and explainable, and the engine enforces that by construction rather than trusting everyone to remember. Minimise: interest expense plus the cost of replacing balances that leave.
The central scenario was proven optimal in seconds. The plan kept the ratio at the 135 percent floor for about €0.9 million over twelve months; the three-tier rule would have cost €1.6 million and left the ratio at 133. Thirty-eight percent of at-risk accounts received no offer at all, either because the model expected them to stay or because keeping them was worth less than the offer.
The pessimistic scenario is where the engine earned its place in the committee. Under weaker acceptance, the same plan fell to a ratio of 131 percent - below the bank’s own floor, still well above the regulatory minimum. The engine did not bury that. It presented both results and the trade-off between them: near the floor, each additional point of liquidity coverage cost about €45,000. The committee chose to raise the spend cap by €200,000 for a fortnight rather than accept 131 percent. That is a judgement, and it belonged to the committee - but for the first time it was made with the price on the table.
12-month cost of retention and replacement
- Every point above the curve is feasible but wasteful.
- Blanket match (+40 bp)≈ €7M a year, off this chart
- Pessimistic acceptancesame plan falls to LCR 131%, flagged, not hidden
- Cost of each LCR pointnear the floor: ~€45k
Composite scenario; figures illustrative. Acceptance probabilities from the Prediction Engine's rate-sensitivity model.
Collections, by the hour
The Prediction Engine’s early-warning score created a better problem: more accounts worth calling than collectors to call them. Six collectors have about six productive hours a day each. The collections lead asked:
Assign tomorrow’s collector hours to delinquent accounts to maximize the expected balance cured within 30 days, using each account’s best contact window and each collector’s languages, with no more than three contact attempts per account per week.
This is an assignment problem with time windows, too large to solve exactly each night in the time available. The engine used a heuristic search and reported the gap to a proven bound, typically under two percent. The contact limits were hard constraints: the solver cannot produce a plan that breaks a contact rule, just as it cannot produce a plan that exceeds collector capacity. The plan sent calls where a call changes the outcome most, rather than to the oldest arrears or the largest balances. On the same hours, expected cures rose by about a fifth.
Calls go where a call changes the outcome, inside every contact rule.
Composite scenario; figures illustrative. Contact-frequency limits and customer contact windows are hard constraints.
Where treasury judgement sits now
None of the committee’s decisions moved to software. The liquidity floor, the spend cap, the fairness rule and the contact policy are still set by people accountable for them. What changed is that those decisions are now inputs to a model, and their consequences are computed rather than debated.
The committee’s Monday meeting reflects that. It spends less time arguing about whether a tier should be twenty or twenty-five basis points and more time on the questions that are genuinely theirs: where the floor should sit, how much uncertainty to tolerate, and what the bank owes its long-standing depositors. The Analytics Engine showed Solvenz its outflow. The Prediction Engine showed who was about to leave. The Optimization Engine priced keeping them, against the ratio that actually binds.
Sources
- Basel Committee on Banking Supervision, Basel III: The Liquidity Coverage Ratio and liquidity risk monitoring tools (BIS, 2013): high-quality liquid assets to cover net cash outflows over a 30-day stress period; differentiated deposit run-off assumptions.