Checking Transaction Data Against Policy Documents

Introduction

In our previous lesson, we meticulously designed the data ingestion pipeline, creating a robust, searchable knowledge base of regulatory and policy documents. We now have a vector database populated with parsed, chunked, and enriched information—the foundational knowledge for our compliance agent.

This lesson directly addresses the learning outcome: Specify an agent's reasoning process for checking transaction or case data against retrieved policy documents. We will move from building the agent's knowledge to architecting its intellect. The central question is: How does an agent methodically use this knowledge base to evaluate a specific case and arrive at a defensible compliance judgment?

We will explore two powerful reasoning patterns. First, a flexible, LLM-native approach that allows the agent to "think" and "act" dynamically. Second, a highly structured, deterministic method that ensures the consistency and auditability required in finance. Ultimately, we will combine them into a sophisticated hybrid architecture that leverages the best of both worlds.

1. The Core Task: Bridging Structured Data and Unstructured Knowledge

The fundamental challenge for a compliance agent is to connect two different worlds:

1. The World of Facts: Structured and semi-structured data about a specific event. This could be a wire transfer with a specific amount, sender, and recipient, or a case file containing notes from an analyst.
2. The World of Rules: Unstructured knowledge locked away in lengthy policy documents, which we have now indexed in our vector database.

The agent's reasoning process is the bridge between these two. It must parse the facts of the case, retrieve the relevant rules, and apply those rules to the facts to make a decision.

2. Pattern 1: Flexible Reasoning with ReAct

One powerful way to model an agent's thought process is the ReAct (Reason + Act) framework. In this model, the agent's Large Language Model (LLM) core acts as an orchestrator, interleaving internal reasoning (thought) with external actions (tool use).

This pattern allows the agent to dynamically break down a problem, gather information, and adapt its plan based on new findings.

Let's trace how a compliance agent might use the ReAct pattern to check a transaction:

1. Initial Prompt: Check transaction TXN45-2025 for compliance with our internal AML policy.
2. Thought 1: "I need to understand the details of TXN45-2025 and retrieve the relevant AML policy sections. First, I'll get the transaction data."
3. Action 1: Call a tool get_transaction_details(id="TXN45-2025").
4. Observation 1: Returns structured data: {amount: 75000, currency: 'USD', sender_jurisdiction: 'HK', receiver_jurisdiction: 'CY'}.
5. Thought 2: "The transaction is for $75,000 USD to Cyprus. Now I need to find the policy rules for international transfers, especially concerning amount thresholds and high-risk jurisdictions."
6. Action 2: Call our RAG tool rag_retriever.query("AML policy for international wire transfers to high-risk jurisdictions").
7. Observation 2: Returns text chunks from the policy: "Section 4.1: All international transfers exceeding $10,000 USD must be screened... Section 4.2: Transfers to jurisdictions on the 'High-Risk Countries List' require Enhanced Due Diligence (EDD)..."
8. Thought 3: "The amount of $75,000 exceeds the $10,000 threshold. I need to check if Cyprus ('CY') is on the high-risk list."
9. Action 3: Call a tool is_high_risk_jurisdiction(country_code="CY").
10. Observation 3: Returns True.
11. Final Thought: "The transaction exceeds the amount threshold and is directed to a high-risk jurisdiction. According to the policy, this requires EDD. I will flag this transaction for review and provide the justification."
12. Final Action: create_compliance_alert(transaction_id="TXN45-2025", reason="Requires EDD per AML Policy Section 4.2", evidence=["TXN45-2025 details", "Policy Section 4.2 text"]).

The ReAct pattern is powerful due to its flexibility. However, for core compliance decisions, its non-deterministic nature can be a liability. Two different LLMs, or even the same LLM at different times, might reason slightly differently, which is unacceptable for auditability.

3. Pattern 2: Structured Reasoning with DMN

Given your background in law and finance, you'll recognize the need for a system that is not only intelligent but also rigorously consistent and transparent. For high-stakes decisions, we cannot rely on the probabilistic nature of an LLM alone.

This is where Decision Model and Notation (DMN) comes in. DMN is an industry standard for modeling and executing operational decisions in a clear, visual, and non-ambiguous way. It separates the structure of a decision from its underlying logic.

