Separate what happened, what is expected, and what is being tested.

Forecasts, plans, scenarios, and stress tests serve different questions

Analytical systems often place several forward-looking outputs on the same dashboard even though they represent different decisions. A forecast may describe a current expectation under stated assumptions. A budget or plan may express a management target. A scenario may test a coherent set of hypothetical conditions. A stress test may examine resilience under adverse conditions. The labels and requirements depend on the institution and intended use.

The distinction matters because a hypothetical scenario is not necessarily a prediction, and a management target is not necessarily the most likely outcome. Users should be able to see which type of output they are reviewing, who approved it, which assumptions it uses, and how it relates to the institution’s governed starting data.

Begin with the decision and time horizon

Before selecting a method, teams should define the decision the analysis supports. Short-term liquidity forecasting, annual planning, interest-rate sensitivity, portfolio growth, capital planning, product profitability, and operational capacity do not share one universal horizon, grain, or assumption set.

A useful scope record identifies:

• the decision, policy, or review process being supported;
• the starting date, reporting period, and forecast horizon;
• the legal entities, portfolios, products, accounts, or relationships included;
• the time increments used for projected results;
• the required outputs and comparison measures;
• the owners of source data, assumptions, methods, review, and approval;
• the limitations and uses that must be disclosed; and
• the events that require recalculation, escalation, or a new version.

Scope should be narrow enough to be testable and broad enough to include material interactions. A deposit runoff assumption can affect liquidity, funding cost, profitability, and balance-sheet composition at the same time.

Control the starting position

A forecast cannot be more traceable than the position from which it begins. The starting balance sheet, portfolio population, income statement, transaction history, or operational measure should reconcile to approved sources at the required level of detail. Unresolved differences need visible treatment rather than silent adjustment.

The analytical layer should retain as-of dates, source extraction times, accounting periods, effective dates, currency, legal entity, product hierarchy, and the mapping versions used to assemble the starting position. If a late record or mapping correction changes the starting data, the affected forecast version should be identifiable.

Historical values should remain separate from projections. Replacing observed values with adjusted or normalized figures may be appropriate for a defined purpose, but those adjustments should be labeled, versioned, and attributable to an authorized rule or reviewer.

Maintain an assumption inventory

Forward-looking analysis usually depends on assumptions that cut across portfolios and functions. Examples may include interest rates, deposit behavior, loan utilization, originations, paydowns, prepayments, maturities, credit performance, fee activity, operating costs, funding availability, liquidity needs, capital actions, and management responses.

For each material assumption, an inventory can record:

• a plain-language definition and analytical purpose;
• the applicable portfolio, product, entity, period, and scenario;
• the source, rationale, or approved method;
• the owner, reviewer, approval status, and effective dates;
• the unit, sign convention, range, and time behavior;
• dependencies on other assumptions or outputs;
• known limitations and conditions for use; and
• the version and change history.

Assumption names should not conceal different meanings. A “deposit decay,” “loan growth,” or “loss rate” may use different populations, time bases, and methods across analyses. Shared definitions reduce disagreement, while explicit scenario overrides allow controlled differences when the purpose requires them.

Design scenarios as coherent sets

A scenario is more than a collection of individually severe values. Its variables should describe a coherent analytical condition over time, with relationships and timing that can be explained. Baseline, alternative, and adverse cases may be useful labels, but institutions should define what each means for the specific analysis rather than relying on the label alone.

Scenario design should identify which variables are externally supplied, internally developed, policy-defined, or produced by another method. It should also show how a scenario translates into portfolio behavior, income, expenses, cash flows, funding, balance-sheet composition, and other outputs relevant to the decision.

Comparisons become more useful when scenarios share the same starting position, definitions, and calculation version unless a difference is intentional. Otherwise, a change attributed to the scenario may actually come from a new data extract, mapping, or method.

Govern methods according to their use and risk

