AI in Finance Isn't What the Press Releases Say
AI in finance gets covered like it's all robo-advisors and GPT-powered chatbots answering questions about your 401(k) balance. That's the visible layer. Underneath it, running 24 hours a day, are systems most engineers never see in tutorials: fraud detection models making decisions in 40 milliseconds, machine learning risk scoring engines replacing credit bureaus, batch pipelines chewing through hundreds of millions of transactions every night to settle positions by 6 AM.
We had a student in our May 2025 MLOps cohort who worked at a regional bank. She came in thinking she'd learn to build chatbots. By week three, she was rebuilding her mental model of what ML in production actually means, because her real job was keeping a LightGBM fraud model from drifting into uselessness every time a new merchant category code showed up in the data.
That's finance ML. Unglamorous. High-stakes. Worth understanding.
How Does AI Fraud Detection Actually Work Under Pressure?
AI fraud detection systems have one constraint that overrides almost every other design decision: latency. A card swipe at a point-of-sale terminal gives you somewhere between 50 and 100 milliseconds before the customer experience degrades. Every model choice flows from that single number.
This is why gradient boosting dominates production fraud systems. XGBoost and LightGBM inference on a single row of tabular features takes microseconds. A neural network with any real depth adds overhead you can't afford at scale. Visa processes roughly 65,000 transactions per second during peak periods. That's not a number you experiment with.
The actual feature set is where the interesting work lives. Raw transaction amounts matter less than you'd think. What matters is deviation from a cardholder's established behavior: transaction velocity over the last 60 seconds, geographic distance from the last swipe, merchant category mismatch relative to historical spend, time-of-day anomaly. These features get computed in real time against a feature store (usually Redis or a managed equivalent) that holds precomputed user profiles updated on a rolling basis.
Class imbalance is the problem nobody talks about enough. Fraud rates at most issuers run between 0.05% and 0.2% of transactions. Train naively on that distribution and your model learns to predict "not fraud" for everything, achieving 99.8% accuracy while being completely useless. We've watched capstone students make exactly this mistake, more than once. The fix involves SMOTE or similar oversampling during training, cost-sensitive learning that weights false negatives more heavily, and moving the decision threshold well below the default 0.5. Finding that threshold is a business decision, not a model decision. It's the point where the cost of a missed fraud equals the cost of a false decline plus the customer friction that comes with it.
What Is Machine Learning Risk Scoring Actually Replacing?
The FICO score has been the default credit risk tool for 30 years. It's built on five factor categories, uses roughly 20 input features, and was designed when batch processing of credit bureau data was the only option. Machine learning risk scoring is eating into it, particularly at fintechs that have access to bank transaction data FICO never sees.
A modern ML credit model might train on 300 or more features derived from checking account history alone: average daily balance over 90 days, payroll regularity, overdraft frequency, rent payment patterns. For applicants who are "thin file" on traditional credit (younger borrowers, recent immigrants, people who pay cash for everything) this data is often the only meaningful signal available. That's not a minor improvement on FICO. That's a different instrument entirely.
The models vary by use case. Logistic regression with well-engineered features is still common for consumer credit because it produces interpretable coefficients, and SR 11-7 model validation requirements make interpretability a practical necessity at regulated institutions. Gradient boosting with SHAP explanations is the next step up. Neural networks appear mostly in large-scale unsecured lending platforms where the volume justifies the infrastructure and the regulatory environment is more permissive.
Bias and fairness testing isn't optional here. ECOA requires adverse action notices, which means any denial needs a human-readable reason. Fair lending law also prohibits models that produce disparate impact along protected class lines even without discriminatory intent. This forces financial ML teams to test for demographic parity and equalized odds before any model ships, using tools like IBM's AI Fairness 360 or Aequitas.
Why Financial ML Pipelines Are an Infrastructure Problem First
Most ML courses teach you to train a model and call .predict(). Financial ML pipelines are 10% model and 90% infrastructure, and the infrastructure is what breaks.
A production financial pipeline runs in two modes that rarely share architecture. Real-time inference serves fraud and transaction-level decisions from a model behind a REST endpoint, usually on Cloud Run or a managed Kubernetes cluster, with feature retrieval from a low-latency store. Batch pipelines run on schedules (nightly credit re-scoring, weekly portfolio risk aggregation, monthly regulatory capital calculations) and use entirely different tooling: Spark on Dataproc or Databricks, orchestrated by Airflow or Vertex AI Pipelines, writing to BigQuery or Snowflake.
Data quality is where batch pipelines die. We've seen this directly in projects from students who work at actual financial institutions. A missing exchange rate feed causes a currency conversion to silently zero out. A downstream risk model scores every foreign-currency position at zero exposure. Nobody notices until the next day's reconciliation. The fix isn't clever ML; it's Great Expectations or Soda running data validation before every pipeline stage, with hard circuit breakers that halt the pipeline rather than propagate bad data.
Model monitoring is the other gap. Fraud patterns shift constantly, sometimes because criminals adapt, sometimes because a new payment channel changes the transaction distribution entirely. A model trained in January on in-person retail transactions will drift badly by March if buy-now-pay-later adoption spikes in the customer base. PSI (Population Stability Index) on input features, tracked weekly, catches this before accuracy collapses. Most teams I've talked to don't instrument this until after their first production incident.
If you want to build the kind of systems we're describing, our MLOps & AI Infrastructure course covers Vertex AI Pipelines, feature stores, and model monitoring in production. The MLOps Deployment lab environment is where students actually run these patterns against real data, not toy datasets.
The Compliance Layer Nobody Wants to Build
Financial ML has a layer that pure ML courses almost never cover: model governance. SR 11-7, the Federal Reserve's guidance on model risk management, requires banks to maintain a model inventory, conduct independent validation of every model that informs a material decision, and monitor all production models for performance degradation and concept drift.
Deploying a new fraud model at a regulated bank isn't a pull request and a deployment pipeline. It's a documentation package, independent validation from a team that didn't build the model, sign-off from model risk management, and often a parallel run period where the new model scores alongside the old one without affecting decisions. The whole process can take three to six months for anything material.
Fintechs under lighter regulatory regimes move faster, but they're not immune. As they grow and start holding deposits or partnering with chartered banks, the compliance requirements follow.
This is genuinely hard. It's also where experienced ML engineers in finance command the salary premiums they do. Anyone can train a gradient boosted classifier. Far fewer people can walk a model through SR 11-7 validation while keeping the engineering team moving at the same time.
The pipelines moving your money aren't exciting. They're correct, monitored, auditable, and rebuilt every time the world changes. That's a harder standard than most ML work, and if you're aiming for it, the gap between "I can train a model" and "I can own this in production" is where the real work starts.
