Investigating flagged transactions

The Investigating Flagged Transactions process sits at the heart of the finance team's compliance obligations. When a transaction is flagged and assigned, the controller or one of two analysts opens four systems, collects relevant documents and correspondence, and writes a short rationale that either closes the case or escalates it for further action. Every outcome must be retained with a full audit trail that regulators can reconstruct years later. The process runs multiple times a day, producing roughly 1,800 cases per year and consuming approximately 2,100 hours of analyst time annually.

The challenge is that no single system holds the full picture. Evidence is spread across an ERP, a banking feed, a document archive and email, and the judgment needed to handle non-standard cases lives largely in the heads of two or three people. Around 10 to 15 percent of cases fall outside the standard pattern and require genuine human reasoning. The remaining 85 to 90 percent follow a predictable path but still demand the same manual retrieval and write-up effort, which is where most of the avoidable cost accumulates.

The team's data engineer already moves data between the ERP, banking feed and document archive via nightly API pipelines, so the integration foundation is solid. The team's preference is for a solution hosted and maintained in-house, with no dependency on external SaaS platforms. GDPR applies to personal data handled during investigations, and the reasoning behind every decision must be reconstructable on demand.

The recommended path is a Hybrid AI workflow with mandatory human-in-the-loop gates, and the case for it is built on three converging factors: high routine volume, hard compliance constraints and an integration foundation that is already in place. The AI layer handles evidence gathering and draft rationale production for every case; human analysts review, edit if needed and sign off before anything is closed or escalated. That structure directly matches the team's stated goal of reserving human attention for the cases that genuinely need it, rather than having analysts spend the majority of their time on straightforward retrievals and write-ups.

The client's preference for an in-house hosted and maintained service is fully compatible with this architecture. The orchestration layer runs on the team's own infrastructure, the data engineer extends the existing API pipelines from nightly batch to near-real-time event-driven calls, and no external SaaS dependency is introduced. The ERP, banking feed and document archive all expose APIs that are already in use, so there is no integration work to justify from scratch. That is a meaningful head start and one reason the build cost estimate is lower than it would be for a team starting without that foundation.

The fully automated AI Workflow path scored 6 and is viable for the standard case tier, but it was not recommended precisely because of the compliance requirements. A process where the reasoning must be reconstructable for regulators years later cannot rely on AI output alone; a human sign-off is not optional. Removing the human gate to save cost would introduce regulatory risk that far outweighs the marginal efficiency gain. The Hybrid design keeps the human in the loop without making every case a full manual effort.

The AI Agent path scored 5. An autonomous agent could navigate multi-system evidence gathering dynamically, and that capability is genuinely useful here, but operating it as a standalone autonomous system on a financial compliance process is not appropriate. The audit trail and GDPR requirements demand structured, logged checkpoints, not open-ended autonomous action. The agent's reasoning capability is better used as the engine inside the Hybrid architecture, where its outputs are captured, versioned and reviewed rather than acted on directly.

Traditional Code scored 4. A rules engine could automate the most predictable cases, but it cannot read unstructured correspondence, it cannot draft a natural-language rationale for auditors and it becomes brittle as transaction patterns evolve. Maintaining a growing ruleset for a financial process with regulatory change risk is expensive and fragile. RPA scored 3 for similar reasons: the systems already have APIs, the exception rate is high, and RPA adds mechanical fragility without adding reasoning capability. Neither path is recommended. Education scored 2, not because training is unimportant but because at 2,100 hours of annual effort the cost of staying manual is too high for upskilling alone to address. Training the team is a necessary complement to the Hybrid build, not a substitute for it.

The two closest alternatives to the recommended Hybrid path are a fully automated AI Workflow and an AI Agent, and it is worth being direct about why neither quite fits this process. A fully automated AI Workflow scores reasonably well because the standard case, which accounts for 85 to 90 percent of volume, follows a clear enough pattern that an AI layer could handle it end to end. The problem is that "fully automated" in a financial compliance context means a machine is closing cases with no human sign-off, and that directly conflicts with the audit trail requirement. A regulator asking to reconstruct a decision years later needs to see a named, accountable person who reviewed and approved the outcome. A workflow that skips that step is not compliant, regardless of how accurate the AI recommendations are in practice.

The AI Agent path is appealing for a different reason: the multi-system evidence gathering across the ERP, banking feed and document archive is exactly the kind of dynamic, multi-step retrieval that an autonomous agent handles well. But an autonomous agent acting without structured human checkpoints introduces the same regulatory gap as the fully automated workflow, and adds an additional layer of unpredictability in how it navigates those systems. The agent architecture is genuinely useful here, just not as a standalone system. It belongs inside the Hybrid design as the engine that drives evidence gathering and rationale drafting, with the human review gate sitting above it.

The Hybrid path wins because it is the only design that automates the routine majority, routes the genuine exceptions to analysts and satisfies the audit trail requirement simultaneously. It does not ask the team to choose between speed and compliance. The existing API infrastructure and the data engineer who already operates pipelines between these systems mean the Hybrid is also the most buildable option given the client's preference for an in-house maintained service.

The build starts with a two to three week discovery and data mapping phase. Every data field the analysts currently retrieve manually needs to be traced to its source API, whether that is the ERP, the banking feed or the document archive. The decision rules for the standard case need to be written down, not left in people's heads, and the triggers that mark a case as an exception need to be made explicit. The output of this phase is a signed-off data dictionary and a process specification the data engineer can build against with confidence. This step is easy to underestimate but it is the foundation everything else sits on.

The data engineer then builds the evidence gathering pipeline, extending the existing nightly batch pipelines to near-real-time event-driven calls. When a transaction is flagged and assigned, the pipeline calls the ERP, banking feed and document archive APIs, retrieves the relevant records, documents and correspondence, and assembles a structured case pack. This component is the most technically straightforward part of the build because the APIs are already in use and the data engineer already knows how they behave. The deliverable is a populated case pack arriving automatically for every new flag, with no analyst spending time on manual retrieval across four systems.

Once the case pack is assembled, an LLM-based reasoning step reads it, drafts the investigation rationale in the required format and produces a preliminary close or escalate recommendation alongside a confidence score. The prompt templates that drive this step must be version-controlled in a system like Git from day one, because when regulatory language changes or transaction patterns shift, the team needs to update the templates without rebuilding the pipeline. The confidence score is what drives the routing decision: cases above the threshold go to a lightweight sign-off queue, cases below it are flagged as exceptions and routed to an analyst for full review.

The human review interface is a lightweight internal tool, not a complex application, where analysts see the AI-drafted rationale, can edit it where needed and must explicitly sign off before a case is closed or escalated. Every AI output, every analyst edit and every sign-off is written to an immutable audit log with a timestamp and user identity. This log is the mechanism that satisfies both the GDPR requirement and the regulator's ability to reconstruct the reasoning years later. After a parallel pilot run on 100 to 150 live cases to calibrate the confidence threshold against real analyst decisions, the system goes into full operation and the manual retrieval process for standard cases is retired.