Artificial Intelligence for Finance | Release 004

The Model Is Not the Business System

What Predictive Analytics Taught Me About Evidence, Economics, and Responsible Decision-Making

Return to the Knowledge HubExplore The Prediction-to-Business-System FrameworkUse Practice Guide No. 004 - The Predictive Analytics Readiness Review

Could I build my own model?

That was the question I had at the end of a trading exercise in Week 4. We had worked through a simplified predictive strategy in Python, moving from historical market data and alternative data to regression outputs and then to rules for turning those predictions into portfolio decisions. I understood that a classroom exercise was only the surface of what a real investment system can require. But the architecture had become visible enough that it no longer felt mysterious.

It felt doable. More than that, it felt fun.

I immediately started imagining what I would change if I built one for myself. Which variables would I choose? What information might capture something the market had not fully reflected yet? What other data would I want to test? Could I create a strategy around my own ideas and use Python to see whether those ideas held up?

I did not leave the trading exercise intimidated by predictive analytics. I left wanting to experiment.

The mathematics did not feel completely foreign. It felt like reconnecting with an earlier version of myself.

During my undergraduate years at San Francisco State University, one of my favorite classes was econometrics with Dr. Mars, one of my favorite professors. We worked heavily with statistical relationships, equations, and derivatives. Statistics had been one of my favorite subjects throughout school, and I tutored it in college. There was something unexpectedly sweet about returning to that way of thinking after years in accounting.

My accounting career trained me to use data for different purposes: financial reporting, reconciliations, audit support, controls, completeness, timing, and evidence for conclusions. Week 4 did not make me discover statistics for the first time. It brought two parts of my background back into the same room: the economist who enjoyed looking for relationships in data and the CPA who had learned to ask whether the evidence behind a conclusion could actually be trusted.

Predictive modeling as structured imagination

That combination changed the way I thought about predictive modeling. I began to see it as partly an act of structured imagination.

The imaginative part comes before the model. Someone has to decide what outcome matters, what time horizon matters, which variables might contain useful information, how those variables should be represented, which historical observations belong in the analysis, and what relationship is worth testing. A model does not originate those business meanings on its own.

The discipline comes next. Once the hypothesis exists, the analyst has to let the evidence challenge it. The model has to perform on data it did not simply memorize. The timing has to be honest. The variables have to mean what we say they mean. The result has to survive testing that was not quietly designed around the answer we hoped to see.

That is what made the trading exercise feel creative without feeling arbitrary. I could imagine my own variables and my own theory of what might drive returns, but I could not simply declare the theory correct. I had to create a process that could prove me wrong.

When a better fit is a worse prediction

The strongest Week 4 aha moment for me was overfitting.

The idea is simple to state and easy to underestimate: a model can become better at explaining the historical data used to build it while becoming worse at predicting new observations. More complexity can improve the appearance of the past without improving the usefulness of the future.

That interrupted a natural instinct. More variables, a higher score, or a cleaner-looking relationship can make an analysis feel more sophisticated. Predictive analytics asks the harder question: does the pattern still work when the model encounters information it has not already seen?

The trading exercise broadened the lesson. Overfitting can enter through much more than the regression equation. It can enter through which securities are selected, which variables are tested, how comparison groups are defined, which dates are included, which thresholds are chosen, how many strategies are tried, and which result is finally presented.

A strong historical result is evidence to investigate, not proof that a predictive system will continue to work.

Time is part of the evidence

Another lesson felt unexpectedly familiar from accounting: information timing is part of model integrity.

In the trading work, we saw why randomly mixing observations across time would be inappropriate for the forecasting problem we were testing. If later information finds its way into the data used to train a model that is supposedly being evaluated on an earlier period, the model has access to knowledge that no real decision-maker would have had. The more faithful logic is to train on the past and test on the future.

To me, that sounded like cutoff.

I do not mean that predictive modeling is an accounting exercise. I mean that the professional habit felt familiar. Accountants understand that a conclusion depends partly on what information existed as of the relevant date. A fact does not become valid evidence for an earlier decision merely because it became known later.

The same discipline matters in prediction. The mathematics can run perfectly while the test is answering an impossible question. Independent evaluation matters for the same reason: a model should have to face observations it did not learn from and conditions that resemble the environment in which it will actually operate.

When an assumption becomes a number

One of the most interesting parts of the trading workflow was watching an early qualitative judgment travel through a quantitative system.

Generative AI helped organize company and competitor information. That structure was then used in Python to connect to Wikipedia page-view data. The page-view information was transformed into variables, those variables became inputs to regression models, and the model outputs later influenced a trading rule. I noticed the connection at the time because we were building the process step by step. One output became an input to the next stage.

