Privacy

When your organisation uploads a borrower's documents, your organisation remains the responsible party for the personal information in them. mako processes it on your instruction and for no other purpose.

The AI providers that read those documents are engaged by you, under your own account and your own agreement with them — not sub-contracted by us. That is a structural consequence of the bring-your-own-key design, and it is why we can tell you exactly who receives your data: the providers you connected, and nobody else.

• Account data — your email address, your name, and the organisation you belong to. Supabase Auth holds the credentials; we never see a password.
• Borrower data — whatever your analysts upload and enter: documents, extracted figures, assessments, notes and reports.
• An audit trail — who did what, and when. Every ingestion, every figure overridden, every sign-off.
• Usage counters — token and request counts per provider call, so your organisation can see and cap its own spend.

There is no analytics or advertising tooling on this site. No third-party script runs on this page.

Documents and their transcripts go to the providers your organisation configured, for as long as the call takes. Nothing else leaves the platform. Retention and training practices at each provider are governed by their own published terms — linked from your terms page — and are the agreement you are actually bound by:

Google Gemini · OpenAI · Anthropic Claude · DeepSeek · LlamaParse · Mistral OCR · Tavily · Exa · Brave Search

Records live in a Supabase Postgres database. Files live in a private storage bucket (underwriting-documents) that is never publicly readable — served only through a signed link that expires in five minutes.

Row-level security isolates every organisation at the database layer, not in application code. A member of another organisation cannot read your rows even by querying the database directly.

Provider keys are encrypted into Supabase Vault. The database keeps only the last four characters and a pointer to the encrypted secret. A key is never returned to the browser and never written to a log.

An admin can delete every borrower record the organisation holds, at any time, from Settings. That destroys borrower files, documents, extracted figures, assessments, reports and the stored files behind them.

The audit trail survives, anonymised: entries lose their link to the borrower and their details, keeping only who acted and when. An audit log that can be erased is not an audit log — and one that still names a deleted borrower is not a deletion.

The demonstration on the home page uploads nothing and stores nothing. It runs entirely in your browser on one fictional borrower that ships with the site. No document of yours is read, no request is made to an AI provider, and no account is required to run it.