Forward-Deployed Engineering · Lending · Compliance operations
Case study: periodic KYC updation, from a due date to a signed file
Illustrative engagement — not a client record. The lender, people, volumes and results below are a representative composite, written to show how a forward-deployed engagement runs end to end. The workflow, the architecture, the controls and the method are real and technically valid.
Offering usedRegulated & Secure DeploymentInside your perimeter: your cloud, your premises or no network at all.
Illustrative results, first 90 days after cut-over, in-scope accounts only:
about 97,000
Accounts past their periodic updation due date
Before about 184,000
7 minutes
Median compliance officer time on an approvable file
Before 26 minutes
1.8%
Files returned with defects in the internal audit sample
Before 9.5%
0, by design
Screening matches closed without a named person
Before not measured
Explainer09 entries
The whole story in about a minute
Nine short scenes, from the overdue backlog to the results. Press play, or pick a scene.
Session09 / 09
>Results
A smaller backlog, and faster, cleaner files.
Illustrative, first 90 days: overdue accounts fell from about 184,000 to about 97,000, officer time per file from 26 to 7 minutes, and audit returns from 9.5% to 1.8%.
26 → 7median officer minutes on an approvable file
Overdue accounts roughly halved
Audit returns 9.5% → 1.8%
No account frozen by the system
At a glance
- Client
- A non-banking financial company in the middle layer: about 2.1 million active retail loan accounts — two-wheeler, consumer durable and small personal loans — sourced across fourteen states through branches and business correspondents
- Workflow
- Periodic updation of KYC: find the accounts due, ask through existing channels, read what comes back, match it against records and permitted verification sources, attach screening results, prepare a file for a compliance officer, and track the backlog
- Engagement
- Regulated & Secure Deployment (scoped per environment: the lender's own cloud account, twelve weeks), with Handover & Enablement as the last two weeks
- Team
- One named senior forward-deployed engineer, full time. Client side: the Head of Compliance Operations (owner), the Principal Officer under the money-laundering rules, a core systems analyst, a platform engineer, the model risk reviewer from the risk function, a security reviewer
- Where it runs
- The lender's own cloud account in an Indian region, with open-weight models self-hosted in that account. Identity numbers stay in the lender's existing vault
- Handover
- Exit gate dated at scoping; runbook executed by the client's engineers in the dry run; our access revoked at the gate
| Measure | Before | After |
|---|---|---|
| Accounts past their periodic updation due date | about 184,000 | about 97,000 |
| Median compliance officer time on an approvable file | 26 minutes | 7 minutes |
| Files returned with defects in the internal audit sample | 9.5% | 1.8% |
| Screening matches closed without a named person | not measured | 0, by design |
| Accounts frozen, closed or marked compliant by the system | not applicable | 0, by design |
FDE / 01Case study
01 / 12
In shortCustomer records were overdue for their periodic check, and the team could not keep up by hand.
KYC is not done once. The rules require a regulated entity to update a customer's records periodically — at least every two years for high-risk customers, every eight for medium risk, every ten for low risk — with advance intimations before the due date and reminders after it, at least one of each by letter. Where nothing has changed, or only the address has, a self-declaration through a registered channel is enough. Aadhaar one-time-password based verification and the video-based customer identification process are both permitted for updation, and business correspondents may collect the declaration.
The lender had 2.1 million live accounts and a compliance operations team of 22. About 184,000 accounts were past their due date. Most were high-risk customers on the two-year cycle, plus a long tail of accounts whose first files had been captured on paper at branches years earlier.
The work was manual, and it looked like this:
A monthly list from the loan system, built by an analyst with a query, of accounts approaching or past the due date.
Intimations sent by whichever channel the branch preferred, tracked in a spreadsheet.
Documents arriving by app upload, by email, at branches, and through business correspondents.
An officer opening each one, comparing it with the record on screen, checking the screening system's output, and filling a checklist.
The cost showed up as risk, not just delay. Supervisory penalties for pendency in periodic updation are a regular feature of the sector's press. Internal audit was returning nearly one file in ten. And each month the list grew faster than the team could clear it.
FDE / 02Case study
02 / 12
In shortAn earlier tool approved accounts on its own, so audit switched it off.
Eighteen months earlier, operations had bought a document-reading tool to clear the backlog in bulk. It ran for eleven weeks and was switched off by internal audit.
It decided. If the name and date of birth on a document matched the record, the tool marked the account compliant and wrote the update. No officer saw the file.
It could not see what it was missing. Audit found accounts marked compliant on documents that had expired, and one file where a potential screening match had been closed because the tool treated an empty response from a batch report as "no hit".
It had no record of itself. There was no log of what the tool had read or why it had concluded anything, so the affected population could not be identified without re-opening every account it had touched.
Nobody owned it. It belonged to an operations project, not to the compliance function whose officers signed the files in law.
The remediation — re-opening about 40,000 accounts — is what made the Head of Compliance Operations insist on two things at the start of this engagement: a person signs every file, and every step leaves a record.
FDE / 03Case study
03 / 12
In shortTwo weeks with compliance, risk and security, ending in a signed scope: the system prepares, people decide.
The first fortnight was spent with the compliance team, the risk function and the security lead. The engineer sat with three officers for two days each, watched a branch collect a self-declaration, and read the loan system, the document store and the screening system.
The environment plan. The lender's board-approved policy on artificial intelligence, written after the central bank's 2025 framework for responsible and ethical enablement of AI, did not permit customer records to reach an outside model service. The deployment was therefore inside the lender's own cloud account in an Indian region, with open-weight models self-hosted in that account and egress blocked at the edge. Identity numbers are tokenised in the vault the lender already runs; the workflow service handles masked copies and tokens only, and never a full identity number.
What was found:
FIG. 3.1- A false assumption. Everyone described the screening system as "an API". It produced a daily batch file. Reading it as though it were live would have repeated the previous tool's worst failure — an empty response mistaken for a clean result. The design made a missing or stale screening result a blocking state, not a pass.
- Downloads from the central KYC registry require the customer's consent for each request, and the registry notifies the lender when a record it holds changes. Both of those are events the workflow can be built around.
- The risk function maintained a model inventory and an independent validation procedure, in anticipation of the central bank's draft model risk guidance. Anything we built with a model would have to enter that inventory and be validated by someone other than its builder.
- Around a third of overdue accounts belonged to customers who had never responded to any intimation. No system was going to change that; the question was whether the lender could prove it had asked properly.
The one-page scope, signed by the Head of Compliance Operations and noted by the Principal Officer:
- WorkflowPeriodic updation for retail loan accounts: due-date identification, intimations and reminders, document and self-declaration intake, matching, verification, screening attachment, file preparation for officer approval, backlog tracking
- Out of scopeNew customer onboarding, the video-based identification interview itself, risk categorisation policy, account closure, transaction monitoring, corporate and partnership accounts
- MetricApprovable files produced per officer hour, at or above the audit quality the team sets: 99% on critical fields and no file presented as complete with an open screening match
- OwnerHead of Compliance Operations; the Principal Officer owns screening outcomes
- GuardrailsNo account is frozen, closed, restricted or marked compliant by the system. A compliance officer approves every file. Every potential screening match goes to a named person. Full audit trail of every step
- Exit gateIndependent model validation complete, security review signed, two weeks of shadow-run parity, the handover dry run passed, our access revoked
Timeline09 entries
The engagement, stage by stage
Nine stages on one clock, from the overdue backlog to ninety days after cut-over. Press play, or pick a stage.
Ledger09 / 09
A smaller backlog, and faster, cleaner files.
26 → 7median officer minutes on an approvable file
- Overdue accounts roughly halved
- Audit returns 9.5% → 1.8%
- No account frozen by the system
267
FDE / 04Case study
04 / 12
In shortTwelve weeks: build it, secure and validate it, shadow the team, cut over, hand over.
five working days
W0Scope
What happened
Scope page signed; environment plan agreed with security; access requested to the loan system, the document store, the screening output and the intimation channels
What existed at the end
The signed scope and an access checklist
What happened
Scope page signed; environment plan agreed with security; access requested to the loan system, the document store, the screening output and the intimation channels
What existed at the end
The signed scope and an access checklist
What happened
Repository in the lender's source control; engineer joined the compliance stand-up
What existed at the end
First pull request merged on day seven: the due-date engine listing accounts from risk category and last update date
What happened
Intake and reading running behind a feature flag on real submissions; golden set agreed with the officers
What existed at the end
A prototype and a golden set of 1,500 past files with known outcomes
What happened
Intimation and reminder scheduling with proof of despatch, document reading, record matching, verification calls, screening attachment, the officer's approval screen, the audit trail, the backlog dashboard
What existed at the end
A system preparing files, approving nothing
What happened
Threat model, penetration of the egress controls, secrets in the vault, and independent model validation by the risk function. The reviewer was unavailable for five working days, so the clock paused, as agreed at scoping
What existed at the end
A signed security review and a validated entry in the model inventory
What happened
Every due account prepared in parallel with the team; files compared with what officers produced
What existed at the end
Two weeks of parity evidence
What happened
Live for one product, then two, then all in scope, each step gated on the audit sample
What existed at the end
Real files reaching officers, rollback one switch away
What happened
Runbook written and corrected by the client's engineers; training by doing; the dry run; the exit gate
What existed at the end
Signed runbook, decision record, revoked access, the pager on their rota
five working days
Calendar time was twelve weeks and five working days. The five days were the paused clock in week six, written down when the validation slot moved.
FDE / 05Case study
05 / 12
In shortA system that prepares each file with its evidence, for an officer to sign.
Try a file
Pick what comes back. Watch where the file goes.
The same system prepares every file and approves none. What comes back, and what the checks find, decide whether it reaches the officer or waits for a person.
File log01
- 01Due list On the due list from its risk category and last update date
- 02Intimations Intimation sent; channel, date and proof of despatch recorded
- 03Intake Lands in the one intake queue, whatever the channel
- 04Read Fields read into a strict schema, each with the page region it came from
- 05Match Compared with the account record: name, date of birth, address
- 06Verify Checked with the issuing source where the lender is entitled to
- 07Screen Screening output attached with its run date: no match
- 08File prepared Record, submission, matches and checklist on one screen
- 09Officer decides The officer approves under their own login and signature
- Accounts frozen or closed by the system
- 0
- Identity numbers seen
- Masked copies and tokens
- Runs in
- The lender's own cloud account
File status
Due list. Deterministic rules read the risk category and the date of the last update and produce the accounts due, the accounts overdue and the accounts due within the intimation window. Risk categorisation itself is the lender's policy and is not touched.
Intimations and reminders. The scheduler sends through channels the lender already uses — application, message, email, branch and business correspondent — and raises letters for the ones the rules require to be posted. What it records is the point: each despatch, its channel, its date and its proof, so the lender can show it asked properly before anything follows from silence.
Intake. Self-declarations of no change or of a change of address, and document submissions, land in one queue whatever channel they arrived through. Records from the video-based identification process, conducted as before by the lender's own authorised officials, are attached as evidence; the system never conducts an interview.
Read. A layout-aware document model reads the submitted pages. A self-hosted language model fills a strict schema — name, date of birth, address, document type, document number in masked form, issue and expiry dates — with the page region each value came from. An unreadable field is left empty and named as unreadable. It is never inferred from the record it is supposed to be checked against.
Match. Deterministic comparison against the account record and, where the customer consents, the registry record: name, date of birth, address, document type and validity. Name comparison is the hard part in fourteen states and several scripts, so the matcher scores and shows its reasons — initials expanded, surname first, transliteration variants — and a score never closes a file by itself.
Verify. Where the lender is entitled to check a document against its issuing source — the identity verification service, documents issued through the government document locker with their signatures checked, the permanent account number service — the check is made and its response stored with the file. A failed or unavailable check is a state, not a silent pass.
Screen. The screening system's output for the customer is attached, with its run date. Three states only: no match, potential match, or stale. A potential match sends the file to the Principal Officer's designated analyst, with the list, the matched fields and the evidence, and the file cannot be presented as complete until that person records their conclusion. A stale result blocks the file. Nothing in the pipeline can clear a match.
File prepared. The officer sees one screen: the customer's record, what was submitted, what each field matched, the verification responses, the screening state, the checklist, and every discrepancy named in plain language, each linked to its evidence. The officer approves, returns for more information, or rejects, under their own login and digital signature.
Write-back. Only after approval does anything change: the loan system's KYC fields and next due date, and the record filed with the central registry through the lender's existing process. No account is frozen, restricted or closed by the system, ever; where the rules require a consequence for continued non-response, the case goes to the officer with the history attached, and a person acts.
Tracking. Dashboards show the backlog by product, state, risk band and age; intimations sent and answered; files by stage; officer throughput; audit sample results. Thresholds page the platform engineer, and the Principal Officer gets a weekly report the compliance committee can read.
System map20 objects
How the pieces connect
Every system, person and record a file passes through, lit one scene at a time. Press play, or pick an event.
objects10 / 20
Object09 / 09
A smaller backlog, and faster, cleaner files.
- · Overdue accounts roughly halved
- · Audit returns 9.5% → 1.8%
- · No account frozen by the system
FDE / 06Case study
06 / 12
In shortA test of 1,500 past files that every change must pass before it reaches an officer.
1,500 past periodic updation files, sampled across products, states, channels, risk bands, document types and languages, including files internal audit had previously returned.
Answers taken from the approved outcome: the fields as the officer finally recorded them, the discrepancies they raised, and the audit finding where there was one.
A screening slice built with the Principal Officer: past potential matches, the true ones and, more importantly, the many false ones, so the harness measures both.
A red-team slice: an expired identity document, a document belonging to a different person with the same name, an address that differs only in building number, a screening output older than the policy allows, and an empty screening file — the exact failure the previous tool had made.
Scoring: 99% on critical fields; recall on discrepancy detection; zero tolerance for a file presented as complete with an open or stale screening state; and a measured false-discrepancy rate, because a file returned to a customer for nothing is a cost too.
The suite runs in the lender's pipeline, and its results are part of the model inventory record. In week nine it caught what mattered most: a change to the name matcher, meant to handle a southern-state initial convention, raised the score on two red-team pairs of different people with the same name to just below the threshold at which a discrepancy is raised. The build failed. The matcher's thresholds are now scored separately for each script.
FDE / 07Case study
07 / 12
In shortIt runs in the lender's own cloud account, and it can read and compare but never approve.
Egress is blocked at the edge and was tested by attempting it and recording the block.
Perimeter. The system runs in the lender's cloud account, in an Indian region. Models are open-weight and self-hosted in that account; nothing calls an outside model service. Egress is blocked at the edge and was tested by attempting it and recording the block.
Identity numbers. Full national identity numbers stay in the lender's existing vault. The workflow service sees masked copies and tokens. Stored document images are masked to the last four digits.
Identity and access. Officers act under their own logins and sign with their own credentials. The service account can read the listed sources and write files in a pending state; it cannot approve, and it has no permission to change an account's status. Our engineer's access ran through the lender's identity provider and was revoked at the gate.
Can
- read the listed sources
- write files in a pending state
Cannot
- approve
- change an account's status
Model governance. Each model is an entry in the lender's model inventory, classified by impact, with its purpose, data, evaluation results, monitoring thresholds and limitations recorded, and validated by the risk function rather than by its builder. The feature flag that returns all work to the manual queue is documented as the stop control.
Data protection. The purpose is a legal obligation the lender carries; the notice, retention and access rules were reviewed against its data-protection duties, and the breach procedure with its notification steps is in the runbook.
Autonomy is bounded. Models read and compare. Rules check and hold. People decide: the compliance officer on every file, the designated analyst on every screening match, the Principal Officer on anything reportable.
FDE / 08Case study
08 / 12
In shortTwo weeks in the shadow, then one product at a time, with one flag to turn it off.
Two weeks of shadow running came first. The system prepared a file for every account the team was working on, and the officer never saw it; the files were compared afterwards. Three quarters agreed exactly. Of the rest, most were the system raising a discrepancy an officer had waved through — old addresses that differed by a building number — and the officers agreed the system was right. A handful were the system missing a document the officers knew a particular state's authorities issue in two formats. That format joined the golden set.
Cut-over went by product: two-wheeler loans first, then consumer durables, then personal loans. Each step needed a clean week of audit samples. Rollback was one flag that sent every account back to the manual queue with its documents intact. It was rehearsed in week ten.
01two-wheeler loans
02consumer durables
03personal loans
EACH STEP · a clean week of audit samples
FDE / 09Case study
09 / 12
In shortThe lender's own engineers proved they could run it before we left.
The last two weeks were the Handover & Enablement phase, planned from the scope page with a dated exit gate.
In the dry run, the client's engineers released, rolled back, added a new state's document layout and scored it against the golden set, with our engineer in the room and off the keyboard. The runbook was signed after that. Credentials were rotated in the final week and ours were revoked at the gate.
Key numbers09
The story in nine numbers
One number for each scene, from about 184,000 overdue accounts to seven minutes a file. Press play, or pick a number.
Reading09 / 09
26 → 7median officer minutes on an approvable file
A smaller backlog, and faster, cleaner files.
- Overdue accounts roughly halved
- Audit returns 9.5% → 1.8%
- No account frozen by the system
FDE / 10Case study
10 / 12
In shortFewer overdue accounts, faster officer reviews, and fewer files returned by audit.
Figures are illustrative, measured on in-scope accounts over the first 90 days after cut-over.
The overdue population fell from about 184,000 to about 97,000. The limit was never the officers' speed alone; it was how many customers answered.
Median officer time on an approvable file fell from 26 minutes to 7. The officers spend it on the files with discrepancies, which is where their judgement is worth something.
Files returned by internal audit fell from 9.5% to 1.8% of the sample. Most of the remaining returns are judgement calls on address evidence.
BEFORE9.5%AFTER1.8%Every potential screening match was closed by a named person, with a recorded reason, and no file was presented as complete on a stale screening result.
No account was frozen, closed, restricted or marked compliant by the system. A compliance officer signed every file that changed anything.
Proof of asking. For non-responding customers, the lender can now show each intimation and reminder, its channel and its date, which is what a supervisor asks for.
What did not improve, and was never promised:
FIG. 10.2Customer response rates barely moved. Better letters and more channels are a different problem, and a real one.
Customers without a registered mobile number still have to visit a branch or meet a business correspondent.
Video-based identification capacity is unchanged. Those interviews are conducted by the lender's officials and always will be.
Nothing in the backlog older than the document store's earliest scans got easier; those files are still rebuilt by hand.
FDE / 11Case study
11 / 12
In shortSix rules for anyone preparing regulated files with a model.
- A missing answer is not a clean answer.
The single most important rule in the system is that an absent or stale screening result blocks the file. The previous tool failed on exactly that.
- Officers sign; systems prepare.
It is the law in this workflow, and it is also what made the audit short.
- Put the model in the inventory on day one.
Validation by someone other than the builder is going to be asked for. It is easier to plan for than to retrofit.
- Name matching is a language problem, not a string problem.
Score it per script, and show the reasons.
- Record the asking, not just the answering.
Proof of intimation is worth as much as the completed file.
- Pause the clock in writing.
A reviewer's diary is a legitimate reason to stop, if both sides record it the day it happens.
FDE / 12Case study
12 / 12
In shortThe lender kept it in-house, extended it to address changes, and scoped a second engagement.
The lender kept the system in-house. Their team extended the same file preparation to customer-initiated address changes, which arrive through the same channels. A second engagement was scoped for onboarding files at business correspondent points, where the same evidence problem exists earlier in the customer's life.