What stayed with me was what could happen to the judgment embedded in that early output. Suppose a competitor relationship is weak, a company is classified incorrectly, or a page is matched to the wrong concept. The regression does not necessarily announce that the business meaning is questionable. It can calculate perfectly using a poorly defined feature. Several transformations later, the original judgment can disappear beneath a numerical result that looks objective.

A number can be mathematically correct given its inputs while the judgment that created those inputs is wrong.

That is a risk I recognize from accounting systems, reconciliations, and complex workbooks. An incorrect mapping, join, category, assumption, or source selection can flow through a technically correct calculation. The precision of the final number can make the weakness upstream harder to see.

I started thinking about data lineage differently. It is not only a technical record of where data came from. In a decision system, it can also reveal where judgment entered. If an output is consequential, I want to be able to trace it backward—from the action, through the decision rule and model, through the transformed data, and back to the source, definition, timing, and assumptions that gave the data meaning.

A good model is only one link in a business system

This is where Week 4 became larger than regression for me.

A predictive initiative starts with a business problem, not a model. The organization has to decide whether the use case is worth pursuing, assemble defensible historical data, examine initial patterns, build and validate the appropriate model, translate the output into a recommendation, place that recommendation inside a decision-support process, determine whether the economics work, and keep evaluating the model and the surrounding process over time.

Each stage answers a different question. Can we predict something useful? Are the patterns real? Does the prediction improve a decision? Can the recommendation be used operationally? Does it create enough value to justify the cost and risk? Will the system remain appropriate as the environment changes?

The best predictive model is not necessarily the best business system.

A model can perform well statistically and still fail in practice because the use case is poorly defined, the economics are weak, the data is too costly or difficult to maintain, employees do not use the recommendation, the decision rules are poorly designed, constraints are inadequate, or the underlying relationships deteriorate as customers and markets change.

Value comes from combining prediction quality with economic logic, operational adoption, controls, and responsible decision-making. The model may be essential. It is not sufficient.

Nine-stage flow showing Business Problem, Viable Use Case, Historical Evidence, Pattern and Feature Design, Predictive Model, Recommendation and Optimization, Decision Support and Authority, Value and Adoption, and Evaluation and Monitoring.
Figure 1. The Prediction-to-Business-System Framework traces a predictive use case from the business problem and historical evidence through model design, decision authority, business value, adoption, and ongoing monitoring.

Prediction, optimization, and what a metric proves

The pricing material made the path from model to business decision especially concrete. I had studied pricing through more classical economics and pricing approaches, so what felt new was seeing those ideas extended through a data-rich predictive and decision-support system that could estimate how different customers might respond to different allowable prices.

A useful statistical refresher was the distinction between linear and logistic regression. Linear regression is used when the outcome is numerical, such as a property value, expense, revenue amount, or return. Logistic regression is useful when the outcome is categorical—often binary—and the goal is to estimate the probability of an event, such as accept or reject, default or not default, purchase or not purchase.

That probability is not yet a decision. It is an estimate that another part of the system may use.

This is where AUC—the area under the receiver operating characteristic curve—became a new and useful concept for me. One intuitive interpretation of ROC AUC in a binary classification setting is this: if we select one case where the event occurred and one where it did not, how often does the model assign the higher score to the case where the event actually occurred? An AUC of 0.5 represents chance-level discrimination; values above 0.5 indicate better ranking, and values closer to 1 indicate stronger discrimination.

What interested me even more was what AUC does not tell us. A strong AUC does not by itself tell us whether the predicted probabilities are well calibrated, whether the selected price creates the best economic outcome, whether the process is fair, whether the investment has a positive ROI, or whether the model will remain relevant as conditions change. A model can rank cases well while its probability estimates are still poorly calibrated. If a business uses an exact predicted probability in an expected-value calculation, that distinction matters.

A metric can be valid and still answer only one part of the business question.

The same principle applies beyond AUC. R-squared, AUC, error measures, and other performance metrics can provide valuable evidence, but no single metric certifies the business system around the model. Professional judgment begins with knowing which question a piece of evidence actually answers—and which questions remain open.

The pricing work then sharpened another distinction: prediction is not optimization. The predictive model estimates customer behavior. The pricing or decision system compares allowable alternatives and chooses among them according to defined objectives. The organization determines what “allowable” means, sets the boundaries, and remains responsible for the policy and its consequences.

