Every AI capability will propose. None will write.
AI in lending cannot be one product. Your documents, your languages, your thresholds and your approval rules are not anyone else's, so each of these seven is built against your book. This page sets out what each will do, and the architectural rule none of them may break.
Most lending platforms bolt a chat box onto a ledger and call it AI. GoDravix starts from the opposite end. The foundation is already running in production: a deterministic engine, six separated roles, and an append-only trail where every event carries an actor and a timestamp. The seven capabilities below are built onto that foundation, and every one of them obeys the same rule: AI proposes, the deterministic engine computes, and a named human approves before anything touches a loan balance.
No two lending books need the same AI. Your document formats, your languages, your thresholds and your approval routing are what the capability is shaped around, which is why we build these with design partners rather than shipping one fixed version.
Why the sequence matters more than the list. Anyone can name seven AI features. We build the migration one first, the hardest and least glamorous of the seven, because we have already solved that problem by hand on real historical data and know exactly what it takes.
No model output will reach a balance without a human approving it
This is the constraint every capability on this page will inherit. It is also the reason this takes longer than a demo-driven approach would.
- 1The requestAn operator asks in plain language. Nothing is written yet.
- 2The proposalThe model reads the ledger and drafts a timeline, dates and amounts.
- 3The engineInterest, penal and waterfall stay with the production code, never the model.
- 4The approvalIt sits pending. No balance moves until a named person accepts it.
- 5The writeAppended with proposer, approver and timestamp. Still reversible.
- ExplainableEach proposal states the records it read and the reasoning behind the figure.
- AttributableProposer and approver are two distinct identities in the ledger.
- ReversibleAn approved proposal is undone by a correcting event, never by an edit.
What each one does, why it sits where it sits
Ordered by build sequence rather than by how well they demo.
Migration Copilot
Would read legacy ledgers, spreadsheets and scanned registers, rebuild each loan’s timeline, run the month-by-month interest recompute, and output an old-versus-new reconciliation report with the variance on every loan stated explicitly.
Why it sits here: It attacks the single biggest reason lenders refuse to switch systems. We have already solved this problem manually on real historical data, which means we are automating a method we understand rather than inventing one.
Read the full designAnomaly & Reconciliation Guard
Would enforce the accounting identity across the book continuously and flag what breaks it: negative interest, duplicate entries, missed accrual runs, balances that will not reproduce from the event log.
Why it sits here: It turns a documented weakness, an order-sensitive interest engine, into something the platform checks continuously and reports on.
Read the full designAsk-Your-Portfolio
Would answer plain-language questions against the loan book, including in Indian languages, and auto-draft board briefings from those answers.
Why it sits here: It removes the reporting bottleneck for organisations where every question currently becomes a request to the one person who knows how to build the export.
Read the full designDocument Intelligence
Would extract structured data from sanction orders, loan applications and KYC documents, and generate outbound documents from the extracted fields.
Why it sits here: Data entry is the largest hidden cost in institutional lending operations, and most of the source documents are already structured enough to read reliably.
Read the full designCollections Assistant
Would predict which accounts are likely to fall behind and draft reminder communications in the borrower’s language.
Why it sits here: It cannot be built before the collections module exists. Building the assistant first would produce predictions with nowhere to act on them.
Read the full designEligibility & Risk Scoring
Would score a proposed sanction against the borrowing entity’s fiscal health and repayment history.
Why it sits here: A score is only defensible once it has been tested against outcomes across many entities and several sanction-to-recovery cycles. That history is created by the platform running, which is why this one is last.
Read the full designIn-app Copilot
Would answer “how do I…” questions in context, trained on the six role-based user manuals.
Why it sits here: The manuals already exist, with screenshots, one per role. The knowledge base is written; this is the capability with the shortest distance between here and useful.
Read the full designNeed an AI capability we have not named?
The seven above are what we intend to build for everyone. If your workflow needs something else (a different extraction, a different check, a different report drafted) we can scope and quote it as development against the same guardrail: it proposes, your engine and your people approve.
Tell us what you needWhy the boring one goes first
The obvious commercial move is to build Ask-Your-Portfolio first. It demos beautifully, it takes weeks rather than quarters, and every prospect nods at it.
We are building the Migration Copilot first instead, for three reasons. It addresses the objection that actually loses deals rather than the one that wins meetings. It automates a method we have already executed manually on real historical data, so we are not discovering the problem in production. And it is the hardest of the seven to copy, because copying it requires having done the migration work by hand first.
Capabilities five and six are sequenced late for a duller reason: they have prerequisites. A collections assistant needs a collections module to act into, and a risk model needs history across more than one institution. Building either early produces something that looks finished and is not.
How migration works| # | Capability | What has to exist first | Wave |
|---|---|---|---|
| 1 | Migration Copilot | Order-independent engine | First |
| 2 | Anomaly Guard | Order-independent engine | First |
| 3 | Ask-Your-Portfolio | Continuous integrity check | Second |
| 4 | Document Intelligence | Extraction layer from migration | Second |
| 5 | In-app Copilot | Maintained help centre | Second |
| 6 | Collections Assistant | Collections module | Third |
| 7 | Risk Scoring | Multi-tenant history | Third |
None of the seven is running today. Each is specified in detail and built against the lender’s own documents, languages and thresholds, so no two deployments of the same capability look alike.
About the AI layer
The platform in production today is conventional, deterministic software: loan lifecycle, interest engine, waterfall allocation, certificates, reporting and an append-only audit trail. None of the seven AI capabilities on this page is running today.
We publish them in this much detail because the sequence, the guardrail and the failure modes are what a buyer needs in order to judge whether the thing is real. A demo is the worst possible moment for the distinction to come as a surprise.
It means no model output will ever write directly to a loan balance. An AI capability produces a proposal (a reconstructed timeline, a flagged anomaly, a drafted reminder) which sits in a pending state. The deterministic engine, the same code that runs every live loan, computes any financial figures. A named human with the relevant authority then accepts or rejects.
The ledger records both identities separately: who proposed, who approved. Because the trail is append-only, an approved proposal that later turns out to be wrong is reversed by a correcting event rather than edited away.
Interest is computed by the deterministic engine and always will be, whatever the AI layer grows into. That is the clearest line we draw. A model may propose that a historical loan’s timeline looked a certain way; the interest arising from that timeline is then calculated by the same code path that runs every other loan in the system, so the result is reproducible and checkable.
We give target dates on a call rather than on a web page, because a date published in July and missed in November does more damage than no date at all. What we can say here: it is first in the sequence, the manual method it automates is already documented and proven on real historical data, and migration work continues to be delivered by our team in the meantime.
Nothing leaves today, because no AI capability is live. When these are built, data handling and model hosting become part of the deployment agreement rather than a default we set unilaterally. For a government finance body or a regulated lender, where the data goes is frequently the whole conversation.
Ask us what is real
Bring the AI capability your board has asked about. We will tell you whether it is built, in build, or a slide, and what the honest date looks like.
45 minutes | On the live deployment | A straight answer on fit