Improving the business logic behind cash forecasting.
Finance-domain co-ownership of Group Cash Flow Forecasting with Data Science, supporting multi-country and multi-currency liquidity planning.
A forecast is only as useful as the business logic behind it.
Group Cash Flow Forecasting combines enterprise Finance data, model logic and Treasury use cases across countries and currencies. My role sits on the Finance side of the product: investigate variances, challenge assumptions and translate recurring business behaviour into changes the model can use.
One production rule, improved.
A payroll forecast used the earliest observed payment date. The code was deterministic; the business assumption was the problem. I tested whether recurrence was a better signal and changed the rule to use frequency-based date selection.
| Dimension | Before | After |
|---|---|---|
| Rule | Choose the earliest observed payroll date. | Choose the date that recurs most frequently. |
| Failure mode | A one-off early payment could pull the forecast forward. | The rule follows recurring payroll behaviour rather than the earliest exception. |
| Where it lives | Production business logic in Group Cash Flow Forecasting / Dataiku. | |
| Status | Shipped to production. No public quantified impact claim is made yet. | |
Why the date rule matters, shown on made-up payroll.
Not project data. It compares the two payroll-date rules from the table above on invented payments. The numbers below are computed at build time from invented data made with a fixed random seed. They show how the idea works, not what happened on the project.
| Rule | Average miss (days) | Forecast exactly right | Months scored |
|---|---|---|---|
| Earliest observed date | 3.1 | 7% | 108 |
| Most frequent date | 1.0 | 59% | 108 |
Each month is forecast using only the 6 months before it. The gap depends on how often a one-off early payment happens, so here is the same test with different assumptions:
| One-off early payments | Earliest rule (days) | Most frequent rule (days) |
|---|---|---|
| 0% of months | 1.4 | 0.5 |
| 5% of months | 2.8 | 0.8 |
| 12% of months | 3.1 | 1.0 |
| 25% of months | 3.4 | 1.9 |
The most frequent rule is not perfect either. When the payday falls on a weekend the payment moves earlier, and a rule that only looks at past dates cannot see the calendar.
How this was computed
6 invented entities, 24 months each. Every entity has a contract payday between the 14th
and 28th. If it falls on a weekend, payment moves to the Friday before. In 12% of
months a one-off run pays 3 to 6 days early. Code: src/lib/artifacts/payroll-rule.mjs, tests in
scripts/artifacts.test.mjs.
Finance-domain co-owner, not solo model owner.
I own / contribute
- Finance-domain investigations
- Business-logic analysis
- Targeted production enhancements
- Translation between Finance, Treasury and Data Science
Shared / specialist ownership
- Broader Data Science model
- Model architecture and specialist data-science decisions
- Enterprise platform engineering
Technical sophistication does not replace a good business rule.
The useful part of my role is the boundary: understand how Finance actually behaves, then make that logic explicit enough to test and improve.