Everything on this page describes how Scout Notebook is built and what we're contractually bound to. Send it to your security team, your compliance officer, or your board — or bring them all to one call and we'll walk it together.
Anyone can save a prompt. The problem is what happens six months later, when a state changes its lending law and the saved prompt doesn't know.
Scout Notebook's banking logic is delivered to your machine, per transaction, from a control plane we maintain. When we determine a federal or state regulatory change affects that logic, the update ships within 30 days. Security patches run on a published severity clock. You don't manage it and you don't have to remember it. That's the subscription.
If Scout Notebook can't check in for seven days, it stops accepting new work until it can. Not a license sanction — work in front of you finishes, and it resumes automatically on reconnect.
It's there because we are not willing to let this tool review a file against rules that may have changed while it was offline.
We built a switch that turns our own product off rather than let it work from stale rules. That's the difference between a template you saved and intelligence somebody is accountable for.
Your documents live in the notebook — a .scoutnb file on your own hardware. That's where they stay. When a value needs reading, it goes from your machine straight to the model provider's API under our zero data retention arrangement — encrypted in transit, held in memory only for as long as the work takes, and gone. Nothing passes through us. We don't receive your documents, cache them, or store them. Not as a policy. As an architecture. There's nowhere for us to put them.
Borrower data is never at rest outside your workstation.
If your security team watches the traffic, this is everything they'll find. We'd rather name both than have them discover the second one.
The banking logic, versioned and maintained by us. Ships down as a local catalog.
The catalog lands in the app, the way any software update lands in any application you run. Your .scoutnb files — the documents, the borrower data, the findings — sit on your disk and are not part of this conversation in either direction.
There are two ways to send a document to a model. You can upload it first and then reference it — simpler to build, and the file is written to storage before any work begins. Or you can carry the document inside the request itself, so it exists only in memory for the moment the work takes.
We do the second one, deliberately. The easier path leaves your borrower's file sitting on a disk somewhere; the one we chose leaves nothing behind to retain. It's also what makes the zero-data-retention arrangement meaningful rather than decorative — there's no stored copy for it to apply to.
Notice what isn't on either diagram: your documents reaching us. We talk to your machine constantly — that's how the banking logic stays current — but the conversation only runs one way for content. Instructions come down. Nothing of yours goes up.
What does come back to Scout HQ is operational telemetry: transaction counts and durations, aggregated confidence distributions, categorical error codes, and version and license identifiers. No document content, no names, no account numbers, no loan amounts. The schema is published, it cannot carry content by construction, and we give 60 days' notice before it changes. Inference is a separate connection entirely, and it goes from your machine to the provider without passing through us.
Point your standard network monitoring at it. You should see exactly two destinations — Scout HQ and the inference endpoint — and no third one. We've agreed in writing not to take countermeasures against inspection, because the traffic tells the story better than we can.
The risk with AI on a loan file was never that it can't read. It's that it reads confidently and wrongly — and nothing in the output tells you it happened.
A loan agreement carries half a dozen dollar figures within an inch of each other. Amount financed, finance charge, total of payments, total sale price. Ask a general-purpose tool for “the total” and it will hand you one, with complete confidence. It may be the wrong one, and you'd have no way to know.
That's the difference between something that demos well and something you can put in front of an examiner. It's also most of what we've spent our time building.
Any model can read a document. The engineering is in knowing when it read it wrong.
Most tools give you a finding or silence. Silence is where the trouble hides.
Only a value contradicted by its own source document is an assertion that something is wrong. Uncertainty is reported as uncertainty. Collapsing those two is how automated review ends up either falsely confident or so noisy that reviewers stop reading it.
Every review grades its own reading. Alongside the findings, each run reports how many values it looked for, how many it found, how many it recovered on a second attempt, how many were confirmed against the page, how many were contradicted, and how many it simply couldn't settle. You see the quality of the read before you decide how much to trust the result — and where the tool can't prove something, it says so rather than guessing.
Think of Scout as a second set of eyes. One that never has a Friday afternoon, never skips a page, and checks every file with the same rigor as the first one of the day.
It never extends credit, denies an application, prices a loan, sends an adverse-action notice, reports to a bureau, or closes an account. Those are decisions, and a qualified person makes each one — at the point of that decision, with the authority and the information to override anything Scout said. Review that happened somewhere else in the workflow doesn't count. That isn't our marketing position; it's a term in the agreement.
You still make the call. Scout makes sure nothing gets past both of you.
Please do. SOC 2 Type II, penetration test summaries, completed SIG and CAIQ questionnaires, a named sub-processor list, and 72-hour incident notification — annually and on request. You and your regulators can audit our compliance with any of it.
We'd rather win that review than avoid it.
Good. Neither do we. Scout flags what needs attention; your reviewer decides. Nothing is auto-resolved, and the agreement requires human judgment at the point of every consequential action.
Every value comes from one named source — a specific block on a specific document, with the look-alike figures beside it explicitly excluded. It gets checked against the page text, and anything unsettled is re-read from the page image. Neither check can change a value; they only attach evidence to it.
Then each review reports on its own reading: what was found, what was confirmed, what was contradicted by its own source, and what couldn't be settled either way. You see the quality of the read before you decide how much to trust the findings.
Examiners don't object to tools. They object to conclusions you can't show your work on. Every finding cites the source document, the specific requirement, and the basis for the flag — the same documentation your examiners expect from a human reviewer — and the audit trail records which version of the banking logic produced it.
The OCC, FDIC and NCUA have all issued guidance on AI and model use in financial services, and Scout is built to align with it.
There's a harder question underneath this one, and it's worth asking out loud: can you defend reviewing a ten percent sample when the technology exists to review the whole population?
Then you stop, on 30 days' notice, and we refund the unused portion of what you paid. It's in the agreement. We'd rather you try this than not, and we're not going to turn an examination finding into your problem.
Your documents are not in our systems — inference runs from your device straight to the model and never traverses our infrastructure. A breach of VisionFI reaches our control plane and our release infrastructure, not your borrowers.
Point your network monitoring at it and confirm. We've agreed in writing not to interfere with that inspection.
That's what you're subscribing to. We monitor federal and state change; when we determine something affects Scout's banking logic, the update ships through the control plane within 30 days and lands on each device at its next check-in. And if a device has been offline more than seven days, Scout stops taking new work until it's current.
The commitments on this page — the data path, the updates, the offline stop, the regulator exit — are terms in our subscription agreement, not marketing claims. Ask for the agreement and check any of them before you sign anything.