AI Architecture Pattern 01: Grounded RAG For Payment Support

“Why is my card payment still pending?” The model has zero idea — and will answer anyway.

A customer asks a simple question. An LLM with no real data behind it will still generate a fluent, confident answer — and it will likely be wrong, because the model was never told this specific transaction’s actual status. It isn’t lying. It just has no concept of “checking” anything unless you hand it real facts first.

That gap — not a weaker model, not a better prompt — is what Pattern 01 of the AI Architecture Patterns series fixes.

[!NOTE] This post is part of a continuing 16-pattern series: a payment-support assistant at a fictional bank, starting simple and accumulating exactly the complexity a real one would, in the order a real one would need it. Read the series overview for how every later pattern builds on this one, or clone the repo and run python -m launcher.main from the repo root to browse the whole series — including this pattern’s live, editable architecture diagrams — from one local server.

Why This Pattern Exists

[!INFO] The first mistake many teams make with AI assistance is asking an AI model to answer business questions directly from its training memory. That is risky for any financial institution, especially when you are dealing with payment journeys.

A Customer may ask

[!NOTE] My Payment is pending. Can I cancel it, and when will the money return to my account?

A useful answer depends on current business facts and what exactly the status of the payment is:

1. The customer’s transaction status.
2. The payment method.
3. The bank/card/network settlement stage.
4. Internal policy.
5. Region-specific or scheme-specific rules.
6. Whether the user is authenticated and authorized to see this information.

The model alone does not know those facts. A Grounded Retrieval-Augmented Generation pattern gives the model relevant, approved context before it answers.

[!INFO] The principle is simple: Retrieve trusted information first. Let the model explain using that information. Refuse or escalate when the retrieved context is not enough.

Mental Model

Grounded RAG is not “chat with PDFs.” It is an architecture pattern for controlling what knowledge the AI is allowed to use.

The model becomes a language and reasoning layer over:

• Trusted policy documents.
• Product FAQs.
• Operational runbooks.
• Transaction facts from internal systems.
• Guardrails that decide whether the assistant can answer.
• For regulated or high-trust domains, RAG should be treated as a controlled information supply chain.

High-Level Architecture

Diagrams below use a shared colour palette so component roles and trust boundaries are visible at a glance. Subgraphs mark the responsibility split between the user edge, the AI plane, grounded knowledge, source-of-truth APIs, and governance.

flowchart TB
    classDef user fill:#E0F2FE,stroke:#0369A1,color:#0C4A6E,stroke-width:2px
    classDef edge fill:#FEF3C7,stroke:#B45309,color:#78350F,stroke-width:2px
    classDef ai fill:#EDE9FE,stroke:#6D28D9,color:#4C1D95,stroke-width:2px
    classDef data fill:#DCFCE7,stroke:#15803D,color:#14532D,stroke-width:2px
    classDef external fill:#FEE2E2,stroke:#B91C1C,color:#7F1D1D,stroke-width:2px,stroke-dasharray: 4 3
    classDef governance fill:#F3F4F6,stroke:#374151,color:#111827,stroke-width:1px

    U[Customer or Support Agent]:::user
    subgraph EDGE["🔓 Edge / Trust Boundary"]
        UI[Web or Support Portal]:::edge
        AUTH[Authentication and Authorization]:::edge
    end
    subgraph AI_PLANE["🤖 AI Plane"]
        API[AI Assistant API]:::ai
        CLASSIFY[Intent and Risk Classifier]:::ai
        RETRIEVE[Retriever]:::ai
        CONTEXT[Context Builder]:::ai
        LLM[LLM Response Generator]:::ai
        VALIDATE[Answer Validator]:::ai
    end
    subgraph KNOWLEDGE["📚 Grounded Knowledge"]
        DOCS[Approved Policy Docs and FAQs]:::data
        CHUNK[Chunk and Embed Pipeline]:::data
        VDB[(Vector Database)]:::data
    end
    subgraph EXT["🔌 Source-of-Truth APIs (read-only)"]
        PAYAPI[Payment Status API]:::external
        PAYDB[(Payment System)]:::external
    end
    subgraph GOV["🛡️ Governance"]
        AUDIT[(Audit Logs)]:::governance
        OBS[Tracing and Evaluation]:::governance
        HUMAN[Human Escalation Queue]:::governance
    end

    U --> UI --> AUTH --> API
    API --> CLASSIFY --> RETRIEVE
    DOCS --> CHUNK --> VDB --> RETRIEVE
    API --> PAYAPI
    PAYDB --> PAYAPI
    RETRIEVE --> CONTEXT
    PAYAPI --> CONTEXT
    CLASSIFY --> CONTEXT
    CONTEXT --> LLM --> VALIDATE
    VALIDATE -->|Grounded and Safe| UI
    VALIDATE -->|Low Confidence or Restricted| HUMAN
    API --> AUDIT
    VALIDATE --> OBS
    HUMAN --> OBS

    subgraph LEGEND[" Legend "]
        L1[User]:::user
        L2[Edge / Trust]:::edge
        L3[AI Plane]:::ai
        L4[Grounded Data]:::data
        L5[External API]:::external
        L6[Governance]:::governance
    end

