An agentic credit pipeline on Ragify: pilot experience at a top-5 Russian bank
A top-5 Russian bank is piloting a credit pipeline built on Ragify. We look at what problem was being solved, what had to be added to the platform for lending, what safeguards are placed on AI agent actions and what can be seen on test packages.
What problem the credit unit was solving
A top-5 Russian bank is piloting an agentic credit pipeline built on Ragify — a product within RESTART AI Platform. We do not disclose the bank’s name; the article contains neither its internal figures nor the pilot results. The pilot is ongoing, and here we describe the engineering side: what had to be built and why.
The task is typical for corporate lending. For each application, a package of company documents arrives: constituent documents, accounting and tax statements, bank account statements, contracts with customers, documents of guarantors and related companies. Usually this is two to three dozen files, some of them scans. Then the credit manager checks the set against the list, the analyst manually transfers indicators into calculation spreadsheets, reconciles the same values across documents, checks them against the credit policy and writes a conclusion, and then compiles the credit forms for the credit committee.
This leads to problems familiar to the head of a credit unit:
- manual entry of a package takes hours, and all this time the deal waits in the queue for an analyst;
- different analysts perform the same checks differently;
- deviations from the regulation — a number taken from another document, a standard breached by committee decision — get lost on the way to the credit form;
- the history of “who changed what and on what grounds” is pieced together from correspondence.
What is changing in the market
Open market data show where lending is heading. Leaders are moving the credit decision closer to the moment the client applies: the process starts with data about the client, and the application becomes confirmation of a ready-made offer. The target model for 2027–2029 looks like a chain of five links.
On the way to this model, banks run into two constraints. The first is manual labor: below a deal size of around a few million rubles, the involvement of a manager and an analyst is not economically viable (a market benchmark). The second is data: building a separate integration for each source takes a long time, and the information missing for a decision in practice sits in the client’s documents — financial statements, bank statements, contracts, collateral documents.
Hence the demand for an agentic process: AI agents prepare data and analysis, while the human role gradually shifts — deal operator, then controller, then owner of policies and metrics. The credit pipeline on Ragify covers the links of data from documents, methodology and the agentic process in this chain and works alongside the bank’s existing decision-making system, BPM and core banking system without replacing them.
Why not a separate development
A separate AI project for lending builds integrations, data protection, the role model and the log from scratch. The next project — procurement or contract review — costs almost as much as the first. We took a different path: we built the pipeline on Ragify, where the process is described by settings.
| What | How it is configured in Ragify |
|---|---|
| Credit application | Document package type: which documents are needed, what data to take from them, how to reconcile, what to check, how to calculate, which documents to compile as output, what the stages are and who approves |
| Bank methodology | Standards, reference books, calculations and check rules in the settings; maintained by the methodologist |
| Agents | Agent card: instruction, skills, model, operating mode and permissions; a new agent does not require development |
| Integrations | Connecting external systems in the admin interface; any HTTP API becomes an agent skill |
| Changes | Controlled versions; history is preserved, applications in progress are not broken |
The main architectural principle: the decision is calculated by a deterministic engine according to the bank’s methodology. The language model extracts data from documents, cites rules and writes drafts. Decisions on the deal are made by the employee and the bank’s engine.
For the bank, this means the process changes as quickly as the regulation does: the methodologist edits a standard themselves, without waiting in the development queue. And the environment, role model and masking rules approved by information security are then reused by other processes.
Participant packages, reconciliation and “no data per regulation”
The first thing we had to build for lending was handling company packages. A package is a folder of documents for one company. It can be created via the “Credit manager” agent even with just a TIN, before any documents exist. Files are uploaded by drag and drop, as an archive, or arrive by email. Each document goes through the path “received → recognized → type identified → data extracted → package recalculated”; documents are processed in parallel, and a recognition model can be selected for each document type.
Documents are not re-uploaded for a credit application: participant packages are linked to it by role — borrower, guarantors, related companies. Application data is taken from the packages, and an edit in the application shows a discrepancy with the package.
A source for every value
A link to the document and page; TIN, OGRN and KPP details are verified using check digits. A doubtful value is flagged and is not passed on silently.
Rule-based reconciliation
For each value, it is defined where to take it from — for example, revenue from a specific accounting document — and what to reconcile it with. A discrepancy is resolved by a person; a value accepted “as is” is recorded in the log.
“No data per regulation”
If a document required by the regulation is missing, the field is not filled in. The platform suggests fallback sources, anything taken outside the regulation is flagged, and the flag carries through to the conclusion and the credit form.
External sources
Information from state registers and counterparty verification services — at the click of a button or on request to the agent; requests run in parallel, a non-responding source is skipped with a reason, paid requests require confirmation. The bank determines the set of sources.
Methodology checks and waivers with grounds
Check rules are set by the methodologist, for example “the share of the largest customer does not exceed the credit policy standard”. The result of each check is passed, failed, no data or not applicable. Semantic requirements such as “the contract specifies the payment procedure and terms” are checked by the agent against the document text, with a quote provided.
The entire methodology lives in the settings: document types, data and reconciliation, checks, standards, reference books, calculations, output documents, stages and deadlines. A change goes through a version draft.
Calculations, conclusion and credit forms
The platform calculates indicators according to the bank’s methodology: turnover, concentration of customers and suppliers, current loans, expenses and profit, cash flow forecast and the maximum recommended loan amount. For each indicator, it is visible how it was obtained; if something is missing for a calculation, this is visible immediately. The analyst can ask the agent “what if” — how the amount would change with a different term or rate — and the agent recalculates using the same methodology without changing the application.
The analyst’s conclusion is compiled from ratings, business characteristics, strengths and weaknesses, and risks. The agent drafts some sections, the analyst edits them, and the human’s edit is not overwritten by the next draft. The conclusion and credit forms are compiled using the bank’s templates in Word and Excel.
Application stages, deadlines and transition buttons are also defined by settings. The queue issues applications in order; after a set number of days, an application is flagged “urgent”, after the deadline — “overdue”, and notifications and agents are triggered by these events.
Three agents and safeguards
Three agents are configured for the roles in the credit process. They work in the package and application card window, in chat and in a messenger, and are also launched by event triggers.
| Agent | Capabilities |
|---|---|
| Credit manager | Create a package, including by TIN only; upload documents; request information from external sources; say what is missing; prepare the text of a follow-up request to the client; fill in the credit request |
| Credit analyst | Answer questions about the application and documents; create an application and link participants; propose waivers for discrepancies and checks; calculate “what if” scenarios; compile reports; assign the manager to upload missing documents |
| Credit methodologist | Answer according to the credit analysis methodology from the bank’s knowledge base |
Five safeguards apply to all pipeline agents:
Employee permissions
The agent performs actions only within the permissions of the user on whose behalf it works: what a person cannot do, the agent cannot do either.
Confirmation
Important actions are confirmed by a person; the platform shows exactly what will be changed.
Result from the platform
The model cannot report an action that did not happen: the result is written by the platform.
Number verification and the log
Numbers in the answer are checked against the data, doubtful ones are flagged; every action is logged with the mark “via agent”.
Triggers launch agents without a person in the chat: “documents processed — report what is missing”, “checks failed — propose a waiver”. When the agent reaches an action that cannot be performed without a person, the employee gets a task in “My tasks”: confirm, reject or reply. The agent can independently perform only actions from an explicit list, after which the employee receives a “Check what was done” task with rollback. Letters to an external applicant are written by the Secretary agent — without internal checks and standards and only after review by a person.
Log, masking and the bank’s environment
For the bank’s IT and information security, the pipeline is just another process in a single approved environment.
The log answers the question that the committee or an auditor will inevitably ask: who — a person or an agent — changed what and when, which checks were waived and on what grounds, which documents were collected. The dialogue log, agent run history and settings changes are stored separately; an agent’s action is always distinguishable from a person’s.
What can be seen on test packages
Below are benchmarks obtained on test packages. These are not pilot results: on a specific bank’s documents, the figures are refined during the pilot.
≈10 minutes
A company package of 20–30 documents is ready for analysis. With manual entry, this takes hours.
≈95% of fields
Extracted correctly; each value has a link to the document page.
0 fabricated values
A doubtful value is flagged, a missing one gets the status “no data per regulation”.
Minutes for documents
Credit forms and a draft conclusion are compiled from the bank’s templates in minutes.
The last point matters more to us than speed: a credit form does not go to the committee with an empty cell or with a number taken from the wrong document — after compilation, the platform itself lists such places.
How the pilot works
The pilot format is shadow mode. The pipeline processes real applications in parallel with analysts, and the pipeline’s conclusions are compared with people’s decisions for each application. In this mode, the pipeline does not affect the bank’s decisions.
| What is measured | How |
|---|---|
| Share of correctly extracted fields | Spot check against the bank’s documents |
| Time until the package is ready | From upload to a recalculated package |
| Agreement of conclusions with analysts | Comparison on real applications in shadow mode |
In this format, success criteria and thresholds are agreed with the bank before the start. The bank needs to provide a process owner, a methodologist and analysts to compare results, the methodology, standards and templates for the conclusion and credit forms, as well as servers in the bank’s environment for the platform and local models.
The pilot is ongoing. Its results are not given in the article — only benchmarks on test packages.
A 24-slide presentation: the market and target model, the process by role, checks and methodology, agents and safeguards, the environment, the pilot. PDF, in Russian.
Download PDFWhat this means for banks, microfinance organizations, leasing and factoring
The pipeline is not tied to a single credit product. The methodology, document types and templates are settings, so the same mechanism can be transferred to adjacent types of financing with their own rules. Below is how it maps onto these processes; the specific set of settings is determined during discovery.
Banks
Corporate lending and SME: participant packages, the bank’s methodology, the conclusion and committee credit forms; alongside existing decision-making systems, BPM and core banking systems.
Microfinance organizations
The organization’s own document list and methodology; checks and calculations based on its standards, deviations are recorded in the log. For small deals, this is a way to reduce manual analysis.
Leasing
Lessee package and documents on the leased asset — new document types and checks in the same settings, reconciliation with the application.
Factoring
Supply contracts are checked by the agent against the text with a quote — for example, payment procedure and terms; the data of the client and its customers are reconciled by rules.
It makes sense to expand agents’ authority gradually, as trust in the results grows:
| Step | What the agents do | Employee role |
|---|---|---|
| Prove the value | Prepare data, checks, calculations and drafts; anything that changes the application requires confirmation | Deal operator |
| Link into a process | Triggers, “My tasks”, standard actions from an allowlist with review and rollback | Controller |
| Optimize the cycle | Run stages within policies, linked to the bank’s engine | Owner of policies and metrics |
At every step, the decision on the deal remains with the employee and the bank’s engine; the levels of agent involvement by stage are determined during AI-discovery.
Where else the same mechanism applies
Capabilities added for lending have become general Ragify capabilities. New processes are built through configuration: a new package type, checks, templates, agents and triggers.
| Scenario | What is used | Status |
|---|---|---|
| Collateral | Collateral documents, deadlines, reconciliation with the application | Scenario on the platform |
| Borrower monitoring | Deadlines, incoming emails, signals to the agent | Scenario on the platform |
| Problem debt | Debtor package, template letters, route | Scenario on the platform |
| Procurement | Commercial offer, contract, specification; reconciliation of details, price limit, counterparty check | Built from existing capabilities |
| Hiring | Candidate documents, validity periods, personal data masking, approval route | Built from existing capabilities |
| Contract review | Semantic checks against the text with a quote, waiver with justification | Built from existing capabilities |
| Application summaries and dashboards | Statuses, deadlines and risks across the portfolio | Development |
| Credit histories | As part of external sources, subject to the data subject’s consent | Development |
“Scenario on the platform” and “build” mean that the process is assembled from working capabilities; the composition and scope of work are determined during discovery. How these components work overall is described on the page Ragify in RESTART AI Platform; on knowledge bases in a bank’s environment, see the case of a top-5 Uzbek bank; on the rules governing agent actions, see the article on safe automation by AI agents.
If you head the credit unit, risk or IT at a bank, leasing or factoring company, start with an analysis of your process: which documents, which checks, where time is lost. The outcome will show whether a shadow pilot on your applications makes sense.
Let's discuss your environment
Describe the task, current systems, constraints, and expected results. We will offer a practical first step: diagnostics, pilot, audit, roadmap or project team.
