Legal

Trust & security

What a third-party risk team needs, in the order they ask for it, and, where Sweet has not yet given us an answer, the question itself rather than a guess.

How to read this page

Two kinds of statement appear below, and they are marked differently on purpose.

Plain text is a claim that can be checked against this website's own source code, and the file to check is named next to it.
A Confirm marker is an open question for Sweet. It is not a fact, it is not a commitment, and it is deliberately visible rather than filled in with something plausible.

Attestations and audits

Sweet maintains a SOC 2 Type II attestation. The report is available to prospective customers under NDA.

Report type: SOC 2 Type II
Auditor: Confirmthe CPA firm that performed the examination.
Period covered: Confirmthe observation period the current Type II report covers, as start and end dates.
Renewal: Confirmthe renewal cadence, and the end date of the period currently in progress.
Criteria in scope: Confirmwhich Trust Services Criteria are in scope — Security only, or Security plus Availability / Confidentiality / Processing Integrity / Privacy. 'SOC 2' with no criteria named means Security only to anyone reading carefully.
Penetration testing: Confirmtesting cadence, the firm, and whether a summary letter is available to prospects.

Why this page never says “SOC 2 certified”

SOC 2 is an attestation engagement. An independent CPA firm examines a service organisation's controls and issues a report containing an opinion. There is no certificate, no certifying body and no pass mark, so no company is “SOC 2 certified”, and nothing is “SOC 2 compliant”, because SOC 2 is not a regime with requirements to comply with. Type II means the report covers how controls operated over a period, which is why the period and the auditor are part of the claim rather than decoration on it.

The correct forms are SOC 2 Type II and SOC 2 Type II attestation. Elsewhere on this site the same attestation is currently written seven different ways, including two that say “certified”. Those are being corrected; the canonical wording lives in src/data/trust.json so there is one of it.

The figures on this site

Four numbers carry most of the proof on this site. A number with no as-of date and no definition is not evidence, so each one is published here with both, or, until Sweet supplies them, with the question showing.

~$10B

of originations and servicing moved through Sweet

Confirmas-of date for the ~$10B figure. Adam supplied the number on 2026-08-11 as "approaching $10B in originations and servicing"; an undated cumulative figure only ever gets older.

>1.5×

increase in conversion for lenders running on Sweet

Confirmthe period this was measured over.

~2×

loan-production efficiency

Confirmthe period this was measured over.

65%

Confirmof whom? See note 3.

Confirmas-of date.

SOC 2

Type II attestation · report available under NDA

Confirmthe period the current SOC 2 report covers — the same date this page states in its SOC 2 register.

~$10B — Cumulative original loan principal that has moved through origination or servicing on Sweet, counted once per loan, since launch. Source: Sweet platform data ↩
>1.5× — Application-to-funded conversion on Sweet compared with the lender's own prior process. Confirmis the denominator applications received, or applications started? And is it measured per lender or pooled? Source: Sweet — attribute list supplied by Adam, 2026-08-11 ↩
~2× — Confirmtwo-times WHAT, against WHICH baseline? Loans closed per officer per month? Days to close? The figure appears nowhere else in the repository — no baseline, no customer, no method — so it currently cannot be defended in a single follow-up question. Source: Confirmlender-reported or measured by Sweet? Name the institution, or describe it without naming it — 'a $2.4B community bank in the upper Midwest' is worth more than a bare multiplier. ↩
65% — Confirmthe current label reads '65% of clients bank mobile-only'. Sweet's clients are BANKS, so the site currently states that 65% of banks are mobile-only. If this is about borrowers, say borrowers, and say whose. Then: mobile-only over what window — a month, a quarter, ever? Across all client institutions or one? Source: Confirmwhich system this is read from, across which institutions, and who signs it off. ↩
SOC 2 — An attestation report issued by an independent CPA firm on the operating effectiveness of Sweet's controls over a defined period. Not a certification; there is no such thing as SOC 2 certification. Source: Confirmthe name of the CPA firm that issued the report. ↩

Data isolation

Unresolved — this site currently gives three answers

The compliance FAQ says each institution's data sits in a dedicated, segregated database and that the platform uses multi-tenant segregation. Both are architectures banks buy; they cannot both describe the same system. All three statements are emitted inside the FAQ's structured data, so an assistant asked how Sweet isolates bank data reads contradictory facts from the same authoritative source.

Confirmengineering must state the tenancy model in ONE sentence, and that sentence becomes the only version anywhere on the site. Option A — each institution's data is held in a dedicated database instance, not pooled with other customers. Option B — data is held in a multi-tenant environment with per-institution logical segregation enforced at the data layer. Pick one, or write the true third thing.

This page will carry that sentence and nothing else once it exists. Choosing the wording here would only move the contradiction; the answer is an engineering fact.

Infrastructure and data handling

Hosting: Confirmcloud provider and regions for the production platform. The compliance FAQ says AWS; that is a marketing string in a JSON file, not a verified fact, and a bank will ask for regions.
Data residency: Confirmthe country or countries customer data is stored and processed in, and whether any processing happens outside them.
Encryption in transit: ConfirmTLS version and minimum cipher policy.
Encryption at rest: Confirmalgorithm and key management — who holds the keys, and whether customer-managed keys are offered.
Access control: ConfirmSSO/SAML support, MFA enforcement, and how Sweet staff access to customer environments is granted, logged and reviewed.
Backups: Confirmbackup frequency, retention and restore testing cadence.
Penetration testing: Confirmtesting cadence, the firm, and whether a summary letter is available to prospects.
Incident notification: Confirmthe contractual notification window for a confirmed security incident affecting customer data.
Business continuity: ConfirmRTO and RPO targets, and the date of the last tested failover.

