What stays in your tenant, and what is deleted

A mortgage file holds everything about a borrower: income, debts, account numbers, a Social Security number on most pages. Before a lender’s IT asks what a product does with a file, it asks where the file goes while it does it.

With Proxara the file goes nowhere. The product is installed inside the lender’s own Azure account, and every page of every file is read and worked there. This post is the longer answer: where the model runs, what is kept while a loan is worked, what is deleted when the work is done, and what is left.

Where the model runs

One open-weight model reads the documents. It runs on a single A100 in the lender’s own subscription, at a version pinned in the signed release, and it listens only inside its own container. It makes no outbound call. No page is sent to a public model service, and no third party’s model ever receives one.

The model’s job ends at reading. It turns each page into facts and points at the printed words each fact came from. Everything that decides something, the qualifying income, the ratios, the limits and the rules, is ordinary code running in the same place. From the first page to the result, the work happens on compute the lender owns.

The same package also runs on a GPU server a lender prepares inside its own firewall. The boundary does not move: the lender’s environment holds the page, the reader and the store.

What is kept while a loan is worked

A loan is worked in a session. It begins when the first document is dropped in and lasts while the loan is being worked. For that time the environment holds everything a result points at: the document copies and the page images, the extracted text and the word anchors, the loan’s state and facts, the findings, the calculation and the history of every attempt.

That is what lets a figure on the page open its source and draw the crop of the words behind it. It is kept for that reason and no other.

It sits on encrypted Azure Files shares in the lender’s own storage account, reached only over TLS. The working files have their own share and the results have another. Every secret the product uses is a versioned entry in the lender’s own Key Vault, with purge protection on. A session is identified by a token, never by a borrower’s name.

When the work is done

A session ends when the AUS returns an acceptable result, when every structure for the file has closed, or when the loan officer closes the loan. It also ends by itself when the loan sits idle past the inactivity period the lender set at installation.

When it ends, the working material is deleted: the documents, the page images, the text, the facts and the state. The deletion is logged. Before a loan officer closes a loan, the page shows what will be deleted and what will remain, and the close has to be confirmed.

What stays, and whose it is

Two things remain. The first is the result. At each result the product writes a PDF package: the qualifying income with its calculation, the readiness lines, the findings, the structures, the evidence crops and the citations, and, where a structure was chosen, that structure as a MISMO 3.4 file. The packages stand in the lender’s own store under the lender’s own retention. They are the lender’s records, like any other document in the loan file.

The second is one de-identified event for each rerun: the loan’s state before it, the rule versions, the change made and its values, and what the AUS said after. The events answer one question for the lender’s own shop: when several structures are valid, which to try first.

Every package also records what made it: the version of the model that read the documents, the rule versions the calculation ran under, the source page for every material fact and the calculation trace. Anyone reviewing the loan a year later can see what was read, by which model, under which rules, and what was kept.

What Proxara never receives

No file, page or value goes to Proxara, to a model service or to any new party. Proxara holds no credential, no role and no standing access in the lender’s tenant. It is not the host, so the product has no sub-processor, and Proxara keeps no copy of anything.

What comes the other way is signed: releases of the application, the model and the rules, each verified inside the environment before it is used. The rules come from a signed feed the application reads every hour with a read-only token. Nothing about a loan travels back along that path.

There is no telemetry, no heartbeat and no crash reporting. When support needs to see something, the lender’s IT exports a diagnostics bundle of versions, timings, rule identifiers, error classes and health state. It carries no borrower data, and nobody at Proxara can read it unless the lender sends it.

What the logs hold

Operational output never contains document text, identifiers or borrower facts. It carries session tokens, component versions, timings, rule identifiers and error classes: enough to say what ran and whether it worked, and nothing about whose loan it was. The environment is created with no log destination of its own, so no container log is kept.

What is recorded on purpose is access. Opening a loan’s documents is logged by person, and every export and every deletion is logged, in the lender’s environment. The FTC Safeguards Rule is the floor this is built to: encryption at rest and in transit, access through the lender’s own sign-in and roles, access logged per document and per person, and working files deleted when a loan closes.

How to check it

None of this has to be taken on trust. The resources are declared as Bicep, so a security team can read every one before anything runs. The image is signed and can be verified with Cosign and the publisher key the lender received. After the install, the team can confirm that no identity outside the tenant holds a role, and that the compute, the storage and the vault all sit in the lender’s own resource group.

The borrower’s file stays where the lender already keeps its files. The product comes to the file, does its work there, and leaves the result behind.