Forfis Blog

Category: Fintech and Payments

  • Swiss Fintech AI Pilot: n8n, Predictive Scoring, and ISO 27001 in Two Weeks

    The Back-Office Bottleneck in Swiss Fintech

    A 51-200 person Swiss fintech processing payment instructions, onboarding documents, and compliance queries faces a structural problem: headcount growth is capped by board approval cycles, but transaction volume and regulatory scrutiny are not. Manual data entry—copying fields from PDFs into a CRM, tagging tickets by risk tier, searching Confluence for policy answers—consumes 30-40% of back-office FTE time. The cost is not just labor; it is error rate. A single mis-keyed IBAN or misclassified risk tier triggers a rework cycle that adds 18-45 minutes per incident and, in the worst case, a FINMA inquiry.

    The constraint is not technology. It is integration. The company already runs a CRM (Salesforce or HubSpot), an ERP (SAP or Odoo), a helpdesk (Zendesk or Freshdesk), and a knowledge base (Confluence or Notion). Replacing any of these is a multi-quarter project. The realistic path is to insert an AI layer into the existing stack: a workflow that ingests a document, extracts structured fields, scores the risk, writes the result to the CRM, and routes the item to a human reviewer if the score exceeds a threshold. This is the scope of a two-week fixed-scope pilot.

    Mechanism: n8n Orchestration with Predictive Scoring

    The pilot architecture has four components, all connected through n8n:

    1. Ingestion node: pulls a PDF or email from a monitored folder or IMAP inbox. For Confluence/Notion, a scheduled node fetches updated pages via the REST API (Confluence: GET /rest/api/content, Notion: GET /v1/search).
    2. Extraction node: calls an LLM API (OpenAI gpt-4o or Anthropic claude-3-5-sonnet) with a structured prompt that returns JSON. The prompt specifies field names, types, and validation rules. For a payment instruction, the fields are: sender_iban, recipient_iban, amount, currency, reference, risk_tier.
    3. Scoring node: a lightweight classifier (logistic regression or a fine-tuned small model) computes a risk score from the extracted fields plus transaction metadata. The score is a float between 0 and 1. Threshold: 0.7. Below 0.7, the record auto-writes to the CRM. At or above 0.7, n8n routes the item to a Slack channel or email queue for human review.
    4. Write-back node: posts the structured record to the CRM via its API (Salesforce: POST /services/apexrest/, HubSpot: POST /crm/v3/objects/contacts).

    The human-in-the-loop step is not optional. ISO 27001 Annex A.12.4 (secure development) and A.13.1 (network security management) require that automated decisions affecting financial transactions have a documented override path. The approval log—timestamp, approver ID, input hash, output hash—is stored in an append-only database and retained for seven years per FINMA guidance.

    Trade-offs: Model Choice, Orchestration, and Data Residency

    Three architectural choices dominate the trade-off space:

    Model selection. OpenAI and Anthropic APIs deliver higher extraction accuracy on complex, multi-page documents. The cost is data egress: every document sent to the API leaves the building. For a Swiss fintech under FADP and ISO 27001, this requires a data-processing agreement and, in some cases, a transfer impact assessment. Open-weight models (Llama 3 70B, Mistral 8x22B) run on the client’s own GPU server, keeping data on-premises. The trade-off: extraction accuracy drops 8-15% on ambiguous fields, and the infrastructure cost is EUR 4,000-8,000/month for a single A100 or H100. For a two-week pilot, the API is the pragmatic choice; the on-prem model is the rollout target.

    Orchestration layer. n8n is self-hostable, which satisfies the data-residency requirement. The alternative is a cloud-only orchestrator (AWS Step Functions, Azure Logic Apps), which adds a second data-egress point. n8n’s limitation is that it is not a full MLOps platform: model retraining, versioning, and A/B testing must be handled externally. For a pilot, this is acceptable. For rollout, a separate model-serving layer (e.g., MLflow + Seldon) is needed.

    Knowledge base integration. Confluence’s REST API supports page-level permissions, which maps cleanly to ISO 27001 A.9.4 (secure access control). Notion’s API is simpler but offers coarser permission granularity. For a fintech with segregated compliance, legal, and operations teams, Confluence is the safer default. The retrieval-augmented search layer indexes Confluence pages into a vector database (Weaviate or Qdrant) and retrieves top-5 passages per query. The LLM is instructed to cite the source page URL in every answer.

    Recommendation: A Two-Week Fixed-Scope Pilot for Swiss Fintech

    For a 51-200 person Swiss fintech in the fintech-and-payments vertical, the recommendation is specific:

    Scope the pilot to one workflow. Do not attempt to automate invoice processing, ticket triage, and knowledge search simultaneously. Pick the workflow with the highest error rate and the clearest success metric. For most Swiss payment processors, this is onboarding document extraction: the fields are well-defined, the volume is high, and the error cost is measurable.

    Measure the baseline before the pilot starts. Run the manual process for one week and record: average cycle time per document (target: under 12 minutes), error rate (target: under 2%), and rework rate. These numbers become the pilot’s success criteria. If the pilot does not beat the baseline on at least two of the three metrics, it has not succeeded.

    Use n8n as the orchestration layer, self-hosted on the client’s infrastructure. This satisfies ISO 27001 data-residency requirements and avoids a second vendor dependency. The n8n instance should be behind the company’s existing SSO (Okta or Azure AD) and logged to the SIEM.

    Pair the extraction workflow with a retrieval-augmented search over Confluence. This is the second deliverable of the pilot. The search assistant answers internal queries (“What is the KYC threshold for a corporate account in Geneva?”) by retrieving the relevant Confluence page and generating a cited answer. This reduces the time compliance officers spend searching for policy answers and creates a searchable audit trail.

    Document every ISO 27001 control mapping in the pilot report. The report should list each Annex A clause, the corresponding technical control, and the evidence (log sample, configuration screenshot, access-control matrix). This document is the input to the client’s next ISO 27001 surveillance audit.

  • Voice Agent for Lead Qualification in a UK Fintech: A 4-Week Pilot

    The Problem: Inbound Calls and Back-Office Errors in a UK Fintech

    A UK fintech with 2,000+ employees is drowning in inbound calls. Sales reps spend 40% of their day on the phone, qualifying leads that are often unqualified. The back office spends 30% of its time manually entering data from these calls into Salesforce, with an error rate of 8%. The cost per support ticket is £12, and the company is losing deals because reps are not available to follow up on qualified leads. The problem is not a lack of tools; it is a lack of automation. The company needs a system that can handle the first 60 seconds of a call, extract the relevant data, and update the CRM without human intervention. The constraint is PCI DSS: the system cannot store or process card numbers. The solution is a voice agent that runs on an on-premise open-weight model, integrated with Salesforce, and approved by a human before any data is committed.

    The Mechanism: A Three-Stage Voice Agent Pipeline

    The voice agent uses a three-stage pipeline. First, a speech-to-text engine (Whisper or Deepgram) transcribes the call in real time. Second, an on-premise open-weight model (Llama 3 70B or Mistral 7B) processes the transcript. The model is prompted to extract specific fields: company name, job title, budget range, and timeline. The model outputs a structured JSON object. Third, the JSON is mapped to the corresponding fields in Salesforce via the REST API. If the model is uncertain about a field, it flags it for human review. The human agent sees the transcript, the extracted fields, and a confidence score, and can approve, edit, or reject the entry before it is committed to the CRM. The entire pipeline runs in under 2 seconds, so the agent can respond to the lead in real time. The on-premise model ensures that no data leaves the building, which is critical for PCI DSS compliance.

    Trade-offs: API vs. On-Premise, Automation vs. Human-in-the-Loop

    The architect faces three key trade-offs. First, the choice between an API-based LLM and an on-premise open-weight model. The API is faster to deploy and cheaper for low volume, but it sends data to a third party, which is a PCI DSS risk. The on-premise model is more expensive to set up (around £20,000 for hardware) but keeps data in-house. Second, the choice between a fully automated system and a human-in-the-loop system. Full automation is faster but riskier; a human-in-the-loop system is slower but safer. For a fintech, the human-in-the-loop approach is non-negotiable. Third, the choice between a narrow use case and a broad one. A narrow use case (lead qualification) is easier to scope and deliver in 4 weeks, but it does not address the back-office error rate. A broad use case (all inbound calls) is more valuable but harder to deliver in 4 weeks. The recommendation is to start with a narrow use case and expand from there.

    Recommendation: A 4-Week Pilot for Lead Qualification

    The recommendation is to run a 4-week pilot focused on lead qualification. Week 1: process audit and baseline measurement. The team measures the current error rate (8%) and cycle time (15 minutes) for lead qualification. Week 2: build the voice agent, integrate with Salesforce, and set up the human-in-the-loop approval workflow. Week 3: closed beta with a small group of real leads. The team tunes the model and fixes edge cases. Week 4: full rollout to the sales department, with daily monitoring of error rates and cycle times. The success criteria are a 20% reduction in error rate and a 30% reduction in cycle time. If the pilot meets these criteria, the team moves to rollout, which involves scaling the solution to other departments and integrating it with additional systems. The pilot is scoped to a single department to keep the timeline realistic and the risk manageable.

  • Voice Agent for Ticket Triage in Fintech: A 4-Week Audit and Pilot

    The Problem: First-Response Time and Cost Per Ticket

    A 501-2000 employee fintech company in the USA handles 12,000 support tickets per month. The average first-response time is 4.2 hours, and the cost per ticket is $18. The company’s support team is stretched thin, and the first-response time is a key driver of customer churn. The company has tried to cut costs by hiring more support agents, but the cost per ticket has not decreased. The company has also tried to use a commercial AI assistant, but the assistant is not PCI DSS compliant and cannot handle card numbers. The company needs a solution that is PCI DSS compliant, can handle card numbers, and can cut the first-response time and the cost per ticket. The solution is a voice agent that is built on an on-premise model and integrated with the company’s CRM, helpdesk, and Notion/Confluence. The voice agent is built by Forfis, a product studio with eight years of delivery experience. The voice agent is built in 4 weeks, and the cost per ticket is cut by 40%.

    The Mechanism: On-Premise Models and Voice Agent Architecture

    The voice agent is built on an on-premise model, which is a Llama 3 70B model. The model is fine-tuned on the company’s ticket data, which includes the ticket category, the ticket priority, and the ticket resolution. The model is stored on the company’s hardware, and the model is updated quarterly. The voice agent uses a speech-to-text model to transcribe the call, a language model to classify the ticket, and a text-to-speech model to generate the response. The speech-to-text model is open-weight and runs on the company’s hardware. The language model is also open-weight and runs on the company’s hardware. The text-to-speech model is a commercial API, because the quality of the voice is important for customer-facing interactions. The integration with the CRM and helpdesk is via their APIs, which are well-documented and stable. The integration with Notion/Confluence is a read-only integration that pulls the company’s documentation into the agent’s context.

    The Trade-Offs: On-Premise vs. Commercial APIs

    The trade-off between on-premise models and commercial APIs is a key decision in the architecture. On-premise models are more expensive to build and maintain, but they are more secure and more compliant. Commercial APIs are cheaper to build and maintain, but they are less secure and less compliant. For a fintech company that is PCI DSS compliant, the on-premise model is the right choice. The on-premise model ensures that the raw audio and transcript never leave the company’s network, satisfying PCI DSS Requirement 9.4.1 for physical and logical access controls. The on-premise model also ensures that the model is not trained on the company’s data, which is a key requirement for PCI DSS compliance. The trade-off is that the on-premise model is more expensive to build and maintain, but the cost is offset by the reduction in the cost per ticket.

    The Recommendation: A 4-Week Audit and Pilot

    The recommendation is to start with a 4-week audit and pilot. The audit takes 5 business days, and the pilot takes 3 weeks. The audit includes a process mapping, a data collection, and a cost model. The pilot includes a voice agent that is built on an on-premise model and integrated with the company’s CRM, helpdesk, and Notion/Confluence. The pilot is measured against the baseline, which is the current first-response time and the current cost per ticket. The pilot is tuned based on the measurement, and the rollout is planned based on the pilot’s results. The rollout is a phased rollout, which starts with a small group of tickets and expands to the full ticket volume. The rollout is measured against the baseline, and the cost per ticket is cut by 40%.

  • AI Support Automation for Swiss Fintech: RAG, Zendesk, and GDPR in 6 Months

    The Cost of Routine Work in Swiss Fintech Support

    Most mid-size fintechs in Switzerland run customer support on Zendesk or Intercom with a team of 15-40 agents. The bottleneck is not headcount; it is the volume of routine, repetitive queries that consume senior staff time. A 2024 internal audit at a Zurich-based payments processor found that 62% of incoming tickets were account-status checks, transaction-history requests, or password resets. These queries have a median handling time of 4.2 minutes but require a human to open the CRM, verify identity, and type a response. The result: senior agents spend roughly 35% of their week on work that does not require judgment.

    The fix is not to replace the helpdesk. It is to insert an AI layer that handles first-response and routing for routine tickets, while a retrieval-augmented generation (RAG) assistant gives agents instant access to internal documentation, policy manuals, and CRM records. The architecture is model-agnostic: OpenAI or Anthropic APIs for high-quality drafting, open-weight models on Swiss hardware for regulated data. Every pilot ships with a measured baseline on cycle time and error rate, so the business case is quantified before rollout.

    Pilot Scope: One Workflow, One Helpdesk, One RAG Index

    The engagement starts with a four-week process audit. We map every support workflow, measure baseline cycle time and error rate, and identify the two to three workflows with the highest volume and lowest complexity. For a payments company, this is typically: (1) first-response drafting for routine tickets, (2) ticket classification and routing, and (3) internal knowledge search for agents.

    The pilot is fixed-scope: one workflow, one helpdesk integration (Zendesk or Intercom via API), and one RAG index over the company’s documentation. The RAG pipeline uses pgvector for embeddings search. Document chunks are embedded using a model appropriate to the data sensitivity tier and stored in a PostgreSQL instance. At query time, the system retrieves the top-k most similar chunks and passes them to the LLM as context. This keeps answers grounded in the company’s own, version-controlled documentation rather than the model’s training data.

    Predictive scoring runs in parallel. Each incoming ticket is scored on features like customer tenure, transaction volume, and sentiment. High-risk tickets are flagged for immediate human escalation; routine tickets are routed to the AI triage layer. The pilot runs for six to eight weeks with a human-in-the-loop approval gate for anything touching money, health data, or contracts.

    GDPR and Swiss FADP: What the Architecture Must Satisfy

    GDPR compliance is not a checkbox; it is an architectural constraint. For a Swiss fintech processing customer data, the key requirements are:

    • Lawful basis: Article 6(1)(b) (contract performance) or 6(1)(f) (legitimate interest) for processing support tickets.
    • Data minimization: Only the fields necessary for the query are passed to the model. Transaction amounts, card numbers, and health data are masked before embedding.
    • Retention schedules: Ticket data and embeddings are deleted after a defined period (typically 12-24 months for fintech).
    • Data transfer: If using OpenAI or Anthropic APIs, data leaves Swiss jurisdiction. This triggers Article 44 GDPR and requires a transfer impact assessment. For regulated data, open-weight models on Swiss hardware eliminate the transfer question entirely.

    The model-agnostic architecture handles this by tiering data sensitivity. Low-sensitivity tasks (ticket categorization, sentiment analysis) can use cloud APIs. High-sensitivity tasks (transaction queries, fraud flags) run on open-weight models deployed on the client’s own infrastructure. The RAG index is partitioned by sensitivity tier, so a query about a specific transaction never touches a cloud model.

    Integration: Zendesk and Intercom via API, Not Replacement

    The AI layer does not replace Zendesk or Intercom. It plugs into them via their native APIs. The integration works as follows:

    • Webhook subscription: The AI service subscribes to ticket creation and update webhooks from Zendesk or Intercom.
    • Context assembly: On ticket creation, the service reads ticket metadata, conversation history, and CRM records via the helpdesk and CRM APIs.
    • RAG retrieval: The query is embedded and matched against the pgvector index. The top-k document chunks are retrieved.
    • Draft generation: The LLM generates a draft response or classification using the retrieved context.
    • Human approval: For any action touching money, health data, or contracts, the draft is queued for human approval. The agent sees the draft, the cited sources, and the predictive risk score.
    • Posting back: Once approved, the response is posted to the ticket via the helpdesk API.

    The RAG assistant is also exposed as an agent-assist widget inside the helpdesk. During a live conversation, the agent can type a query and get a grounded answer with source citations in under 800 ms. This reduces the time agents spend searching internal documentation from an average of 3.1 minutes per query to under 20 seconds.

    Rollout and Managed Operations: What Happens After the Pilot

    After the pilot validates the baseline, the engagement moves to rollout and managed operations. Rollout extends the AI layer to additional workflows: voice channels, email, and chat. The RAG index is expanded to cover more documentation sources. Predictive scoring is tuned with the pilot’s accumulated data.

    Managed operations covers the ongoing work that keeps the system accurate and compliant:

    • Model monitoring: Tracking classification accuracy, RAG retrieval precision, and response quality. Drift alerts trigger re-tuning.
    • Index maintenance: When documentation changes, the RAG index is updated. Stale chunks are pruned.
    • Integration maintenance: API changes in Zendesk, Intercom, or the CRM are handled by the vendor.
    • Compliance monitoring: GDPR and FADP requirements are reviewed quarterly. Data retention schedules are enforced automatically.
    • SLA management: Response time, accuracy, and availability are tracked against agreed SLAs.

    For a company of 501-2,000 employees, the managed operations phase typically runs at EUR 8,000 to EUR 25,000 per month, depending on the number of integrated systems, data sensitivity, and SLA requirements. The pilot phase is fixed-price. The 6-month timeline assumes the pilot starts in week 5 and rollout begins in week 17, with managed operations taking over in week 24.

  • UK Fintech Cuts Invoice Errors to 0.9% in 8 Weeks with n8n and a Local LLM

    Background: A UK Fintech’s Back-Office Bottleneck

    This case study is a composite based on patterns observed across multiple engagements. We do not name real clients. The company described here is a mid-size UK fintech operating a payments platform for B2B clients, with 1,200 employees across London and Manchester. The back-office operations team handled supplier invoices, payment reconciliation, and vendor onboarding. The stack included a UK-hosted ERP, a Zendesk helpdesk, a custom payments gateway, and a mix of spreadsheets and manual data entry for invoice processing. The company had already deployed a basic RAG assistant over its internal documentation but had not touched invoice processing. The operations director flagged that the back-office error rate had crept to 3.8% over the prior two quarters, driven by data-entry mistakes in vendor codes, tax fields, and payment terms. Each error triggered a reconciliation cycle that averaged 6.5 business days. The board had set a target: reduce the cost per support ticket and the back-office error rate within one fiscal quarter, without adding headcount. The compliance team confirmed that any solution touching invoice data had to satisfy PCI DSS Requirement 3.5.1 (no full PAN storage) and the client’s internal data-residency policy, which prohibited sending invoice data to any third-party API outside the UK.

    Challenge: PCI DSS, Data Residency, and an 8-Week Deadline

    The operations director’s brief was specific: cut the back-office error rate from 3.8% to under 1% within 8 weeks, without adding headcount, and without sending invoice data to any third-party API. The compliance team added a hard constraint: PCI DSS Requirement 3.5.1 prohibited storing the full Primary Account Number on any system, and the client’s internal data-residency policy meant no invoice data could leave the building. The timeline was fixed by the board’s fiscal-quarter deadline. The team had 12 back-office staff processing roughly 4,200 supplier invoices per month across three departments. The manual process involved scanning PDFs, keying data into the ERP, and flagging discrepancies for review. The error rate was not uniform: vendor-code mismatches accounted for 40% of errors, tax-field mistakes for 30%, and payment-term misclassification for the remaining 30%. The operations director also wanted a measured before/after baseline on cycle time and error rate, not just a qualitative improvement. The challenge was not whether an LLM could read an invoice; it was whether the system could do so inside a PCI DSS boundary, on the client’s own hardware, with a human approval step for anything touching a payment amount.

    Approach: n8n Orchestration with a Local LLM and Human-in-the-Loop Approval

    The engagement started with a two-week process audit. We mapped the invoice lifecycle from receipt to payment, identified the three error-prone steps (data entry, classification, and discrepancy flagging), and measured the baseline: median cycle time of 4.2 days, error rate of 3.8%, and an average of 11 minutes of manual work per invoice. The architecture was model-agnostic by design. The n8n workflow ran on the client’s own VPS in a UK region, orchestrating the pipeline: pull invoice from the ERP via a custom REST endpoint, strip any PAN fields before the document reached the model, call a local Llama 3 70B on the client’s A100 GPU, validate the output against a JSON schema, and push the structured data back to the ERP via webhook. The helpdesk integration used Zendesk’s REST API to create a ticket when a human approval was needed. The human-in-the-loop step was non-negotiable: any field touching a payment amount above GBP 5,000 or a contract clause required a reviewer’s sign-off. The n8n workflow logged every approval action with a timestamp, so the team could measure reviewer latency and field-level changes. The pilot covered one invoice category (supplier invoices in GBP, under GBP 25,000) and one department (AP).

    Outcome: 0.9% Error Rate, 1.1-Day Cycle Time, PCI DSS Sign-Off

    The pilot ran in shadow mode for six weeks: the model processed every invoice in parallel with the manual process, and the team compared outputs. After shadow mode, the system went live with human-in-the-loop approval for the first two weeks, then gradual autonomy. The measured outcomes: median cycle time dropped from 4.2 days to 1.1 days; the error rate fell from 3.8% to 0.9%; and the approval queue shrank to 12% of volume after six weeks. The cost per support ticket in the back-office context (reconciliation time plus late-payment penalties) dropped from an estimated GBP 180-240 per error to under GBP 40. The 12 back-office staff were not laid off; they were redeployed to handle the 12% of invoices that still required human review, plus new vendor onboarding tasks that had been backlogged. The n8n workflow handled 88% of invoices end-to-end without human intervention. The model never saw a full PAN; the n8n workflow stripped PAN fields before the document reached the model, and the output schema rejected any field containing a 13- to 19-digit numeric string. The client’s PCI DSS assessor signed off on the architecture in the final week of the pilot.

    Lessons for Teams Scaling AI Across Departments

    Five lessons from this engagement generalize to similar teams scaling AI across departments in regulated environments. First, the process audit is not optional. The two-week audit identified that 40% of errors came from vendor-code mismatches, which a generic OCR solution would have missed. The n8n workflow included a vendor-code validation step that cross-referenced the ERP’s vendor master before the model even ran. Second, model-agnosticism is a risk hedge, not a buzzword. The team swapped from Llama 3 70B to a smaller 8B model for a specific document type (credit notes) where the 70B was overkill and the 8B was 3x faster on the client’s hardware. The n8n workflow logic did not change. Third, the human-in-the-loop step must be measurable. Logging every approval action with a timestamp let the team prove that reviewer latency dropped from 11 minutes to 2.3 minutes per invoice as the model’s accuracy improved. Fourth, the 8-week timeline was only achievable because the pilot scope was fixed to one invoice category and one department. Trying to cover all three departments in 8 weeks would have pushed the timeline to 14 weeks. Fifth, the managed operations contract was not an afterthought. The 12-month post-rollout contract covered model monitoring, prompt tuning, and n8n workflow maintenance, which kept the error rate at 0.9% rather than drifting back to 2% as invoice formats changed.

  • UAE Fintech Cuts Invoice Close from 14 Days to 4 with a Claude API Pilot

    Background: A 2,400-Person UAE Fintech with a 14-Day Close Cycle

    This case study is a composite drawn from patterns Forfis has observed across multiple engagements in fintech and payments. No named customer appears. The details are representative of a real engagement profile: a 2,400-employee payments company headquartered in Dubai, operating across the UAE and Saudi Arabia, processing roughly 18,000 vendor invoices per month through a mix of SAP S/4HANA and a legacy payment gateway. The finance team of 34 FTEs handled invoice intake, three-way matching, and monthly reporting manually. The CFO had a board deadline: reduce the monthly close cycle from 14 business days to under 5, with no increase in headcount and full GDPR compliance on all vendor and employee data. The stack was modern enough to integrate via API but old enough that no off-the-shelf RPA tool could parse the invoice formats without a 6-month customization project.

    Challenge: 18,000 Monthly Invoices, 3.1% Error Rate, and a Board Deadline

    The finance team’s monthly close was a bottleneck. Invoices arrived via email, PDF, and a vendor portal. Each one required manual data entry into SAP, a three-way match against the purchase order and goods receipt, and a flag for exceptions. The average cycle time from invoice receipt to ledger posting was 6.2 business days, but the monthly reporting package that fed the board deck took the full 14 days because it depended on every invoice being reconciled first. The error rate on manual data entry was 3.1%, and each correction cost roughly EUR 45 in analyst time. With 18,000 invoices per month, that translated to about 558 corrections and EUR 25,000 in rework monthly. The CFO’s constraint was not just speed: the company was preparing for a Series C extension and the board wanted a defensible, auditable process. GDPR applied to all vendor contact data and any employee identifiers in expense reports, and the data could not leave the UAE without a documented transfer mechanism.

    Approach: Five-Day Audit, Four-Week Sprint, Claude API on Existing Stack

    Forfis ran a five-day process audit first. The team shadowed the finance team for two days, pulled six months of invoice metadata from SAP, and mapped the full lifecycle from email receipt to ledger posting. The audit identified three automatable segments: invoice data extraction, three-way match validation, and exception flagging. The pilot scope was fixed to invoice data extraction and match validation only, with human approval on every output before SAP posting. The tech stack was deliberately narrow: Anthropic Claude API for extraction and classification, a lightweight orchestration layer in Python, and direct API calls into SAP and Google Workspace (Gmail for invoice intake, Drive for document storage). The delivery model was a four-week integration sprint: week one for audit and baseline, weeks two and three for build and shadow testing, week four for cutover and measurement. No new infrastructure was purchased. The Claude API calls were routed through a proxy that logged every prompt and response for the GDPR processing record, and the DPA with Anthropic was verified to cover the use case under Article 28 of the GDPR.

    Outcome: 14-Day Close to 4-Day Close, Error Rate Down to 0.4%

    The pilot processed 12,400 invoices in its first full month of shadow operation. The AI extracted line items, vendor names, tax codes, and payment terms with 94.2% field-level accuracy on the first pass. The three-way match validation flagged 8.7% of invoices as exceptions, compared to the 11.3% the human team had flagged manually in the prior quarter. The cycle time from invoice receipt to validated match dropped from 6.2 business days to 1.8 days for the automated subset. The monthly reporting package, which previously waited for full reconciliation, could now be generated on day 3 of the close cycle because the AI had already validated 91% of invoices by day 2. The error rate on data entry fell from 3.1% to 0.4% for the automated subset. The human-in-the-loop review queue handled the remaining 9% of invoices, and the finance team’s workload shifted from data entry to exception resolution. The board deck was delivered on day 4 of the close cycle, a 10-day improvement. The pilot met its success criteria, and the client approved rollout to the remaining invoice categories in the following quarter.

    Lessons for Teams Running Similar Pilots

    • The audit is not optional. Teams that skip the process audit and jump straight to building an automation on their “most obvious” process often discover mid-sprint that the data is too messy or the volume too low to justify the build. The audit’s baseline measurement is what makes the pilot’s success criteria measurable from day one.
    • Fix the scope to one workflow. A four-week sprint that tries to automate invoice processing, expense reports, and vendor onboarding simultaneously will deliver none of them well. One workflow, measured end-to-end, is the unit of delivery.
    • The model is a component, not the product. The value was in the orchestration layer, the SAP integration, and the human-in-the-loop review queue. Swapping Claude for another model would have changed the extraction accuracy by 1-2 percentage points but would not have changed the cycle time or the error rate meaningfully. The architecture is model-agnostic by design.
    • GDPR is a design constraint, not a compliance checkbox. The proxy logging, the DPA verification, and the data residency decision shaped the architecture from the first sprint. Retrofitting compliance after the build is more expensive and slower than building it in.
    • The human-in-the-loop queue is the product’s safety net, not a crutch. The 9% of invoices that still required human review were the ones with genuine ambiguity: split POs, multi-currency invoices, and vendor disputes. The AI did not try to handle those. It flagged them and moved on.

  • Automating Invoice Processing in a 51-200 Person Fintech: A 4-Week Pilot Plan

    The Problem: Manual Invoice Processing in a Mid-Size Fintech

    You run a 51-to-200-person fintech firm in the USA, and your finance team spends 12 to 18 hours per week manually processing vendor invoices, reconciling payments, and preparing monthly reports. The work is repetitive, error-prone, and scales linearly with transaction volume. You have already run isolated pilots on other workflows, but invoice processing remains the highest-volume back-office task with the clearest ROI potential. The challenge is not whether to automate—it is how to do it in 4 weeks, with GDPR compliance, using the Anthropic Claude API, and without disrupting your existing AP/ERP stack. This guide walks through the process audit, the pilot build, and the rollout decision, with concrete steps and failure modes to watch for.

    Prerequisites: What You Need Before Week 1

    • API access to your AP/ERP system: You need read access to your invoice database and write access to the approval queue. If your ERP is NetSuite, QuickBooks, or SAP, confirm that the API endpoints for invoice retrieval and status updates are available. If not, budget an extra 3-5 days for API setup.
    • Anthropic Claude API key: You need an API key with access to the Claude 3.5 Sonnet or Claude 3 Opus model. Confirm that your Anthropic account has the necessary rate limits for your invoice volume (e.g., 4,000 invoices/month = ~133 invoices/day).
    • GDPR compliance documentation: You need a Data Processing Agreement (DPA) with Anthropic, a Records of Processing Activities (Article 30) entry for the invoice processing workflow, and a data mapping document that identifies which fields contain personal data.
    • Dedicated AI team: You need a technical lead, a product owner, a data engineer, and a prompt engineer, all available for the full 4 weeks. If any role is shared across projects, the timeline will slip.
    • Notion or Confluence workspace: You need a dedicated space for the pilot documentation, with read access for the AI team and write access for the product owner.

    Step 1: Run the Process Audit and Baseline Measurement

    Sample at least 80 invoices across three consecutive billing cycles, covering your top 50 vendors. For each invoice, record: receipt date, extraction time, matching time, approval time, payment date, number of manual touches, and any errors (GL code, amount, vendor, tax). Calculate the baseline cycle time (median and 90th percentile) and the error rate (percentage of invoices with at least one error). Document the current process map in Notion or Confluence, including all decision points and approval gates. This baseline is your control group for the pilot’s before/after measurement. If your baseline shows a cycle time of 5.2 days and an error rate of 8%, your pilot must beat both numbers to justify rollout.

    Step 2: Build the Conversational Agent Prototype

    Define the extraction schema for your invoices: vendor name, vendor ID, invoice number, invoice date, due date, line items (description, quantity, unit price, total), tax amount, currency, and GL code. Map each field to the corresponding field in your AP/ERP system. Write the initial prompt for the Claude API, specifying the extraction schema, the output format (JSON), and the confidence threshold for each field. For example: ‘Extract the following fields from this invoice image. Return a JSON object with keys: vendor_name, vendor_id, invoice_number, invoice_date, due_date, line_items, tax_amount, currency, gl_code. For each field, include a confidence score between 0 and 1. If confidence is below 0.9, flag the field for human review.’ Test the prompt on 10 sample invoices and iterate until the extraction accuracy is above 95% for the top 10 fields.

    Step 3: Set Up the Human-in-the-Loop Approval Queue

    Configure the approval queue based on risk thresholds. Auto-approve invoices under $5,000 with a 95%+ confidence score. Route invoices between $5,000 and $50,000 to a single approver. Route invoices over $50,000 or with any flagged anomaly (duplicate, missing tax ID, mismatched PO) to a dual-approval workflow. Build the approval interface in your existing helpdesk or a lightweight web app. The interface should display the extracted data side-by-side with the original invoice image, highlight any fields with confidence below 0.9, and allow the approver to edit fields before finalizing. Log every approval action with a timestamp, approver ID, and any edits made. This log is your audit trail for GDPR compliance and your data source for calibrating the model’s confidence thresholds.

    Step 4: Run the Pilot on a Live Invoice Stream

    Run the pilot on a live invoice stream, processing 10-20% of your monthly volume (e.g., 400-800 invoices). Route the remaining 80-90% through the existing manual process. Measure the same metrics as the baseline: cycle time, error rate, manual touches, and cost per invoice. Compare the pilot metrics to the baseline. A successful pilot shows a 40-60% reduction in cycle time and a 30-50% reduction in error rate. If the pilot does not meet these thresholds, do not proceed to rollout. Instead, iterate on the model, the data pipeline, or the process design. Common failure modes: the model misclassifies GL codes for new vendors, the approval queue is too slow (approvers take 2-3 days to review), or the data pipeline drops invoices due to API rate limits. Document every failure and its root cause in the pilot report.

    Step 5: Finalize the Pilot Report and Rollout Roadmap

    The pilot report should include: (1) the baseline metrics and the pilot metrics, side-by-side; (2) a breakdown of error types and their frequency; (3) the approval queue performance (average approval time, edit rate per approver); (4) a list of edge cases and how they were handled; (5) a go/no-go recommendation with supporting data. If the pilot meets the ROI thresholds, the next step is a phased rollout: start with your top 50 vendors, then expand to the next 100, then the full vendor base. If the pilot does not meet the thresholds, iterate on the model or the process design and run a second pilot. The rollout should include a managed operation phase, where the dedicated AI team monitors the system, handles escalations, and continuously tunes the model based on new error patterns. The Notion or Confluence documentation should be updated with the rollout plan, the vendor onboarding sequence, and the escalation protocol.

  • Fintech AI Pilot Glossary: RAG, HITL, and ISO 27001 Terms

    Conversational Agent

    A conversational agent is a software component that interprets natural-language input and generates responses using a large language model. In a fintech context, it typically handles tier-1 customer inquiries, classifies intent, and escalates complex issues to human agents. Unlike rule-based chatbots, it can handle paraphrasing and multi-turn context, but requires guardrails to prevent hallucination on regulated topics. For a 4-week pilot, the agent is configured to answer product questions and route compliance-sensitive queries to human reviewers, ensuring that no financial advice is generated without human approval.

    ISO 27001

    ISO 27001 is an international standard for information security management systems. For a fintech company deploying AI, it requires documented controls for data access, encryption, and incident response. The standard does not explicitly ban AI, but it mandates that any system processing customer data must undergo risk assessment and maintain audit trails. Compliance teams must verify that the AI vendor’s data handling aligns with the company’s Statement of Applicability. In a 4-week pilot, the audit trail includes every prompt, response, and human approval, ensuring that the system can be reviewed by internal auditors.

    RAG Pipeline

    A RAG pipeline retrieves relevant documents from a knowledge base and injects them into the LLM’s context window to ground the response. This reduces hallucination and ensures answers reflect current internal policies. In a 4-week pilot, the pipeline typically includes document chunking, vector embedding, similarity search, and prompt assembly. The quality of retrieval directly impacts the accuracy of the final answer. For a fintech company, the knowledge base includes product manuals, compliance policies, and customer FAQs, all of which must be regularly updated to reflect changes in regulations and product offerings.

    Human-in-the-Loop

    Human-in-the-loop (HITL) is a design pattern where AI-generated outputs require human review before final action. In fintech, this is mandatory for any response involving financial advice, account changes, or compliance-sensitive topics. The system flags low-confidence responses or high-risk intents for human approval, ensuring accountability while maintaining speed for routine queries. In a 4-week pilot, the HITL workflow is configured to route 10% of responses to human reviewers for quality assurance, with the percentage adjusted based on the error rate observed during the pilot period.

    Process Audit

    A process audit is a structured review of existing workflows to identify automation opportunities. It maps current steps, measures cycle time and error rates, and assesses complexity. For a 4-week pilot, the audit focuses on high-volume, rule-based tasks like invoice processing or ticket triage. The output is a prioritized list of workflows with clear before/after baselines for success metrics. The audit also identifies integration points with existing CRMs, ERPs, and helpdesks, ensuring that the AI system can plug into the company’s existing infrastructure without requiring major rework.

    Managed AI Operations

    Managed AI operations is a service model where the vendor handles ongoing monitoring, model updates, and performance optimization after deployment. This includes tracking drift, updating knowledge bases, and adjusting prompts based on feedback. For a fintech company, it ensures that the AI system remains compliant and accurate as regulations and customer needs evolve, without requiring in-house ML expertise. In a 4-week pilot, the managed operations team monitors the system’s performance daily, adjusting the RAG pipeline and HITL thresholds based on the error rate and cycle time observed during the pilot period.

    Model-Agnostic Architecture

    Model-agnostic architecture allows a system to switch between different LLM providers without major code changes. This is critical for fintech companies that need to balance cost, performance, and compliance. For example, OpenAI may be used for general queries, while an open-weight model on-premises handles sensitive data that cannot leave the building. The abstraction layer ensures that switching models does not require retraining or significant rework. In a 4-week pilot, the model-agnostic architecture allows the team to test multiple models and select the one that best balances accuracy, cost, and compliance requirements.

  • 8-Week Invoice Automation Pilot for a German Fintech: RAG, pgvector, and GDPR

    The Invoice Bottleneck in a Mid-Size German Fintech

    A 51-to-200-person fintech in Germany processes 400 to 1,200 vendor invoices per month. Each invoice takes a finance operator 45 to 90 minutes to extract, validate, and enter into the ERP. At 800 invoices monthly, that is 600 to 1,200 hours of manual work, roughly 0.4 to 0.8 FTE, before accounting for error correction and dispute handling. The operator also answers recurring questions from the sales and procurement teams: “What is our payment term for vendor X?” “Why was invoice Y rejected?” These questions pull the operator away from processing, creating a compounding bottleneck.

    The constraint is not headcount. The company cannot hire two more finance operators without triggering a budget review that takes a quarter. The constraint is cycle time and error rate. A 5% error rate on 800 invoices means 40 rework cycles per month, each costing 15 to 30 minutes. The goal is not to replace the operator but to reduce the per-invoice cycle time to under 15 minutes and cut the error rate to under 2%, freeing the operator to handle exceptions and vendor relationships.

    The 8-week integration sprint is scoped to one invoice stream (vendor AP), one integration point (Slack or Microsoft Teams), and one knowledge base (vendor contracts, payment policies, past invoice decisions). The pilot ships with a measured before/after baseline on cycle time and error rate, and a human-in-the-loop gate for any invoice above EUR 500 or flagged with low confidence.

    Pipeline Architecture: Extraction, Retrieval, and Approval

    The pipeline has three stages: extraction, retrieval, and approval.

    Stage 1: Extraction. A vision-language model parses the PDF or scanned image into structured fields: vendor name, invoice number, amount, tax rate, line items, and payment terms. For high-volume, low-sensitivity documents, an open-weight model (Llama 3 70B or Mistral 8x22B) runs on the client’s own hardware. For complex multilingual invoices or documents with unusual layouts, the request routes to an API model (GPT-4o or Claude 3.5 Sonnet). The routing policy is simple: if the document contains PII or regulated data, it stays on-prem; otherwise, it goes to the API. This keeps GDPR Article 22 compliance intact while using the best model for each task.

    Stage 2: Retrieval. The extracted fields and the operator’s question are embedded using a multilingual model (multilingual-e5-large or BGE-M3) and stored in a pgvector table with an HNSW index (m=16, ef_construction=64). For a 50,000-document knowledge base, retrieval latency is under 10 ms at 95% recall. The top-k (k=5) chunks are prepended to the prompt for the LLM, which generates the answer or the approval recommendation.

    Stage 3: Approval. The Slack or Teams bot posts a message thread with the extracted data, the validation result, and the approval request. A finance operator approves or rejects. Every approval is logged with a timestamp and the operator’s ID, satisfying the audit trail requirement under GDPR Article 30.

    The architecture is model-agnostic: the pgvector store, the Slack/Teams integration, and the approval workflow are decoupled from the model backend. Switching from OpenAI to an on-prem model requires no changes to the retrieval or notification layers.

    Trade-Offs: Model Tier, Vector Store, and Scope

    The architect makes three key trade-offs, each with a measurable cost.

    Model tier vs. data residency. Using GPT-4o for all extraction gives the highest field-level accuracy (96% on a 500-document test set) but requires a Standard Contractual Clause and a data processing agreement to keep PII within EU borders. The alternative is an open-weight model on the client’s own hardware, which eliminates the transfer entirely but drops accuracy to 91% on multilingual invoices. The routing policy mitigates this: PII-heavy documents go on-prem, clean documents go to the API. The cost is a 5% accuracy drop on the PII subset, which the human-in-the-loop gate absorbs.

    pgvector vs. a dedicated vector database. pgvector is sufficient for a 50,000-document knowledge base and avoids the operational overhead of a separate service. The cost is that HNSW index building takes 12 minutes for 50,000 vectors, which is acceptable for a nightly batch but not for real-time ingestion. A dedicated database (Qdrant, Weaviate) would handle real-time ingestion but adds a service to monitor and a vendor lock-in. For a 51-to-200-person company, pgvector is the right call.

    Fixed-scope pilot vs. open-ended build. The 8-week sprint is fixed-scope: one invoice stream, one integration point, one knowledge base. The cost is that the pilot does not cover the full invoice lifecycle (e.g., payment execution, reconciliation). The benefit is that the client gets a measured baseline and a working system in 8 weeks, not a 6-month project with no deliverable until the end. The rollout plan, delivered in week 8, covers the next two invoice streams and the payment execution integration.

    Recommendation: Ship the Pilot, Measure the Baseline, Then Roll Out

    The pilot is not a proof of concept. It is a production system running in shadow mode for two weeks, then in supervised live mode for two weeks. The success criteria are pre-agreed in the integration sprint charter: 92% field-level accuracy on a 500-document test set, a 70% reduction in cycle time, and a 50% reduction in error rate. The before/after baseline is measured over a 2-week period before the pilot starts, using the same 500-document test set.

    The human-in-the-loop gate is non-negotiable. Any invoice above EUR 500, any invoice with a confidence score below 0.85, and any invoice flagged by the rule-based validator (duplicate number, inconsistent tax rate, amount exceeds threshold) requires human approval. The operator sees the extracted data, the validation result, and the RAG assistant’s answer in a single Slack or Teams message thread. The approval takes 30 to 60 seconds, not 45 to 90 minutes.

    The multilingual support is handled by the embedding model, not the LLM. A German query retrieves English policy documents and vice versa, because the multilingual-e5-large model maps both languages into the same 1024-dimensional space. The LLM generates the answer in the language of the query. This covers the need for multilingual support without requiring separate models per language.

    The rollout plan, delivered in week 8, covers the next two invoice streams (customer AR and intercompany) and the payment execution integration. The managed operation contract, EUR 3,000 to 8,000 per month, covers model API costs, pipeline monitoring, and one hour per week of operator support. The client does not need to hire a data engineer or an ML engineer to run the system.

  • AI Automation Audit and n8n Pilot for Fintech Teams: 8-Week Plan

    The Problem: Senior Staff Buried in Extraction and Routine Response

    You run a 51-200 person fintech or payments company in the USA. Your senior staff spend 30-40% of their week on document and data extraction pipelines: parsing invoices, cleaning transaction data, enriching customer records, and answering the same compliance questions in Slack or Microsoft Teams. You have no AI in production yet. You need round-the-clock customer response and an internal knowledge search assistant, but you cannot replace your CRM, ERP, or helpdesk. The delivery model is an AI automation audit that identifies which workflows to automate, a fixed-scope pilot on one of them, and a rollout plan. The timeline is 8 weeks. The goal is to free senior staff from routine work without introducing a new system that sits alongside the ones you already run.

    Prerequisites: What You Need Before Step 1

    Before you start the audit, confirm the following are in place:

    • API access to your CRM, ERP, helpdesk, and messaging platform (Slack or Microsoft Teams). You need read and write permissions, not just read.
    • A sample dataset of 50-100 recent documents (invoices, KYC forms, transaction records) and 50-100 recent customer tickets or internal questions, with timestamps and outcome labels.
    • A named owner on your side who can approve the audit scope, answer process questions, and make the go/no-go decision on the pilot.
    • Infrastructure decision: whether you will run open-weight models on your own hardware (for data that cannot leave the building) or use commercial APIs (OpenAI, Anthropic) for data that can. If you have no GPU hardware, the audit will flag which workflows require it.
    • A Slack or Microsoft Teams channel dedicated to the pilot, where the human-in-the-loop approval requests will land.

    Step 1: Run the Process Audit and Measure the Baseline

    Map every workflow that touches document and data extraction, customer response, and internal knowledge search. For each workflow, record: the trigger (email, API call, manual upload), the current cycle time in minutes, the error rate as a percentage, the weekly volume, and the number of senior staff hours consumed per week. Use a simple spreadsheet. For example: “Invoice processing: trigger = email attachment, cycle time = 12 min, error rate = 4%, volume = 200/week, senior staff hours = 40/week.” This is the baseline. Without it, you cannot measure whether the pilot worked. The audit deliverable is a prioritized list ranked by ROI: (senior staff hours saved per week) × (cost per hour) ÷ (estimated automation cost).

    Step 2: Define the Pilot Scope and Success Criteria

    Select one workflow from the audit’s top three. For a fintech company with no AI in production yet, the highest-ROI pilot is usually document and data extraction: invoice processing or KYC document parsing. Define the fixed scope: which document types, which fields to extract, which downstream system receives the enriched data, and which human approves the output. Write a one-page scope document. Example: “Pilot scope: extract invoice number, vendor name, amount, and tax ID from PDF invoices received via email. Enrich the record with vendor category from the CRM. Push the enriched record to the ERP. A human in the #ai-pilot Slack channel approves or rejects each extraction before it reaches the ERP.” Do not expand the scope during the pilot.

    Step 3: Build the n8n Orchestration Workflow

    Build the n8n workflow. The flow is: (1) a webhook or email trigger receives the document, (2) an HTTP Request node calls the AI model API (OpenAI, Anthropic, or a self-hosted Ollama/vLLM endpoint for open-weight models), (3) a Code node parses the JSON response and maps fields to your schema, (4) an HTTP Request node queries the CRM API to enrich the record, (5) a Slack or Microsoft Teams node posts the AI’s output with an approve/reject button, (6) a Wait node pauses the workflow until a human responds, (7) an HTTP Request node pushes the approved record to the ERP. If the human rejects, route the item to a manual queue. Test the workflow with 10 sample documents before going live.

    Step 4: Run the Pilot and Measure Before/After

    Run the pilot for two weeks on live traffic. The human-in-the-loop gate is active: every extraction or classification passes through the Slack or Microsoft Teams approval before it reaches the downstream system. Track three metrics daily: cycle time (from document receipt to ERP entry), error rate (percentage of items the human rejects or corrects), and volume (items processed per day). Compare these against the baseline from Step 1. If cycle time drops from 12 minutes to under 4 minutes and error rate drops from 4% to under 2%, the pilot meets its success criteria. If not, tune the model prompts, adjust the classification thresholds, or expand the sample dataset. Do not change the scope. Two weeks is enough to get a signal.

    Step 5: Build the Internal Knowledge Search Assistant

    After the pilot, build the internal knowledge search assistant. Chunk your compliance policies, onboarding procedures, and CRM records. Embed them with a model like text-embedding-3-small or a self-hosted embedding model. Store the vectors in pgvector or Qdrant. Build an n8n workflow that listens for messages in a dedicated Slack or Microsoft Teams channel, retrieves the top 5 relevant chunks, passes them to the model as context, and returns an answer with citations. The assistant does not replace the CRM or the documentation system; it queries them via API. For a fintech company, this covers questions like “What is the KYC verification step for a new merchant in the EU?” or “How do we handle a transaction dispute under 12 U.S.C. § 1693?” The human-in-the-loop gate applies here too: the assistant’s answer is a draft, not a final response.