What happened
In a Habr article, Oleg, managing director of Rosselkhozbank’s Center for Financial Technologies, recounts moving the bank’s individual-customer chat from a vendor platform to an internally built one. The bank had already developed its own chat, bot and operator workstation for business customers. The vendor’s platform had handled about 60% of individual-customer requests without an operator, but the vendor’s replacement came with migration and integration costs. The internal platform was already integrated with bank systems, and the bank wanted control over its code, data and models. The article says a small dedicated team for individual-customer chats comprises three backend developers, two frontend developers, two testers, an analyst and a product manager.
The migration took a quarter for adaptation and another six months for rollout. The team rebuilt customer scenarios rather than simply copying them. The initial catalog had 50 scenarios; it grew to more than 400. New integration scenarios were released every two weeks or more often, and FAQ scenarios could be updated daily because they were stored in a database and did not require an app release. The bank gradually expanded access, moving operators between old and new chat systems as customers migrated. The rollout also exposed performance issues under heavier load, including database queries and event-processing paths.
Automation fell from the vendor platform’s roughly 60% to 40% as real customers arrived. The initial bot relied on matching phrases, which failed on spelling variations, synonyms, informal language and multiple questions in one message. The team first added navigation buttons and manually expanded phrase examples. It then deployed paraphrase-multilingual-MiniLM-L12-v2 in an int8 ONNX version. The model creates embeddings for intent matching; it does not generate customer-facing text. The article says it runs on CPU, with model and tokenizer files sized at 118 MB and 4 MB respectively. Its reported benchmark on 4,565 real requests was 2.9 ms median, 6.7 ms at p95 and 8.4 ms at p99 for the full request path. Loading took 0.4 seconds; recalculating embeddings for 14,083 phrases across 113 intents took 10.2 seconds.
The routing pipeline combines embedding similarity and PostgreSQL full-text search. It can launch a scenario when confidence is high, ask the customer to choose among up to four candidate buttons when intent is ambiguous, or fall back to a default step, usually an operator. The article’s headline reports automation reaching 75%. It also describes navigation into app modules and transactional workflows, including changing a card PIN and blocking a card. The model returns a scenario identifier; deterministic code performs the banking action.
What the archive adds
We have not covered this before; it opens a new thread.
Trend signal
This case does not yet fit a pattern New Runtime tracks. The article describes a production intent router and deterministic banking workflows, but does not establish a broader shift in agent protocols, portable skills or model economics.
Why now
The bank’s account connects the project’s timing to migration pressure: it says a 2022 decree set a technology-independence direction for state-participation banks and deadlines for critical systems. When the vendor’s replacement required substantial migration and integration spending, the bank compared that path with expanding its existing internal platform. Later, the support queue made improved recognition urgent; the team says it chose a CPU model because GPUs and AI specialists were not then available to the project.
Why it matters
The useful lesson is not that a small embedding model will automatically deliver a particular automation rate. It is that a production support system can separate language understanding from the authority to act. The classifier selects among reviewed scenarios; deterministic code and bank integrations carry out the operation. That boundary makes it easier to audit what the model did and avoids letting generated text become an instruction to a banking system.
The fallback design also treats uncertainty as a workflow state rather than a failure. When two candidate intents are close, asking a customer to choose can be safer than forcing a classification or sending every ambiguous request to a person. Teams can apply the same pattern to internal support, account servicing or other bounded workflows: measure latency and automation on real traffic, keep a clear human route, and use customer choices to improve intent examples. The reported 75% is a result claimed in the article’s headline, not a general benchmark for other deployments.
Limits and uncertainty
The figures are reported by the bank’s author, not an independent evaluation. The article describes the timing and scope of its tests, but the reported latency does not establish comparative accuracy, false-routing rates or performance across other languages and customer populations. The 75% automation figure in the headline is not accompanied here by a full definition of the metric or a baseline period. The account also describes a particular bank’s integrations and operating environment; teams without similar control over workflows, data and staffing may not reproduce its results.
Reader takeaway
A small classifier can be useful in customer support when its job is narrowly bounded: route a message to a known workflow, ask for clarification when candidates are close, and leave execution to deterministic services. The transferable design is the uncertainty-handling and action boundary—not the headline automation percentage or a promise that CPU inference alone solves support automation.