AI governance

A human is always in the loop. Sweet's AI extracts, checks completeness, validates and flags. It does not approve, decline, price or decision a loan on its own. Every credit decision is made by a person at the lending institution.

What the AI does

Reads submitted documents, including handwritten ones, and extracts the data on them.
Checks a file for completeness and validity against the lender's own requirements.
Raises flags for a human to look at, with the underlying document one click away.

What it does not do

It does not approve or decline an application.
It does not set pricing or eligibility.
It does not act on a borrower's account without a person authorising it.

Model providers: Confirmwhich models are used, self-hosted or via an API, and whether any customer data reaches a third-party model provider. If it does: name them here and on the sub-processor list, and state whether that provider is contractually barred from training on it.
Customer data in training: Confirmis customer or borrower data ever used to train or fine-tune a model? A yes/no with no qualifiers is the only answer a bank will accept.
Automatic clearing of flags: Confirmis there any workflow in which a Sweet-raised flag can clear itself without a person seeing it?

Sub-processors

The list below is not yet Sweet's sub-processor list. It is the set of vendors this website's own copy already names as part of the product, which is where the real list starts. Each one needs a confirmed role, purpose and location before this page can be sent to anyone.

Vendors named in Sweet's published copy, and what still needs confirming about each
Vendor	Purpose claimed on this site	Outstanding
AWS	Hosting	Confirmentity, regions, and whether this is the only hosting provider.
Plaid	Financial data connectivity	Confirmis Plaid a sub-processor of Sweet, or contracted directly by the lender?
eOriginal / Wolters Kluwer	E-vaulting of authoritative copies	Confirmintegration only, or does Sweet transmit borrower data to them?
Web3Forms	Delivery of enquiries submitted on this website (inert in this build: no key configured, so no form renders)	Confirmstorage location, retention and a DPA. Unlike the three above, this one is verifiable from this repository: the lead capture form on this site posts to api.web3forms.com. It is the only vendor on this list that will hold personal data the moment the form goes live.

Confirmthe rest of the real list — model/AI providers, email delivery, error monitoring, support tooling, payroll-adjacent systems that touch customer data. An AI product with no AI vendor on its sub-processor list is the question a risk team will ask first.

Data retention

Enquiries from this website: Confirmhow long an enquiry submitted through this site is kept, and where.
Customer data during the contract: Confirmretention during the contract, and the deletion or return window after termination.
Backups after deletion: Confirmhow long deleted data persists in backups before it ages out.
Application and audit logs: Confirmretention for application, access and audit logs.

This website

Separate from the platform, and the one part of this page that makes positive claims without a marker, because these are properties of the code that serves you this page, and each one names the file it can be checked in.

This site sets no cookies.

No document.cookie write exists anywhere in src/. The measurement layer in src/layouts/Base.astro is explicitly cookieless.
Loading a page on this site makes no third-party requests. Every font, image, script and style comes from this domain.

Fonts are self-hosted in public/fonts/ (the Google Fonts import was removed); there is no analytics vendor tag, no pixel and no embed in the build. The one thing that can leave this domain is a form you deliberately submit. See below.
No analytics data is collected or transmitted unless and until Sweet configures an endpoint of its own.

The event layer in src/layouts/Base.astro sends nothing when PUBLIC_ANALYTICS_ENDPOINT is unset, and additionally requires an explicit consent signal before it sends anything even when it is set.
The site is static. Pages are pre-rendered files with no server-side session and no user account.

Astro static build, astro.config.mjs.

Form backend: The enquiry form posts to Web3Forms (https://api.web3forms.com/submit), the only third party this website sends anything to, and it is inert in this build: with no access key configured, no form is rendered at all. ConfirmWeb3Forms' own data handling — where submissions are stored, for how long, under which jurisdiction, and whether a DPA is in place. It receives the name, work email, institution and role of every prospect who contacts Sweet.
Server logs: Confirmthe hosting provider's own request logs — what is captured (IP, user agent), how long it is kept, and who can read it. Static hosting still logs.
If analytics are switched on: Confirmif Sweet turns the measurement layer on, name the endpoint, what is stored, for how long, and whether a consent banner is required in the jurisdictions Sweet sells into. Until then this paragraph describes something that is not happening.

Full detail of what this site does and does not collect is on the privacy page.

Reporting a vulnerability

If you believe you have found a security issue in this website or in the Sweet platform, we want to hear about it before anyone else does.

Security contact: Confirmsecurity contact address for vulnerability reports.
Disclosure process: Confirmthe address security researchers should report to, and the response commitment.

The full control set, the SOC 2 Type II report and completed questionnaires are available to prospective customers under NDA. Ask the person you are already speaking to, or use the contact form.

Send us your vendor questionnaire.

We would rather answer it early than late. Ask for the security pack and the SOC 2 Type II report under NDA.

Talk to the team Read the FAQ