Collections Assistant
Will rank who to chase, draft the notice in their language and wait for your officer.
Recovery in most institutional lenders is run from a spreadsheet of who owes what, refreshed by hand and already out of date when the calls start. Reminders go out late, in the wrong language, quoting a figure that has moved since the export. There is no consistent view of ageing, no record of what was promised on a phone call, and no way to tell whether the effort spent chasing one entity produced more recovery than the effort spent on another.
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
Ageing and bucket computation
Deterministic and first in the pipeline. The collections module will compute days past due, assign the bucket, and split the overdue amount across penal, interest and principal using the same waterfall that runs in production today. No model participates in this step.
- 02
Risk shaping
Each overdue account would be scored on likelihood of recovery within the next cycle, using repayment history, the grant-deduction or instalment calendar, prior promise behaviour and any fiscal signals the lender supplies. The score would order a work queue. It will never change a balance, a bucket or a due date.
- 03
Action sequencing
A next action would be proposed per account against the lender's own written recovery ladder: a first reminder, a formal notice, an escalation to the zone, a meeting request, a grant-deduction instruction. The ladder is yours; the sequencing would decide where each account sits on it.
- 04
Message drafting
The communication is designed to be drafted in the borrower's language from your approved template. Figures would be merged from the deterministic ledger at the moment of drafting, so a notice cannot quote a stale number, and the model will not author the numeric content.
- 05
Human review and dispatch
A named officer would review, edit and send. Dispatch will run through the notifications layer across email, SMS or WhatsApp according to the entity's recorded preference, with delivery status recorded against the account.
- 06
Response capture and learning
Replies, promises to pay, part payments and non-responses would be recorded against the account and would feed the next cycle's sequencing, so the queue reflects what actually happened rather than what was planned.
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 Assistant would propose | A named human would approve |
|---|---|
| A ranked recovery queue by likelihood and exposure | Which accounts are worked this cycle |
| A recovery score with the factors behind it | No approval to give: the score would be advisory and would move no figure |
| The next rung on your recovery ladder for each account | The action, before anything is sent |
| A drafted notice in the borrower's language with merged figures | Every notice, individually or in a reviewed batch, before dispatch |
| A suggested escalation to zone level | The escalation, and its receipt by whoever holds regional oversight |
| A recorded promise to pay from a captured reply | Confirmation of the promise and its due date |
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.
- Bucket definitions and DPD thresholds
Your ageing bands, your grace treatment, and whether ageing counts from due date, from grace expiry or from a scheme-specific trigger.
- The recovery ladder
The written policy: what happens at each stage, who owns each rung, how many days between rungs, and what triggers a jump straight to escalation.
- Templates and languages
Your notice wording per rung, in each language you actually serve, with only merge fields variable. Legal and regulated wording would stay locked.
- Contact policy
Quiet hours, frequency caps per entity per period, permitted channels, and any statutory notice period that must elapse between communications.
- Exclusions
Which accounts are suppressed from dispatch: under dispute, under restructure, subject to a board matter, in reconciliation, or flagged manually.
- Escalation routing and reporting
Which bucket escalates to whom, how zone-level review is scheduled, and how recovery performance is reported by bucket, officer and scheme.
Inputs
- The overdue position from the ledger
- repayment history per entity
- the grant-deduction or instalment calendar
- the entity contact directory with language preference
- your written recovery policy
- notice templates per rung and language
- notification channel configuration (email, SMS, WhatsApp)
- prior correspondence and promise history
- dispute and restructure flags
Outputs
| Artefact | Format |
|---|---|
| Ageing and bucket view across the book, filterable by zone, scheme and officer | In-app and Excel |
| Prioritised action list per officer for the cycle | In-app and PDF |
| Drafted notices queued for approval, with merged figures | PDF and DOCX |
| Dispatch log with channel, timestamp and delivery status | Excel |
| Promise-to-pay register with due dates and outcomes | Excel |
| Recovery performance report by bucket, officer, scheme and zone | PDF and 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.
- Owning the queue
Works the day's list, records outcomes and logs promises to pay.
- Confirming the overdue figure
Verifies the amount against the ledger before any formal notice quoting it is issued.
- Configuring
Owns the escalation ladder, the message templates, the exclusion list and the contact policy, including quiet hours.
- Reviewing recovery performance
Reads escalations and outcome rates for one segment of the book.
- Reviewing after the fact
Reads the dispatch log and the promise register: what was sent, to whom, quoting what figure.
The borrower is the recipient, and sees its own position and the full correspondence history in its portal.
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 overdue figure is disputed or under reconciliation
The account would be suppressed from dispatch automatically until the dispute closes, and the suppression reason would be visible in the queue. A demand notice quoting a figure the borrower has already challenged does more damage than a late notice.
An account looks delinquent but its grant deduction is simply scheduled later
The deduction calendar would be a hard input to the ageing computation, not a factor in a model. Scheduled recovery will never be presented as delinquency, which is the most common false positive in on-lending books.
The contact detail or language preference is missing
The draft would be held with a data-gap task, not sent in a fallback language to an unverified address. A notice in the wrong language to the wrong recipient is a compliance event, not an inconvenience.
Regulated or statutory notice wording is required
The template would be yours, locked, with only merge fields varying. The model will not rewrite, shorten or improve legal wording, and the design does not offer that as an option.
An account is ranked high risk with almost no history behind it
It would be presented as unscored with the reason stated, rather than scored badly. Sparse-history accounts would sort into a separate review list instead of being ranked against accounts with years of behaviour.
Why it sits where it does
A later build, and the placement is a prerequisite fact rather than a judgement about value. The collections module and the notifications layer are both ahead of it, and an assistant built before them would produce ranked predictions with nowhere to act on them.
What has to exist first
- A collections module with DPD buckets, ageing and a promise-to-pay register
- notifications across email, SMS and WhatsApp
- the entity contact directory with verified channels and language preference
- the lender's written recovery policy
- sufficient repayment history in the platform to make sequencing meaningful, which in practice means several cycles after go-live
What buyers actually ask about this
The drafting itself would happen inside your deployment, and contact details would reach only the dispatch channel you configure, because that is how a message is delivered, with those providers named in the deployment agreement rather than chosen by us. A lender that wants drafting only, with dispatch handled by its own existing channel, will be able to run it that way, and the security page sets out the detail.
It will not be able to send anything. Every notice would be reviewed and dispatched by a named officer, figures would be merged from the deterministic ledger at draft time rather than authored by the model, and accounts under dispute or reconciliation would be suppressed automatically. The failure mode the design protects hardest against is a confident notice quoting a contested number.
The lender issuing it, which is exactly why dispatch would be gated on a named human and why exclusions would be enforced by the system rather than by memory. We will build the suppression rules, the frequency caps and the locked templates so that the officer approving a notice is approving something that has already passed your own policy checks.
Yes, and some lenders will. Ageing, buckets, the overdue split and the promise register are deterministic parts of the collections module, which is later platform work. Once it is built, the scoring, sequencing and drafting layers would sit on top and each could be switched off. A lender will be able to take the ranked queue and write its own letters, or take the drafts and rank manually.
It would stay in your deployment as part of the loan record, under the retention period you set, and it would be visible to the Auditor as evidence of what was sent and when. Correspondence will not be used to train any shared model, and inside your own deployment it would feed your own sequencing.
Inside your own deployment, yes: outcomes, promises kept and promises broken would feed the next cycle. The same isolation applies here, and the security page sets out the detail. That is also why this capability is sequenced late. A model trained on a few months of one book is a guess with a decimal point, and we would rather say so than ship a score you cannot defend to a committee.
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