Price and fee optimization with ML, within the rules

Price optimization with machine learning means estimating how demand and retention respond to the fees and rates you charge, then choosing prices that raise revenue or margin under explicit constraints. In regulated finance the constraints are the hard part. A pricing model is also a compliance surface, and the price a customer sees has to survive fair-pricing and conduct review, not only a revenue backtest.

There is a worse failure mode than mispricing by a few basis points. It is a model that learns to charge more wherever it can, where “wherever it can” turns out to track a protected class, or customers who do not shop around because they are elderly, new to the country, or simply not paying attention. That is the version of price optimization that ends in a consent order. Everything below is about building the profitable version without building that one.

Elasticity is the model; the price is a decision on top of it

The thing you actually estimate is elasticity: how a segment’s take-up, balance, or attrition moves as you move the fee or rate. That estimation is a causal problem, not a correlational one, and it is where most of the engineering effort goes.

Historical price variation is confounded. Prices were set by old policies that already conditioned on risk, channel, and negotiation, so a naive regression of volume on price recovers the old policy, not the demand curve. We lean on the sources of variation that were closer to random: pricing experiments where the business ran genuine A/B tests, discontinuities at policy thresholds, and staggered rollouts across regions or cohorts. Where clean experiments do not exist, we say so, and we widen the uncertainty band rather than pretend the elasticity is known.

Point-in-time correctness matters here as much as in credit modeling. If your elasticity training set joins a customer’s response to features as they look today rather than as they looked at quote time, you have leakage, and the model will credit the price for outcomes it never caused. Balances, risk scores, and relationship tenure all drift, so every feature in the elasticity set carries its as-of timestamp and is reconstructed from the feature store at the moment the price was shown.

The price itself is a separate step. Given an elasticity estimate with honest error bars, the optimizer picks a fee or rate that maximises expected margin subject to constraints. Keeping estimation and decision apart is deliberate. It lets you change the objective or tighten a constraint without retraining, and it gives you two artifacts to audit instead of one black box.

Put the constraints inside the optimizer

Fair-pricing rules cannot be a screen you run after the optimizer has already chosen. If the objective is pure margin and you filter afterwards, the model spends its whole search in the region you will end up rejecting, and whatever survives the filter is the least-bad corner of a bad space. Constraints belong inside the optimization.

Concretely, we encode:

• A bounded rate band per risk tier, so pricing tracks the underwriting model and cannot drift into charging risk-equivalent customers different amounts for unrelated reasons.
• A reviewed allowlist of features that are permitted to influence price, kept separate from the larger set used for elasticity research. Postcode, device, and browsing behaviour tend to live on the research side and stay out of the price.
• Disparate-impact ceilings measured across protected groups, checked on the proposed price distribution before any change ships, using the same fairness test suite we apply to credit models.
• A conduct check on vulnerable segments, so the optimizer is not rewarded for the fact that some customers do not renegotiate.

Each constraint is a line in the audit trail. When a regulator or an internal model-risk reviewer asks why customer X was charged what they were, the answer is the risk tier, the allowlisted features, the elasticity estimate, and the binding constraints, all reproducible from lineage. Under SR 11-7 that reproducibility is not optional for a model this material, and treating price optimization as a governed model rather than a growth hack is what keeps it deployable.

Watch the drift, and watch the second-order effects

Elasticities move. A rate environment shift, a competitor repricing, or a change in your own acquisition mix will make last quarter’s demand curve wrong. We monitor realised take-up and attrition against what the elasticity model predicted, segment by segment, and treat a widening gap as a drift signal that pulls the affected segment back to a conservative default until it is re-estimated. Quarter-end is a bad time to discover the curve has moved, so the monitoring runs continuously rather than on a review cadence.

Two second-order effects deserve their own eval sets:

• Cross-product substitution. Push a fee up and customers may shift to another product, cancel an add-on, or reduce balances. Optimising one line item while a neighbouring one bleeds is easy to do if you only score the product you touched. We measure at the relationship level.
• Feedback loops. Today’s prices generate tomorrow’s training data. If the model prices a segment out, that segment thins from the data, elasticity estimates for it degrade, and the model grows more confident about a curve it can no longer see. Holding out a small randomised pricing slice keeps a source of unconfounded variation alive, which costs a little margin now and buys you a model that still works next year.

None of this removes judgement from pricing. It moves the judgement into places you can inspect: the objective, the constraints, the feature allowlist, and the monitoring thresholds. A pricing model built this way earns more where demand genuinely allows it and holds the line where the rules, or plain fairness, say it should not push. That is the only kind worth putting into production on a book you have to answer for.