That final layer cannot be outsourced to a probability. Business objectives, pricing limits, approvals, applicable legal requirements, fairness considerations, risk appetite, customer strategy, and accountability shape the action that follows.

The material also reinforced the difference between prediction and causation. Historical data may show that customers who received lower prices accepted more often. That does not automatically mean lowering the price caused the higher acceptance. Other characteristics may differ at the same time. “What is likely to happen?” and “What will happen if we change this?” are different questions.

The economics and the implementation still have to work

The business case does not end when the statistical model performs well. A recommendation has to survive contact with operations and economics.

Predictive initiatives can require data acquisition, integration, technical talent, validation, governance, training, monitoring, and ongoing maintenance. In some applications, specialized market or alternative data can also be expensive. The full cost of the system matters alongside the elegance of the model.

That makes ROI part of the business evaluation, not an afterthought. Technical performance tells us something about the model. Economic evaluation asks whether using the model improves the business enough to justify the implementation, operating cost, complexity, and risk.

Adoption matters too. A recommendation that cannot be integrated into the operating process does not create value merely because the underlying model is impressive. Someone has to know when the recommendation appears, who is permitted to use it, how overrides work, how exceptions are documented, and what outcomes are measured afterward.

Personalization increases both opportunity and responsibility

The pricing work also changed the way I thought about personalization. More granular information can make a prediction more economically useful because customers who look similar on one dimension may respond differently on another. But the same granularity can make the consequences more sensitive.

If a system can tailor a price, offer, intervention, or recommendation to an individual customer, the organization has to be able to defend more than the mathematics. Which variables are appropriate to use? Could an apparently neutral variable act as a proxy for something sensitive? Are similarly situated customers treated consistently? What limits constrain the optimization? Who reviews exceptions? What outcomes would cause the organization to stop or redesign the process?

Historical data deserves particular attention because it can carry past patterns into future decisions. Bias can enter through the data, labels, variables selected, objective being optimized, decision rules, or the way the system is deployed. The fact that a model learned a pattern does not make the pattern appropriate to use.

This is where governance stops feeling like a layer added after innovation. It becomes part of the design of the business system itself.

For me, analytics-supported personalized pricing is not simply about finding the highest price a customer might tolerate. It is about estimating customer response and selecting an allowable action within business, legal, ethical, risk, and governance constraints that people remain responsible for defining and enforcing.

AI in business is not one model

By the end of Week 4, my definition of AI in business had expanded.

I had seen generative AI help structure information, Python transform data, an API retrieve external data, statistical models estimate relationships, and decision rules or optimization translate predictions into alternatives. None of those components by itself was the business system. The value—and the risk—came from how they were connected.

That changed the way I think about implementation. Powerful tools require strong implementation, qualified professionals, reliable data, clear parameters, meaningful controls, and governance that understands the full process rather than focusing only on the most visible model.

That conclusion is not anti-innovation. My reaction to the trading exercise was curiosity. I wanted to experiment, and I still do. Governance should not extinguish that instinct. It should help distinguish an interesting experiment from a system an organization is prepared to rely on.

What a finance or accounting professional can do tomorrow

Week 4 was technical, and I do not think the responsible takeaway is that every accountant or finance professional should build a predictive model tomorrow.

Real predictive systems can require statistical expertise, data engineering, domain knowledge, specialized data, model validation, infrastructure, legal or compliance input, and ongoing monitoring. One useful professional conclusion is recognizing when a use case requires specialists.

But that does not make finance professionals passive observers. We can become better evaluators and sponsors of predictive analytics before becoming the people who build the models.

We can ask whether the business problem is precise and valuable enough to justify modeling; whether the historical population is complete and consistently defined; whether the information existed at the prediction date; whether the model was challenged on genuinely unseen data; what a performance metric actually proves; whether correlation is being used to justify an intervention; how a score or probability becomes an action; what constraints sit between prediction and execution; whether the economics work; and who remains accountable for the result.

Those questions do not replace technical expertise. They help technical expertise become useful inside a business.

For professionals who want to build, validate, or take material responsibility for these systems, I would recommend serious, structured education through a rigorous university or comparable program. A checklist, a few prompts, or a short article cannot replace the statistical, technical, and domain knowledge sophisticated predictive systems can require.

Questions I’m Still Exploring

I still want to build my own model. That curiosity is one of my favorite things I took from Week 4. Predictive analytics felt powerful because it made experimentation tangible: I could imagine a hypothesis, turn it into variables, test it in Python, and see whether the data supported the story in my head.

