Continuous credit risk reassessment

A continuous reassessment is not a new score sitting in a notebook. The artefact is a proposed limit change with a cite a credit officer can defend, and a write-back to core banking only when policy allows that change to become the live limit.

The model can watch consented open-banking cash flows and first-party account behaviour all day. It does not own the cut. Human review or a published policy rule owns the cut. If the pipeline cannot name the drivers in language a second-line reviewer would accept, it has not finished the job.

That is a different product from a bureau refresh, from thin-file credit limit calibration at origination, and from a scheduled annual pack. Continuous reassessment exists so a material change in inflows, utilisation, or commitment mix can surface between annual cycles, without treating a noisy feed as affordability.

Credit still has to answer three questions on every proposal: what changed, why that change supports this limit, and whether core banking is allowed to take the new number. If any of those is missing, hold the existing limit.

Re-score from two streams you can evidence, not from a blended mystery number.

First-party flows are the bank's own books: current-account credits and debits, card spend, existing limit utilisation, arrears status, product holdings, and internal behavioural flags already in the risk data mart.

Consented open-banking flows are the customer's other accounts, pulled through an aggregation layer of the same class as TrueLayer or Plaid, only while consent is valid and scoped. Treat them as a second view of income timing, commitments, and competing credit, not a licence to invent household surplus. Bureau files from providers in the Experian or Equifax class remain a periodic overlay, not a substitute for live cash-flow evidence and not a restatement of affordability.

Build features a credit person can read back: salary-like cadence and misses, persistent commitments, utilisation trend, new revolving balances on consented accounts, and age of last in-policy KYC or income evidence. Pair the cash-flow watch with perpetual KYC refresh so a limit proposal is not built on a stale identity or occupancy picture.

What you ignore matters as much as what you score. A single late salary credit is a blip until it repeats. A one-day open-banking outage is not a risk event. A surplus figure the model inferred from incomplete merchant data is not an input. If the feature cannot be shown on a statement extract or a consented transaction list, it does not belong in the cite.

The pipeline's job is to propose. The proposal is a candidate limit, a direction (hold, reduce, or increase), driver statements, and a flag that those drivers are complete enough to act.

Write the cite as a short stack a credit officer can check in minutes. Each driver line must point at a field, a window, and a comparison to policy: salary-like credit missing against expected pay cycles; first-party utilisation above the policy band for the required window; a new revolving facility with a rising balance on consented accounts. None of these is an affordability amount the model made up.

Increases are not the default. A higher limit the customer never asked for is a conduct and credit problem. If there is no customer request and no documented pre-approved programme, emit eligible-do-not-apply rather than a live increase. Reductions and holds are the usual continuous-review outputs.

One illustrative path. A personal current-account customer holds a stable card limit, with open banking consented. On a Thursday the aggregators show no salary credit on the expected day, and the internal current account is quiet too. The model proposes a cut. Overnight the salary lands two days late, at the usual amount. Auto-applying the cut would have reduced a performing customer on a payroll-timing blip. Hold instead: expected credit delayed, cadence intact, no second miss, no utilisation spike. Policy, or the officer, owns whether a first miss is even eligible for a cut.

Do not let the cite collapse into a model score. If the second line would only hear that the ranker moved, do not write back.

Core banking is the system of record. Cores in the Temenos class, and the limit services in front of them, reject updates that fail product, collateral, or customer-state checks. A proposal that never reached core, or that core rejected, is not a decision. It is an exception.

Gate write-back on an explicit policy table: which products may auto-apply a hold or a capped reduction; which reductions must queue to a named credit role; which increases are forbidden without a customer request; required evidence age; and what to do when consent has lapsed. Map each gate to a reason code the core API will accept. If the core returns a reject, do not retry a different number to force the write. Park the case, keep the live limit, and show the reject reason next to the cite.

The write-back payload should carry the new limit, the previous limit, the policy rule id, the driver ids, the model version, the consent snapshot id, and the officer or system actor. annual review document generation can later replay that trail so the file does not look as if the limit moved on its own.

Treat downstream consumers as part of the same change. Collections, authorisations, and early arrears prediction should see the live core limit, not the model's last proposal. A shadow limit gives two truths.

Cutting on a one-off salary delay is the failure mode to design out first. Payroll can move for bank holidays, employer batching, or a changed pay-day. Open-banking completeness can drop for a day without income changing. Require persistence, first-party corroboration, and a hysteresis band before a reduction is eligible. A noisy blip is a watch item, not a cut.

Raising a limit the customer never asked for is the opposite error with the same root: the model is acting. Unsolicited increases create unused headroom, surprise statements, and a weak story if the account later impairs. Keep increases in a may-offer state until a request or a governed programme applies them.

Writing a decision core rejected is a control break. The dashboard looks green because the model decided. The card still authorises on the old limit, or an authorisation service read a cache the core never accepted. Close the loop: proposed, policy-approved, core-accepted, caches invalidated. Anything short of that is a draft.

Other failure modes: scoring after consent expiry; mixing another household member's consented account into the cite; treating merchant category as income; auto-cutting while dispute or forbearance is open; emitting a surplus figure no underwriter could reconstruct.

Run three queues. Auto-hold or auto-reduce only inside published caps. Officer queue for cap-breaching reductions, conflicting drivers, consent gaps, and any contemplated increase. Exception queue for core rejects, missing reason codes, and stale evidence.

Staff the officer queue like a review desk, not a data-science backlog. Each item should open on the cite, the transaction windows, the policy rule, and the recommended action. The officer confirms, amends within mandate, or rejects. Their action is the decision.

Measure time from trigger to a core-accepted limit or an explicit hold, officer overturns, core rejects, and how often a first-miss flag dies when the delayed credit arrives. Count a change as complete only when core has a cite, an actor, and a policy id.

When the same name keeps appearing for income interruption, pass it to collections rather than cutting in isolation. When the file is thin or consented history is short, send it back to origination calibration. This pipeline is for names you already bank, with evidence you can show.