[!TIP] A logged-in customer asks: “I made a card payment yesterday and it is still pending. Can I cancel it?”

[!NOTE] To address the customer query — simplified journey:

1. User authenticates in the banking app.
2. Assistant detects this is a payment-status question.
3. System retrieves the transaction status from a read-only payment API.
4. System retrieves approved policy snippets about pending card payments.
5. The model generates an answer using only retrieved policy and transaction facts.
6. If the status is ambiguous, the assistant escalates to support instead of guessing.

[!NOTE] Example Answer Shape Your payment is currently pending, which usually means the merchant has authorized the amount but final settlement has not completed yet. Based on the payment policy, pending card payments usually cannot be cancelled by the bank while the merchant authorization is active. If the merchant releases the authorization, the amount is normally made available again after the hold expires. I can help you raise a support request if you do not recognize this payment.

Sources:

• Card payment pending policy
• Transaction status from payment service

[!CAUTION] Important: the assistant is not moving money, cancelling payments, or making a dispute decision. It is explaining status and routing the user safely.

Activity Diagram

Same colour language applied here — green is a safe terminal state, red is a refusal or escalation, yellow is a decision gate, purple is an AI step, grey is governance/logging.

flowchart TD
    classDef start fill:#E0F2FE,stroke:#0369A1,color:#0C4A6E,stroke-width:2px
    classDef ai fill:#EDE9FE,stroke:#6D28D9,color:#4C1D95,stroke-width:2px
    classDef decision fill:#FEF3C7,stroke:#B45309,color:#78350F,stroke-width:2px
    classDef safe fill:#DCFCE7,stroke:#15803D,color:#14532D,stroke-width:2px
    classDef refuse fill:#FEE2E2,stroke:#B91C1C,color:#7F1D1D,stroke-width:2px
    classDef log fill:#F3F4F6,stroke:#374151,color:#111827,stroke-width:1px

    A[User asks payment question]:::start --> B[Authenticate user]:::ai
    B --> C{User authorized<br/>for transaction?}:::decision
    C -->|No| C1[Refuse account-specific answer]:::refuse
    C1 --> Z[Log event]:::log

    C -->|Yes| D[Classify intent and risk]:::ai
    D --> E{Action requested?<br/>cancel / refund / dispute}:::decision
    E -->|Yes| E1[Route to controlled workflow<br/>or human approval]:::refuse
    E1 --> Z

    E -->|No — explain status| F[Retrieve payment status]:::ai
    F --> G[Retrieve relevant policy docs]:::ai
    G --> H{Enough trusted<br/>context?}:::decision
    H -->|No| H1[Ask clarifying question<br/>or escalate]:::refuse
    H1 --> Z

    H -->|Yes| I[Build grounded prompt]:::ai
    I --> J[Generate answer]:::ai
    J --> K[Validate citations, PII,<br/>and policy compliance]:::ai
    K --> L{Answer safe<br/>and grounded?}:::decision
    L -->|Yes| M[Return answer with sources]:::safe
    L -->|No| N[Escalate or limited fallback]:::refuse
    M --> Z
    N --> Z

    subgraph LEGEND_AD[" Legend "]
        LD1[Start / Input]:::start
        LD2[AI Step]:::ai
        LD3[Decision Gate]:::decision
        LD4[Safe Terminal]:::safe
        LD5[Refusal / Escalation]:::refuse
        LD6[Audit / Log]:::log
    end

Sequence Diagram

Numbered steps and grouped phases — Authentication, Grounded Retrieval, Generation & Validation, Response — make the request flow scannable.

sequenceDiagram
    autonumber
    participant User
    participant App
    participant API as AI Assistant API
    participant Auth as Auth Service
    participant Pay as Payment Status API
    participant Vec as Vector DB
    participant LLM as LLM
    participant Obs as Logs and Traces

    User->>App: Ask about pending payment
    App->>API: Send question and transaction id

    rect rgb(254, 243, 199)
    Note over API,Auth: 🔓 Authentication
    API->>Auth: Verify access
    Auth-->>API: Authorized
    end

    rect rgb(220, 252, 231)
    Note over API,Vec: 📚 Grounded Retrieval (read-only)
    API->>Pay: Read transaction status
    Pay-->>API: Pending authorization
    API->>Vec: Search policy snippets
    Vec-->>API: Relevant payment policy chunks
    end

    rect rgb(237, 233, 254)
    Note over API,LLM: 🤖 Generation and Validation
    API->>LLM: Generate answer from supplied context
    LLM-->>API: Draft answer with source references
    API->>API: Validate grounding and safety
    end

    rect rgb(243, 244, 246)
    Note over API,Obs: 🛡️ Audit
    API->>Obs: Record prompt metadata, retrieved docs, result
    end

    API-->>App: Answer with sources or escalation
    App-->>User: Display response

The LLM is called once, with a prompt that already contains the authorized transaction status and the retrieved policy chunks. The model is not deciding what data it sees; the application is.

What This Looks Like For Real, On AWS