As the video explains, a DMN model consists of two key parts:

• Decision Requirements Diagram (DRD): A graph showing the decisions, sub-decisions, and data inputs required. It answers, "What information do I need to make this decision?"
• Decision Tables: A set of business rules in a simple table format that defines the logic for each decision node. It answers, "Given these inputs, what is the output?" This logic is fully deterministic and auditable.

4. A Hybrid Architecture: The Best of Both Worlds

We don't have to choose between the flexibility of ReAct and the rigor of DMN. The most robust architecture for a compliance agent uses both, assigning each to the task it does best.

• The LLM Agent's Role (Perception & Extraction): The agent uses its language capabilities and ReAct-like reasoning to interact with the messy, unstructured world. Its job is to extract and structure the specific facts needed for a decision.
• The DMN Engine's Role (Logic & Decision): The DMN engine takes these structured facts as input and executes the formal, auditable business rules to produce the final decision.

In this hybrid model, the agent's process for checking our transaction looks like this:

1. Agent Task: Execute compliance check for TXN45-2025.
2. Agent Reasoning (LLM): The agent knows it needs to populate the inputs for the AML_Compliance_Check DMN model. The required inputs are transaction_amount, is_international, and is_high_risk_jurisdiction.
3. Agent Actions (LLM):
   • Calls get_transaction_details() -> gets amount.
   • Analyzes sender/receiver data -> determines is_international.
   • Calls is_high_risk_jurisdiction() -> determines risk status.
4. Structured Handoff: The agent now has a structured set of facts: {transaction_amount: 75000, is_international: true, is_high_risk_jurisdiction: true}.
5. DMN Execution: The agent passes these facts to the DMN decision engine, which executes the following decision table:

6. Auditable Result: The DMN engine returns the result Flag for EDD Review, along with the specific rule that was triggered. The agent can then use this to formulate its final, fully justified output.

This hybrid process is both intelligent and rigorous. The LLM handles the ambiguity of data retrieval and interpretation, while the DMN engine ensures the final judgment is consistent, transparent, and defensible.

5. Implementation Pattern: A Multi-Agent Compliance Crew

In a production environment, this workflow would likely be implemented not by a single monolithic agent, but by a "crew" of specialized agents, each responsible for a part of the process. This aligns with the principles of systems thinking—breaking a complex function into modular, interacting components.

A recent research paper on agentic systems in finance proposes exactly this: a "Model Risk Management (MRM) crew" that acts as a safeguard team.

As the paper describes, an agent like the Documentation Compliance Checker is purpose-built for our task. Its reasoning process is explicit:

1. Ingest the output of another process (e.g., a transaction log or a model development document).
2. Use a RAG tool to retrieve the official "organizational modeling guide" (our policy documents).
3. Compare the steps taken in the process against the requirements in the retrieved guide.
4. Issue a finding of compliance or non-compliance.

This demonstrates that specifying an agent's reasoning process is a core part of its design, where we define its goals, tools, and the sequence of operations it must perform to fulfill its specialized role.

Conclusion

In this lesson, we have specified the reasoning process for a compliance agent, moving beyond a simple RAG query to a complete, auditable workflow.

Key Takeaways:

• Reasoning as a Workflow: An agent's reasoning process is a structured workflow that bridges raw data and unstructured knowledge to produce a decision.
• ReAct for Flexibility: The ReAct pattern provides a flexible way for an LLM to orchestrate its own reasoning, using tools to gather information and adapt its plan.
• DMN for Rigor: For regulated decisions, a deterministic layer like a DMN decision table is essential for ensuring consistency, transparency, and auditability.
• Hybrid Architecture is Superior: The most robust design uses an LLM-powered agent for perception and fact-extraction, handing off a structured payload to a DMN engine for the final, rule-based decision.
• Specialization via Multi-Agent Crews: Complex functions like compliance are best handled by a team of specialized agents, each with a clearly defined reasoning process and role.

Preview of the Next Lesson:

The hybrid reasoning process we designed today naturally produces a rich decision trail. In our next lesson, we will formalize this by exploring the distinction between an audit trail (what happened) and explainability (why it happened). We'll see how generating "reasoning traces" and using transparent models like DMN are fundamental to satisfying both of these critical governance requirements.