Most articles about AI automation in financial services describe what it could do. This one describes how it works: the specific technologies, the integration patterns, and the architectural decisions that separate automation that runs in production from automation that runs in a demo.
The challenge of building automation for investment management is not generic. A $146B AUM asset manager's data environment is not a scaled-up version of a standard enterprise. It has 20+ years of proprietary business logic, custom benchmark definitions that don't exist anywhere else, and data dependencies on FactSet, Bloomberg, SEI, and MSCI that each arrive in different formats on different schedules and have to agree with each other before any of it can be used.
The automation stack has to handle all of that.
Every automation workflow in financial services depends on one thing: a centralized, governed data layer that the pipeline can trust.
Snowflake is the platform that makes this practical. It provides the storage, the query performance, the access control, and the data sharing infrastructure that automation workflows depend on. But Snowflake alone is not the solution. It is the layer on which the solution is built.
The reason Snowflake works for financial services data specifically is the data sharing model. FactSet Standard Datafeeds are available natively in Snowflake: no ETL, no batch delay, no flat-file ingestion process. The same is true for Bloomberg, MSCI, and other market data providers. Data that previously arrived via file drop or API call and required a pipeline to ingest it now arrives as a live Snowflake share, queryable immediately by any downstream tool.
For a $146B AUM asset manager Continuus worked with, this replaced a process where data item requests required six months of IT backlog. After restructuring five FactSet Standard Datafeeds natively in Snowflake and migrating 20+ years of business logic into the platform, those requests take one week. The speed improvement is real. But it's the governance and reliability that make the data usable at scale.
Getting data into Snowflake reliably is the job of Fivetran and dbt. They handle different parts of the problem.
Fivetran handles ingestion: pulling data from source systems, vendor APIs, CRM platforms, and internal databases and landing it consistently in Snowflake. Its value in financial services is connector coverage: it integrates with Salesforce, SQL Server, Oracle, and the operational systems that asset managers actually run on. Ingestion runs automatically, on schedule, with alerting when sources fail.
dbt handles transformation: taking raw data as it lands in Snowflake and building the governed, business-logic-correct data products that downstream workflows depend on. In financial services, this is where the hard work lives. The custom benchmark logic, the performance calculation rules, the attribution model adjustments that exist nowhere in documentation but are embedded in macros that have run for 15 years, and dbt is where that logic gets extracted, documented, version-controlled, and made reliable.
Version control on transformation logic is not a convenience. It is a compliance capability. When an SEC reviewer asks why a particular calculation produced a particular output on a particular date, a well-built dbt project can answer that question. An Excel macro cannot.
With a governed Snowflake data layer and reliable transformation pipelines in place, Alteryx sits at the front of the research workflow.
Alteryx is the tool that lets research analysts consume data and run workflows without IT involvement. An analyst who needs to run a quantitative screen against holdings data, blend it with FactSet factor data, and output a formatted report can build that workflow in Alteryx and run it on demand. When the analysis proves repeatable, it gets deployed to the Alteryx server as a governed, scheduled workflow that runs automatically.
This is the mechanism that closes the analyst productivity gap. The manual work: the pulling, blending, reconciling, and reformatting that consumes 70–80% of analyst time, and it moves into Alteryx workflows and runs in the background. The analyst interacts with the output.
One investment management team that moved from fragmented tool usage (Bloomberg for some, FactSet for others, Python for a few) to a unified Alteryx + Snowflake environment described the shift as moving from "whatever the person has is the tool they use" to a consistent process that produces the same output regardless of who runs it.
The final component is the semantic layer: the structured definition of what the data means, expressed in business terms that portfolio managers and analysts can query directly.
Without a semantic layer, self-service access to data requires each user to know which table holds which data, how it's defined, and how to write the SQL or Alteryx workflow to get what they need. That is not self-service. That is IT dependency with extra steps.
Snowflake Cortex Analyst provides a semantic layer that maps business questions to data: a portfolio manager can ask "show me holdings back 10 years, US equity only, excluding positions below $1M" in natural language, and the semantic layer translates that into a governed query against the correct tables, using the correct definitions, returning a result the analyst can trust.
The prerequisite for this to work is the same as for everything else in the stack: the data underneath has to be governed, consistently defined, and accurate. The semantic layer is the interface. The governed data foundation is what makes the interface trustworthy.
The full automation stack for financial services works as a sequence of layers, each enabling the next:
Each layer reduces manual work at a different point in the workflow. Together, they automate the data preparation that currently consumes 70–80% of analyst time, not by removing the analyst from the process, but by removing the friction that keeps the analyst from doing analysis.
The firms building on this stack are not doing something exotic. They are implementing tools that are available, proven, and deployed across financial services today. The difference between firms that have achieved the productivity gains and firms that haven't is not the tooling. It is whether they built the governed data foundation that the automation depends on.