Dynamic credit limit management with ML

A static credit limit is a guess about a customer that stops updating the moment you set it. Dynamic limit management replaces that guess with a scheduled decision: a model estimates how much credit a customer can use and repay, an affordability calculation caps the number, and a policy layer decides whether to offer an increase, hold, or cut the line. The models rank; the rules bind.

The temptation is to treat this as one scoring problem. It is not. Assigning a line to a new account, offering an increase to a performing one, and pulling exposure from a deteriorating one are three separate decisions. They optimize for different objectives and run on different data, and the regulator treats each differently. Collapse them into a single “limit model” and you get a system that offers increases to customers who are three weeks from missing a payment.

Three decisions, not one

Line assignment at origination runs on thin data. You have the application, a bureau pull, and whatever cash-flow signal you managed to collect, but no repayment history on this account. The job is to set an opening limit that is useful enough to drive usage without handing exposure to someone who will run it up and default. We treat the opening line as a conservative starting point and let the account earn its way up.

Limit increase is the decision with the most upside and the most room to get wrong. Here you do have behaviour: payment history, utilization, balance trajectory, how the customer responded to previous increases. The model estimates capacity to repay a larger line. But capacity is not permission. The increase can only be offered if it sits inside a verified affordability envelope, and that envelope is computed separately from the score.

Limit decrease is a risk and conduct action, and it is the one people build last and regret. Cutting a line on a customer who is relying on it can push them into difficulty, which is exactly the outcome conduct rules exist to prevent. A decrease model has to be defensible to a customer, to an ombudsman, and to your own second line. We build it to produce a reason, not just a number: which signals moved, over what window, and why the reduction is proportionate.

Point-in-time features or nothing

Every failure mode in these models traces back to the feature layer, and the specific failure is leakage. If your training set computes a customer’s utilization or arrears status using data that only became available after the decision date, the model learns from the future and looks brilliant in backtest, then collapses in production.

The discipline is point-in-time correctness on every feature:

• Reconstruct each feature as it would have been known at the decision timestamp, not at extraction time.
• Watch bureau data especially. A refresh dated last week may contain a delinquency that was reported after the decision you are training on.
• Handle the reconciliation gap between transaction posting date and the date a balance was actually visible to the decision engine.
• Keep lineage for every feature so that when a decision is challenged, you can show the exact inputs as of that moment.

A feature store helps here only if it stores history correctly. Point-in-time joins against a versioned feature table, with the decision timestamp as the key, are the mechanism. Storing the current value and hoping the training pipeline reconstructs the past is where teams lose months to a model that will not replicate.

Entity resolution matters more than it looks. A customer with two accounts, a joint facility, or a recent product migration can show up as several entities, and if your exposure feature only sees one of them, the affordability cap is computed against the wrong denominator. Resolve the customer to a single obligor before you compute total exposure, or the limit you assign is measured against a fiction.

Affordability and conduct as hard constraints

Affordability sits after the model as a separate calculation, and it can override the score. The model tells you a customer ranks well for an increase; the affordability layer tells you the largest increase that keeps their committed outgoings inside verified income. When the two disagree, affordability wins and the decision is logged with that reason.

We structure it so the constraint is auditable:

• Verified income and committed spend feed a documented affordability formula, versioned like code.
• The proposed limit is the minimum of the model-eligible amount and the affordability cap.
• Anything the affordability layer refuses is recorded with the input figures, so a reviewer can reproduce the refusal.

Conduct rules add a second binding layer, particularly on decreases and on customers showing signs of difficulty. A customer flagged as vulnerable, or one whose recent behaviour matches an early-warning pattern, should not receive an unsolicited increase offer even with a strong score. Encode these as pre- and post-scoring gates rather than trusting the model to have learned them. The model optimizes for repayment probability; it has no concept of a conduct obligation unless you build one.

Straight-through processing is the goal for the clear cases, but the threshold matters. Small increases to well-inside-affordability customers can run automatically with a full audit trail. Decreases, large increases, and anything touching a vulnerability flag route to a human with the reason codes and the underlying figures attached. Automating the decrease is where an efficient system becomes an unfair one.

Watching the models after they ship

These models degrade, and they degrade quietly. Rate environments shift, a segment’s spending pattern changes after a seasonal peak, a data feed starts arriving late around quarter-end and silently changes the freshness of a feature. None of this throws an error. The model keeps producing numbers that look plausible and are progressively wrong.

Drift monitoring has to run on both inputs and outcomes. Track the distribution of each feature against its training baseline, and track realized performance: are the increases you granted three and six months ago performing as the model predicted? A rising share of increases followed by utilization spikes and arrears is the signal that the increase model has drifted toward optimism.

Hold out a stable eval set and re-score it on every model version, so a regression shows up before it reaches customers. When you retrain, keep the old and new decisions side by side on the same population and read the difference before you cut over. A limit decision is a promise about someone’s finances, and the cost of being wrong lands on them first.