Migration Copilot
Will read your legacy loan book, rebuild every timeline and reconcile every balance.
Decades of loan history sit in departmental Excel workbooks, handwritten sanction registers and scanned approval orders, and rebuilding that history by hand takes months of an accountant's time before a single new loan can be sanctioned in a new system. Worse, the interest convention the old book was maintained under is frequently undocumented. On a real municipal loan carried over several years, neither simple interest nor monthly compounding reproduced the closing figure the lender's own register showed. That combination, high manual cost plus an unprovable opening balance, is the single biggest reason lenders stay on a system they have outgrown.
The pipeline, stage by stage
Each stage names what goes in and what comes out, because a capability you cannot inspect is a capability you cannot audit.
- 01
Records intake and classification
Designed to accept Excel workbooks, CSV extracts, digital PDFs and scanned register images. Each file would be classified by type, paged, scored for legibility, and entered into an inventory that would state exactly what arrived and what is readable before any extraction begins.
- 02
Layout parse and field extraction
OCR with layout retention for scans, header and structure inference for spreadsheets. The pipeline will extract loan identifier, sanction amount and date, scheme, each disbursement row, each repayment row, rate changes and waiver orders. Every extracted field will carry a citation back to its source page and coordinates, or its source cell.
- 03
Master matching
Extracted scheme names, borrowing entity names and rates would be matched against the configured scheme and entity masters using exact match, fuzzy match and the lender's own alias list. Anything unmatched would queue for a human decision. No master record will be created silently to make an import succeed.
- 04
Timeline reconstruction
Events would be ordered chronologically per loan and checked for structural gaps: a repayment with no prior disbursement, an interest charge with no rate in force, a closure with a residual balance. The output will be a proposed event sequence carrying a dedicated migration opening reference, so a migrated balance is always distinguishable from a balance created in the system.
- 05
Deterministic recompute
The proposed timeline will be handed to the production interest engine, which runs the month-by-month accrual and the penal-interest-principal waterfall. The model will not calculate a rupee of interest at any point in this pipeline.
- 06
Variance reconciliation
The recomputed closing position would be compared against the legacy figure loan by loan. Variance would be decomposed into principal, interest and penal components, and each loan would be issued a reconciliation record that cannot be closed without a disposition.
What it proposes, and what you approve
This is the architectural rule of the whole AI layer, made specific to this capability. Nothing a model produces reaches a balance on its own.
| The Copilot would propose | A named human would approve |
|---|---|
| A file inventory and a legibility assessment | Which files are in scope for the migration |
| Extracted field values with page or cell citations and a confidence score | Every field below the configured confidence floor, individually |
| Master matches for scheme, entity and rate | Creation of any new master record, and every fuzzy match |
| A reconstructed event timeline per loan | The timeline, loan by loan, before it is committed |
| The recomputed balance from the deterministic engine | Acceptance of the recomputed balance as the opening position |
| A quantified variance split into principal, interest and penal | The written disposition of that variance: replicate the legacy convention, or adopt the platform method and route the residual through the waiver workflow |
| An exception register of everything it could not resolve | Closure of each exception, with a reason |
| A portfolio-level cut-over pack | Cut-over itself, signed, before the legacy system is retired |
Shaped to your book, not shipped as one fixed version
These are the decisions you make and we build against. They are the reason two deployments of the same capability do not look alike.
- Source formats and languages
Which register layouts, spreadsheet templates and scripts your history is actually in, including Hindi, Marathi, Gujarati or a mixed-script register. Extraction templates would be built against your documents, not a generic sample.
- Scheme and rate master, with history
Your schemes, your rates, and the effective dates of every rate change, so the recompute applies the rate that was actually in force in each period.
- Interest convention policy, per scheme
The written decision made before migration begins: reproduce the legacy convention exactly, or adopt the platform method and treat the difference as a documented adjustment through the waiver workflow with an order reference.
- Variance tolerance
The band inside which a variance may be accepted with a note, and the band above which it must be escalated, set per loan and in aggregate, in your currency.
- Extraction confidence floor
Set per field type. Amount and date fields can be held to a stricter threshold than address or remarks, because the cost of a wrong amount is not the cost of a wrong address.
- Approval routing and cut-over sign-off
Who signs off a single loan, who signs off a zone, who signs off the portfolio, and whether the legacy system runs in parallel for a stated period before it is retired.
Inputs
- Legacy ledger exports and departmental spreadsheets
- scanned or digital sanction registers
- sanction letters and approval minutes
- rate circulars with effective dates
- waiver, write-off and restructure orders
- the last audited balance statement or trial balance
- the configured scheme master
- the configured borrowing entity master
- an alias list for entity and scheme naming variants
- a named person in the organisation who can answer questions about historical entries
Outputs
| Artefact | Format |
|---|---|
| Source inventory with legibility and page counts | Excel |
| Extraction result per document, with per-field citations and confidence | On-screen, exportable Excel |
| Proposed loan timeline, per loan | On-screen, Excel and PDF |
| Reconciliation pack per loan: legacy figure, recomputed figure, variance split by principal, interest and penal | |
| Portfolio variance summary, sortable by magnitude and by scheme | Excel |
| Exception register of unresolved and parked items | Excel |
| Cut-over sign-off record, naming every approver and every accepted variance | PDF, plus an append-only audit trail entry |
The duties this creates
Duties, not job titles. Each one below is a permission you grant, so you map them onto the roles you already have. Preparing, approving and configuring are separate by design, which is how you stop one person holding two of them.
- Running the reconstruction
Points the Copilot at a batch of legacy sources and works the exceptions it returns.
- Reviewing the recomputed figures
Reads the variance split loan by loan and decides whether the difference is explained.
- Approving a timeline
Commits one loan's rebuilt history. A separate permission from running the reconstruction, so the person who produced a proposal cannot accept it.
- Accepting the position
Signs off a whole segment before cut-over, once the loan-level approvals are in.
- Configuring
Owns the extraction templates, the masters they map to and the variance tolerance that decides what gets flagged.
- Reviewing after the fact
Read-only access to the source document, the proposal and the approval as three linked records.
After cut-over is signed, the borrower receives an opening balance statement showing the position it is being carried into.
What it will do when the data fights back
Any vendor can describe the happy path. These are the cases that decide whether a capability is safe to put near a loan balance. Designed behaviour in each case:
The historical convention cannot be reproduced by either interest method
The Copilot would surface the variance per loan, quantified and split, and force a written decision. It will not silently pick the method that produces the smaller number, and it will not close a loan's reconciliation record without a disposition attached.
A page is illegible, torn or missing from the register
The loan would be parked in the exception register with the specific page identified. No repayment, date or amount will ever be inferred from surrounding entries to complete a sequence.
The same loan appears in two source files with different figures
Both records would be surfaced side by side with their provenance and dates, and a human would nominate the authoritative source. There will be no most-recent-file-wins default, because the most recent file is often the least reliable.
A repayment predates every disbursement on the loan
The loan would be blocked rather than posted, and the ordering conflict shown with both source citations. Posting it would drive the accrual negative, which is precisely the failure mode the Anomaly Guard is designed to prevent.
The legacy book shows two different closing balances for the same period
A register total and an audited trial balance frequently disagree, so both would be carried into the reconciliation as separate comparison figures and the variance computed against each, rather than one being quietly preferred. The officer nominating the opening position would name the source in writing, and the rejected figure would stay on the reconciliation record with its variance stated. No opening balance will be committed while two candidate figures are still live.
Why it sits where it does
A first-wave build, and first of the seven despite being the largest and least certain build of the first wave. Three reasons. It attacks the objection that stops most system changes before they start: we cannot risk losing decades of loan history. It automates a method DigiWagon has already executed by hand on a real multi-year government book, with a documented reconciliation tracker, so the problem is being automated rather than discovered. And it is the hardest of the seven to copy, because copying it requires having done the reconciliation work manually first. It also builds the OCR and extraction layer that Document Intelligence would reuse in the second wave.
What has to exist first
- Deterministic, order-independent interest engine
- reproducible outstanding computation
- config-driven schemes with historical rates
- a records assessment completed with the lender before any file is loaded. Already in place: the documented manual migration procedure and reconciliation tracker
What buyers actually ask about this
Into your GoDravix deployment and nowhere else by default. Data residency is set in the deployment agreement before any file is loaded, not assumed by us. For a government finance body, in-country hosting or a government cloud target is the clause we would expect to settle first, and the migration cannot start until it is settled in writing.
Model hosting is a configuration decision made with you, covering which components run inside your boundary and which, if any, call an external service. Your documents are not used to train any shared model. Where a lender requires that nothing leaves the deployment at all, extraction would run against models hosted inside it, and that constraint is priced into the engagement.
Structure, not optimism. Every extracted field will carry a citation to the page or cell it came from, so a reviewer checks the working rather than the answer. Fields below the confidence floor would be left blank rather than filled. Gaps would become exceptions, never inferences. And no timeline will commit until a named human approves it loan by loan.
The organisation that approved it, which is why the approval will be named, dated and recorded in the append-only trail. That is not a way of shifting responsibility onto you: it is why the design forces a per-loan review rather than a bulk accept. Our contractual obligation is that the method is sound, the variance is disclosed, and the working is checkable.
Yes. The manual method exists, is documented, and is what our team runs today. The Copilot is designed to accelerate it, not to replace the judgement in it. A lender will be able to run extraction with AI and reconciliation by hand, or take the Copilot's inventory and do everything else manually. The pipeline is designed with those stages separable.
It is the hardest input and it is planned for. Handwriting in a regional script will produce low extraction confidence, and the design responds to that honestly: those pages would route to assisted transcription with the scanned image displayed beside the field, rather than being auto-filled. It is the slowest migration path, and it is where the Copilot would save the most operator time.
Other capabilities
Anomaly & Reconciliation Guard
Will prove continuously that every balance reproduces from the event log, and flag what does not.
See the designAsk-Your-Portfolio
Will let you ask the loan book a question in your own language and get a figure you can trace.
See the designDocument Intelligence
Will read sanction orders and resolutions into draft records, and draft your letters back.
See the designShape this one around your book
Bring your document formats, your languages and your thresholds. We will show you what this looks like against your own data.
45 minutes | On the live deployment | A straight answer on sequence