Swiss Fintech Cuts Candidate Screening Cost 78% with On-Prem AI in 4 Weeks

Background: A 300-Person Swiss Payments Firm Stuck in Pilot Limbo

This case study is a composite built from patterns Forfis has observed across multiple engagements in Swiss fintech and payments. No named customer is represented. The company described here is a mid-size payments processor in Zurich, roughly 300 employees, operating in the Running Isolated Pilots stage of AI maturity. It runs a standard on-prem ERP, a mid-market ATS, and Google Workspace as its primary collaboration suite. The team had tried two earlier AI pilots in 2023, both scoped to marketing copy generation, and had not moved past the pilot phase. The CTO wanted a third attempt that would actually change a cost line, not just produce a demo. The constraint was non-negotiable: candidate data could not leave the building, and the solution had to work inside the tools the recruiting team already used.

Challenge: 120 Applications a Month, 14 Minutes Each, and a Q3 Deadline

The recruiting team of six handled roughly 120 applications per month across four open roles. Each application required a recruiter to read the CV, extract key fields, compare them against the role criteria, and write a short assessment. The average time per application was 14 minutes, and the monthly reporting cycle for the CTO’s ops dashboard took two full days of manual spreadsheet work. The cost per processed application, loaded with recruiter salary and overhead, sat around CHF 18. The team was not understaffed in absolute terms, but the volume was growing 15% quarter-over-quarter as the firm expanded into new payment corridors. The CTO’s deadline was the end of Q3: a working pilot that reduced the cost per ticket and the monthly reporting effort, delivered in four weeks, with GDPR compliance documented before any candidate data was touched.

Approach: Four-Week Integration Sprint with an On-Prem Open-Weight Model

Forfis ran a one-week process audit that mapped the screening workflow end to end: application intake from the ATS, CV parsing, field extraction, criteria matching, recruiter review, and the monthly report. The audit confirmed that 70% of the recruiter’s time went to extraction and initial scoring, not to judgment calls. The pilot scope was fixed: build a document and data extraction pipeline that ingests CVs from the ATS, runs them through an open-weight model on the client’s own A100 GPU node, scores each application against weighted criteria, and writes the result back to the ATS and into a Google Docs template for the recruiter’s review. The model was a 7B-parameter Llama 3.1 8B fine-tuned on the client’s historical screening decisions. No candidate data left the building. The integration sprint ran four weeks: audit and baseline in week one, pipeline build in week two, shadow test in week three, and human-in-the-loop approval workflow plus handover in week four.

Outcome: 79% Less Time per Application, 78% Lower Cost per Ticket

The pilot processed 340 applications over a six-week shadow period, compared to the 120 the team handled manually in the same window. The model agreed with the recruiter’s accept/reject decision on 89% of cases. On the 11% where it disagreed, a structured review found the model was correct in 4 of 12 cases, the recruiter in 7, and 1 was genuinely ambiguous. The error rate on structured field extraction was 2.3% across 340 documents, down from the 8% baseline of the previous manual process. The recruiter’s manual time per application dropped from 14 minutes to 3 minutes for review, a 79% reduction. The cost per processed application fell from roughly CHF 18 to CHF 4, a 78% reduction, before accounting for the one-time GPU hardware cost. The monthly reporting cycle, which had taken two days of spreadsheet work, was reduced to a 20-minute review of an auto-generated summary in Google Docs. The CTO’s Q3 deadline was met on the fourth Friday.

Lessons for Teams Running Isolated Pilots in Regulated Fintech

• Baseline before you build. The 8% manual error rate and the 14-minute cycle time were measured in week one, not assumed. Without that baseline, the 2.3% and 3-minute results would have been unprovable. Every pilot should ship with a measured before/after on cycle time and error rate.
• On-prem is not a technical constraint, it is a compliance constraint. The client’s DPO required a documented data flow map before any candidate data was processed. The one-page diagram showing that all data stayed on the A100 node and that no external API calls were made was the single most important artifact in the engagement. GDPR Article 35 DPIA updates were handled in week one, not after the model was built.
• Integrate into the tools the team already uses. The recruiter’s review happened in a Google Docs template linked from a Gmail notification. No new dashboard, no new login. The adoption rate was 100% because the workflow lived inside the tools the team already used every day.
• Human-in-the-loop is not optional for regulated data. Every candidate decision required a recruiter’s approval. The model drafted, ranked, and flagged; the person decided. This satisfied both the GDPR accountability requirement and the team’s trust threshold.
• Fixed scope, four weeks, one workflow. The pilot touched one workflow, one model, one integration point. The CTO’s Q3 deadline was met because the scope was fixed in week one and did not expand.