The Escrow Analysis Agent

Escrow analysis is one of those servicing processes that looks clerical from the outside and is anything but. Once every twelve months, for every escrowed loan on the book, a servicer has to project the coming year's taxes and insurance, compare that projection against what is actually sitting in the borrower's escrow account, work out the shortage or surplus, re-cut the monthly payment, and send the borrower a statement that explains all of it. Get it wrong and you have either taken money you were not entitled to or under-collected and created a shortage that compounds into next year.

It is annual, it is deadline-bound, and it is done at portfolio scale. That combination is exactly where agents earn their keep.

Why this is harder than it looks

The naive version of this — "the numbers are in the system, just run the calculation" — falls apart on contact with real loan data.

The inputs are not clean. Next year's tax bill is not a field in the servicing system. It arrives as a document from a taxing authority, or through a tax service vendor, or it does not arrive at all and has to be estimated from prior years. Hazard insurance premiums change when a policy renews, and the declaration page is a PDF. Flood, wind, HOA, and PMI each have their own cadence and their own source.

Disbursement timing matters as much as amounts. An escrow projection is not an annual total divided by twelve. It is a month-by-month model of when money goes out versus when it comes in, because the low point of that curve is what determines the required cushion.

The rules are not universal. Cushion limits, shortage-spread options, and statement content are constrained by regulation and then further constrained by investor requirements and state-level overlays. A loan in one state with one investor does not behave like the loan next to it.

And the output is a borrower communication. The statement is the part the borrower actually reads, and it is the part that generates the call to the contact centre when the payment jumps.

What the agent actually does

We build this as a graph, not as a prompt. Each step is a node with a defined input, a defined output, and a place to stop.

Collect. The agent gathers everything bearing on the coming year: tax records from the tax service feed, insurance policies and renewal declarations, the loan's disbursement history, current escrow balance, and any pending changes already logged. Documents are classified and extracted here — a declarations page becomes structured premium, effective date, and carrier fields.

Reconcile. Extracted values are checked against the system of record. This is where the agent earns most of its value, because it is looking for disagreement: a premium that jumped 40% year over year, a tax line that vanished, two policies that appear to cover the same peril, a disbursement that posted twice. Anything that does not reconcile becomes an exception with a reason attached.

Project. With inputs settled, the agent builds the month-by-month disbursement schedule for the coming cycle, computes the required cushion under the applicable rules, and finds the projected low point.

Compute. Shortage or surplus, the new escrow portion of the payment, and the resulting total payment. Where a shortage can be spread, the agent computes the options rather than picking one.

Explain. The agent drafts the borrower-facing narrative: what changed, which line items moved, and why the payment is different. This is generated from the computed figures, not written freehand — every number in the narrative traces back to a value the reconcile step validated.

Route. Clean loans flow to statement generation. Loans with exceptions go to an analyst with the exception, the evidence, and the agent's proposed resolution already assembled.

Where the human stays

We are deliberate about this line, because escrow analysis directly changes what a borrower pays.

The agent does not decide to override a tax amount it could not verify. It does not select a shortage-spread option on the borrower's behalf. It does not release a statement on a loan that failed reconciliation. And it does not touch loans in states or investor programs that have been flagged for manual handling.

What it does is make the human's job small. Instead of an analyst working a queue of thousands of loans looking for the problems, they work a queue of exceptions where the problem is already identified, the supporting documents are already attached, and a proposed answer is already drafted. The reviewer's job becomes judgement, which is what they are good at, rather than search, which they are not.

Every action is logged — inputs used, values extracted with their source document and confidence, rules applied, the figure produced, and who approved what. In a regulated servicing environment the audit trail is not a nice-to-have; if you cannot reconstruct how a payment change was derived, the automation is a liability rather than an asset.

The integration is most of the work

The interesting engineering in this build is rarely the model. It is that escrow analysis touches the servicing platform, the tax service vendor, the insurance tracking system, the document repository, the statement composition and print/mail vendor, and the customer contact platform that will field the resulting calls.

An agent that reasons beautifully over one of those and cannot see the others produces confident, wrong answers. Most of our time on builds like this goes into giving the agent one coherent picture — and into the plumbing that lets it write back safely, with idempotency and reversibility, so a retry does not double-post a disbursement.

How we know it works

We do not ship this against a vibe check. The metrics that matter are straight-through rate (what share of loans complete with no human touch), exception precision (when the agent flags something, is it actually wrong), extraction accuracy against a labelled document set, and downstream call volume after statements land — because a statement that is technically correct but badly explained shows up as contact centre load two weeks later.

We backtest against a completed prior cycle before going anywhere near a live one. If the agent cannot reproduce last year's known-good outcomes, it is not ready for this year's.

What this is not

This is not an agent that replaces an escrow analyst. It is an agent that removes the mechanical 90% so the analyst spends their year on the 10% that needs a person — the odd jurisdictions, the disputed assessments, the loans where something genuinely does not add up.

That framing matters, because the failure mode we see most often in this domain is a team that automates the judgement and keeps the paperwork. We build it the other way around.

---

Mortgage is the domain we work in most deeply — origination through servicing, default, investor reporting and claims. If you have a servicing process that looks like this one, describe it in the console or run /estimate and we will scope it.