Skip to content
Skip to content
Ava 1.0

A governance layer that sits between a client file and the AI doing the work.

Ava 1.0 removes client identity from a financial document, hands the de-identified derivative to an enterprise AI account where a licensed professional does the analysis they would do anyway, and restores the real names into the finished work. A validation report confirms what came back.

It is not an AI product. No model runs inside Ava. It does not reason about credit, score a borrower, or form a view on a deal. It removes the one constraint that stops skilled people from using tools that already exist.

Borrower 2419887 Ontario Inc. [[BORROWER_1]]
Guarantor Peter Vasilenko [[GUARANTOR_1]]
SIN 046 454 286 [[SIN_1]]
Loan amount $4,250,000 $4,250,000
DSCR 1.42x 1.42x

Identity replaced. Financial content untouched.

The boundary

Raw client documents never leave infrastructure the firm controls. Only de-identified derivatives cross the border.

That sentence is the whole architecture. Every design decision either serves it or is out of scope. The token map, the file that maps a token back to a real name, lives beside the client documents it describes, inside the firm, and is never transmitted anywhere.

One installation per entity. The entity is fixed when Ava is installed and displayed on screen, not chosen at runtime, because a control that can be set wrongly will eventually be set wrongly. Two regulated businesses under the same roof get two installations and two separate vaults. The same borrower carries different tokens in each. That is mildly inconvenient and it is correct.

Custody

Ava 1.0 is software that runs on the professional’s own machine.

Nothing hosted. No database. No vendor receiving client content, including us. The deal vault and the token map sit in a folder beside the client documents they describe, on hardware the firm already owns and already secures.

This converts a promise into a fact. A hosted tool’s privacy claim is a contract term. A local tool’s privacy claim is a statement about network topology. Nothing transmitted means nothing to breach at a vendor, nothing to retain, and nothing to attest to.

It also keeps AVA Credit out of the trust chain entirely. Were Ava hosted, the moment a firm’s institutional counterparty ran a third-party review, we would become the third party: vendor questionnaires, sub-processor disclosure, breach notification paths. A five-lawyer practice can install software. It cannot run a vendor onboarding process.

And the token map has nowhere else to live. It is the one file that resolves a token to a real name, so an architecture where it never travels is the only architecture where “never transmitted” is structurally true rather than a policy someone could change.

Three tiers. What varies is where the key sits.

These are not stages a firm graduates through. They are three answers to one governance question, and the right answer depends on who should hold the key rather than on how large the firm is.

Ava 1.0

Local, single operator

Software on the professional’s own machine. The current release, in use inside our own lending businesses before it goes anywhere else.

Key held by the operator
Ava 2.0

Local, managed by the firm

The same artifact running inside a customer firm’s own tenant, administered centrally across a team. Customer data never leaves customer control.

Key held by the firm
Ava 3.0

Hosted, governed, Canadian

A separate product for firms with no internal technology function, holding the deal record, the audit trail and the identity boundary in one governed place. Convenience is the reason to choose it. Completeness is the better one.

Key held under contract

The invariant holds across all three: what identifies a client and what makes a deal analyzable are separable, and the key is separable from the analysis. Custody by design, at whatever distance the firm needs.

Sequence

Four steps, one boundary, crossed twice.

01 Seed

Name the parties you already know

The operator enters the borrower, guarantors, property and any other known party before uploading. Seeded names are always tokenized regardless of what detection thinks, which is the single largest accuracy gain available.

02 Scrub

Identity out, financial content preserved

Currency, rates, ratios, dates and fiscal periods are located and protected first, so nothing in the arithmetic can be overwritten. Detection then runs over what remains, and every identifier becomes a consistent token.

03 Work

The professional uses the AI account normally

The de-identified file goes into an enterprise AI account. Full use of every feature that interface provides. Ava is not in the room for this part and has no view of it.

04 Restore

Real names back in, and a report on what happened

Tokens are substituted back to canonical names. The validation report records what was restored, which tokens the model dropped, and any token-shaped string the model invented that does not exist in the map. Problems are reported rather than shipped.

In practice

What identifies a client and what makes a deal analyzable are two different things in the same document.

Names, addresses, social insurance numbers, business numbers and account details identify. Loan amounts, appraised values, coverage ratios, rates and three years of margins are what make the file analyzable. Ava removes the first and leaves the second exactly as written, so the model still sees the whole financial picture. It simply does not know whose deal it is.

As received
Borrower 2419887 Ontario Inc. Trade name Northline Fabricating Guarantor Peter Vasilenko SIN 046 454 286 Property 118 Passmore Avenue Loan amount $4,250,000 Appraised $6,200,000 LTV 68.5% DSCR 1.42x Closing March 14, 2026
As sent to the enterprise model
Borrower [[BORROWER_1]] Trade name [[BORROWER_2]] Guarantor [[GUARANTOR_1]] SIN [[SIN_1]] Property [[PROPERTY_1]] Loan amount $4,250,000 Appraised $6,200,000 LTV 68.5% DSCR 1.42x Closing March 14, 2026

