---
id: "lib-2026-11-05-no-vendor-no-gpu-how-we-moved-a-bank-chat-to-our"
type: "library"
title: "No vendor, no GPU: how we moved a bank chat to our own platform and reached 75% automation (Без вендора и GPU: как мы переводили банковский чат на собственную платформу и выросли до 75% автоматизации)"
lang: "RU"
org: "RSHB"
source_type: "Practitioner post"
date: "2026-11-05"
week: "2026-W45"
url: "https://nosov.ai/library/lib-2026-11-05-no-vendor-no-gpu-how-we-moved-a-bank-chat-to-our/"
original_url: "https://habr.com/ru/companies/rshb/articles/1103790/"
tier: "A"
tier_name: "Strong evidence"
tier_reason: "First-hand Habr case by the managing director responsible for Rosselkhozbank's chats, with the full intent-matching design, thresholds, measured latency and a 7,014-conversation accuracy sample, and candid notes on what was not measured."
summary_basis: "full-text"
original_minutes: "16"
tags: ["business transformation", "ai technology", "banking customer service", "intent classification on cpu", "vendor exit", "contact centre load"]
---

# No vendor, no GPU: how we moved a bank chat to our own platform and reached 75% automation (Без вендора и GPU: как мы переводили банковский чат на собственную платформу и выросли до 75% автоматизации)

Tier A (Strong evidence): First-hand Habr case by the managing director responsible for Rosselkhozbank's chats, with the full intent-matching design, thresholds, measured latency and a 7,014-conversation accuracy sample, and candid notes on what was not measured.

Summary based on the full text.

## In short

A Habr post (5 November 2026) by Oleg, managing director at Rosselkhozbank's fintech development centre, on moving the bank's retail chat (millions of clients) from a domestic vendor to an in-house platform. The vendor wanted payment for the import-substitution upgrade and again for migration. On the in-house keyword-matching bot, automation fell from the vendor's ~60% to ~40% and contact-centre queues grew. With no GPUs and no AI staff, the team added a quantised MiniLM encoder on CPU next to Postgres full-text search, plus clarifying buttons; automation is now ~75%.

## Key numbers

- ~60% / ~40% / ~75%: chat automation with the vendor, after the move on keyword matching, and now with a CPU MiniLM encoder
- 93.3%: bot answers on topic in a check of 7,014 conversations (26-30 June)
- 2.9 / 6.7 / 8.4 ms: p50 / p95 / p99 end-to-end latency on 4,565 real requests, CPU only
- 50 to 400+: chat scenarios at launch versus now
- 9 of 759: messages with words like "fraudster" or "stolen" that were real fraud cases

## What it reports

- Team of 9 (3 backend, 2 frontend, 2 testers, an analyst, a product owner) on the bank's internal PaaS; Python/FastAPI, React, Postgres Pro, Kafka. Adaptation took a quarter, roll-out another six months.
- Scenarios had to be reverse-engineered from the vendor's Elasticsearch store; 50 at launch, now over 400. Integration scenarios ship every two weeks, FAQ scenarios any day, without app releases.
- Real clients wrote very differently from the team's test traffic; early waves picked from vendor reports were inactive, so the team switched to its own app statistics.
- Model: paraphrase-multilingual-MiniLM-L12-v2, int8 ONNX, 118 MB, three dependencies; deployed in a few days. Re-embedding 14,083 phrases for 113 intents takes 10.2 s.
- Scoring: 0.7 x cosine + 0.3 x Postgres FTS rank; unconfirmed candidates need cosine of at least 0.75 (0.85 for "magnet" intents); auto-run when the top score is at least 0.9 and leads by 0.12, otherwise up to 4 clarifying buttons, otherwise an operator. Weights and thresholds were set by expert judgement, with no ROC analysis.
- Failure modes: one UnionPay answer captured every UnionPay question until phrases were balanced across scenarios; a single threshold could not say "I don't know".
- In 13,000 first messages in a week, over 10,000 wordings were unique and the top 20 covered under 10%.
- Integration scenarios let the bot block a card or open the PIN-change screen for a chosen card: five instruction steps became two taps.
- Automation is the share of conversations closed by 3 minutes of client silence; accuracy is checked separately by hand and by a strong LLM on masked exports.

## How they got it

Production metrics from the bank's own platform: latency on 4,565 real requests, an accuracy audit of 7,014 bot-answered conversations, and an early threshold sweep on about 1,100 synthetic queries. The author states which figures were not kept.

## Limits

- The 75% automation figure uses silence as a proxy for success; the author says a client may have given up.
- The vendor's ~60% was measured by the vendor, possibly differently.
- No cost comparison in money; the author says the in-house team costs somewhat more than the licence.

## Why it matters for companies

For intent routing, a small encoder on ordinary CPUs, paired with full-text search and a clarify step, reached higher automation than a mature vendor NLU, and security approval was easier because the model only picks a validated scenario. The bigger gains came from data balance and from letting the bot act in banking systems. Plan for an initial drop below the incumbent when real customers arrive, and measure accuracy separately from automation.

## Key passages in translation

> Но по мере подключения реальных клиентов автоматизация просела до 40% – против 60% у вендора.

But as real clients were connected, automation sank to 40%, against 60% with the vendor.

> Забавно, но именно «тупость» модели (она только классифицирует и ничего не генерирует) сильно упростила согласования.

Funnily enough, it was the model's "dumbness" (it only classifies and generates nothing) that greatly simplified the approvals.

> Честно признаем: молчание – это прокси для «бот помог», а не гарантия.

We admit it honestly: silence is a proxy for "the bot helped", not a guarantee.

Original: https://habr.com/ru/companies/rshb/articles/1103790/