Everything above is a local mock — zero AWS credentials, zero cost, the right default for anyone following along. But it’s worth being concrete about what the production version of “Option B” actually is, because it’s a real, deployable, cheap architecture, not a hand-wave.

flowchart LR
    C[Chat client] --> APIGW[API Gateway]
    APIGW --> L["Lambda (orchestration)"]
    L -->|"session history"| DDB[(DynamoDB)]
    L -->|RetrieveAndGenerate| BR[Bedrock Converse]
    BR -->|queries| KB[Bedrock Knowledge Base]
    KB -->|vectors| S3V[(S3 Vectors index)]
    S3[S3 — policy docs] -.->|"ingest: chunk + embed"| KB

[!IMPORTANT] The one correction worth knowing: Lambda does not sit between the app and the Knowledge Base for retrieval — RetrieveAndGenerate can be called directly from any backend. Lambda’s real job here is orchestration: pull session history from DynamoDB, then make that one Bedrock call. This was a real misconception caught by reading AWS’s own docs before drawing this diagram, not assumed.

Vector store choice matters more than it looks. S3 Vectors (GA December 2025) costs effectively $0 at this scale — fractions of a cent per month for a handful of policy documents. OpenSearch Serverless, the longer-established default, has a ~$345/month minimum, even at zero queries. For a demo recorded a handful of times, that floor alone makes S3 Vectors the right pick.

Model choice matters too — and the cheapest model in Bedrock is plenty here. This pattern’s actual job is a short, single-question grounded answer over a handful of policy documents — that doesn’t need the most capable (or most expensive) model. Amazon Nova Micro (~$0.000035/1K input + $0.00014/1K output tokens) is the recommended default — roughly 170x cheaper on input and 200x cheaper on output than Claude 3.5 Sonnet, with no meaningful capability loss for this task. A full recording session against real AWS — S3, Bedrock Knowledge Base, the model call — typically costs under $1, often just fractions of a cent.

A Newer Option, Found Mid-Build: AgentCore Gateway

While building this pattern’s AWS deployment steps, the Bedrock console surfaced something not in the original plan: Knowledge Bases can now be added as an AgentCore Gateway target, exposed as a standard MCP (Model Context Protocol) tool that any agent framework — Strands, LangChain, CrewAI — can discover and call automatically, including a multi-step “Agentic Retrieval” mode for compound questions.

It’s real and current (announced at AWS Summit New York, June 2026) — but it requires a different, newer product called Managed Knowledge Base, not the regular Knowledge Base + S3 Vectors setup this pattern uses. The two aren’t interchangeable: RetrieveAndGenerate (what this pattern calls) explicitly cannot be used with Managed Knowledge Base, confirmed directly from AWS’s own API Reference — even though AWS’s own announcement blog claims otherwise. That’s a real contradiction between two AWS-published sources, and worth knowing about rather than papering over.

This pattern keeps its direct, cheaper approach — AgentCore Gateway solves a genuinely different problem (an agent deciding whether and how to query a knowledge base, possibly choosing between several tools) than this pattern’s single, well-defined question. It’s the right answer for a later, agent-oriented pattern in this series, not a retrofit here.

When to Use This Pattern

[!TIP] Use grounded RAG when:

1. The answer must come from approved, current knowledge.
2. The user question depends on account-specific facts.
3. The assistant must cite sources.
4. The cost of a hallucinated answer is high.
5. Missing context should trigger escalation instead of guesswork.

Good candidates: payment support, fraud support, dispute intake, claims support, compliance help desks, policy Q&A, internal operations support.

When Not to Use This Pattern Alone

[!WARNING] Do not use this pattern by itself when:

1. The assistant needs to move money or change account state.
2. The workflow requires legal, regulatory, or dispute decisions.
3. The answer depends on private data that cannot be safely passed to the model.
4. The source documents are stale, conflicting, or not governed.
5. There is no escalation path for uncertain answers.

For those cases, combine grounded RAG with workflow orchestration, policy-as-code, human review, and stronger audit controls.

Implementation Sketch

[!NOTE] Build a local demo that answers payment-support questions from: However, we will use synthetic data to model real RAG behaviour — a flat policy document in place of a vector store, and a static JSON in place of a payment database.

Error: Unable to fetch the remote file from https://raw.githubusercontent.com/narenmak17/ai-series-demo/main/patterns/01-grounded-rag-payment-support/README.md. Check if the URL is correct or if the repository is private.

What I Learned

[!NOTE] The biggest takeaway was that with this pattern in mind, AI is not a replacement for your point-to-point API communication and should not be used for those flows — the RAG pattern shows how additional documentation and processes can be plugged in alongside your AI to give customers accurate, cited answers with the right context. Start with the simplest solution that works first.

What’s Next

This pattern works because one team built it end to end. Pattern 02: Prompt And Context Contract picks up exactly where this leaves off — the moment a second team integrates with the same prompt, and what breaks silently when there’s no formal contract for what it expects.

[!TIP] Star the GitHub repo and follow along with the series.

SELECT * FROM transactions
WHERE id = 'txn_9999'
  AND user_id = 'user_123'   ← both fields, one query

Have questions or feedback? Drop a comment below or connect on LinkedIn.