Synthetic example

Tokens are consistent across a deal and across sessions. A file assembled over four days keeps the same borrower token throughout, so the analysis holds together instead of fragmenting into strangers.

Intake

An unread page is an unscrubbed page.

Client documents arrive in whatever state the client sent them. Word files, spreadsheets, clean PDFs, and PDFs that are photographs of paper. Ava identifies the format from the file itself rather than trusting the extension, since files get renamed.

Scanned pages are the security problem, not the convenience problem. Text that cannot be read cannot be scrubbed, and a signature block sitting in an image would pass straight through a scrubber that only sees the text layer. Ava measures every page for both text density and image coverage. If a page looks scanned or carries an unread image region, the document is routed to a document reader before anything else happens. Where that reader is unavailable, the document is refused rather than partially scrubbed.

Pairing

Ava is not an alternative to an enterprise AI agreement. It is what you send through one.

Two controls, doing two different jobs. A team or enterprise agreement with a major AI provider governs the vendor: security attestation, contractual terms on retention and model training, administrative control over accounts. Ava governs the content. The first is a promise about handling. The second is a fact about what was sent.

Control one

The enterprise agreement Covers the vendor. Security attestation, terms on retention and model training, administrative control, and the audit surface a firm needs when it is asked about third-party risk.

Control two

Ava Covers the content. Direct identifiers are removed before the document crosses the boundary, and the key that maps them back never leaves the firm at all.

Residency is the clearest case. An enterprise agreement is a promise about handling, not a change of address: the servers are somewhere else, usually the United States, and no contract moves them. A large institution avoids the question by building its own system on infrastructure it controls. A ten-person firm cannot. Ava does not stop the data crossing the border. It changes what crosses.

Because Ava sits in front of the boundary rather than behind it, it does not care which model is on the other side. Whatever proves best next year is a configuration change, not a rebuild.

Govern the data, not the infrastructure.

Capability and custody are different axes

Limits

Ava removes direct identifiers. It does not anonymize a deal.

This is the most important paragraph on the page, so it is stated plainly. A $4.25M first mortgage on an industrial property in Scarborough at 68.5% LTV closing in March stays recognizable to anyone active in that market with every name stripped out. Amount, asset type, location, timing and structure are collectively identifying, and no de-identification tool changes that.

What is delivered is real and worth having. No client name, address, social insurance number, business number, account number or contact detail is transmitted to an external AI provider or left sitting in a chat log. What is not delivered is a file that an informed reader could not trace back to a deal.

Two further limits, stated for the same reason. An unread page is an unscrubbed page. And where one party appears under several spellings, all of them map to one token and restore writes back the first form encountered, with the variants recorded in the map.

Operating on an accurate description of a tool is worth more than operating on a flattering one.

Why now

The deadline is not arriving to an empty field. It is arriving to a habit.

OSFI’s Guideline E-23 on model risk management takes effect on 1 May 2027, and it defines a model broadly enough to include AI tools that materially affect decisions. It binds federally regulated institutions directly. Independent firms are reached a different way: through B-10 third-party risk, when the institutions they serve begin asking their channel what AI touches client data, and through the privacy and professional obligations that already apply.

Those questions arrive before the deadline, not after. The firms that answer them well will not be the ones that waited, and they will not be the ones that told their people to stop. They will be the ones that governed the data instead of the behaviour.

Status

Built, running, and not finished.

Ava 1.0 is in active build. The engine works end to end: intake, protected spans, detection, tokenization, restore and validation. It is being run against our own files first, inside our own lending businesses, before it goes anywhere else.

The gate before wider use is accuracy at scale on person detection, measured against a validation corpus rather than asserted. Financial integrity through a full round trip is covered by a test that must pass completely before any client material is scrubbed. Open items are tracked in the technical documentation rather than left implicit, and the honest ones stay on the list until they are closed.

Release
Ava 1.0 — governance layer
Deployment
Local install. Nothing hosted.
Model inside
None
Scope
In use within our own businesses first
Demonstration

A click-through replica of the application as it runs.

No detection engine and no model run in the replica. Every result is scripted from a synthetic deal file, and the interface is faithful to the build as it stands.

The Restore tab deliberately shows a failure. The model invents a token that was never issued, and the validation report catches it and refuses to guess. That is the part worth watching, because a tool that quietly cleaned it up would hide the fact that the model asserted something about a party who does not exist.

Open the demonstration

Questions about deployment inside a practice with a confidentiality obligation are welcome.

info@avacredit.ca
AVA Credit Inc.
AVA Credit Inc.
AI Credit® is a registered trademark of AVA Credit Inc.  ·  Privacy