Forecasts may use contractual schedules, accounting rules, deterministic calculations, statistical methods, expert judgment, vendor tools, or combinations of these approaches. Institutions determine which tools meet their definition of a model and how governance should be tailored to the risk, complexity, materiality, and use.

Useful controls can address conceptual design, data suitability, testing, implementation, limitations, change management, ongoing monitoring, outcomes analysis, independent challenge, and approval. The depth of review should be proportionate to the consequence of error and the role the output plays in decisions.

A polished visualization should not elevate an informal calculation into an authoritative result. The interface should display method identity, version, review status, limitations, and the distinction between approved production use, exploratory analysis, and draft work.

Preserve versions and reproducibility

A published forecast should be reproducible using the starting data, assumptions, method versions, configurations, manual adjustments, and approval state that were effective when it was released. Re-running the current method against revised data is not the same as reproducing a prior result.

Versioning should connect:

• the source-data snapshot and reconciliation evidence;
• the scenario and assumption set;
• calculation, model, and allocation versions;
• configuration and hierarchy versions;
• manual adjustments and overrides;
• review comments, exceptions, and approvals; and
• the reports, dashboards, or files produced from that run.

When a result changes, reviewers should be able to separate movements caused by new actual data, updated assumptions, revised methods, corrected defects, mapping changes, and management actions.

Compare actual outcomes with prior expectations

Actual-to-forecast review is a control and a learning process. It can identify data problems, assumption drift, method limitations, timing differences, operational changes, and events that were not represented in the prior view. Variance should be analyzed at a level where its cause can be investigated rather than only at a final institution total.

Useful review questions include:

• Which differences reflect volume, rate, mix, timing, credit, behavior, cost, or accounting effects?
• Did the observed population match the one assumed in the forecast?
• Were missing or delayed records material to the comparison?
• Did a management action occur as represented in the scenario?
• Did model or calculation performance change for a particular segment or horizon?
• Should an assumption, method, limitation, or escalation threshold be revised?

A revised method should not rewrite prior performance. Institutions may need to retain both the original published result and later analysis explaining how and why the process changed.

Report uncertainty and limitations with the result

Executive reporting should present the decision-relevant outcome without removing the context required to interpret it. Useful disclosures may include the scenario type, as-of date, horizon, key assumptions, range or sensitivity, major limitations, unresolved exceptions, approval status, and comparison with prior forecasts or actual outcomes.

Ranges, sensitivities, and scenario comparisons can communicate uncertainty more honestly than a single point estimate. They do not eliminate uncertainty, and they should not be presented as probabilities unless the method supports that interpretation.

Access should follow role and purpose. Draft assumptions, exploratory runs, approved plans, regulatory work, and executive reports may require different audiences, controls, and retention. A common platform can preserve those distinctions without duplicating definitions across disconnected spreadsheets and dashboards.

Automate repeatable runs without automating judgment away

Routine data assembly, validation, reconciliation, assumption loading, scenario execution, comparison, and report preparation can be automated. The workflow should stop when required data, approvals, versions, or validation evidence are missing, or when results exceed institution-defined exception conditions.

Automation should record which inputs and versions were used, what passed or failed, which exceptions remain open, and whether a result is draft, reviewed, approved, or superseded. Material assumption changes, ambiguous authorization, validation failures, and risk-acceptance decisions remain appropriate escalation points.

This article provides general technical information. It is not accounting, legal, regulatory, cybersecurity, investment, model-risk, or risk-management advice, and it does not describe a finished or generally available product.

How this informs our platform development

Morrow Creek Banking Analytics Division is designing forecasting and scenario analysis around reconciled starting positions, versioned assumptions, governed methods, comparable scenarios, role-based review, reproducible outputs, variance analysis, and auditable workflow history.

The public website does not accept production financial information. Future institution deployments are planned as a separate technical and governance boundary from the existing Morrow Creek Data Services ordering and delivery process.