Forfis Blog

Category: Fintech and Payments

  • RAG Shipment Status Assistant for US Fintech: 12-Item PCI DSS Checklist

    Scope and Baseline

    This checklist applies to a US-based fintech with 2,000+ employees deploying a retrieval-augmented knowledge assistant to cut first-response time on order and shipment status inquiries. The assistant integrates with Slack or Microsoft Teams, uses LangChain and LangGraph for orchestration, and runs on a model-agnostic stack. The pilot is fixed-scope, eight weeks, and measured against a baseline captured in week zero. PCI DSS compliance is a hard constraint: the assistant must never ingest, store, or transmit cardholder data. Every item below is a discrete action you can mark done or not done.

    Data, Compliance, and Scope

    1. Capture the week-zero baseline. Sample 50–100 real shipment status inquiries and record median cycle time and error rate. This baseline is your success metric; without it, you cannot prove the pilot delivered value.

    2. Define the PCI DSS data boundary. Identify which fields in your CRM and ERP are in PCI scope (PAN, CVV, track data) and which are not (order ID, tracking number, status). The RAG vector store must be partitioned so the assistant never retrieves PCI-scope fields.

    3. Select the pilot workflow. Choose one high-volume channel (e.g., a Slack channel for shipment status) and one department. A fixed-scope pilot on a single workflow is deliverable in eight weeks; multi-department rollout is a separate engagement.

    4. Document the approval threshold. Specify which response types trigger human-in-the-loop review (any response touching money, health data, or a contract). This threshold is encoded as a node in the LangGraph pipeline and must be agreed with your compliance team before week one.

    Architecture and Pipeline

    1. Build the extraction pipeline. Ingest shipment status data from your ERP or carrier API using layout-aware OCR and LLM-based field extraction. Validate extracted fields against known formats (e.g., USPS tracking numbers are 20–22 digits) and flag low-confidence extractions for human review.

    2. Partition the vector store. Create a non-PCI partition for shipment status, order metadata, and policy docs. The RAG retrieval query accesses only this partition by default; PCI-scope data is never embedded.

    3. Configure the LangGraph pipeline. Define the stateful graph: parse inbound message → classify intent → query vector store → check PCI scope → route to human if needed → format and send. LangGraph handles branching logic and human-in-the-loop interrupts; LangChain handles LLM calls and vector store interactions.

    4. Select the model stack. Use OpenAI or Anthropic APIs for quality-critical steps (intent classification, response generation) and open-weight models on client hardware if regulated data cannot leave the building. The architecture is model-agnostic; the choice depends on your data residency and compliance constraints.

    Integration, Approval, and Measurement

    1. Integrate with Slack or Microsoft Teams. Use the Events API (Slack) or Bot Framework (Teams) to listen for messages in a designated channel and post responses. The integration layer is a thin adapter that translates between the messaging platform’s format and the LangGraph pipeline’s schema; the core RAG logic is platform-agnostic.

    2. Implement the human-in-the-loop gate. Add a node that pauses the pipeline when the response touches money, health data, or a contract. The gate sends the draft response to a human approver via Slack or Teams and waits for sign-off before delivering to the customer.

    3. Set up monitoring and logging. Log every pipeline execution: input, extracted fields, retrieved documents, generated response, and approval status. This log is your audit trail for PCI DSS and your debugging tool when the assistant misbehaves.

    4. Run the eight-week measurement. Re-measure the same 50–100 inquiries through the automated pipeline and compare cycle time and error rate against the week-zero baseline. The delta is your before/after metric; if the pilot hits its targets, scope the rollout separately with a new SOW.

  • AI Process Audit vs. Direct Contract Review Pilot: A 3-Month Fintech Verdict

    What Is Being Compared

    The two options are not alternatives but sequential phases of the same engagement. Option A is the AI process audit and roadmap: a structured assessment of every finance and accounting workflow in a 2,000+ employee Austrian fintech, scored on volume, error rate, cycle time, and integration complexity, producing a prioritized automation roadmap. Option B is the direct contract review pilot: a fixed-scope, 3-month build that deploys an AI layer for contract clause extraction, data enrichment, and cleanup, integrated into SAP or Microsoft Dynamics ERP, with a measured before/after baseline on cycle time and error rate. The question is whether a company in the “Running Isolated Pilots” maturity stage should spend the first 3 months on the audit or jump straight to the pilot. The answer depends on how many workflows are candidates, how well the ERP integration surface is documented, and whether the finance team can commit senior staff to the audit interviews.

    Criteria for Judgment

    Eight criteria determine which path delivers more value in a 3-month window:

    • Scope clarity: Does the company know which workflows to automate, or is that the unknown?
    • ERP integration readiness: Are SAP BAPI/RFC or Dynamics OData endpoints documented and accessible?
    • Data availability: Can the finance team provide 200+ historical contract samples for model validation?
    • Compliance surface: Does the contract data touch PSD2 payment records or MiFID II client data, requiring on-premise deployment?
    • Senior staff availability: Can 2–3 senior finance or legal reviewers commit 4 hours/week to the human-in-the-loop approval layer?
    • Model accuracy gap: Is the open-weight model’s extraction accuracy within 5% of the frontier API for the specific contract types?
    • Rollout dependency: Does the pilot’s success depend on a roadmap that sequences multiple workflows, or is contract review a standalone win?
    • Budget structure: Is the 3-month budget a fixed pilot fee or an audit-plus-pilot package?

    Comparison Table

    Criterion Option A: AI Process Audit & Roadmap Option B: Direct Contract Review Pilot
    Time to first measurable result 4–6 weeks (audit report) 6–8 weeks (pilot baseline)
    Scope All finance/accounting workflows One workflow: contract review
    ERP integration depth Read-only access for data profiling Write access via SAP BAPI or Dynamics OData
    Data requirement 50–100 sample records per workflow 200+ historical contracts for validation
    Model selection Recommended, not deployed Open-weight model deployed on-premise
    Output Prioritized roadmap with ROI per workflow Measured cycle time and error rate delta
    Senior staff commitment 2–3 reviewers, 4 hrs/week for interviews 2–3 reviewers, 4 hrs/week for approval layer
    Risk of scope creep Low (fixed audit scope) Medium (new contract types discovered mid-pilot)

    Scenario-by-Scenario Verdict

    When Option A wins: The company has not previously run any AI pilot and does not know which of its 15–20 finance workflows are worth automating. The audit prevents the common failure mode of picking a low-volume, high-complexity workflow that looks impressive in a demo but delivers no ROI. For a 2,000+ employee fintech with multiple business units (payments, lending, insurance products), the audit surfaces that contract review is only one of four high-value targets, and sequencing matters. The 3-month audit produces a roadmap that justifies a 9-month rollout budget.

    When Option B wins: The company already knows contract review is the target—perhaps because a prior isolated pilot on invoice processing proved the model-agnostic architecture works. The finance team has 200+ historical contracts, the SAP AP module API is documented, and the project sponsor wants a measurable before/after baseline within 60 days. In this case, the audit adds 4 weeks of delay without changing the pilot scope.

    Hybrid scenario: A 2-week compressed audit (covering only contract review and two adjacent workflows) followed by a 10-week pilot. This fits the 3-month timeline and gives the roadmap context without the full audit cost.

    Recommendation

    For a 2,000+ employee Austrian fintech in the “Running Isolated Pilots” maturity stage, with a 3-month timeline and a specific need to free senior staff from routine contract review, Option B—the direct contract review pilot—is the correct first move, provided two conditions are met: the finance team can supply 200+ historical contract samples within the first two weeks, and the SAP or Dynamics ERP integration surface is documented. The pilot delivers a measurable baseline (cycle time, error rate, throughput) that becomes the business case for the full rollout. The audit is not skipped; it is compressed into the first 10 days of the pilot, covering contract review and two adjacent workflows (invoice data entry, vendor master data cleanup). This hybrid approach respects the 3-month constraint, uses the open-weight model on-premise to keep PSD2 and MiFID II data inside the building, and plugs into the existing ERP via API rather than replacing it. The managed operations retainer begins at pilot completion, ensuring the model stays current as contract templates evolve.

  • PCI DSS-Compliant AI Support Agent for a 2000+ Employee Fintech in Austria

    The Problem: Routine Work in a Regulated Fintech

    A 2,000-employee fintech in Austria faces a common problem: senior engineers and support specialists are buried in routine tasks. Ticket triage, document extraction, and data entry consume 40% of their time, leaving little room for high-value work. The company wants to deploy an AI agent to handle customer-facing support and internal knowledge search, but the compliance constraints are strict. PCI DSS Requirement 3.7.1 mandates that cardholder data must not be stored in logs or accessible to unauthorized systems. The AI agent must operate within these boundaries while still providing accurate, context-aware responses. The challenge is to build a system that is both technically robust and compliant, without replacing the existing CRM or ERP systems. The solution must integrate via custom REST APIs and webhooks, ensuring that data flows through controlled channels. This deep dive examines the architecture, trade-offs, and implementation details of such a system, focusing on how to free senior staff from routine work while maintaining compliance.

    Mechanism: RAG, LangGraph, and Predictive Scoring

    The core of the system is a retrieval-augmented generation (RAG) pipeline built on LangChain and LangGraph. LangChain provides the abstractions for prompt templates, vector stores, and LLM calls. LangGraph adds a stateful execution engine that models the agent as a graph of nodes. Each node represents a step in the workflow: classify intent, retrieve documents, draft response, human review. This structure is critical for compliance because it allows you to insert mandatory human-approval nodes at specific points. The RAG pipeline ingests documentation from the internal knowledge base, CRM records, and product manuals. Documents are chunked, embedded using OpenAI’s text-embedding-3-small, and stored in a vector database like Pinecone. At query time, the user’s question is embedded, and the top-k most relevant chunks are retrieved. These chunks are injected into the LLM’s context window, allowing the model to generate answers grounded in the company’s specific data. The predictive scoring model, trained on historical ticket data, outputs a confidence score that drives the routing logic. High-risk tickets are flagged for immediate human review, while low-risk tickets are handled by the AI agent.

    Trade-offs: Latency, Accuracy, and Compliance

    The primary trade-off is between latency and accuracy. Using a large, high-quality model like GPT-4 or Claude 3 Opus provides better accuracy but increases latency and cost. Using a smaller, faster model like GPT-3.5 or a local open-weight model reduces latency and cost but may sacrifice accuracy. For a support context, the recommended approach is to use a smaller model for initial classification and retrieval, and a larger model for drafting the final response. This hybrid approach balances speed and quality, keeping the average response time under 2 seconds while maintaining high accuracy. Another trade-off is between centralization and decentralization. A centralized RAG pipeline is easier to manage but may not scale well across departments. A decentralized approach, where each department has its own RAG pipeline, is more scalable but harder to maintain. The recommended approach is a modular architecture where the core components are reusable services that can be configured for different departments. This reduces the time and cost of scaling, as the core infrastructure is already in place. The final trade-off is between automation and human oversight. Full automation is faster but riskier. Human-in-the-loop is slower but safer. The recommended approach is to use human-in-the-loop for high-risk tasks and full automation for low-risk tasks, with the predictive scoring model driving the routing logic.

    Recommendation: A 6-Month Rollout Plan

    The 6-month timeline is aggressive but feasible if the scope is tightly controlled. Months 1-2 cover the process audit, PCI DSS gap analysis, and infrastructure setup. Months 3-4 focus on building the RAG pipeline, integrating with the CRM via REST APIs, and developing the predictive scoring model. Months 5-6 are dedicated to the pilot, including human-in-the-loop testing, baseline measurement, and final compliance validation. The pilot should measure three key metrics: cycle time, error rate, and customer satisfaction. The baseline is established by measuring these metrics over a 2-week period before the AI agent is deployed. After the pilot, the same metrics are measured over another 2-week period. The goal is to reduce cycle time by at least 30% and error rate by at least 20% while maintaining or improving CSAT. These metrics are tracked in a dashboard that is reviewed weekly by the project team. The managed AI operations model ensures that the system is monitored, updated, and optimized continuously. The vendor provides 24/7 monitoring, monthly model retraining, and quarterly compliance audits. This approach ensures that the system remains compliant and effective over time, freeing senior staff from routine work and allowing them to focus on high-value tasks.

  • Three Months to Cut Back-Office Errors in a German Fintech

    1. Start with a Process Audit, Not a Model

    A German fintech with 30 employees processes 400 payment-related documents per week. The back-office team spends 12 hours a week manually extracting data from invoices and payment confirmations, with a 4% error rate that triggers reconciliation delays. Forfis starts with a process audit that maps every manual touchpoint, then selects document extraction as the pilot workflow. The fixed-scope pilot runs for six weeks, shipping with a measured baseline: cycle time drops from 18 minutes per document to 4 minutes, and the error rate falls to 0.8%. The pilot’s success criteria are explicit and tied to the audit’s findings, not vague “efficiency gains.”

    2. Run the Pilot on Document Extraction

    The pilot targets one workflow: extracting line items, amounts, and reference numbers from payment statements and invoices. Forfis uses an open-weight model on the client’s own hardware because PCI DSS requires cardholder data to stay within a controlled environment. The model runs on a single GPU server in the client’s Frankfurt data center. The extraction pipeline feeds directly into the existing ERP via API, so no new data store is introduced. A human reviews every extracted record before it posts to the ledger, satisfying the human-in-the-loop requirement for anything touching money.

    3. Layer a Lead-Qualification Assistant on the CRM

    With the back-office pilot validated, the second phase adds a customer-facing AI assistant for lead qualification. The assistant pulls from the CRM and a Confluence knowledge base to draft first-response emails for inbound leads. It classifies each lead by intent, budget range, and product fit, then flags high-value prospects for the sales team. A rep approves every outbound message before it sends. The assistant reduces initial qualification time from 25 minutes to under 5 per lead, and the sales team reports a 15% lift in response rate within the first month of rollout.

    4. Keep the Stack Model-Agnostic and On-Premise

    The architecture is deliberately model-agnostic. OpenAI and Anthropic APIs handle non-sensitive tasks like drafting marketing copy or summarizing meeting notes. Open-weight models on the client’s hardware handle anything touching payment data, health records, or contracts. This split lets the fintech use frontier models where quality matters most while keeping regulated data on-premise. The integration layer plugs into the existing CRM, ERP, and helpdesk through their native APIs, so no system is replaced. For a 30-person team, this means no new vendor lock-in and no migration project.

    5. Scale Across Departments in the Third Month

    After the pilot, the rollout extends to two adjacent departments: the finance team adopts the document extraction pipeline for vendor invoices, and the support team uses the same RAG assistant for ticket triage. The key is that each new workflow reuses the same architecture, the same on-premise model, and the same human-approval gate. Forfis ships a measured before/after baseline for every workflow: cycle time, error rate, and cost per transaction. By month three, the back-office error rate has dropped from 4% to 0.8% across all automated workflows, and the team has freed up roughly 20 hours per week for higher-value work.

    6. Ship a Measured Baseline, Not a Promise

    The three-month timeline works because the scope is fixed and the success criteria are measurable. The process audit takes two weeks, the pilot runs six weeks, and the rollout occupies the final four weeks. For a 30-person fintech in Germany, this means no open-ended engagement and no surprise invoices. The human-in-the-loop design means the team never has to trust the model blindly: anything touching money, contracts, or health data gets a human sign-off. The result is a back office that runs on 0.8% error rates, a sales team that responds to leads in under five minutes, and an architecture that keeps PCI DSS-compliant data on the client’s own hardware.

  • Cutting First-Response Time in Swiss Fintech: A 6-Month AI Automation Playbook

    The Problem: Manual Back-Office Work and Slow First-Response in Swiss Fintech

    You run a 51-200 person fintech in Switzerland. Your legal and compliance team spends 40-60 hours per week reviewing contracts, processing invoices, and responding to customer queries. First-response time on customer tickets averages 4-6 hours. Your back-office staff manually extracts data from PDFs, enters it into the ERP, and flags discrepancies. You want to cut first-response time to under 30 minutes and reduce manual back-office work by 50% within 6 months. The constraint: you operate under PCI DSS, Swiss FSA supervision, and GDPR. Your AI stack must use Anthropic Claude API for quality-critical tasks, keep regulated data on-prem, and integrate with your existing CRM, ERP, and helpdesk. This guide walks you through a 6-month, model-agnostic, human-in-the-loop deployment that scales across departments without replacing your core systems.

    Prerequisites: What You Need Before Step 1

    Before you start step 1, confirm the following are in place:

    • PCI DSS scope statement updated to include any new AI systems that touch cardholder data. Your QSA must sign off before the pilot goes live.
    • Anthropic Claude API access with a production key and a sandbox key. Budget for at least 500,000 tokens/month for the pilot.
    • On-prem hardware (minimum 2x A100 GPUs or equivalent) if you plan to run open-weight models for regulated data. If you do not have this, plan to use only the Claude API and keep all data outside the CDE.
    • Notion or Confluence workspace with version-controlled contract templates, compliance checklists, and escalation rules. This is your RAG knowledge base.
    • CRM, ERP, and helpdesk API credentials (e.g., Salesforce, SAP, Zendesk). The AI layer plugs into these via their APIs; it does not replace them.
    • A named process owner in legal/compliance who will approve the pilot scope and sign off on the baseline metrics.
    • A 6-month timeline with a fixed-scope pilot in months 3-4 and rollout in months 5-6.

    Step 1: Run a Process Audit and Set the Baseline

    Map every back-office workflow that touches contract review, invoice processing, or customer response. For each workflow, record: (1) current cycle time, (2) error rate, (3) number of manual steps, (4) systems involved, and (5) compliance constraints. Use a simple Notion database with these columns. Interview the process owner in legal/compliance and the back-office lead. The goal is to identify the 2-3 workflows with the highest volume and the clearest ROI. For a 51-200 person fintech, contract review and invoice processing are typically the top candidates. Document the baseline in a one-page summary and get sign-off from the process owner. This baseline is your control group for the pilot.

    Step 2: Build the Pilot on One Workflow with a Fixed Scope

    Choose one workflow for the pilot. For a fintech focused on contract review, the pilot scope is: the AI assistant reads a contract PDF, extracts key clauses (payment terms, liability caps, termination conditions), flags non-compliant language against your PCI DSS and Swiss FSA checklists, and drafts a summary for the legal reviewer. The reviewer approves or rejects each flag. The AI does not send the contract to the counterparty. Build the workflow using a simple orchestration tool (n8n, Zapier, or a custom Python script). The Claude API call uses the claude-3-5-sonnet model with a system prompt that includes your compliance checklist. The output is a structured JSON with flagged clauses and a plain-English summary. Log every API call and human approval in a Notion database.

    Step 3: Integrate with CRM, ERP, and Helpdesk via APIs

    Connect the AI assistant to your existing systems. For contract review, the AI reads the PDF from your document management system (e.g., SharePoint or a local S3 bucket). The output goes to Notion or Confluence, where the legal reviewer sees the flagged clauses and the AI’s reasoning. The reviewer clicks approve or reject. If approved, the contract is marked as reviewed in your CRM. If rejected, the AI logs the reason and the reviewer can add a note. For customer-facing channels, the AI triages incoming tickets in Zendesk, drafts a first response, and routes it to the support agent for approval. The agent sees the AI’s draft, edits it if needed, and sends it. The first-response time is measured from ticket creation to agent approval. Target: under 30 minutes.

    Step 4: Measure the Pilot and Validate the Baseline

    Run the pilot for 4-6 weeks. Measure: (1) cycle time from contract receipt to approved output, (2) error rate (misclassified clauses, missed red flags), (3) human review time per document, and (4) first-response time on customer tickets. Compare these metrics against the baseline from step 1. The pilot is successful if cycle time drops by at least 40% and error rate stays below 5%. If the error rate exceeds 5%, pause the pilot, review the AI’s reasoning logs, and adjust the system prompt or the compliance checklist in Confluence. Do not scale to other workflows until the pilot meets the success criteria. Document the results in a one-page report for the board.

    Step 5: Scale to a Second Workflow and Hand Over to Managed Operations

    Once the pilot meets the success criteria, expand to a second workflow. For a fintech, the natural next step is invoice processing: the AI extracts invoice data (vendor, amount, due date, tax ID) from PDFs, validates it against the PO in the ERP, and flags discrepancies. The back-office staff approves or rejects each invoice. The AI does not pay the invoice. Use the same orchestration tool and the same Claude API model. The knowledge base in Confluence now includes invoice templates and vendor master data. The human-in-the-loop approval workflow is identical to the contract review pilot. Measure the same four metrics. Target: 50% reduction in manual data entry time and a 30% reduction in invoice processing cycle time.

  • Six Ways Forfis Automates Ticket Triage for Swiss Fintechs in a 3-Month Sprint

    1. Triage eats senior hours that should go to disputes

    A 2,000-employee payments firm in Zurich runs Zendesk as its primary helpdesk. Senior agents spend 40% of their day re-routing misclassified tickets and drafting first responses that follow the same template every time. The process audit identifies ticket triage and routing as the highest-impact workflow: 12,000 tickets per month, a median cycle time of 4.2 hours from receipt to first response, and a 14% error rate on routing. The AI layer classifies by intent, urgency, and department, then routes to the correct queue. After the pilot, median cycle time drops to 38 minutes and routing errors fall to 2.1%. The senior agents who previously handled triage now focus on complex disputes and fraud escalations, work that actually requires their judgment. The 3-month sprint covers audit, pilot, and rollout, with every decision logged for ISO 27001 audit trails.

    2. Workflow orchestration, not a chatbot wrapper

    The orchestration layer sits between Zendesk’s API and the model inference endpoint. Incoming tickets trigger a webhook that passes the ticket body, metadata, and customer history to the classifier. The model returns a structured JSON object with intent, urgency score, and recommended queue. The orchestrator validates the output against a schema, checks confidence thresholds, and routes the ticket accordingly. If confidence falls below 0.85, the ticket flags for human review. Every step logs a timestamp, model version, and input hash. This architecture means the client can swap the classifier model without touching the Zendesk integration or the routing logic. The orchestration layer is the stable contract; the model is a pluggable component.

    3. On-premise open-weight models keep regulated data local

    Swiss data protection law and the client’s ISO 27001 certification require that customer payment data never leaves the building. Forfis deploys an open-weight model on the client’s own GPU cluster, handling all ticket payloads that contain account numbers, transaction IDs, or personal identifiers. The model runs on-premise, so no regulated data crosses a network boundary. For non-sensitive workflows, such as routing a general FAQ ticket, the orchestrator can route to a cloud API where latency and cost are less critical. The model-agnostic design means the client chooses the model per workflow, not per project. This split keeps the ISO 27001 statement of applicability clean: the on-premise path satisfies Annex A.8.22 (use of cryptography) and A.8.15 (access control) without requiring a separate risk assessment for cloud data transfer.

    4. A 3-month sprint with a measured before/after baseline

    The pilot runs on one workflow for six weeks. The baseline is measured in the first two weeks: 12,000 tickets, 4.2-hour median cycle time, 14% routing error rate. The AI layer goes live in week three, handling triage and routing with human approval on any ticket flagged below the confidence threshold. By week six, the metrics show a 38-minute median cycle time and a 2.1% error rate. The before/after comparison is documented in a one-page report that the client’s CFO uses to justify the rollout budget. The pilot also surfaces edge cases: 3% of tickets contain multilingual content that the model misclassifies, prompting a fine-tuning pass before full rollout. This measured approach means the client sees ROI before committing to broader automation across invoice processing or document extraction.

    5. Human-in-the-loop by default, not as an afterthought

    The AI layer classifies and routes, but a human approves any action that touches money, health data, or a contract. In a payments context, this means the model drafts a refund response or flags a fraud-related ticket, but a senior agent signs off before the action executes. The approval threshold is not arbitrary; it is set based on the pilot’s error-rate data. If the model’s routing accuracy on fraud-related tickets is 97%, the human-in-the-loop threshold applies to that subset. For general FAQ tickets where accuracy is 99.5%, the system can auto-route without approval. This tiered approach frees senior staff from routine work while keeping them in the loop for high-stakes decisions. The approval log feeds directly into the ISO 27001 audit trail, showing who approved what and when.

    6. Plugs into Zendesk or Intercom without replacing them

    The integration sprint adds a new processing layer on top of the existing Zendesk or Intercom instance. No data migration is required; the AI layer reads tickets through the helpdesk’s native API and writes routing decisions back through the same API. The client’s existing workflows, SLAs, and reporting dashboards continue to function unchanged. The orchestration layer exposes a REST API that the helpdesk calls, so the integration is a few lines of configuration in Zendesk’s webhook settings. This means the client does not need to retrain agents on a new interface or rebuild their ticket taxonomy. The AI layer is invisible to the end customer; it simply makes the existing system faster and more accurate. The 3-month timeline includes two weeks of integration hardening after the pilot, where edge cases from the pilot are addressed and the system is stress-tested under production load.