# Wait

> Source: <https://promptcube3.com/en/threads/3056/>
> Published: 2026-07-25 04:46:50+00:00

# Wait

***

# Building a Debt-Logic Engine: Handling Charge-Off State Transitions

Hard-coding the logic for "debt ownership" in a financial AI agent is a nightmare because the state of a debt account isn't binary; it's a timeline of ownership transfers. If you're building an LLM-powered agent to help users navigate collections, you can't just prompt the model to "find the creditor." You have to implement a strict state machine to distinguish between internal collections and third-party debt buyers, or your agent will hallucinate and tell users to pay the wrong entity.

## The State Transition Problem

The core issue is the "Charge-Off" event (typically occurring around day 180). From a data architecture perspective, this is a critical state change.

**State A (Internal):** Debt is owned by the original creditor. Payment clears the balance.**State B (Charge-Off/Sold):** Debt is legally transferred to a third-party buyer. The original creditor no longer has the authority to accept payment for satisfaction.

If your AI agent suggests a consolidation loan to pay the original creditor during State B, the user pays money to a company that no longer owns the debt, while the actual debt buyer continues to trigger collection events.

## Implementing Validation Logic

To prevent these errors, I've been implementing a validation loop in my agent's workflow. Instead of relying on the LLM's interpretation of a PDF statement, I'm using a structured verification step.

If the agent detects a "collection" keyword, it must trigger a `DebtValidation`

tool before recommending any payment action. Here is a conceptual JSON schema for how I'm structuring the debt entity to ensure the LLM tracks the current legal owner:

```
{
  "account_id": "ACC-99283",
  "current_status": "CHARGED_OFF",
  "ownership_chain": [
    {
      "entity": "Original Bank",
      "role": "ORIGINATOR",
      "status": "DIVESTED",
      "transfer_date": "2023-11-15"
    },
    {
      "entity": "Debt Buyer X",
      "role": "CURRENT_OWNER",
      "status": "ACTIVE",
      "validation_verified": false
    }
  ],
  "legal_framework": "FDCPA_15_USC_1692"
}
```

## Debugging the "Double Entry" Hallucination

A specific bug I encountered involved the agent reading credit report data. Credit reports often show two entries: one from the original creditor marked "charge-off" and one from the buyer marked "collection."

The LLM initially flagged this as "duplicate debt" and tried to subtract one from the other in the total balance calculation. To fix this, I had to update the system prompt to explicitly define the relationship between these two markers.

**The Fix:**

I added a few-shot example to the prompt explaining that `Charge-off`

+ `Collection`

= `Single Debt, New Owner`

.

```
## Logic Rule: Debt Ownership
When analyzing credit tradelines:
- IF (Entity A == "Charge-off") AND (Entity B == "Collection") 
- THEN (Current_Owner = Entity B)
- ACTION: Do not sum these balances; they represent the same underlying liability.
```

## Practical Workflow for AI Agents

If you are building a tool to automate this, don't let the LLM handle the "validation request" logic on its own. Use a step-by-step pipeline:

1. **Extraction:** Use an LLM to parse the latest communication and extract the sender's entity name.

2. **Verification:** Cross-reference the entity against a known database of debt buyers.

3. **Action:** If the entity is a third party, the agent must generate a formal Debt Validation Request based on `15 U.S.C. § 1692g`

rather than suggesting a consolidation payment.

This architectural approach turns a vague "financial advice" bot into a precise tool that understands the legal state of the data it's processing.

[Next Inflect v2: Running TTS under 10M Parameters →](/en/threads/3050/)