Financial AI Workflows: Separate Extraction, Reconciliation, and Decisions

Financial AI becomes easier to reason about when the workflow is separated into distinct jobs. Reading a document, reconciling its contents with other records, and deciding what to do are related, but they require different kinds of evidence and control.

Tokyo AI’s AI in Financial Services on 10 June 2026 brought together Colin Rowat, Jeff Tsui, and Sanjeev Sinha to examine LLM failure modes, institutional investment data, and graph-based investigation. The engineering lesson is to be precise about which part of the work a model is qualified to support.

A plausible explanation is not a validated financial method

Colin Rowat, Principal Research Scientist at Rakuten Institute of Technology, distinguishes asking a general-purpose LLM for a prediction from using specialist models and AI-assisted analysis. His talk also broadens the discussion beyond trading to other financial tasks.

The useful question is what validates the output. A natural-language explanation can help a specialist explore a problem, but it does not establish that the underlying data, calculation, or decision rule is correct. A generated script needs to be tested against the intended computation. A document answer needs support from the relevant record.

This distinction avoids treating “AI in finance” as a single capability. Extracting a reporting date, calculating an exposure from verified positions, and predicting a future price are different tasks. Success at one should not be used as evidence for the others.

Extraction ends before reconciliation does

Jeff Tsui, CEO and Founder of Visual Alpha, frames the institutional data problem around fund information arriving in inconsistent formats. His announced talk connects extraction with reconciliation across accounting, risk, performance, and reporting workflows.

That connection is important even in a narrow implementation. A number can be transcribed correctly and still be used incorrectly. It may refer to a different period, currency, entity, or basis of calculation. When two records disagree, the system needs to preserve the disagreement rather than choose the more plausible-looking value.

An extraction system therefore needs a destination schema with business meaning. The record should distinguish the value from its unit, period, source, and verification status. The work is complete only when the organization can determine whether that value belongs in the intended downstream process.

Connected evidence can support investigation

Sanjeev Sinha’s programme describes knowledge graphs and graph neural networks for fraud and anomaly investigation. A knowledge graph represents entities and their relationships; a graph model can use patterns in those relationships to identify cases worth examining. The announced architecture also includes an agentic layer that coordinates queries and presents evidence to an analyst.

The key distinction is between detecting a pattern and establishing its meaning. A connection between accounts can be relevant without proving wrongdoing. An analyst needs the underlying relationships, their dates, and the reasons the system prioritized the case. An explanatory narrative should remain linked to that evidence.

For a deployment team, this makes investigation a workflow with explicit stages: collect context, identify a possible inconsistency, examine alternatives, and decide whether to escalate. It does not require handing a model final authority over a consequential financial judgment.

Foundry’s perspective: build an exception queue before automating the decision

Consider an illustrative monthly reporting process that receives fund statements in several formats. A PoC extracts values into a table. A production system needs to identify which statement each value came from and whether it agrees with the records used by the reporting team.

We would begin with a small set of fields and a clear definition of what “reconciled” means for each. Some checks can be deterministic, such as whether a reporting period matches or a total equals its components under the specified calculation. Others require a person to interpret an amended statement or an unfamiliar category.

Those cases should become reviewable exceptions. The reviewer sees the conflicting values, their source locations, and the reason for the flag. A correction updates the normalized record while preserving the original evidence. The system should not silently repair the inputs to make a report appear consistent.

A first release can run alongside the existing process. The team can compare reconciliation outcomes, time spent resolving exceptions, and the frequency of errors that reach the final report. These measures reveal whether automation reduces work or simply moves it into a harder-to-see review step.

Only after that evidence is available should the team expand the fields or reduce routine manual handling. This is the link to Foundry Labs’ enterprise AI engineering: use models where they help interpret messy inputs, and build the verification, ownership, and system connections that make the result dependable in an actual process.

Sources and further reading

This article draws on the AI in Financial Services - From LLM Failure Modes to Graph-Based Fraud Detection programme and the talks identified above. Tokyo AI (TAI) connects researchers, engineers, and industry; explore Foundry Labs’ community work for more context.

Talk materials from Colin Rowat are available upon request. Please use our contact form and include the event title and speaker name.

Speaker profiles

Colin Rowat. Principal Research Scientist at Rakuten Institute of Technology, working on financial AI and formal verification. LinkedIn.

Jeff Tsui. Founder and CEO of Visual Alpha, working on investment-data workflows. LinkedIn.

Sanjeev Sinha. AI Evangelist at SHIFT, with a background in finance and AI. LinkedIn.

All articles