Document Intelligence
Will read sanction orders and resolutions into draft records, and draft your letters back.
Sanction letters, approval minutes, rate circulars and KYC files arrive as PDFs and scans, and somebody retypes them into the system. Data entry is the largest hidden cost in institutional lending operations, and retyping is also where the wrong amount, the wrong date or the wrong scheme enters the ledger in the first place. Documents then live in a shared drive with no link to the loan they authorise, so an auditor asking "show me the order behind this waiver" starts a search rather than opening a record.
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
Ingest and classification
A document would be uploaded against a loan, or dropped into a watched location, and classified by type: sanction letter, approval minute, waiver or write-off authorisation, rate circular, KYC document, bank mandate, general correspondence. Classification confidence would be recorded with the document.
- 02
Layout parse and field extraction
OCR with layout retention, then extraction against the field template configured for that document type. Each field will return a value, a confidence score and a bounding box on the page, so the citation is visual and checkable in one glance.
- 03
Validation against masters and rules
Extracted scheme, entity, rate, amount and date would be validated against the configured masters and the lender's business rules: is the rate inside the scheme band, is the entity active, is the sanction inside the scheme ceiling, is the order date inside the resolution's validity.
- 04
Proposal into the workflow
The result would become a pre-filled draft, for example a draft loan sanction or a draft waiver, with each field showing its source citation and confidence beside it. It is designed as a draft in the existing maker-checker flow. It is not a record, and it will not skip an approval step.
- 05
Outbound generation
From approved records, the capability will draft outbound documents using your templates and merge fields: sanction letters, demand notices, certificate covering letters, acknowledgements. Figures on outbound documents would come from the ledger, not from the model.
- 06
Filing and linkage
The source document would be attached to the loan, indexed for search, and stored with its extraction result, so an auditor can put the page and the field side by side without leaving the record.
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.
| Document Intelligence would propose | A named human would approve |
|---|---|
| A document type classification | Reclassification where the type is wrong or unrecognised |
| Extracted field values with page citation and confidence | Every field below the confidence floor, and every amount field regardless |
| A validation result against masters, ceilings and bands | Any override of a failed validation, with a reason |
| A pre-filled draft sanction, waiver or rate change | The record itself, through the existing maker-checker approval |
| A drafted outbound letter or notice from your template | Issue of that document, by the officer with authority |
| A proposed link between a document and a loan | The link, where confidence is below the floor |
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.
- Document types and field templates
Which document types you actually handle and what fields matter on each. A state finance board's sanction order and a cooperative bank's member resolution share almost no layout, so the templates would be built against your documents.
- Languages and scripts
Which languages your orders and resolutions are issued in, including bilingual documents where the operative amount appears in one script and the narrative in another.
- Confidence floor per field
Set field by field. Amount, date, rate and entity identifier can be held far stricter than remarks or address, because the consequences differ.
- Validation rules and ceilings
Scheme rate bands, sanction ceilings, entity eligibility, resolution validity periods, and what happens on a failure: block, or allow with a recorded override.
- Outbound templates
Your letterhead, your wording, your merge fields, your signature blocks, and which role may issue each document type.
- Retention and redaction
How long source documents and extraction results are kept, and which KYC fields are masked or redacted at rest and by role.
Inputs
- Scanned or digital sanction orders
- board and committee resolutions
- waiver, write-off and restructure orders
- rate circulars
- KYC and entity constitution documents
- bank mandates
- the scheme and entity masters
- your outbound document templates
- the field templates and validation rules agreed during configuration
Outputs
| Artefact | Format |
|---|---|
| Extraction result with per-field value, confidence and page citation | On-screen, exportable JSON and Excel |
| Pre-filled draft record in the maker-checker queue | In-app |
| Validation report per document, listing passes, failures and overrides | |
| Document index attached to each loan, searchable by type, date and reference | In-app |
| Generated outbound documents | PDF and DOCX |
| Extraction quality report: fields accepted, corrected and rejected, by template | Excel |
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.
- Reviewing the draft
Reads the extracted fields against the source page and corrects what the model got wrong.
- Validating a figure
Confirms against the ledger any number that will appear in a document sent outside the organisation.
- Approving the record
Commits extracted data to a loan. Separate from reviewing, so a lender that wants two pairs of eyes can enforce it.
- Configuring
Owns the document templates, the confidence threshold below which nothing auto-fills, and the validation rules.
- Reviewing after the fact
Uses the document index and the page-to-field comparison to see where any stored value came from.
Where the lender enables it, the borrower uploads its own documents into the same pipeline.
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:
A handwritten register or resolution in a regional script
Extraction confidence will be low and the design does not hide that. The document would route to assisted transcription with the page image displayed beside each field, and the operator would type the value while the system holds the context. It is slower than machine extraction and considerably faster than retyping from a physical file.
Two versions of the same sanction order carry different amounts
Both would be surfaced with their dates, references and page citations, and an officer would nominate the authoritative one. There will be no most-recent-wins rule, because in practice the superseding order is not always the later file.
The amount in words disagrees with the amount in figures
A hard stop. Both values would be shown with their citations and a human would decide. Amount conflicts will never resolve automatically, in either direction, regardless of which one carries higher extraction confidence.
The document type is not recognised
It would be filed as unclassified, attached to the loan and made searchable, and it will never be guessed into a workflow. An unclassified document that is filed is recoverable. A misclassified document that pre-fills a sanction is a liability.
Scan quality is below the usable threshold
It would be rejected at ingest, with the specific reason (skew, resolution, cropping, contrast) and a re-scan instruction. The failure belongs at upload, not three steps later at the ledger.
Why it sits where it does
A second-wave build, and the least certain of the second-wave group because extraction accuracy depends on document quality we cannot assess in advance. It is placed second in build order behind the Migration Copilot for a practical reason: the Copilot builds the OCR, layout parse and citation machinery against the hardest possible input, historical registers. Document Intelligence would extend that layer to live operational documents rather than paying for it twice. On the outbound side it depends on configurable certificate and letter templates, named in the dependencies.
What has to exist first
- The extraction and citation layer from the Migration Copilot
- config-driven schemes with rate bands and ceilings
- configurable certificate and letter templates for outbound generation
- agreed field templates per document type. Already in place: the maker-checker approval workflow
What buyers actually ask about this
In your deployment, under your retention policy, with access governed by your configured roles and the existing zone and borrower scoping, and with no separate document store introduced outside the platform boundary. Storage location, including in-country or on-premise where a mandate requires it, is set in the deployment agreement, and the security page sets out the detail.
Extraction would happen against the deployment you control, and your documents will not be used to train any shared model. Which components run locally and which, if any, call an external service is a configuration decision made with you before go-live. KYC fields would additionally be masked by role and redacted at rest.
Amount fields would carry the strictest confidence floor by default, and a mismatch between words and figures would be a hard stop rather than a judgement call. Every field will show its citation on the page, so verification is a glance rather than a re-read. And nothing will become a record without passing through the maker-checker approval that already governs every sanction today.
The approver, named in the append-only trail, which is why the design keeps the citation attached all the way to the approval screen rather than dropping it after extraction. Our responsibility is that the citation will be accurate, the confidence honestly reported, and low-confidence fields never quietly filled.
Yes, type by type. A lender will be able to use extraction for sanction orders and rate circulars while keeping KYC entirely manual, or use only the outbound generation half and none of the reading half. The capability is designed as a set of separable stages precisely because appetite differs by document class.
Partly, and it is worth being clear about which part. Machine extraction works well on typed and printed orders and poorly on handwriting. For handwritten stock, the value would be in assisted transcription, classification, indexing and linking the document to the loan, which is where most of the retrieval pain actually sits. We would scope that honestly against a sample of your real files before you commit.
Other capabilities
Migration Copilot
Will read your legacy loan book, rebuild every timeline and reconcile every balance.
See the designAnomaly & 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 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