Anomaly & Reconciliation Guard
Will prove continuously that every balance reproduces from the event log, and flag what does not.
In most lending operations a wrong balance is discovered at audit, sometimes years after it was created, and by then the correction is a negotiation rather than a fix. Loan systems accumulate the same small set of defects: a repayment entered twice, an accrual month that never ran, a rate applied outside the window it was in force, a back-dated entry that pushes interest below zero. GoDravix's interest engine is order-sensitive today, which is why the Guard is specified alongside the order-independence rebuild rather than after it.
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
Invariant definition
A set of accounting identities would be declared per loan and per portfolio: outstanding principal equals disbursed less principal repaid less principal waived; interest outstanding is never below zero; the balance recorded after each ledger event reproduces exactly when the event log is replayed from the opening reference.
- 02
Continuous evaluation
After every ledger event, and on a scheduled sweep, the event log will be replayed deterministically and the result compared against the stored balance. This is arithmetic, not inference, and it is designed to run whether or not the pattern layer finds anything.
- 03
Pattern detection
A model layer would sit over the exception stream looking for shapes the invariants alone will not catch: a duplicate repayment (same entity, near-identical amount, dates within a window), a missed accrual month in an otherwise regular series, a rate applied outside its effective dates, an out-of-order back-dated entry, a waiver posted without an order reference.
- 04
Triage and ranking
Each finding would be scored on currency impact, number of loans affected and how long it has been present, then grouped: twelve findings that share one cause become one case with twelve members, not twelve tickets.
- 05
Correction proposal
For each case the Guard will propose a specific correcting event: a reversal, a re-run of accrual across a stated month range, a duplicate marked for reversal. The before and after figures on that proposal would be computed by the deterministic engine, never by the model.
- 06
Disposition and closure
Approved corrections would post as new append-only events, never as edits. Rejected cases would close with a written reason, and the Guard is designed to remember that disposition so the same legitimate pattern is not re-raised every sweep.
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 Guard would propose | A named human would approve |
|---|---|
| A failed invariant, with the loan and the event that broke it | Nothing. A failed invariant is arithmetic, and it would be reported as fact |
| A suspected duplicate, missed run, or out-of-window rate | Whether the finding is a genuine defect or a legitimate business event |
| A ranked case list by currency impact and age | Which cases are worked, and in what order |
| A named correcting event with engine-computed before and after figures | The correction itself, before it posts to the ledger |
| An escalation when a case exceeds the materiality threshold | Acceptance or rejection of the escalation at zone or portfolio level |
| A monthly ledger integrity statement | Signature on that statement for the audit file |
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.
- Which invariants are hard blocks and which are advisory
A lender that wants "interest outstanding below zero" to physically prevent a save sets it as a block. A lender migrating a messy book may need it advisory for a defined period, with the exception visible.
- Materiality thresholds
In your currency and as a percentage of the loan, separately for detection, for escalation and for the audit statement, so a two-rupee rounding difference does not sit in the same queue as a two-lakh reversal.
- Duplicate detection window
The date range and amount tolerance that define a suspected duplicate for your recovery pattern. A lender recovering monthly by grant deduction needs a different window than one taking irregular cheques.
- Accrual calendar
Which day of the month accrual runs, how holidays and financial year end are treated, and what counts as a missed run for your book.
- Routing and escalation
Which finding types go to first-line triage, which require an approval permission, which escalate to whoever holds regional oversight, and the notification channel and quiet hours for each.
- Sweep frequency and statement cadence
Whether the replay runs on every ledger event, nightly or on demand at close, and whether the integrity statement is issued monthly, quarterly or when the audit asks for it.
Inputs
- The Guard runs against data already in the platform: the event log, the masters, the accrual history and the user directory. It needs nothing from the lender except the invariants, thresholds and routing named in Configured to your book
Outputs
| Artefact | Format |
|---|---|
| Live exception queue, filterable by type, impact, age and zone | In-app |
| Case file per finding: evidence, affected loans, proposed correction, engine-computed impact | |
| Daily integrity digest with the last successful sweep timestamp | Email and PDF |
| Disposition register: every finding, what was proposed, who approved or rejected it, the reason and the date | Excel |
| Ledger integrity statement for the period, listing open and closed exceptions | PDF, for the audit file |
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.
- Working the queue
First-line triage: reads each flagged item, gathers the context and proposes a disposition.
- Approving a correction
Anything that changes a balance needs this permission, and it is deliberately not the same one that works the queue.
- Configuring
Owns the invariants, the tolerance thresholds and the routing rules that decide what escalates and to whom.
- Receiving escalations
Takes the items that breach a threshold, scoped to one segment of the book.
- Reviewing after the fact
Reads the integrity statement and the disposition register with no write access anywhere.
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 legitimate event looks exactly like a duplicate
Two identical grant deductions in the same month against the same scheme are normal for some lenders. The finding would require an explicit "confirmed distinct" disposition with a reason, and that disposition would be remembered for the loan and the pattern, so nobody re-answers the same question every sweep.
The Guard detects a variance it cannot attribute to a cause
It would raise an unattributed case stating the amount and the affected loan, and stop there. It will never propose a balancing entry to make the identity hold. A plug figure with no named cause is the exact behaviour this capability is designed to eliminate.
A proposed correction would itself break a different invariant
The proposal would be blocked before it reaches an approver, and both invariants shown side by side with the conflict stated, so the underlying data problem is fixed rather than swapped for another.
The Guard is behind, degraded or has not run
The dashboard would show the timestamp of the last successful sweep as a first-class field. The absence of exceptions will never be rendered as a green state. Silence and health look different.
A migration or bulk load floods the queue with thousands of findings
Findings would group by cause, the queue would rate-limit, and a single portfolio-level summary would be issued instead of a per-loan storm. An unusable queue is an ignored queue.
Why it sits where it does
A first-wave build, and the capability that makes every other number on this list defensible. It is deliberately paired with the order-independent interest engine rebuild: the rebuild fixes correctness once, and the Guard is what would prove it stayed fixed. It also has to exist before Ask-Your-Portfolio, because a natural-language answer is only as trustworthy as the balance behind it, and quoting a number to a board without a continuous integrity check behind it is worse than making them wait for the export.
What has to exist first
- Deterministic, order-independent interest engine with an interest-not-below-zero invariant
- reproducible, cached outstanding computation. Already in place: the append-only audit trail, which records an actor and a timestamp on every ledger event
What buyers actually ask about this
The invariant checks would be arithmetic performed inside your deployment against your event log, with no external call involved, and a lender will be able to run that tier alone and add the pattern tier later. Where the pattern layer runs is a hosting decision settled in the deployment agreement, and the full position is set out on the security page.
It will be able to flag it. It will not be able to reverse it. A finding would be a proposal that sits in a queue until whoever works the queue dispositions it, and any correction that moves a balance would additionally need a separate approval permission. False positives cost review time, which is why the design remembers dispositions and groups by cause. They do not cost a wrong reversal.
The lender's own controls and audit remain the authority: the Guard is designed as an additional continuous check, not a replacement for them, and we will not market it as one. What we commit to is that the invariant tier will be deterministic and complete for the identities you have configured, and that the last successful run time will always be visible so a silent failure is not mistaken for a clean book.
Yes. Sweep frequency would be configuration: continuous on every event, nightly, or on demand at close. Individual invariants could be set to advisory rather than blocking. Some lenders will want it hard-blocking from day one; a lender in the middle of a messy migration would normally want advisory first, then blocking after cut-over.
It stays in your deployment under the retention period you set, including rejected findings and their written reasons, because the rejections are frequently the most useful audit evidence. The Guard would learn your dispositions inside your own deployment. Nothing would be aggregated across customers, and each customer is a separate single-tenant deployment in any case.
It would be built primarily on rules and statistics derived from your own book inside your own deployment: your recovery cadence would define the duplicate window, your accrual calendar would define a missed run. Where a model component is used, it would be configured and tuned against your patterns as a design partner, and any behaviour it learns stays with you.
Other capabilities
Migration Copilot
Will read your legacy loan book, rebuild every timeline and reconcile every balance.
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