Forfis Blog

Category: Fintech and Payments

  • AI Contract Review Rollout for US Fintechs: A 12-Point ISO 27001 Checklist

    12-Point Checklist for a Compliance-Safe AI Contract Review Rollout

    1. Verify the scope of the contract review workflow.
      Define the specific contract types, clause categories, and approval thresholds for the pilot.

    2. Document the baseline cycle time and error rate.
      Sample 50-100 historical contracts to measure manual review time and error frequency.

    3. Map the data flow from source to destination.
      Identify where contracts originate, how they are stored, and where reviewed data is sent.

    4. Select the open-weight model for on-premise deployment.
      Choose Llama 3 or Mistral based on contract complexity and hardware constraints.

    5. Configure the model serving infrastructure.
      Deploy vLLM or TGI on the client’s GPU cluster to ensure data never leaves the building.

    6. Integrate the AI system with Confluence or Notion.
      Use APIs to pull contract templates, store drafts, and log approval decisions.

    7. Define the human-in-the-loop approval workflow.
      Specify which clauses require human review and how approvers are notified.

    8. Implement data enrichment and cleanup rules.
      Configure extraction, classification, and deduplication logic for contract fields.

    9. Set up access controls and audit trails.
      Map each AI component to ISO 27001 controls, including A.8.2.2 and A.12.4.1.

    10. Test the end-to-end workflow with sample contracts.
      Run 10-20 test contracts through the full pipeline to validate accuracy and latency.

    11. Train the legal and compliance team on the new workflow.
      Provide documentation and a 2-hour training session on using the AI-assisted review tool.

    12. Schedule the post-implementation metrics review.
      Plan a 2-week check-in to compare cycle time and error rate against the baseline.

    Maintaining the Checklist Over Time

    The checklist above is a living document. After the pilot concludes, review which items were completed, which were skipped, and why. Update the checklist to reflect lessons learned, such as new clause types or changed approval thresholds. Assign a single owner for the checklist, typically the project lead, and review it quarterly to ensure it remains aligned with the company’s compliance requirements and operational changes. This maintenance process ensures that the checklist continues to serve as a reliable guide for future AI rollouts.

    Timeline and Scope Considerations

    The 4-week timeline is aggressive but achievable for a single, well-scoped pilot. Weeks 1-2 focus on the process audit, data mapping, and environment setup. Weeks 3-4 cover model fine-tuning, integration with Confluence or Notion, and the human-in-the-loop approval workflow. This timeline assumes the client has already identified the specific contract types and has access to historical data for baseline measurement. If the scope expands or the data is not ready, the timeline will slip, so it is critical to lock the scope during the audit phase.

  • Compliance-Safe AI Knowledge Agent for HR in a UAE Fintech

    The HR Knowledge Gap in a 2,000-Seat Fintech

    A 2,000-employee fintech in the UAE runs its HR operations on a patchwork of systems: an HRIS for payroll and benefits, a CRM for vendor records, a shared drive for policy documents, and Slack or Microsoft Teams for day-to-day communication. When an employee asks a question about leave entitlements, visa sponsorship, or the new compliance policy, the HR representative opens the shared drive, searches for the relevant PDF, reads through 30 pages, and types an answer. The median cycle time is 45 minutes. The error rate on benefits details is 12% because the representative is working from a document that was updated six weeks ago but the shared drive still holds the old version. The HR team of 14 handles 200 to 300 policy queries per week. The cost is not just the 45 minutes per query; it is the 12% error rate that leads to incorrect leave calculations, visa delays, and compliance gaps that surface during an ISO 27001 audit.

    Why Off-the-Shelf Chatbots and Manual Triage Fail

    The first common approach is to buy a commercial HR chatbot. These products ship with a generic knowledge base and a rule-based intent classifier. They handle “What is my leave balance?” but fail on “How does the new UAE labor law amendment affect my end-of-service calculation?” The rule-based classifier cannot parse the nuance, and the generic knowledge base does not contain the company’s specific policy. The second approach is to build a custom RAG pipeline on the company’s own documentation. This works for a single language and a single department, but it breaks when the HR team needs to cover Arabic, English, and Hindi queries across 2,000 employees in a UAE-based fintech. The third approach is to hire more HR staff. This scales linearly with query volume and does not fix the 12% error rate caused by stale documents. None of these approaches address the compliance requirement: ISO 27001 Article 14 requires documented controls for external information processing, and a chatbot that sends employee queries to a third-party API without a data classification gate fails that control.

    A Model-Agnostic, Compliance-First Architecture

    The architecture is model-agnostic and compliance-first. For general knowledge search, the agent uses the OpenAI API to process queries and draft responses. For regulated data that cannot leave the client’s network, the agent routes the query to an open-weight model running on the client’s own hardware. The routing layer classifies each query by data sensitivity before it reaches any model. The agent plugs into the existing HRIS, CRM, and Slack or Teams through their native APIs; it does not replace any system. The retrieval index is language-aware, so an Arabic query retrieves the Arabic version of the policy directly, avoiding the accuracy loss of machine translation. Every answer that touches compensation, contracts, or personal data routes to a human reviewer before it reaches the employee. The approval gate is logged with a timestamp and reviewer ID, creating the audit trail that ISO 27001 Article 10.1 and Article 14 require. The pilot ships with a measured before/after baseline on cycle time and error rate, so the HR operations team can see the 45-minute median drop to under 3 minutes and the 12% error rate fall to 2% in the first month of managed operation.

    How to Start: Five Concrete Steps in the First 60 Days

    Week 1: assign a compliance reviewer from the ISO 27001 team and a product owner from HR operations. The compliance reviewer confirms the data classification tags and the list of documents that are in scope for the retrieval index. Week 2: run the process audit. Measure the current cycle time and error rate on a sample of 50 policy queries. Document the top 10 query types and the documents they reference. Week 3: build the retrieval index on the in-scope documents. Tag each document by language and data sensitivity. Week 4: integrate the agent with Slack or Teams through the native API. Set up the human-in-the-loop approval gate for queries that touch compensation, contracts, or personal data. Week 5: run the shadow-mode test. The agent answers alongside human staff without touching production. Compare the agent’s answers to the human answers and log discrepancies. Week 6: fix the top discrepancies and re-run the shadow test. Week 7: begin the measured rollout with the human-in-the-loop gate active. Track cycle time and error rate in a dashboard. Week 8: hand over to managed operation. The Forfis team monitors the dashboard, handles model updates, and reviews the audit log weekly. The 6-month timeline assumes the client has ISO 27001 documentation ready and can assign the compliance reviewer within the first two weeks.

  • 14-Day AI Pilot Checklist for Fintech Order and Shipment Status Updates

    1. Map the current order and shipment workflow

    Before any model touches a document, the team maps the current workflow end to end. For a 201-500 person fintech firm handling order and shipment status updates, this means identifying every touchpoint where a human reads a PDF, CSV, or email attachment, extracts an order ID or tracking number, and types it into the CRM or ERP. The audit also captures the customer-facing side: how many order status queries arrive per day, what channels they come through (email, chat, phone), and what the current first-response time is. The output is a one-page process map with cycle time and error rate baselines. This map becomes the acceptance criteria for the pilot. Without it, the 14-day window has no measurable target.

    2. Build the document extraction pipeline

    The extraction pipeline ingests documents from Google Drive and Gmail. For a fintech operations team, the typical inputs are order confirmations, shipment manifests, and carrier tracking updates. The pipeline uses OCR or structured parsing to pull out order IDs, tracking numbers, and status codes, then applies a validation rule set to flag anomalies. The Anthropic Claude API handles the classification step: it reads the extracted text and assigns a status category (e.g., “shipped,” “in transit,” “delivered”). The rule set is deterministic; the model only classifies. This keeps the extraction layer auditable and the error rate measurable.

    3. Configure the customer-facing assistant

    The assistant layer uses the Anthropic Claude API to generate natural-language responses to customer queries about order and shipment status. It pulls data from the CRM or ERP via API, formats the response, and sends it through the existing helpdesk or email channel. The system is configured to handle 24/7 queries, but it does not process payments, issue refunds, or modify contract terms. Any query that touches money or a contract routes to a human agent. The assistant is a lookup and response tool, not a transaction processor. This boundary is hard-coded into the prompt and the escalation logic.

    4. Wire the integration to Google Workspace and the CRM

    The assistant and extraction pipeline write to and read from the existing CRM, ERP, and helpdesk through their native APIs. No new infrastructure is required. For a fintech firm using Google Workspace, the integration points are Gmail (for inbound queries and document attachments), Google Drive (for document storage), and the CRM or ERP API (for order and shipment data). The dedicated AI team handles all wiring: OAuth tokens, API rate limits, and error handling. The system plugs into what the firm already runs. It does not replace the CRM, ERP, or helpdesk. It adds an AI layer on top.

    5. Run parallel tests against live data

    Days 9-11 of the pilot run the system in parallel with the existing manual process. The team feeds live order and shipment documents through the extraction pipeline and compares the output against the human-entered data. The assistant handles live customer queries and the team measures first-response time and accuracy. The human-in-the-loop approver reviews every output that touches money, health data, or a contract. The goal is not to prove the system works in a vacuum. The goal is to measure the delta: cycle time reduction, error rate change, and first-response improvement against the baseline captured in step 1.

    6. Validate, fix edge cases, and hand over the runbook

    Days 12-14 are for fixing edge cases, tuning the classification rules, and writing the operating runbook. The runbook documents: how to monitor the extraction pipeline, how to escalate assistant queries to a human, how to update the validation rule set, and how to measure the before/after metrics. The dedicated AI team hands over the runbook and the measured baseline. The pilot is a one-time deliverable. The runbook is what keeps the system running after the team leaves. Without it, the 14-day investment decays within a month.

  • German Fintech Cuts Ticket Triage Time 43% with On-Premise RAG Pilot

    Background: A 340-Person German Payments Processor

    This case study is a composite based on patterns observed across multiple engagements in the field. We do not fabricate named customers; the company described here is a representative profile drawn from recurring scenarios in German fintech and payments.

    The company is a mid-size payments processor in Frankfurt, operating in the B2B space with roughly 340 employees. It processes card and SEPA transactions for mid-market merchants across DACH and Western Europe. The support team handles 1,200-1,800 tickets per month, with a mix of payment disputes, settlement queries, API integration issues, and onboarding questions. The existing stack includes a Zendesk helpdesk, a Salesforce CRM, and Google Workspace for internal documentation and communication. The company is in the “Running Isolated Pilots” stage of AI maturity: it has experimented with a chatbot on its public website but has not yet integrated AI into core operational workflows.

    Challenge: Senior Agents Buried in Routine Triage

    The support lead identified a specific bottleneck: senior agents were spending an estimated 35-40% of their time on routine triage and first-response drafting for payment-related tickets. These tickets required looking up transaction status in the CRM, checking internal runbooks in Google Drive, and composing a templated response. The work was repetitive but required enough domain knowledge that junior agents could not handle it independently.

    The operational pressure was threefold. First, the company had a hiring freeze due to a recent funding round that did not close as expected. Second, the EU AI Act’s transparency and oversight requirements meant that any AI system touching customer data needed a documented risk assessment before deployment. Third, the company’s data residency policy prohibited sending transaction data to external API providers, which ruled out a straightforward OpenAI or Anthropic integration for the core triage workflow. The need was clear: free senior staff from routine work without adding headcount, and do it within a four-week pilot window.

    Approach: Four-Week Audit, On-Premise RAG Pilot

    The engagement began with a process audit spanning the first week. We mapped the ticket lifecycle in Zendesk, categorized 200 recent tickets by type and handling time, and identified the top three categories consuming senior-staff time: payment dispute triage, settlement delay inquiries, and API error classification. The audit also inventoried the documentation assets in Google Drive and Confluence that agents referenced during triage.

    The technical architecture was deliberately model-agnostic. Because transaction data could not leave the building, we deployed an open-weight model (Llama 3 70B) on a single A100 80GB GPU in the company’s on-premise data center. The retrieval-augmented knowledge assistant ingested internal runbooks, API documentation, and historical ticket resolutions into a Qdrant vector store. The system connected to Zendesk via its REST API to read incoming tickets and write routing decisions, and to Google Workspace via the OAuth 2.0 API to pull shared documentation. The delivery model was a fixed-scope pilot: one workflow (payment dispute triage), one model, one integration surface, with a measured before/after baseline on cycle time and error rate.

    Outcome: 43% Faster Triage, 7 Points Fewer Errors

    The pilot ran in shadow mode for the final week of the four-week window, with senior agents reviewing every AI-generated triage decision before it was logged. The measured results, based on a 30-day baseline captured during the audit phase:

    • Median triage cycle time for payment dispute tickets dropped from 14 minutes to 8 minutes, a 43% reduction.
    • First-response error rate (misrouted or incorrectly classified tickets) decreased from 12% to 5%.
    • Senior agent time spent on routine triage fell from an estimated 38% to 22% of their working hours.
    • Documentation retrieval time (time spent searching Google Drive for relevant runbooks) dropped by roughly 60%, as the RAG assistant surfaced the relevant document in the triage suggestion.

    The system handled approximately 70% of payment dispute tickets with a routing suggestion that the senior agent approved without modification. The remaining 30% required human adjustment, typically for edge cases involving multi-currency settlements or disputed chargebacks. The pilot did not replace any agents; it reduced the volume of routine work that required senior-level attention.

    Lessons for Similar Teams

    • Audit before you build. The process audit identified that 60% of the “complex” tickets were actually routine status inquiries that a rule-based macro could handle. The RAG assistant was scoped to the remaining 40% where retrieval and classification genuinely added value. Skipping the audit would have led to over-engineering.

    • On-premise deployment is not a compromise. The open-weight model on the A100 performed within 5-8% of the closed-model API on the triage classification task, and it satisfied the data residency requirement. For regulated industries, this is not a trade-off; it is the only viable path.

    • Human-in-the-loop is a feature, not a limitation. The shadow-mode validation in week four caught two edge cases where the model misclassified a chargeback as a settlement delay. Without the human approval step, these would have gone to the wrong queue. The approval step also built trust with the support team, which was critical for adoption.

    • Baseline measurement is non-negotiable. The 30-day pre-pilot baseline on cycle time and error rate is what made the 43% and 7-point improvements defensible to the CTO and the board. Without it, the results would have been anecdotal.

    • Four weeks is a pilot, not a rollout. The pilot covered one ticket category. Full rollout across all support workflows (API errors, onboarding, general inquiries) required an additional six weeks of integration and tuning. Plan the timeline accordingly.

  • AI-Native Contract Review vs Manual Legal Workflows: A UK Fintech Comparison

    What Is Being Compared

    The comparison centers on two operational models for contract review in a 51-200 person UK fintech: manual legal review (current state) and AI-native operations (target state). Manual review relies on senior lawyers reading each clause, flagging risks, and drafting redlines. AI-native operations uses a pgvector embeddings search pipeline to retrieve similar clauses, apply predictive scoring to risk assessment, and generate first-draft responses. The AI layer integrates with existing Confluence or Notion documentation, the CRM, and the helpdesk via APIs, without replacing any tool. Both models must satisfy PCI DSS requirements for payment contracts and free senior staff from routine work within a 6-month timeline.

    Criteria for Judgment

    We judge both models against eight criteria: cycle time (hours from receipt to approval), error rate (missed risk clauses per 100 contracts), cost per contract (fully loaded), vendor lock-in (ability to switch models or tools), compliance (PCI DSS, UK GDPR), scalability (contracts/hour without adding headcount), audit trail (traceability of decisions), and staff utilization (senior hours on high-value work). Each criterion carries a quantitative target: cycle time under 4 hours for standard agreements, error rate below 2%, cost under £150 per contract, no single-vendor dependency, full PCI DSS Requirement 3.5.1 compliance, 50+ contracts/hour, immutable decision logs, and 60%+ of senior time on negotiation and strategy.

    Comparison Table

    Criterion Manual Legal Review AI-Native Operations
    Cycle time 3-5 days (18-30 hours) Under 4 hours for standard agreements
    Error rate 5-8% missed risk clauses Below 2% with human-in-the-loop approval
    Cost per contract £400-600 (senior lawyer time) Under £150 (API + infrastructure)
    Vendor lock-in None (human-dependent) Model-agnostic: OpenAI/Anthropic APIs + open-weight on client hardware
    Compliance Manual PCI DSS checks, error-prone Automated PCI DSS Requirement 3.5.1 validation, immutable audit trail
    Scalability 5-10 contracts/hour per lawyer 50+ contracts/hour without added headcount
    Audit trail Email threads, version control Immutable decision logs with clause-level traceability
    Staff utilization 70% on routine review 60%+ on negotiation, strategy, regulatory interpretation

    When Manual Review Wins

    Manual review wins when contracts are highly novel, involve unprecedented regulatory interpretations, or require nuanced negotiation strategy. A 51-200 person fintech handling bespoke payment product agreements or cross-border regulatory filings benefits from senior lawyers’ judgment on ambiguous clauses. AI-native operations wins for high-volume, template-based contracts: standard merchant agreements, data processing addenda, and service level agreements. The predictive scoring model trains on the firm’s own reviewed contracts in Confluence or Notion, using pgvector embeddings to retrieve similar clauses and assign risk probabilities. For a UK fintech processing 200+ contracts/month, the AI layer handles 80% of routine review, freeing senior staff for the 20% requiring human judgment.

    When AI-Native Operations Wins

    AI-native operations wins when the firm has 50+ contract types, 30+ hours/week of routine review, and existing documentation in Confluence or Notion. The integration sprint delivers a working pipeline in 4-6 weeks: document ingestion, pgvector embeddings search, predictive scoring, and human-in-the-loop approval gates. Round-the-clock customer response is enabled by the AI layer handling first-response triage, while humans approve final decisions. The model-agnostic architecture uses OpenAI or Anthropic APIs for high-quality clause analysis and open-weight models on client hardware for regulated data that cannot leave the building. For a 51-200 person UK fintech, the 6-month timeline includes a 2-week audit, 4-week pilot on one contract type, and 4 months of phased rollout, with PCI DSS validation and staff training built into the schedule.

    Recommendation

    For a 51-200 person UK fintech in the payments sector, AI-native operations is the recommended model. The firm’s contract volume, existing Confluence or Notion documentation, and PCI DSS compliance requirements align with the AI layer’s strengths. The integration sprint delivers a working pipeline in 4-6 weeks, with human-in-the-loop approval ensuring compliance throughout. The 6-month timeline includes buffer for PCI DSS validation and staff training, ensuring the AI layer operates within the firm’s existing compliance framework. Senior staff are freed from routine work, focusing on negotiation strategy and regulatory interpretation. The model-agnostic architecture avoids vendor lock-in, using OpenAI or Anthropic APIs where quality matters and open-weight models on client hardware where regulated data cannot leave the building.

  • Voice Agent for Order Status in Austrian Fintech: Two-Week Pilot with pgvector

    The Problem: Routine Inquiries Consuming Senior Staff Time

    Your support team handles 300-500 calls per week, 60% of which are routine inquiries about order status or shipment tracking. Senior staff spend 12-15 hours weekly on these repetitive tasks, delaying complex escalations and fraud reviews. The goal is to free senior staff from routine work by deploying a voice agent that handles 24/7 customer response for order and shipment status updates. The agent must integrate with your existing CRM and ERP, comply with the EU AI Act, and operate within a two-week pilot window. The architecture uses pgvector embeddings search to retrieve relevant records from your own database, keeping regulated data on-premises. The pilot ships with a human-in-the-loop approval gate for any action that touches money or modifies a contract.

    Prerequisites: What You Need Before Step 1

    • Access to your CRM or ERP API with read permissions for order and shipment records.
    • A sample of 50-100 historical customer inquiries, anonymized, to train the intent classifier.
    • A designated human approver with authority to approve or reject transactional actions.
    • Slack or Microsoft Teams workspace where your support team already operates.
    • A PostgreSQL database with pgvector extension enabled, or a plan to deploy it.
    • A clear definition of the pilot scope: one workflow (order/shipment status), one channel (voice), two weeks.
    • Compliance sign-off from your legal team on the EU AI Act requirements for financial services AI.

    Steps 1-3: Audit, Embeddings, and Agent Configuration

    1. Audit the workflow. Map the current process for order status inquiries: average call duration, number of escalations, error rate, and the specific data points customers ask for. Document the before/after baseline: cycle time from inquiry to resolution, and the percentage of inquiries that require human intervention. This baseline becomes the success metric for the pilot.

    2. Set up pgvector embeddings. Install the pgvector extension in your PostgreSQL database. Create a table for embeddings with a vector column of dimension 1536 (matching OpenAI’s text-embedding-3-small). Ingest your order and shipment records, generating embeddings for each record. This allows the voice agent to retrieve relevant records via semantic search rather than exact keyword matching.

    3. Configure the voice agent. Use a model-agnostic architecture: OpenAI or Anthropic APIs for quality-critical tasks like intent classification and response generation, and an open-weight model on your own hardware for any task involving regulated data. Configure the agent to query pgvector for order and shipment records, then generate a response. Set the human-in-the-loop gate: any action that modifies a customer’s financial state requires approval from a human in Slack or Microsoft Teams.

    Steps 4-6: Integration, Pilot, and Go-Live

    1. Integrate with Slack or Microsoft Teams. Configure the agent to post notifications to your support team’s channel when a case requires human approval. The notification includes a summary of the customer’s inquiry, the retrieved records, and the proposed action. The human approver reviews the case, clicks approve or reject, and the agent executes the approved response. This keeps the workflow within your existing communication tools, reducing friction.

    2. Run the pilot in parallel. For two weeks, the voice agent handles incoming calls in parallel with your existing support process. Measure the after/after metrics: cycle time, error rate, and the percentage of inquiries resolved without human intervention. Compare these to the baseline from Step 1. Identify any misclassifications or retrieval errors, and feed them back into the embeddings and intent classifier.

    3. Go-live and hand off to managed operations. After two weeks, if the pilot meets the success criteria, transition the voice agent to production. Forfis takes over managed AI operations: monitoring model performance, handling drift, updating embeddings as new records are added, and maintaining the human-in-the-loop workflow. Your staff focuses on reviewing flagged cases and expanding the agent’s scope to new workflows.

    Common Pitfalls and How to Detect Them

    • Over-scoping the pilot. Trying to automate multiple workflows or channels in two weeks leads to a rushed build with insufficient testing. Stick to one workflow and one channel. Detect this by reviewing the pilot scope document: if it lists more than one workflow or channel, cut the scope.
    • Skipping the baseline measurement. Without a clear before/after metric on cycle time and error rate, you cannot prove the pilot’s value to stakeholders. Detect this by checking whether the audit in Step 1 produced a documented baseline with specific numbers.
    • Untrained human approvers. If your approvers are not trained on the approval workflow, the human-in-the-loop gate becomes a bottleneck, negating the time savings. Detect this by measuring the average time from notification to approval during the pilot. If it exceeds 10 minutes, retrain the approvers.
    • Embedding drift. As new order and shipment records are added, the embeddings may become stale, leading to retrieval errors. Detect this by monitoring the retrieval accuracy metric during the pilot. If it drops below 90%, re-ingest the embeddings.

    Conclusion: What Comes After the Pilot

    The pilot proves whether a voice agent can handle routine order and shipment status inquiries in an Austrian fintech within a two-week window. If the success criteria are met, the next logical step is to expand the agent’s scope to additional workflows, such as payment disputes or account changes. This requires a deeper integration with your ERP and a more complex human-in-the-loop approval workflow. The managed operations model ensures that the technical side of this expansion is handled by Forfis, while your staff focuses on the business side: defining the new workflows, training the approvers, and measuring the impact on senior staff time. The architecture remains model-agnostic and data-resident, satisfying the EU AI Act and GDPR requirements throughout the scaling process.

  • UK Fintech AI Lead-Qualification Checklist: 15 Steps for a 3-Month Pilot

    1. Audit the Current Lead-Qualification Workflow

    Start by mapping the current lead-qualification workflow end-to-end. Identify every touchpoint where a human manually enters data, classifies intent, or drafts a response. Document the average cycle time from ‘lead submitted’ to ‘qualified’ and the error rate on misclassified leads. This baseline is the anchor for the pilot’s before/after report. Without it, you cannot prove the AI agent delivers measurable value. The audit also flags which workflows are worth automating and which are too complex for a 3-month pilot. For a 201-500 person fintech, this typically means focusing on one high-volume, low-complexity workflow, such as inbound lead triage from a marketing form.

    2. Define the Pilot Scope and Success Metrics

    Define the exact scope of the pilot before writing a single line of code. The pilot should cover one workflow, one integration, and one success metric. For lead qualification, this means the agent handles inbound leads from a specific channel, integrates with one CRM, and measures cycle time reduction. Avoid scope creep by documenting what is out of scope, such as multi-channel routing or contract drafting. The fixed scope keeps the 3-month timeline realistic and ensures the pilot report is actionable. For a fintech team, this also means defining the human-in-the-loop approval step: the agent drafts, a rep approves, and the system logs the approval with a timestamp and user ID.

    3. Map ISO 27001 Controls to the AI Layer

    Map every data flow that touches the AI agent against ISO 27001 Annex A controls. Identify where PII enters the system, how it is stored, and when it is deleted. For a fintech agent, this means ensuring transaction data and customer identifiers are not logged in model weights or sent to unapproved endpoints. Document the access controls: who can view agent logs, who can approve responses, and how incidents are escalated. The audit trail must show that every interaction is logged, every approval is timestamped, and every data deletion is recorded. This documentation is what your ISO 27001 assessor will review, so it must be complete and current before the pilot goes live.

    4. Configure the Anthropic Claude API and Integration Layer

    Configure the Anthropic Claude API endpoint with the appropriate model and temperature settings for lead qualification. For a fintech agent, use a model that handles nuanced intent classification and drafts professional first-response emails. Set the temperature low, around 0.2 to 0.3, to reduce hallucination risk. Implement rate limiting and error handling so the agent degrades gracefully if the API is down. The integration layer should plug into your existing CRM and helpdesk through their APIs, not replace them. This means the agent reads lead data from the CRM, writes qualified leads back, and logs every interaction in the helpdesk. The model-agnostic design means you can swap to an open-weight model on your own hardware if regulated data cannot leave the building.

    5. Integrate with Notion or Confluence for Knowledge Grounding

    Connect the agent to your Notion or Confluence workspace through their APIs so it can pull documentation, product specs, and compliance policies. This grounds the agent’s responses in your current content, not generic AI output. For a marketing and content team, this means the agent can reference the latest product page, pricing sheet, or compliance FAQ when drafting a first-response email. When marketing updates a page in Notion, the agent’s knowledge base updates automatically without manual retraining. This reduces the risk of the agent providing outdated information, which is a critical concern in fintech where compliance and accuracy are non-negotiable. The integration should be tested with a sample of 50 real leads before the pilot goes live.

    6. Build the Conversational Agent with Human-in-the-Loop Approval

    Build the conversational agent with a clear human-in-the-loop approval step. The agent drafts the response and classifies the lead, but a human must approve anything that touches money, health data, or a contract. In a fintech lead-qualification context, this means the agent can tag a lead as ‘high-intent’ and draft a follow-up email, but a sales rep must click ‘send’ before it goes out. The approval step is logged with a timestamp and user ID for audit purposes. The agent should also flag leads that require human review, such as those with compliance questions or high transaction volumes. This ensures the AI layer accelerates the workflow without bypassing the controls your ISO 27001 certification requires.

    7. Run the Pilot and Measure Before/After Baselines

    Run the pilot for 4 to 6 weeks with a small group of sales reps. Track cycle time, error rate, and rep satisfaction daily. Compare the pilot results against the baseline captured in the process audit. If the agent reduces cycle time by 40% and error rate by 25%, the business case for rollout is quantified. Document any edge cases where the agent misclassified a lead or drafted an inappropriate response. These edge cases inform the prompt tuning and approval rules for the rollout phase. The pilot report should include a recommendation on whether to proceed to rollout, what changes are needed, and what the managed operations plan looks like. For a 201-500 person fintech, this report is the decision point for scaling the AI layer across the sales and marketing teams.

  • UAE Fintech Cuts Contract Review Cycle Time 52% in a 2-Week On-Premise AI Pilot

    Background: A 1,200-Person UAE Fintech at One-Process-Automated

    This case study is a composite based on patterns observed across multiple engagements. It does not describe a named customer. The company profile, metrics, and timeline are representative of what Forfis has delivered in fintech and payments in Tier-1 markets.

    The client is a 1,200-person fintech operating in the UAE, processing approximately 40,000 payment-related contracts and invoices per month. The company is at the one-process-automated stage of AI maturity: they had piloted a basic OCR tool for invoice line-item extraction but had not integrated it into their review workflow. Their stack includes SAP S/4HANA for ERP, Salesforce for CRM, and Confluence as the internal knowledge base for contract templates and review guidelines. The finance and accounting team of 85 people handled first-response triage manually: a reviewer opened each document, extracted key fields, checked them against the standard template, and logged the result. Median cycle time from document receipt to review completion was 14 business days, with a field-level error rate of 6.2%.

    Challenge: PCI DSS Re-Assessment and a 2-Week Deadline

    The finance director set a hard deadline: cut first-response time by at least 40% within two weeks of pilot launch, without increasing headcount. The pressure was operational, not strategic. The company was preparing for a PCI DSS Level 1 re-assessment in Q3, and the assessor had flagged the manual contract review process as a potential gap in Requirement 3 (protection of stored cardholder data) because reviewers were handling documents containing PANs in unencrypted email threads. The compliance team needed a defensible, auditable process where cardholder data never left the client’s infrastructure.

    The specific need was less manual back-office work in the finance and accounting function, focused on contract review and document and data extraction pipelines. The company did not want to replace SAP or Salesforce. They wanted an AI layer that sat on top of the existing stack, extracted structured fields from contracts and invoices, scored each document for risk, and routed high-risk items to senior reviewers first. The 2-week timeline was non-negotiable because the PCI DSS re-assessment window was fixed. The pilot had to ship a measurable before/after baseline on cycle time and error rate within that window.

    Approach: On-Premise Open-Weight Models and a Fixed-Scope Sprint

    Forfis ran a process audit in the first 72 hours, mapping the manual review workflow end-to-end and identifying the three highest-volume document types: payment service agreements, merchant onboarding contracts, and settlement invoices. The pilot scope was fixed to one document type (merchant onboarding contracts) and one integration point (Confluence for template retrieval, Salesforce for review status).

    The architecture used open-weight models on-premise: a fine-tuned Mistral 7B for field extraction and a Llama 3 8B for clause-level risk scoring, both running on the client’s own NVIDIA A100 hardware inside the cardholder data environment. No document data transited a third-party API. The extraction pipeline parsed PDFs and scanned images, extracted 14 structured fields (parties, amounts, dates, penalty clauses, data-sharing terms), and assigned a predictive risk score from 0 to 100 based on clause deviation from the Confluence-stored standard template. A human-in-the-loop approval gate required a reviewer to sign off on any document with a risk score above 40 or any field touching payment terms. The integration sprint delivered the pipeline, the Confluence RAG connector, the Salesforce status webhook, and the baseline measurement dashboard in 10 business days.

    Outcome: 52% Cycle-Time Reduction and a 4.1% Error Rate

    The pilot ran for 10 business days on a sample of 1,800 merchant onboarding contracts. The measured results:

    • Median cycle time dropped from 14 business days to 6.7 business days, a 52% reduction. The 95th percentile improved from 28 days to 12 days.
    • Field-level error rate on the 14 extracted fields was 4.1%, below the manual baseline of 6.2%. The largest error source was date parsing on contracts with non-standard calendar formats (Hijri and Gregorian mixed), which the model flagged for human review rather than auto-filling.
    • First-response time for high-risk documents (score > 40) improved from a median of 9 days to 2.3 days, because the scoring model surfaced them at the top of the reviewer queue.
    • PCI DSS compliance: all document processing occurred inside the CDE. The assessor’s follow-up note confirmed no Requirement 3 gaps remained in the contract review workflow.

    The pilot did not cover settlement invoices or payment service agreements. Those were scoped for the rollout phase. The 2-week window was met: the pipeline went live on day 10, and the baseline report was delivered on day 14.

    Lessons for Similar Teams

    • Scope the pilot to one document type, not one business function. The client initially wanted all three document types in the 2-week window. Forfis pushed back and fixed the scope to merchant onboarding contracts. The result was a shippable, measurable pilot. Trying to cover three types would have produced a 6-week project with no baseline.

    • On-premise open-weight models are not a quality compromise for structured extraction. The Mistral 7B, fine-tuned on 400 labeled contracts, matched the manual extraction accuracy on 12 of 14 fields. The two fields where it trailed (Hijri date parsing, multi-currency amount normalization) were exactly the fields where human-in-the-loop approval was mandatory. The model’s job was to flag, not to decide.

    • Confluence as the RAG source is underused in fintech. Most teams store contract templates in SharePoint or a shared drive. Confluence’s REST API and page-level granularity made it a clean retrieval target. The model’s risk scoring improved by 11 percentage points when grounded in the client’s own template language versus generic legal boilerplate.

    • The 2-week timeline is a constraint that clarifies scope, not a reason to cut corners. The sprint worked because the architecture was pre-built: the extraction pipeline, the RAG connector, and the approval workflow were templated from prior engagements. The client-specific work was fine-tuning, Confluence mapping, and Salesforce webhook configuration. Teams without a reusable architecture will not hit 2 weeks.

    • PCI DSS compliance is an architecture decision, not a checkbox. Running the model inside the CDE on the client’s own hardware was the single most important design choice. It eliminated the need for data anonymization, third-party DPA negotiations, and residual risk assessments that would have added 3-4 weeks to the timeline.

  • AI Ticket Triage for a Swiss Fintech: A Two-Week On-Premise Pilot

    The Problem: Manual Triage Is Your Largest Support Cost

    You run a 1,200-person fintech in Zurich. Your support team handles 4,000 tickets a month across chargebacks, onboarding, API errors, and account disputes. Every ticket is read, classified, and routed by a human before a specialist touches it. That first pass takes 90 seconds on average, and it is the single largest cost driver in your support operation. You have heard about AI agents, but your data residency requirements mean you cannot send ticket content to a US-hosted API. You need a triage agent that runs on your own hardware, plugs into your existing helpdesk, and gives you a measured cost-per-ticket reduction in two weeks. This is a fixed-scope pilot: one queue, one routing logic, one baseline report, and a go/no-go decision.

    Prerequisites: What You Need Before Day One

    Before the pilot starts, you need four things in place. First, access to your helpdesk API (Zendesk, Freshdesk, Jira Service Management, or equivalent) with read and write permissions on the target queue. Second, a Notion or Confluence workspace containing your support knowledge base, with API access for retrieval. Third, a GPU server or a private cloud instance with at least 80 GB of VRAM (an A100 80 GB or two A100 40 GB cards) to serve the open-weight model. Fourth, a 200-ticket sample from the last 90 days, exported with timestamps, categories, and resolution notes, to serve as your baseline dataset. If any of these are missing, the two-week timeline slips. Confirm all four with your IT and support leads before day one.

    Step 1: Audit the Triage Workflow and Define the Baseline

    Spend the first two days mapping the triage workflow. Export 500 historical tickets from your helpdesk. Tag each one with the category a human assigned, the time from creation to routing, and whether the routing was correct. Build a confusion matrix from this data. This tells you which categories the human team already struggles with, and it becomes the ground truth for evaluating the agent. The deliverable is a one-page process map: ticket arrives, human reads, human classifies, human routes, specialist responds. You are automating the first three steps. The specialist response stays human. This boundary is fixed for the pilot.

    Step 2: Deploy the Open-Weight Model On-Premise

    Deploy the open-weight model on your GPU server. Use vLLM to serve Llama 3 70B or Mistral 8x7B with a 128k context window. The model receives the ticket text, the category taxonomy from your process map, and a retrieval-augmented context pulled from your Notion or Confluence knowledge base. The prompt instructs the model to output a JSON object: {“category”: “chargeback_dispute”, “priority”: “high”, “route_to”: “chargeback_team”, “confidence”: 0.94}. The confidence score is critical: any ticket below 0.80 is flagged for human review instead of auto-routing. This is your human-in-the-loop gate, and it is non-negotiable for a fintech environment.

    Step 3: Wire the Agent to Your Helpdesk via API

    Build the orchestration layer that connects the model to your helpdesk. Use a lightweight workflow engine (n8n, Temporal, or a custom Python service) to poll the helpdesk API for new tickets in the target queue. For each ticket, the engine calls the model, parses the JSON output, and writes the classification and routing decision back to the helpdesk via the API. The engine also logs every decision, the confidence score, and the timestamp to a local database. This log is your audit trail and your source for the before/after comparison. The integration is read-write on the helpdesk only; no other system is touched in the pilot.

    Step 4: Run Shadow Mode and Measure Accuracy

    Run the agent in shadow mode for three days. It processes every new ticket in the target queue, but its routing decision is not applied. A support lead reviews each decision against what a human would have done. You track three metrics: classification accuracy (does the agent pick the right category?), routing accuracy (does it send the ticket to the right team?), and cycle time (how fast does the agent classify versus the human average of 90 seconds). After three days, you have 150-300 shadow decisions. If accuracy is below 90%, you tune the prompt, adjust the retrieval context, or narrow the category taxonomy. You do not move to live routing until accuracy is above 90% on the shadow set.

    Step 5: Go Live on One Queue with Human-in-the-Loop

    Switch the agent to live routing on the target queue. The human-in-the-loop gate remains: any ticket with a confidence score below 0.80 is routed to a human reviewer instead of auto-routed. For the remaining tickets, the agent’s classification and routing are applied directly in the helpdesk. You monitor the queue for five business days. The support lead reviews a random 20% sample of auto-routed tickets each day to catch drift. If the misclassification rate exceeds 5% on any day, you pause live routing and return to shadow mode. The five-day live window gives you enough data to compute a reliable before/after comparison on cycle time and error rate.

  • Fixed-Scope Pilot vs. In-House Build: Lead Qualification for a UK Fintech

    What Is Being Compared

    The two options are distinct in scope and risk profile. Option A is a fixed-scope pilot delivered by an external product studio: a 6-8 week engagement on one workflow—lead qualification—using the Anthropic Claude API as the model layer, integrated via custom REST API and webhooks into the existing CRM. The studio handles technical planning, product design, and full-cycle development. The pilot ships with a measured before/after baseline on cycle time and error rate. Option B is a fully in-house build: the company’s own engineering team designs, develops, and operates the agent, using the same model API or an open-weight model on internal hardware. The in-house team owns the architecture, the integration, and the ongoing operation. Both options target the same use case—lead qualification for a 201-500 employee fintech in the UK—but they differ in who bears the delivery risk, how fast the first working system ships, and what the company must maintain after the pilot.

    Criteria for the Comparison

    The comparison is judged against seven criteria that matter to a fintech scaling operations without new hires:

    • Time to first working system — how many weeks from kickoff to a live agent handling real leads.
    • Total cost of ownership over 6 months — including model API costs, integration work, and ongoing operation.
    • PCI DSS scope impact — whether the agent’s data boundary touches cardholder data and what that means for compliance.
    • Error rate reduction — the measured delta in misclassified leads between the manual baseline and the agent.
    • Cycle time reduction — the measured delta in time from lead creation to qualified status.
    • Vendor lock-in — how easily the company can switch model providers or take the system in-house after the pilot.
    • Operational burden — who monitors, tunes, and maintains the agent after the pilot ends.

    Comparison Table

    Criterion Option A: Fixed-Scope Pilot (External Studio) Option B: In-House Build
    Time to first working system 6-8 weeks from kickoff; studio has delivery templates and prior fintech experience 12-16 weeks minimum; team must design architecture, build integration, and tune the model from scratch
    Total cost over 6 months Fixed pilot fee (typically £25,000-£40,000) plus Anthropic API usage (approx. £1,500-£3,000/month at 500-1,000 leads/month); no new hires 2-3 FTEs at £60,000-£80,000/year each plus API costs; total £150,000-£250,000 over 6 months including salaries
    PCI DSS scope impact Studio designs data boundary to exclude cardholder data; client retains compliance ownership Same design principle, but in-house team must validate the boundary against PCI DSS 4.0 requirements; no external review
    Error rate reduction Measured in pilot; studio ships with baseline and delta report; typical delta: 30-50% reduction in misclassification Measured after build; no external baseline; team must design the measurement framework themselves
    Cycle time reduction Measured in pilot; typical delta: 40-60% reduction in time-to-qualified Measured after build; no external baseline; team must design the measurement framework themselves
    Vendor lock-in Low: model-agnostic architecture; client can switch to OpenAI or an open-weight model post-pilot Low: in-house team controls the stack; no external dependency
    Operational burden Studio provides handover documentation and a 30-day post-pilot support window; client takes over operation In-house team owns all operation, monitoring, and tuning from day one

    Scenario-by-Scenario Verdict

    When Option A wins: The company has no dedicated AI engineering team and needs a working lead qualification agent within 6-8 weeks to hit a quarterly sales target. The fixed-scope pilot removes delivery risk: the studio has delivered similar systems for fintech and payments clients in Tier-1 markets, and the pilot’s measured baseline gives the sales team a concrete number to report to leadership. The 6-month timeline is tight for an in-house build, and the pilot’s fixed fee is a smaller commitment than hiring 2-3 engineers. For a 201-500 employee company where every new hire is a significant cost, the pilot’s cost profile is easier to justify.

    When Option B wins: The company already has a strong engineering team with experience in API integrations and LLM applications, and the lead qualification workflow is one of several AI initiatives the team is building. The in-house build gives the team full control over the architecture, which matters if the company plans to extend the agent to other workflows (invoice processing, document extraction) over the next 12-18 months. The in-house team can also choose to run an open-weight model on internal hardware if the data residency requirements tighten, without renegotiating a vendor contract.

    Recommendation

    For a 201-500 employee UK fintech with a 6-month timeline and no dedicated AI engineering team, Option A—the fixed-scope pilot on the Anthropic Claude API—is the better fit. The pilot’s 6-8 week delivery window fits the 6-month timeline with room for a rollout phase after the pilot. The fixed fee is a smaller financial commitment than hiring 2-3 engineers, and the studio’s prior experience with fintech and payments clients in Tier-1 markets reduces the risk of a failed pilot. The measured baseline on cycle time and error rate gives the sales team a concrete business case for scaling. The model-agnostic architecture means the company is not locked into Anthropic; if the data residency requirements change, the team can switch to an open-weight model on internal hardware without rebuilding the integration. The in-house build is the right choice only if the company already has the engineering capacity and the lead qualification agent is part of a broader AI roadmap that justifies the longer build time and higher cost.