Security, data handling and the things we do not claim

01 Principles

Four commitments shape every decision below. They are worth stating first because they explain the rest.

• Least access. Every connector, every person and every process gets the narrowest access that lets it do its job, and nothing beyond that.
• Your data is yours. We do not sell it, pool it into a benchmarking product, or use it to improve a service for anyone other than you.
• Everything is attributable. Any action taken on your behalf can be traced to a trigger, a policy and a point in time.
• No overstatement. We describe what we actually do. Where a practice is still maturing, we say that rather than implying otherwise.

02 Where data lives

Fashti runs on established cloud infrastructure in the United States. Your operational data is held in isolated storage per customer, so one customer's records are never served from a shared pool that another customer's queries can reach.

The authoritative copies of your portfolio records remain in your own systems. What Fashti holds is a working view assembled from them, together with the conversations it has conducted and the audit trail of what it did. That distinction is deliberate, and it is the reason stopping the service does not leave you without your records.

Backups are encrypted, held in the same region, and tested by restoration rather than assumed to work.

03 Access control

Connector access

Each connection into your systems is authorised by your administrator through that system's own permission flow, and is scoped to the narrowest set of permissions that supports the agreed workflows. Connectors begin with read access only. Write access is granted per system, after the read side has been verified against your expectations, and can be revoked by you at any time from within that system.

Your team's access

Access to Fashti is per person, never shared. Roles separate those who can view the exception queue and reporting from those who can change policy, approve spending above a threshold or alter connector permissions. Changes to permissions are logged and visible to your administrators.

Our access

Our staff do not have standing access to your operational data. Access for support or investigation is time limited, requires a reason to be recorded, and is logged. Where a problem can be diagnosed without reading your data, it is.

04 Encryption

Data is encrypted in transit using current transport security, and encrypted at rest in storage and in backups. Credentials and connector tokens are held in a dedicated secret store rather than in application configuration, and are rotated on a schedule and immediately on any suspicion of exposure.

We do not transmit your operational data over unencrypted channels, and we do not ask your team to send credentials by email. If anyone appears to ask you for a password on our behalf, it is not us.

05 What language models are allowed to see

Fashti uses large language models to understand inbound messages and to draft replies. This is the part of the system customers ask about most, so it is worth being precise.

• Your data is not used to train models. We use commercial model providers under terms that exclude training on customer content, and we do not train or fine tune models on your operational data for any other customer's benefit.
• Only the necessary context is sent. A model receives the message being handled and the specific portfolio context required to answer it. It does not receive your full database, your ledger or unrelated tenancies.
• Sensitive fields are minimised. Identification documents, bank details and payment credentials are not placed into model context. Where a document must be checked, the check is performed without exposing the underlying file to a general purpose model.
• Facts come from your systems. Rents, dates, availability, balances and policy answers are read from the portfolio model and inserted into replies. The model composes the wording; it does not supply the facts.
• Policy is enforced outside the model. Whether an action is permitted is decided by the policy engine, not by the model's judgement. A model cannot talk its way past a threshold you have set.

06 Resident and applicant data

Most of the personal information Fashti touches belongs to your residents and applicants rather than to your staff. For that data we act on your instructions, as a processor acting for you, and the obligations that come with it are taken seriously.

• Residents and applicants are told they are speaking with an assistant, and can ask for a person at any point.
• Protected characteristics are not used as qualification criteria, and conversations that drift towards them are escalated rather than handled automatically.
• Identification and income documents are collected through your existing storage and signature tools, not held in a parallel repository.
• Requests from individuals to access, correct or delete their information are routed to you, since the relationship and the legal obligation are yours. We support you in fulfilling them.

How personal information is handled more generally is set out in the privacy policy.

07 Retention and deletion

Retention periods are set in your agreement rather than chosen by us, because the right period depends on your jurisdiction and your own obligations. By default, operational records and conversation histories are retained for the life of the engagement and then deleted on the schedule agreed, with the audit trail retained for the longer period you specify where regulation requires it.

On termination, we provide a structured export of everything Fashti holds, and delete our copies on the agreed schedule. Records already written into your own systems are unaffected, because they were never ours to remove.

08 Reliability and how it fails

How a system behaves when something breaks matters more than how it behaves when everything works.

• Degraded, not wrong. If a connector cannot reach one of your systems, the workflows that depend on it pause rather than acting on stale information.
• Visible, not silent. Your team is told which workflows are paused and why, rather than discovering the gap later from a resident.
• Queued, not dropped. Inbound messages received during an interruption are queued and processed in order once service resumes, with timestamps preserved.
• Escalated when urgent. Anything matching an emergency category is routed to your on call arrangement even when automated handling is unavailable.

09 Our own people and suppliers

Everyone at Fashti with any possibility of access to customer data is subject to confidentiality obligations and background checks appropriate to the role. Devices used for work are encrypted, access requires multi factor authentication, and access is removed on the day a person leaves.

We use a small number of suppliers to run the service, principally cloud infrastructure, model providers and communication services. The current list, with what each is used for and where it operates, is provided on request and before you sign, and we tell existing customers before adding a supplier that would process their data.

10 What we do not claim

Fashti is a young company and we would rather be straightforward about that than imply a maturity we have not yet reached.

• We do not claim to hold security certifications that we do not hold. If a certification matters to your procurement process, ask us directly and you will get a direct answer about what exists today and what is planned.
• We do not claim an uptime figure we have not measured over a meaningful period. Commitments that do exist are written into your agreement rather than advertised here.
• We do not claim that automated handling is error free. It is governed, logged and reversible, and the escalation rate is reported to you alongside the automation rate so you can see both.
• We do not claim to make you compliant. Fair housing, data protection and tenancy law obligations remain yours. Fashti is built to help you meet them and to evidence how a decision was reached, which is not the same thing.

Detailed security documentation, including our supplier list and architecture notes, is shared with prospective customers under a confidentiality agreement during assessment.

11 Reporting a problem

If you believe you have found a security vulnerability in anything we operate, please tell us at hello@fashti.co with enough detail to reproduce it. We will acknowledge within one business day and keep you informed until it is resolved.

We will not pursue legal action against anyone who reports a vulnerability in good faith, who avoids privacy violations and service disruption while investigating, and who gives us a reasonable opportunity to fix the issue before disclosing it publicly.