What changed is what I now consider success. I would not be satisfied with a model that merely fits historical data well. I would want to know whether the business problem is worth solving, whether the data and definitions are defensible, whether timing has been preserved, whether performance holds on unseen data, whether the metric answers the question we think it answers, whether the probabilities are useful for the decision that follows, whether optimization respects appropriate constraints, whether the economics justify implementation, and whether the system can be monitored as the world changes.

I am still exploring how much predictive-model literacy finance and accounting leaders should develop if they are not the people building the models; how organizations should preserve visibility into the human or AI judgments that enter upstream data and feature design; and when an improvement in predictive performance justifies the additional cost, complexity, and governance required to use it responsibly.

Those questions do not make the technology less exciting to me. They make the ambition larger. For me, they mark the difference between an interesting analytical exercise and responsible professional practice.

The question I carry forward is no longer only, “Could I build my own model?” It is, “Could I build a model—and help build the system around it—that I would be willing to rely on?”

The Prediction-to-Business-System Framework

The Prediction-to-Business-System Framework traces a predictive use case through nine stages, from the business problem and historical evidence to decision authority, value, adoption, evaluation, and monitoring.

The Prediction-to-Business-System Framework stages
StagePurposeKey question
1Business ProblemWhat business outcome matters, and what decision could improve if we predicted it?
2Viable Use CaseIs prediction useful, feasible, and valuable enough to justify the effort and risk?
3Historical EvidenceIs the population complete, comparable, timely, and properly defined?
4Pattern & Feature DesignWhich relationships, variables, categories, mappings, and transformations are worth testing?
5Predictive ModelWhat exactly is being estimated, and does performance generalize beyond the fitting sample?
6Recommendation / OptimizationHow does the prediction become a preferred alternative, ranking, threshold, or recommended action?
7Decision Support & AuthorityWho may act, within what boundaries, with what review and override rights?
8Value & AdoptionDoes the system improve the business enough to justify its cost, complexity, and operating burden?
9Evaluation & MonitoringDoes the model and decision process remain relevant as data, behavior, markets, policy, and systems change?

CPA Insight

The best predictive model is not necessarily the best business system. Business value depends on the quality of the prediction and on the economics, decision rules, controls, adoption, and accountability around it.

Companion practical resource

Practice Guide No. 004 helps accounting and finance professionals assess whether a predictive-analytics use case is sufficiently defined, supported, and governed to move into deeper discovery, a controlled pilot, or formal implementation review.

Selected Sources

  1. Scikit-learn. Cross-validation: evaluating estimator performance. Overfitting, unseen-data testing, and evaluation design. Open source. Accessed August 9, 2026.
  2. Scikit-learn. TimeSeriesSplit. Time-aware validation and avoiding future-to-past testing. Open source. Accessed August 9, 2026.
  3. Scikit-learn. roc_auc_score. Definition and scope of ROC AUC. Open source. Accessed August 9, 2026.
  4. Scikit-learn. Probability calibration. Probability calibration and distinction from ranking metrics. Open source. Accessed August 9, 2026.
  5. National Institute of Standards and Technology. AI Risk Management Framework. System-level trustworthiness and lifecycle risk framing. Open source. Accessed August 9, 2026.
  6. Board of Governors of the Federal Reserve System. SR 26-2, Revised Guidance on Model Risk Management. Current model-risk principles for relevant banking organizations. Open source. Accessed August 9, 2026.

Further Reading

  1. NIST AI Resource Center. AI RMF Playbook. Practical actions for applying the AI Risk Management Framework. Open resource. Accessed August 9, 2026.
  2. Scikit-learn. Metrics and scoring: quantifying the quality of predictions. A broader reference for matching performance measures to modeling objectives. Open resource. Accessed August 9, 2026.

Learning note and limitations

This article was inspired by Valentina’s professional education in predictive analytics and AI for business and finance. It reflects her own interpretation, professional judgment, and application to accounting, finance, controls, and business decision-making. It does not imply institutional endorsement. It is intended for general educational purposes and is not investment, legal, regulatory, statistical, model-validation, accounting, audit, tax, compliance, cybersecurity, or other professional advice. Predictive systems may require qualified specialists and organization-specific review before use in consequential decisions.

Continue the conversation

This article continues my exploration of how accounting and finance professionals can use emerging technologies while preserving evidence, governance, controls, professional judgment, and accountability.

Return to the Knowledge Hub

About the author

Valentina DuPont, CPA is an accounting and finance professional with experience in financial reporting, month-end close, reconciliations, cash management, internal controls, audit support, and process improvement. Through the Knowledge Hub, she explores how professional judgment, governance, and emerging technologies intersect in modern finance.