← Back to all posts
Where LLMs Sit in a Credit Decision Stack

Where LLMs Sit in a Credit Decision Stack

Gautam Anand··9 min read

The Four Pillars of Decisioning

Over the past year, I've had countless conversations with financial institutions across the Asia-Pacific region, and one question keeps surfacing: "Where exactly does generative AI fit in our credit decisioning systems?"

It's a fair question. With all the hype around LLMs like GPT-4 and Claude, it's tempting to think they might revolutionize — or even replace — traditional decision engines. But the reality is more nuanced, and frankly, more interesting.

To understand where LLMs fit, we first need to understand what a modern decisioning system actually does. And that brings us to the four pillars.

At its core, every sophisticated decisioning system — whether for credit, fraud, collections, or customer management — rests on four foundational pillars:

  • DATA — Ingest & integrate data from diverse sources and formats

  • INSIGHTS — Build features, models & data-driven strategies

  • ACTIONS — Execute decisions & orchestrate agentic workflows

  • OUTCOMES — Track, measure & simulate business impact

These pillars don't operate in isolation — they form a continuous loop. Outcomes feed back into data, which generates new insights, which inform better actions. It's an ever-evolving system.

Now here's the key question: Where do LLMs fit in this framework?

The short answer: LLMs don't replace any pillar. They augment each one — but in very different ways. Think of them as translators and interpreters that help each pillar work with the messy, unstructured, human-generated content that traditional systems struggle with.

Let's walk through each pillar and see exactly how LLMs can help — and where they should step aside.

Pillar 1: DATA

The Data pillar is about ingesting and integrating information from diverse sources — credit bureaus, bank statements, tax returns, pay slips, business financials, identity documents, and increasingly, alternative data like utility payments or e-commerce transactions.

Traditional systems excel at processing structured data: CSV files, database tables, API responses with well-defined schemas. But credit decisions increasingly depend on unstructured data — documents that come in PDFs, scanned images, or free-text formats.

LLM Role: Intelligent Document Processing — LLMs can read and extract structured data from messy documents — understanding that "Total Revenue," "Gross Sales," and "Annual Turnover" mean roughly the same thing, regardless of where they appear on the page or what format the document uses.

Decision Engine Role: Data Validation & Storage — Once extracted, the decision engine validates the data against business rules, normalizes formats, and stores it in structured form for downstream processing. This ensures consistency and auditability.

Pillar 2: INSIGHTS

The Insights pillar is where raw data becomes actionable intelligence. This includes feature engineering, building predictive models, creating scorecards, and developing data-driven strategies.

Traditional ML models and scorecards remain the gold standard here — they're explainable, consistent, and regulatory-compliant. But there's one area where LLMs offer something genuinely new: making sense of narrative data.

LLM Role: Narrative Analysis & Signal Extraction — Fraud investigators review case notes. Collections teams read customer communications. Underwriters parse business descriptions. LLMs can analyze these narratives at scale, extracting signals that feed into traditional scoring models.

Technical Deep Dive: Fraud Narrative Scoring

Here's how this works in practice. The LLM extracts signals from unstructured text; the decision engine applies deterministic rules to those signals:

# LLM extracts signals; Decision Engine scores them

class FraudInsightsEngine:

    def extract_fraud_signals(self, case_notes: str) -> dict:
        """
        LLM analyzes narratives and extracts structured signals.
        These signals become FEATURES for the scoring model.
        """

        prompt = f"""
        Analyze this case narrative for fraud indicators.
        Extract factual signals only — no judgments.

        Return JSON:
        - inconsistencies: list of contradictions
        - urgency_language: boolean
        - story_changes: count of narrative changes
        - third_party_involvement: boolean

        Case Notes: {case_notes}
        """

        # LLM returns structured signals
        signals = self.llm.extract_json(prompt)

        # Decision Engine converts signals to features
        features = {
            "inconsistency_count": len(signals["inconsistencies"]),
            "urgency_flag": 1 if signals["urgency_language"] else 0,
            "story_change_count": signals["story_changes"],
            "third_party_flag": 1 if signals["third_party_involvement"] else 0
        }

        # These features feed into a TRADITIONAL scorecard
        return self.scorecard.calculate_score(features)

Key Insight: The LLM doesn't determine the fraud score. It generates features that feed into a traditional, explainable scorecard. This means every score can be audited and explained to regulators.

Pillar 3: ACTIONS

The Actions pillar is where decisions get made and executed. This includes applying business rules, running decision strategies, orchestrating workflows, and taking autonomous action based on the insights generated.

This is the pillar where traditional decision engines are absolutely essential — and where LLMs should generally not make final calls.

Why? Three critical reasons:

1. Explainability: When you decline a loan, you must explain why. "The AI said no" doesn't satisfy regulators — or customers.

2. Consistency: Ask an LLM the same question twice, you might get different answers. Decision engines are deterministic: same inputs = same outputs, every time.

3. Auditability: Every decision must be traceable. Traditional systems maintain complete audit trails.

LLM Role: Policy-to-Rules Translation — LLMs can help configure the decision engine by translating dense policy documents into implementable decision rules — with human review before deployment.

Technical Deep Dive: Policy-to-Rules Translation

Here's an example of how an LLM translates policy text into a structured decision rule:

Input — Policy Text:

"Section 4.2.1: Applicants with a debt-to-income ratio exceeding 43% shall be declined for conventional mortgage products unless they demonstrate compensating factors such as significant liquid reserves (minimum 6 months) or a credit score above 720."

LLM Output — Draft Rule:

{
  "rule_id": "CONV-MTG-DTI-001",
  "condition": "applicant.dti_ratio > 0.43 AND loan.product == 'CONVENTIONAL_MORTGAGE' AND NOT (applicant.reserves_months >= 6 OR applicant.credit_score > 720)",
  "action": "DECLINE",
  "policy_reference": "Section 4.2.1",
  "status": "PENDING_REVIEW"
}

Human-in-the-Loop: No rule extracted by the LLM ever goes directly to production. Every rule requires explicit human approval, ensuring accountability and catching misinterpretations.

Pillar 4: OUTCOMES

The Outcomes pillar closes the loop. It's about tracking decisions, measuring their effectiveness, connecting them to business results, and simulating alternative scenarios.

This pillar answers questions like: Did our new credit policy reduce defaults? What would happen if we loosened our DTI threshold by 2%? How are approval rates trending across different customer segments?

LLM Role: Report Generation & Natural Language Querying — LLMs can help stakeholders interact with outcome data more naturally — generating executive summaries, answering ad-hoc questions about portfolio performance, and translating complex analytics into business language.

# Natural language interface to outcome analytics

class OutcomeAnalyzer:

    def query(self, question: str) -> str:
        """
        Translate natural language questions into analytics queries.
        LLM interprets; Analytics engine computes.
        """

        # Example: "How did our Q3 policy change affect approval rates?"

        # Step 1: LLM translates to structured query
        query_spec = self.llm.translate_to_query(
            question=question,
            available_metrics=["approval_rate", "default_rate", "volume"],
            available_dimensions=["time", "segment", "product"]
        )

        # Step 2: Analytics engine runs the actual computation
        results = self.analytics.execute(query_spec)

        # Step 3: LLM summarizes results in natural language
        return self.llm.summarize(results, audience="executive")

Decision Engine Role: Simulation & What-If Analysis — The actual simulations — "what if we changed this threshold?" — must run through the decision engine to ensure accuracy. LLMs can help interpret the results, but they shouldn't compute them.

The Complete Picture: LLM Role by Pillar

Here's the full mapping of where LLMs add value versus where traditional decision engines remain essential:

DATA — LLM does: Document extraction, format interpretation, unstructured-to-structured conversion. Engine does: Data validation, normalization, storage, quality checks, schema enforcement.

INSIGHTS — LLM does: Narrative analysis, signal extraction from text, feature generation from unstructured data. Engine does: Scorecard calculation, ML model inference, feature engineering, strategy optimization.

ACTIONS — LLM does: Policy translation, rule drafting (with human approval), natural language workflow configuration. Engine does: Rule execution, decision rendering, workflow orchestration, action dispatch, audit logging.

OUTCOMES — LLM does: Report generation, natural language queries, result interpretation, executive summaries. Engine does: KPI computation, simulation runs, scenario analysis, statistical calculations, trend detection.

"LLMs don't replace the four pillars — they make each pillar more accessible, more flexible, and better at handling the messy reality of human-generated content."

Side-by-Side: Capabilities Comparison

Here's how LLMs and Decision Engines compare across key capabilities:

  • Reading unstructured documents — LLMs: Excellent | Decision Engines: Limited

  • Consistent, repeatable outputs — LLMs: Variable | Decision Engines: Deterministic

  • Explaining decision rationale — LLMs: Opaque | Decision Engines: Transparent

  • Understanding context & nuance — LLMs: Strong | Decision Engines: Rule-bound

  • Regulatory compliance — LLMs: Uncertain | Decision Engines: Auditable

  • Adapting to new formats — LLMs: Flexible | Decision Engines: Needs config

  • Processing speed at scale — LLMs: Fast | Decision Engines: Very fast

Getting Started: A Pragmatic Approach

If you're considering integrating LLMs into your decisioning stack, here's a phased approach mapped to the four pillars:

Phase 1 (Data): Start with document processing. This is low-risk, high-reward — automate the extraction of data from income verification documents, bank statements, or business financials.

Phase 2 (Insights): Add fraud narrative analysis. Use LLMs to extract signals from case notes that feed into your existing fraud scorecards.

Phase 3 (Actions): Pilot policy-to-rules translation. Help your compliance team keep decision rules aligned with policy documents — always with human review before deployment.

Phase 4 (Outcomes): Enable natural language querying of your analytics. Let business users ask questions about portfolio performance without writing SQL.

Key Takeaways

  • Four pillars frame everything: Data → Insights → Actions → Outcomes

  • LLMs augment each pillar — they don't replace any of them

  • Traditional engines remain essential for explainability, consistency, and compliance

  • The hybrid approach wins — LLMs handle unstructured content; engines make decisions

  • Human oversight is non-negotiable — especially in the Actions pillar

Looking Ahead

The decisioning landscape is evolving rapidly. LLMs are becoming more consistent. Decision engines are becoming more flexible. The boundaries are blurring.

But the four pillars endure. However the technology evolves, you'll always need to ingest data, generate insights, take actions, and measure outcomes.

The institutions that thrive will be those who understand where each technology excels — and who master the art of making them work together across all four pillars.

That's where the competitive advantage lies.

AICreditLLMsDecision Engines